December 2002 - U-Boot

[U-Boot-Users] "Standard" Practice for config of SanDisk compact pci memoru
by Jerry Walden 24 Dec '02

24 Dec '02

Greetings: Our hardware guy is tells me that the SanDisk can be placed in one of three modes: 1) PC Card Memory Mode 2) PC Card I/O Mode 3) True IDE Mode The device is going on a custom ppc 405GPr board. He is also asking me how the device will be accessed 1) on bytes 2) on words 3) or both I am not much of a hardware person, so I am not even certain if the question I am asking makes sense. The main goal is to use u-boot to bootstrap and initialize the board, and to load the linux kernel/file system from the compact flash. Does anyone have a reference design for a ppc based SBC with a san-disc like part on it that runs Linux? Kindest Regards, Jerry

1 0

Re: [U-Boot-Users] BDI debugger + u-boot
by Jerry Van Baren 23 Dec '02

23 Dec '02

At 10:16 AM 12/23/2002 -0500, invictus_rm(a)hotmail.com wrote: >Hi, > I am looking for a hardware debugger to help me in broad bringup and >kernel >debugging . Searching through google , i could find BDI2000 . It claims to >support firmware debugging as well as linux kernel with MMU enabled ........ > Has anyone on the list tried out the BDI2000......... > Will it be useful enough ?? YES >Is there something better ?? NO Sorry for shouting, but if you check the email archives of the ppc-boot (predecessor to u-boot), almost every discussion on hardware debugging has in it a recommendation to buy a BDI2000. If the poor unfortunate had already bought something else, condolences were expressed and they were advised to give away the "something else" and buy a BDI2000. It is possible to debug with "something else", but the bulk of the engineers here use the BDI2000 so you will get a lot more help here. The reason for this is because Abatron is a very enlightened company, very responsive (last week I got an update overnight to support a new flash memory), supports linux very well (including kernel debug with MMU support), etc. >regards >rm gvb ********************************************************************** This e-mail and any files transmitted with it are confidential and may be legally privileged or otherwise exempt from disclosure under applicable law. This e-mail and its files are intended solely for the individual or entity to whom they are addressed and their content is the property of Smiths Aerospace. If you are not the intended recipient, please do not read, copy, use or disclose this communication. If you have received this e-mail in error please notify the e-mail administrator at postmaster(a)si.com and then delete this e-mail, its files and any copies. This footnote also confirms that this e-mail message has been scanned for the presence of known computer viruses. ***********************************************************************

1 0

[U-Boot-Users] BDI debugger + u-boot
by invictus rm 23 Dec '02

23 Dec '02

Hi, I am looking for a hardware debugger to help me in broad bringup and kernel debugging . Searching through google , i could find BDI2000 . It claims to support firmware debugging as well as linux kernel with MMU enabled ........ Has anyone on the list tried out the BDI2000......... Will it be useful enough ??Is there something better ?? regards rm _________________________________________________________________ Add photos to your e-mail with MSN 8. Get 3 months FREE*. http://join.msn.com/?page=features/featuredemail&xAPID=42&PS=47575&PI=7324&… http://www.hotmail.msn.com/cgi-bin/getmsg&HL=1216hotmailtaglines_addphotos_…

2 1

[U-Boot-Users] hello
by Mikore 21 Dec '02

21 Dec '02

1 0

[U-Boot-Users] U-Boot-0.2.0 released
by Wolfgang Denk 17 Dec '02

17 Dec '02

