April 2004 - U-Boot

[U-Boot-Users] U-Boot for Motorola's DragonBall MX1/MXL ???
by Steven Scholz 20 Apr '04

20 Apr '04

Hi there, have there been any attempts to port U-Boot onto Motorola's MC9328MXL processors (aka. DragonBall MX1/MXL)? They're based on ARM9(TDMI). Thanks. -- Steven Scholz imc Measurement & Control imc Meßsysteme GmbH Voltastr. 5 Voltastr. 5 13355 Berlin 13355 Berlin Germany Deutschland

1 0

[U-Boot-Users] SDRAM autodetection patch for Debris board update
by Sangmoon Kim 20 Apr '04

20 Apr '04

Hi, This patch do the same as the last patch for Debris board, and changes the value of CFG_MAX_RAM_SIZE from 0x10000000 (256M) to 0x20000000 (512M). Regards, Sangmoon Kim

2 2

RE: [U-Boot-Users] Re: Latest changes to cmd_nand.c
by Dave Ellis 19 Apr '04

19 Apr '04

Wolfgank Denk wrote: > To: "David Müller (ELSOFT AG)" > In message <407FCCDA.6040508(a)elsoft.ch> you wrote: > > > > What was the reason to make a new command "nand read.jffs2s" to handle > > bad block skipping in the read case. > > > > Why not just integrate the bad block skipping into the standard > > "read.jffs2" command. > > Good questions. > > > IMHO the "original functionality" is broken. The "nand write" command > > skips over bad blocks by default, while "nand read" and (even worse) > > "nandboot" don't. > > I agree. Can you please submit a patch? I implemented the current nand read.jffs2 bad block handling so that both the amount of the nand read and memory written would always be the amount requested. If I ask for 2 MiB and there are bad blocks, there would be some unknown amount of memory at the end with random data and I didn't see a good way to tell the jffs2 code to ignore it. Initializing all the memory to 0xff to account for that would have slowed my boot process too much. The read.jffs2 command could skip bad blocks and pad the data with 0xff at the end instead so that the total bytes read is still always what was requested. This change to the "original functionality" wouldn't break any code (like mine :-) ) that depends on all of the destination memory being defined. I should have done it that way originally, but I didn't think of it. It seems to me that the current functionality is fine for jffs2 and the jffs2s version is needed when you are not actually using jffs2. I think we should reserve read.jffs2 for jffs2 use. Then it can be optimized to read only the data really needed for jffs2. If it is used for other purposes these optimizations would break the other uses. If what is really needed (and it isn't for jffs2) is what nandboot should (but doesn't) do, which is read enough blocks to get a certain amount of _good_ data, there should be a new command, something like "nand read.good". This would need a new option flag for nanda_rw(). Dave Ellis

1 0

[U-Boot-Users] v1.1.0, omap boards and udelay()
by Dave Peverley 19 Apr '04

19 Apr '04

Hi all, I'm just merging my omap730p2 port into the 1.1.0 codebase, and have hit a snag that I would have thought would affect the omap1510 and 1610 code as well ; can anyone confirm this? The problem is as follows : in boards/omapXXXX/omapXXXX.c, the function ether__init() uses the udelay() call. Prior to version 1.1.0, this was implemented using : #if defined(CONFIG_INNOVATOROMAP1610) || defined(CONFIG_P2OMAP730) #define LOOPS_PER_MSEC 100 /* tuned on omap1610 */ volatile int i, time_remaining = LOOPS_PER_MSEC * usec; for (i = time_remaining; i > 0; i--) { } #else so that the omap's wouldn't use the MPU timer, as this does not work (at least at that point in the startup) This means that u-boot hangs on my board during ether__init() now as the timer never gets incremented. Can anyone tell me why this code was removed? Looking at it, I can't see a reason why it shouldn't break the 1510/1610 omap support as well. I've tested moving the code back as it was (using the 1.1.0 CONFIG_OMAP instead) and this fixes the problem once more. Best Wishes, Dave Peverley --------------------------------------------------------------------------- Dave Peverley, Software Engineer, MPC Data Limited. Phone : [+44] (0) 1225 868 228 Web : http://www.mpc-data.co.uk

1 0

[U-Boot-Users] NetSilicon NS9750 DevBoard not listed in Makefile
by Wolfgang Denk 19 Apr '04

19 Apr '04

Dear markus, it seems some parts of your patch to add the NetSilicon NS9750 DevBoard board were missing - there is no entry for this board in the toplevel Makefile. Please check and send a patch. 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 "The fundamental principle of science, the definition almost, is this: the sole test of the validity of any idea is experiment." - Richard P. Feynman

2 3

Re: [U-Boot-Users] Need help booting linux on 8265 eval board
by 19 Apr '04

19 Apr '04

