July 2004 - U-Boot

[U-Boot-Users] [PATCH] Setup correct bi_arch_number for OMAP1610 boards
by George G. Davis 07 Jul '04

07 Jul '04

Greetings, The attached patch fixes OMAP1610 board builds so that the correct machine number is setup based on the board target config file. This allows recent OMAP linux-2.6 kernels to boot on OMAP1610 based boards since recent OMAP Linux-2.6 kernels now expect the correct and official machine number to be passed in for these OMAP1610 based boards. If the correct machine number is not passed in to recent OMAP Linux-2.6 kernels, then the Linux kernel will either malfunction or hang due to selection of the wrong machine specific support code due to wrong machine number passed into the kernel by U-Boot. I've tested U-boot on an OMAP1610 H2 board with recent OMAP Linux-2.6 kernel with this patch applied - it works ok for me. There is in fact one build failure for this MAKEALL test case: CROSS_COMPILE=/opt/montavista/pro/devkit/arm/v4t_le/bin/arm_v4t_le- ./MAKEALL arm Here's the build failure for the above test case: Configuring for xsengine board... cc1: error: unrecognized option `-fdisassemble-all' cc1: error: unrecognized option `-fdisassemble-all' cc1: error: unrecognized option `-fdisassemble-all' make[1]: *** [.depend] Error 1 make: *** [board/xsengine/libxsengine.a] Error 2 /opt/montavista/pro/devkit/arm/v4t_le/bin/arm_v4t_le-size: u-boot: No such file or directory I did not perform a test build prior to applying this fix. But I'm confident the above build failure is not a regression due to this patch. Perhaps this is merely a problem with my tool chain? However I'm indifferent about that failure and do not know or really much care (at the moment : ) if it exists for other tool chains or not. -- Regards, George

1 0

[U-Boot-Users] UDP Console
by Rune Torgersen 07 Jul '04

07 Jul '04

I know this has been discussed a few times before.... I need to implement some sort of ethernet console access for u-boot (udp, similar to netconsole/netpoll in linux, I guess) But before I start reinventing the wheel (and also dive into the mysterious depths of u-boot): Has anybody done any kind of work in this area? Rune Torgersen System Developer Innovative Systems LLC 1000 Innovative Drive Mitchell, SD 57301 Ph: 605-995-6120 www.innovsys.com

3 2

RE: [U-Boot-Users] ARM exception vectors -- relocating
by Friedrich, Lars 07 Jul '04

07 Jul '04

>> Maybe, but I don't think so. At least I see no code in ARMBoot to >> relocate the exception vectors. > Because they can't be. The vectors always sit at address 0000'0000, > and thus in the flash. You can only change that by turning on the MMU. > So the relocated entry points are loaded to the pc via ldr, the only > exception being the RESET vector, obviosly. In other words, interrupts > in ARMboot can only be used _after_ relocation. I think you fail to understand the problem. IF the flash memory is mapped to an area != 0x0 AND the SDRAM memory is mapped to 0x0 BUT the _TEXT_BASE does not start at 0x0, THEN the exception vectors will not work, as there is no proper handling of this case in the current code. All other issues you have raised are correct, but fail to recognize the situation. Best regards, Lars Friedrich --

2 1

[U-Boot-Users] getting u-boot on the mv64360
by Amit Shah 07 Jul '04

07 Jul '04

Hi all, I have an MV64360 board (IBM dev brd), that has PIBS on it. What's the best way to use u-boot with it? I compiled u-boot with powepc-gcc-3.3.4 (compiled via crosstool), but PIBS fails to load the binary (.bin). (In fact, PIBS doesn't recognize any of the binaries). So what's the recommended way? Should I put u-boot on the flash, overwriting PIBS? And since I don't have a BDI cable, how can I put u-boot on the board? Too many questions, would be glad if anyone answered them. Thanks, Amit. -- Amit Shah http://amitshah.nav.to/

2 2

[U-Boot-Users] ARM exception vectors -- relocating
by Curt Brune 07 Jul '04

07 Jul '04

Hello, I have a question about relocating the exception vectors for the ARM platform. I am working with cpu/arm720t/start.S and want to use interrupts, but I think I see a problem with the code as it stands now. Consider the following scenario: 1. power on, cpu starts executing from address 0x0, which is located in flash. 2. memsetup.S configures 8MB SRAM to begin at address 0x0 and remaps flash to address 0x01000000. 3. back in start.S u-boot is relocated(copied) from flash to TEXT_BASE = 0x007d0000. Now the exception vectors are sitting in SRAM @ 0x007d0000 and in flash @ 0x0100000 -- if I want to use interrupts, however, the exception vectors need to be in SRAM at address 0x0. Currently I have added an additional relocation step to start.S that explicitly copies the vectors from flash to 0x0 (in SRAM) if TEXT_BASE is not equal 0x0 (if TEXT_BASE is equal to 0x0 there is no problem). Question: Is start.S the correct place to put this, perhaps bracketed with "#ifdef CONFIG_USE_IRQ/#endif"? It seems like a global problem that all arm720t boards that use interrupts would have. Or is memsetup.S a better place for this? Comments? Cheers, Curt -- ======================================================================== Curt Brune | Phone 1.650.380.2528 | Managing Principal curt(a)cucy.com | WWW www.cucy.com | Cucy Systems ======================================================================== Cucy Systems -- Software. Integration. Training. ========================================================================

3 4

[U-Boot-Users] [PATCH] ARM720t -- Relocating Exception Vectors
by Curt Brune 07 Jul '04

07 Jul '04