The first version of U-Boot has been released. It is named U-Boot-0.2.0 and tagged as "U-Boot-0_2_0" on the CVS server. A tarball is available at ftp://ftp.denx.de/pub/u-boot/u-boot-0.2.0.tar.bz2 [In case anybody asks if there was a version 0.1.0: yes, there is such a version. It is identical with PPCBoot-2.0.0.] Major news: - Support for AmigaOne board - Support for x86 architecture ====================================================================== Changes for U-Boot 0.2.0: ====================================================================== * Use 1-byte-read instead of -write for iprobe() function Add i2c commands to PM826 config * extend I2C POST code: check for list on known addresses * Improve log buffer code; use "loglevel" to decide which messages to log on the console, too (like in Linux); get rid of "logstart" * Add command line tool to access the U-Boot's environment (board-specific for TRAB now, to be fixed later) * Patch by Hans-Joerg Frieden, 06 Dec 2002 Fix misc problems with AmigaOne support * Patch by Chris Hallinan, 3 Dec 2002: minor cleanup to the MPC8245 EPIC driver * Patch by Pierre Aubert , 28 Nov 2002 Add support for external (SIU) interrupts on MPC8xx * Patch by Pierre Aubert , 28 Nov 2002 Fix nested syscalls bug in standalone applications * Patch by David Müller, 27 Nov 2002: fix output of "pciinfo" command for CardBus bridge devices. * Fix bug in TQM8260 board detection - boards got stuck when board ID was not readable * Add LED indication for IDE activity on KUP4K board * Fix startup problems with VFD display on TRAB * Patch by Pierre Aubert, 20 Nov 2002 Add driver for Epson SED13806 graphic controller. Add support for BMP logos in cfb_console driver. * Added support for both PCMCIA slots (at the same time!) on MPC8xx * Patch by Rod Boyce, 21 Nov 2002: fix PCMCIA on MBX8xx board * Patch by Pierre Aubert , 21 Nov 2002 Add CFG_CPM_POST_WORD_ADDR to make the offset of the bootmode word in DPRAM configurable * Patch by Daniel Engström, 18 Nov 2002: Fixes for x86 port (mostly strings issues) * Patch by Ken Chou, 18 Nov 2002: Fix for natsemi NIC cards (DP83815) * Patch by Pierre Aubert, 19 Nov 2002: fix a bug for the MII configuration, and some warnings * Patch by Thomas Frieden, 13 Nov 2002: Add code for AmigaOne board (preliminary merge to U-Boot, still WIP) * Patch by Jon Diekema, 12 Nov 2002: - Adding URL for IEEE OUI lookup - Making the autoboot #defines dependent on CONFIG_AUTOBOOT_KEYED being defined. - In the CONFIG_EXTRA_ENV_SETTINGS #define, the root-on-initrd and root-on-nfs macros are designed to switch how the default boot method gets defined. * Patch by Daniel Engström, 13 Nov 2002: Add support for i386 architecture and AMD SC520 board * Patch by Pierre Aubert, 12 Nov 2002: Add support for DOS filesystem and booting from DOS floppy disk * Patch by Jim Sandoz, 07 Nov 2002: Increase number of network RX buffers (PKTBUFSRX in "include/net.h") for EEPRO100 based boards (especially SP8240) which showed "Receiver is not ready" errors when U-Boot was processing the receive buffers slower than the network controller was filling them. * Patch by Andreas Oberritter, 09 Nov 2002: Change behaviour of NetLoop(): return -1 for errors, filesize otherwise; return code 0 is valid an means no file loaded - in this case the environment still gets updated! * Patches by Jon Diekema, 9 Nov 2002: - improve ADC/DAC clocking on the SACSng board to align the failing edges of LRCLK and SCLK - sbc8260 configuration tweaks - add status LED support for 82xx systems - wire sspi/sspo commands into command handler; improved error handlering - add timestamp support and alternate memory test to the SACSng configuration * Patch by Vince Husovsky, 7 Nov 2002: Add "-n" to linker options to get rid of "Not enough room for program headers" problem * Patch by David Müller, 05 Nov 2002 Rename CONFIG_PLL_INPUT_FREQ to CONFIG_SYS_CLK_FREQ so we can use an already existing name * Patch by Pierre Aubert, 05 Nov 2002 Hardware relatied improvments in FDC boot code * Patch by Holger Schurig, 5 Nov 2002: Make the PXA really change it's frequency * Patch by Pierre Aubert, 05 Nov 2002 Add support for slave serial Spartan 2 FPGAs * Fix uninitialized memory (MAC address) in 8xx SCC/FEC ethernet drivers * Add support for log buffer which can be passed to Linux kernel's syslog mechanism; used especially for POST results. * Patch by Klaus Heydeck, 31 Oct 2002: Add initial support for kup4k board * Patch by Robert Schwebel, 04 Nov 2002: - use watchdog to reset PXA250 systems - added progress callbacks to (some of the) ARM code - update for Cogent CSB226 board * Add support for FPS860 board * Patch by Guillaume Alexandre,, 04 Nov 2002: Improve PCI access on 32-bits Compact PCI bus * Fix mdelay() on TRAB - this was still the debugging version with seconds instead of ms. * Patch by Robert Schwebel, 1 Nov 2002: XScale related cleanup (affects all ARM boards) * Cleanup of names and README. ====================================================================== Notes for U-Boot 0.1.0: ====================================================================== This is the initial version of "Das U-Boot", the Universal Boot Loader. It is based on version 2.0.0 (the "Halloween Release") of PPCBoot. For information about the history of the project please see the PPCBoot project page at http://sourceforge.net/projects/ppcboot ====================================================================== Best regards, Wolfgang Denk -- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd(a)denx.de "Though a program be but three lines long, someday it will have to be maintained." - The Tao of Programming