hello,Mr Wolfgang thanks for your reply. I think i should describe the problem clearly. First i explain why i modified the uboot/linux default values. I'm a graduate student. the board is designed by my schoolfellow(the board use 8265,but it is very like the board MPC8266ADS-PCI-AI), but this board is not supported by uboot, I must modify the configuration of sdram,IMMR and some other registers(from motorola datasheet). now the uboot looks running well(it can read/write flash/sdram, scc and fcc is also working), but when i boot the linux kernel, i meet the problem. i think i must let imap_addr(linux kernel)=IMMR(uboot), so I modify some default values. Now I want to know why linux mapped at 0xC0000000 , the uboot say "## Transferring control to Linux (at address 00000000) ...", so KERNELLOAD should be 0xc0000000 or 0x00000000? and if I use linux kernel 2.4.20, CONFIG_CLOCKS_IN_MHZ should be 0 or 1? Best regards, liu ming liutomorrow(a)hotmail.com >From: Wolfgang Denk <wd(a)denx.de> >To: <liutomorrow(a)hotmail.com> >CC: u-boot-users(a)lists.sourceforge.net >Subject: Re: [U-Boot-Users] Need help booting linux on 8265 eval board >Date: Sun, 18 Apr 2004 17:10:53 +0200 > >In message <BAY2-F91LEdyt3cew8k000156e5(a)hotmail.com> you wrote: > > > > I have problem booting linux on 8265 eval board. when I boot the linux > > kernel, the board be dead. the registers look like > > to be some default values(use powertap pro). I try u-boot1.1, ppcboot1.1.5; > >Be careful. User the default values as defined in U-Boot and Linux, >and DON'T change these unless you know EXACTLY what you are doing. > > > vim Makefile, arch=ppc CROSS_COMPILE=ppc_82xx > > vim arch/ppc/platforms/ads826x.h, IMAP_ADDR=0x04700000 BCSR=0x04500000 > >This cannot work. Please leave the mapping as defined by U-Boot and Linux. > > > > then the board is dead and the LED(FCC link) coruscate . > > (I have modified clock calculations for this board. it's the reason?) > > any ideas? thanks a lot! > >You seem to modify a lot of stuff without konwing exactly why - don;t >do this. The default values are there for a reason - they are known >to work. > >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 >"There are three principal ways to lose money: wine, women, and engi- >neers. While the first two are more pleasant, the third is by far the >more certain." - Baron Rothschild, ca. 1800 >>Hi, I have problem booting linux on 8265 eval board. when I boot the linux kernel, the board be dead. the registers look like to be some default values(use powertap pro). I try u-boot1.1, ppcboot1.1.5; linux kernel 2.4.4 2.4.18 2.4.20. (1)about kernel vim Makefile, arch=ppc CROSS_COMPILE=ppc_82xx vim arch/ppc/platforms/ads826x.h, IMAP_ADDR=0x04700000 BCSR=0x04500000 then make mrproper/make ads826x_config/make oldconfig/make dep/make pImage (bd info struct is quite same between uboot and linux) Is there anything I had ignored? (2)let's see!(I add some "printf" to display values, "console=ttyS0,9600" is added) => bootm ffa00000 ffc00000 ## Booting image at ffa00000 ... Image Name: Linux-2.4.20-pre7ncsd1 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size: 634729 Bytes = 619 kB = 0 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK Uncompressing Kernel Image ... OK ## Current stack ends at 0x03F7FC48 => set upper limit to 0x00800000 ## cmdline at 0x007FFF00 ... 0x007FFF23 memstart = 0x00000000 memsize = 0x04000000 flashstart = 0xFF800000 flashsize = 0x00800000 flashoffset = 0x00000000 sramstart = 0x00000000 sramsize = 0x00000000 immr_base = 0x04700000 bootflags = 0x00000001 vco = 266.666 MHz sccfreq = 66.666 MHz brgfreq = 16.666 MHz intfreq = 166.666 MHz cpmfreq = 133.333 MHz busfreq = 33.333 MHz ethaddr = 00:10:EC:00:30:8C IP addr = 8.6.0.1 baudrate = 9600 bps ## Loading RAMDisk Image at ffc00000 ... Image Name: Simple Ramdisk-Image Image Type: PowerPC Linux RAMDisk Image (gzip compressed) Data Size: 567988 Bytes = 554 kB = 0 MB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## initrd at 0xFFC00040 ... 0xFFC8AAF3 (len=567988=0x8AAB4) Loading Ramdisk to 03ef4000, end 03f7eab4 ... OK ## Transferring control to Linux (at address 00000000) ... then the board is dead and the LED(FCC link) coruscate . (I have modified clock calculations for this board. it's the reason?) any ideas? thanks a lot! -- liu >>liutomorrow(a)hotmail.com _________________________________________________________________ 免费下载 MSN Explorer: http://explorer.msn.com/lccn/

2 1

[U-Boot-Users] IceCube target names to be unified?
by Jonas Mark-r50740 19 Apr '04

19 Apr '04

Dear IceCube users, looking at the U-Boot Makefile one can see that there are lot of redundant targets for the Lite5200 / IceCube boards. Is there some reason for this legacy or would cleaning it up help? I propose the following targets: - icecube_5100_config (MPC5100 boards with 8 MB Flash, official name is Lite5100) - icecube_5100_lowboot_config (Lite5100, lowboot position) - icecube_5200_config (MPC5200 boards with 16 MB Flash, official name is Lite5200) - icecube_5200_lowboot_config (Lite5200 with U-Boot at lowboot position) - icecube_5200_08_config (Lite5200 with only 8 MB Flash) - icecube_5200_08_lowboot_config (Lite5200 with only 8 MB Flash, lowboot position) - icecube_5200_ddr_config (Lite5200 with DDR instead of SDR memory) - icecube_5200_ddr_lowboot_config (Lite5200 with DDR, lowboot position) These targets cover the same cases like the existing ones but ignore 2 redundant cases (MPC5200LITE_config, IceCube_5200_config, icecube_5200_config), remove a non-existing target (icecube_5200_DDR_LOWBOOT08_config), add an existing but not mentioned case (Lite5100 lowboot) and present a unified naming convention. I advocate using the project name IceCube instead of the product name Lite5x00 because the source files and dirctories are already named such. Hopefully our marketing people are not reading this mailing list. For doing the work I would volunteer but I guess it would be less work for Wolfgang to do it himself than applying my patch. Wolfgang, what would you prefer? Regards Mark Jonas

3 2

[U-Boot-Users] [PATCH] IceCube fixed and cleaned up SDRAM init
by Mark Jonas 19 Apr '04

19 Apr '04

Hello, the attached patch fixes a problem with the SDRAM init code for IceCube (Lite5xxx) I experienced when using LOWBOOT images. In my case U-Boot would always die when doing the first access to SDRAM after initialization which is usually done when trying to find out how big the SDRAM is. I found that no sync instructions where used the synchronize the program flow during SDRAM initialization. This is fixed now. Additionally, I cleaned up the code and moved all the SDRAM chip specific constants into separate include files. The SDRAM initilization itself should be better readable now, too, by merging the DDR / SDR and the MGT5100 / MPC5200 code as cleanly as possible. The code was tested on a Lite5200 (16 MB Flash, LOWBOOT), a Lite5200DDR (16 MB Flash, LOWBOOT) and a Lite5100 (8MB Flash). Regards Mark Jonas * Patch by Mark Jonas, 13 Apr 2004: - Add sync instructions to IceCube SDRAM init code - Move SDRAM chip constants into seperate include files - Unify DDR and SDR initialization code icecube.c | 226 ++++++++++++++++++++++++++++++++++------------------- mt46v16m16-75.h | 37 ++++++++ mt48lc16m16a2-75.h | 43 ++++++++++ 3 files changed, 228 insertions(+), 78 deletions(-)

3 3

[U-Boot-Users] Patch for mii read range and mii dump
by Kerl, John 19 Apr '04

19 Apr '04

Hello, Please find included a minor enhancement to the mii command. This is my first u-boot patch submission so it is almost certain that I've screwed something up. Please forgive! * Patch by John Kerl, 16 Apr 2004: Enable ranges in mii command, e.g. mii read 0-1f 0 or mii read 4-7 18-1a. Also add mii dump subcommand for pretty-printing standard regs 0-5.

2 2

[U-Boot-Users] [PATCH] MPC5200: Remove CSBOOT / CS0 configuration from start.S
by Mark Jonas 19 Apr '04

19 Apr '04

Hello, the attached patch fixes the problem that the current start.S for MPC5200 contains code to initialize CSBOOT / CS0 timing, bus width and other configuration. lis r3, 0x00047800@h ori r3, r3, 0x00047800@l stw r3, 0x300(r4) /* set timing, CS0/boot conf reg */ Right now that only works because all U-Boot supported MPC5200 boards are very Lite5200 (aka IceCube 5200) like. Once there is a board which's Flash is is connected in 24 bits address, 8 bits data, non-multiplexed mode this will break. Additionally, the patch removes enabling of the IPBI wait states. This is not needed because IP bus is not configured to run with > 66 MHz in U-Boot and if needed this should be done always and not only when performing a low boot. Interesting enough U-Boot already has a solution for setting tuned CS0 timings. This is done using the CFG_BOOTCS_CFG define which is applied in cpu/mpc5xxx/cpu_init.c. Regards Mark Jonas * Patch by Mark Jonas, 13 Apr 2004: - Remove CS0 chip select timing setting from cpu/mpc5xxx/start.S start.S | 20 ++++++++------------ 1 files changed, 8 insertions(+), 12 deletions(-)

2 1