This patch is for cpu/arm720t/start.S -- The patch relocates the exception vectors to RAM address 0x0. See previous posting about relocating ARM exception vectors for a discussion of the problem. Cheers, Curt -- ======================================================================== Curt Brune | Phone 1.650.380.2528 | Managing Principal curt(a)cucy.com | WWW www.cucy.com | Cucy Systems ======================================================================== Cucy Systems -- Software. Integration. Training. ========================================================================

1 0

[U-Boot-Users] [PATCH] Updates for evb4510 (ARM7)
by Curt Brune 07 Jul '04

07 Jul '04

This patch is for the evb4510 target. The patch adds support for a timer interrupt and cleans up the config header file for passing boot arguments to linux. u-boot/board/evb4510/evb4510.c ============================== Removed code related to the non-interrupt method for timers. u-boot/cpu/arm720t/interrupts.c =============================== Added interrupt handling. Timer interrupt configuration. u-boot/include/asm-arm/arch-arm720t/s3c4510b.h ============================================== Added macros and constants related to interrupts u-boot/include/configs/evb4510.h ================================ Changed boot args. Enabled CONFIG_CMDLINE_TAG, CONFIG_SETUP_MEMORY_TAGS and CONFIG_INITRD_TAG u-boot/lib_arm/armlinux.c ========================= Copy the ramdisk to destination address for this target (similar to the B2 target). -- ======================================================================== Curt Brune | Phone 1.650.380.2528 | Managing Principal curt(a)cucy.com | WWW www.cucy.com | Cucy Systems ======================================================================== Cucy Systems -- Software. Integration. Training. ========================================================================

1 0

[U-Boot-Users] relocate_code problem
by Oliver Fuchs 06 Jul '04

06 Jul '04

Hi all, I try to get up U-Boot 1.1.1 on a "home brewed" board with MPC8280 and have problems with the relocation of code. It crashes after the call of in_ram. It seems that it calculates the address of in_ram correctly, but the copied code is somehow shifted. Is there anyone who can point me to the function that copies the code into RAM? Sorry, but the assembler code is not my favorite thing. Thanks in advance, Oliver ---- some extra info: symbol in_ram is linked to 0xfff03404 relocate_code is called: relocate_code( 03fbdf48, 03fbdf6c, 03fdf000) relocate_ram jumps to 0x03fe2404 // there is code, but not in_ram

2 3

RE: [U-Boot-Users] How to generalize SDRAM support for MPC5200 an d MGT5100?
by Jonas Mark-r50740 06 Jul '04

06 Jul '04

Hi Reinhard, > This e-Mail of yours did reach me directly, but did not make > it to the list. Something funny going on... That's what happened to me as well I guess. > The current SDRAM/DDRAM init in top5200.c consists of 13 > assignment statements, parametrized by 8 constants from top5200.h. Correct. That's about the minimum of stores you need to perform to initialize the SDRAM controller and the SDRAM itself. > So far I have not added any VPD reading for those, because > the only TOP5200 version being built so far has exactly that > kind of Micron SDRAM (64MB total). If you add VPD (I do not know the abbreviation but I guess you mean a configuration EEPROM) you can live with the same amount of stores if you specify everything inside the VPD. So I guess we agree here. > When I look at the original source for the IceCube SDRAM init > this is very hard to read and understand; not to mention that > this init did not work for the TOP5200 although it is the > same type of SDRAM and the same wiring. But I found out that > the IceCube init produces quite different values than I come > up with following the 5200 Manual and the Micron Manual. My > values work on TOP5200 and incidently also on LITE5200 - in > fact the TOP5200 port can be parametrized to produce code for > the LITE5200 which works perfectly and was done by me as a crosscheck. The original init code from Wolfgang did also not work on one of my engineering boards. That was the reason I submitted a fixed version. There were some sync instructions missing. Additionally the new code uses #defines to make it flexible and SDRAM type independent. I did not remove the automatic detection of SDRAM size and CS usage because I wanted the SDRAM include files to be board independent. Of course you could specify the missing parameters in the board code as well. But the code to do it automatically already existed. > How would you want to generalize? > > A) a small function, containing 13 statements and having 8 parameters > B) a function that tries to figure out what SDRAM/DDRAM is > connected and which size it has > C) a function with alot of #if's catering for the minute > differences between the various boards I would go for B with a kind of C where some parameters are passed to the initialization function. These parameters can either come from an EEPROM, #defines, calculated on the fly or whatever you can think of. > For the argument of an initial port, I prefer to use fixed > values for initialization of SDRAM, values that have been > tested in other environments (BDI2000, other OS) compared to > automatic determined values. If the automatic determined > values work, its fine, of course - but if they don't you end > up researching why. Personally I do not want to have the code calculate all the values. But detecting the usage of CS1 and the size of the SDRAM is not a bad thing in my mind. The nice thing of doing in like that would be that we could add a #define option to make it a programmers choice whether to do the detection of simply take #defines instead. I guess that would make both of us happy. Coming back to the reason I started this discussion: Do you have an idea where to place this MGT5100 / MPC5200 generic piece of code? Where to put the SDRAM initialization values? As they are also board independent and many boards are using the same SDRAM a central place would be good, too. Regards Mark

1 0

[U-Boot-Users] [PATCH] one-liner to fix sbc8260 environment variables
by Dan Poirot 06 Jul '04

06 Jul '04

Howdy, The file include/configs/sbc8260.h has an 'extra' NULL at the end of the first element of CONFIG_EXTRA_ENV_SETTINGS. This terminates the string before any of the cool stuff like 'reprog' and 'zapenv' get added... The patch was created against code from the current CVS using the command : diff -purN u-boot u-boot_sbc8260 > sbc8260.patch Changelog Entry : * Patch by Daniel Poirot, 06 July 2004: removed extra NULL from CONFIG_EXTRA_ENV_SETTINGS in the file include/configs/sbc8260.h All comments and feedback welcome.

1 0