1 0

Re: [U-Boot-Users] booting linux from u-boot - help!
by Murray Jensen 17 Dec '02

17 Dec '02

On Tue, 17 Dec 2002 19:04:41 +1100, My-Hong Vuong <My-Hong.Vuong(a)au.thalesgroup.com> writes: >with the cache, i've disabled MSR_DR in head_8xx.S You mustn't do this - virtual memory will not work if you do this. >which then seems to >get to start_here fine. This is giving you false hope - you must leave the virtual memory on. >but inserting the same code just before >early_init doesn't seem to work... One problem that you need to look out for is that you only have 0x100 bytes available to you at that point. This is executing the reset exception handler at 0x...100 and the next exception handler must start at 0x...200. Don't insert too much code (you should get an error from the assembler - saying that you are trying to set the location backwards or something like that). >the assembly I'm using is : >lis r25, 0xaaaa >ori r25, r25, 0xaaaa >lis r26, 0x8100 >ori r26,r26,0x0000 >stw r25, 0(r26) > >where r25 is the pattern I want to write into address 0x81000000. I've >used r25 and r26 because I can't see them being used anywhere in the >code... r25 and r26 (and others) are used to save the arguments passed to kernel from the boot loader (in r3, r4, ..., r7) - it's like the first few instructions ever executed by Linux - you mustn't clobber these registers. Besides this, if you leave virtual memory on, this will not do what you think it will - you must first set up a temporary translation in the TLB before you can access that physical location, as is done for the Internal Memory Mapped Registers (IMMR) area. Of course, the appropriate BRx/ORx for the LEDs must have been set up by the boot loader so that the physical address 0x81000000 really does access the LED hardware (I assume this is the case - since you say this code works elsewhere). >I'm not sure how do do it otherwise (i.e. restoring the original >register values) Use some other registers (if you're careful) - e.g. r3, r4, r5 - these will be restored later when required (see call to identify_machine - or some name like that). >any other ideas would be muchly appreciated, I just got my BDI2000 - it's great. Other than that - pull out all code you have inserted and go back to the original Linux code - after carefully examining all the config options. If your hardware is correct and your linux config matches it properly, it should "just work" :-) Good luck. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/ To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

1 0

Re: [U-Boot-Users] booting linux from u-boot - help!
by My-Hong Vuong 17 Dec '02

17 Dec '02

I used smc1 because i was unable to get ppcboot running with smc2. our smc1 is at 9600. with the cache, i've disabled MSR_DR in head_8xx.S which then seems to get to start_here fine. but inserting the same code just before early_init doesn't seem to work... the assembly I'm using is : lis r25, 0xaaaa ori r25, r25, 0xaaaa lis r26, 0x8100 ori r26,r26,0x0000 stw r25, 0(r26) where r25 is the pattern I want to write into address 0x81000000. I've used r25 and r26 because I can't see them being used anywhere in the code... I'm not sure how do do it otherwise (i.e. restoring the original register values) any other ideas would be muchly appreciated, My Hong Vuong >>> Murray Jensen <Murray.Jensen(a)csiro.au> 12/17/02 04:24pm >>> On Tue, 17 Dec 2002 14:17:50 +1100, My-Hong Vuong <My-Hong.Vuong(a)au.thalesgroup.com> writes: >Thanks for the prompt response. My pleasure. >The board I'm working with does not utilise SDRAM, rather SRAM - Samsung >K1S321615M, which does not utilise burst access - our ORx has Burst >Inhibit turned on - it does not support burst accesses. This shouldn't >pose a problem then, should it? No you are correct, you simply won't do burst transfers on the bus which means it can't be the problem. >We have CPU6 turned off as we're using an MPC860T Rev.D.4. OK >Switching >the Copyback on and off seem to have no effect. OK >also, for the console, we have it set at SMC1, standard/generic >serial... SMC1 - therefore no modem control (this was going to be my next guess). By the way, don't try to set the baud rate too high - it won't work on and SMC. A nice easy 9600 is good to use. >i'm unclear as to what you mean by: >you must have a virtual memory mapping set up once the mmu is turned on >- the head.S file sets one up for the IMMR and the first 8M of RAM until >the kernel takes over. > >Do you mean that BRx and ORx need to be set up again? (btw, i'm a newbie >at this stuff) No, a virtual memory mapping in the MMU. Linux takes care of this stuff, but if you are going to be poking values into a hardware device, you need to set up a virtual to physical address mapping and use the virtual address when the MMU is turned on, and the physical address when it is turned off. The mapping also needs to be non-cached. For example, something like: volatile phys_addr_t phys_addr = (phys_addr_t)0xXXXXXXXX; volatile void *virt_addr; volatile led_struct *led_ptr; virt_addr = ioremap(phys_addr, size); /* if MMU is off */ led_ptr = (led_struct *)phys_addr; led_ptr->... /* if MMU is on */ led_ptr = (led_struct *)virt_addr; led_ptr->... Don't take this literally - its just quick notes to give you an idea. Note the BRx/ORx stuff sets the "physical" address of devices, while the MMU mappings set the "virtual" address (you don't need a mapping to access the IMMRs - this is done for you). Also, most places in Linux have the MMU on, except for certain routines in the startup, and the exception handlers (in assembly). Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/ To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 1

Fwd: Re: [U-Boot-Users] booting linux from u-boot - help!
by My-Hong Vuong 17 Dec '02

17 Dec '02

1 0

[U-Boot-Users] booting linux from u-boot - help!
by My-Hong Vuong 17 Dec '02

17 Dec '02

Hi, I've finally resolved my ethernet reset problem - we just happened to be moving things arount on our development area, and found that upon removal of the mpcbdm cable, our board no longer sporadically reset and our ethernet worked just fine. Can anyone shed some light on this? I'm open to suggestions and I'm sure users developing for custom boards would also find this information useful. Anyway, I'm now up to the stage of booting linux. i've tftp'd a pImage, loaded it into flash and have tried to boot it using: setenv bootargs root=/dev/hda1 bootm 04880000 ## Booting image at 04880000 ... Image Name: Linux-2.4.19-pre7 Created: 2002-12-16 8:04:21 UTC Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 599083 Bytes = 585 kB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK At this point, it hangs. I've double-checked linux/include/asm-ppc/ppcboot.h with u-boot/include/asm-ppc/ppcboot.h and the only difference is the following line: mon_fnc_t *bi_mon_fnc; /* Pointer to monitor functions */ which is required(?) I've also tried it with the clocks_in_mhz turned on and off with no avail. I modified linux/arch/ppc/kernel/head_8xx.S to flash some LEDs on the board at _start and that works, suggesting to me that at least the memory map parsed to linux is ok. however, trying to flash our leds to try and find out where our system hangs, it fails when i get to start_here. it appears that the system crashes after the "rfi", which enables our mmu. to "prove" this, we replaced the turn_on_mmu block with a simple "b start_here". what could possibly be the problem here?? in desperate need of help... and thanks in advance, My Hong Vuong

1 0

[U-Boot-Users] Automatic boot of Linux from flash (Big ppcboot image the sequel)
by "Callebaut, Benoît" 16 Dec '02

16 Dec '02

Hi, I tried another approach to boot directly Linux ,from flash from an image loaded in flash in one block. Instead of compiling ppcboot with an image of the linux kernel in a big array ( makes linking problem) I placed the kernel image direcltly after the ppcboot image with the (linux) command cat image >> ppcboot.bin. With the offset of the kernel and its length hardcoded no problem everything start. But when I use the function get_endaddr() (before relocation of course) It give me back an address approximatively 30 kBytes after the real end of ppcboot. Second problem, How can I find back or make ppcboot find the end of the Kernel image without anything hardcoded ? ---------------------------------------------------------------------------- ------ Benoit Callebaut Software Development Engineer Barco | Control Rooms Noordlaan 5, 8520 Kuurne, Belgium Tel +32(0)56 36 84 28 Fax +32(0)56 36 86 05 mailto:benoit.callebaut@barco.com http://www.barcocontrolrooms.com

2 1