July 2007 - U-Boot

[U-Boot-Users] Problem booting MPC8568MDS board + improvement suggestion
by David Saada 18 Jul '07

18 Jul '07

Hello, I've got the MPC8568MDS board. When I try to compile the latest version of U-boot for this board and burn it onto its flash, the boot process gets stuck right after the RAM initialization sequence (it prints the DDR+SDRAM size, but doesn't continue). As far as I was able to see with my ICE, the DDR wasn't properly initialized after the DDR setup sequence (wasn't able to track the exact reason). The thing is that the original Flash image I've got from Freescale does boot properly on the same board. Its startup prints indicate that it's based on version 1.2.0 as well, but there's no way to know which version of the current tree was taken for this purpose (the date only specifies the compilation date - not the tree version date). I don't think it has to do with my compilation environment - I use ELDK 4.0 (used it also with the MPC 8560 & 8360 processors with success). Would appreciate any help, especially information about the last version that was stable with this board. This brings me to suggest the following improvement: With every check in to the U-boot tree (any of them), there should also be a main auto generated file, that includes the date, tree name and perhaps an auto incremented build version. This information should be printed at startup along with major version and compilation date. This should give proper details for the referenced U-boot version. Best regards, David. -- View this message in context: http://www.nabble.com/Problem-booting-MPC8568MDS-board-%2B-improvement-sugg… Sent from the Uboot - Users mailing list archive at Nabble.com.

3 2

[U-Boot-Users] New architecture -- TI DaVinci
by Peter Pearse 18 Jul '07

18 Jul '07

Sergey Apologies - you fooled me with the "New Architecture". I did a quick google & found the TMS320DM6443 was a DSP, so assumed it would be a new DSP architecture, rather than being part of arm. I don't always know where ARM cores have been used - it helps if the email subject mentions ARM. I'll add your patch to my list. Peter -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

5 8

[U-Boot-Users] Problems with tftp-transfers on u-boot (with Linux ok)
by Roesli, Patrick 18 Jul '07

18 Jul '07

Dear u-boot community, First of all, thank you very much for this great bootloader! >From time to time we have some problems on the ethernet-communication at the bootloader level. When we are trying to download an image via tftp, the communication isn't running fluently, there are some interruptions as we can see with ethereal, or even the communication isn't running at all. These problems do not occure on every hardware and may be caused by some chip/hardware tolerances. On the other side, after starting the Linux-Kernel and running tftp in userspace there is no problem anymore. We haven't found any related changes on the source since the u-boot 1.0.2. Had anbody similar effects on the ethernet-communication or any idea how we could solve the problem? Kind regards Patrick Roesli software components: - u-boot 1.0.2 (denx-tree) U-Boot-1_0_2 - kernel 2.4 (denx-tree linuxppc_2_4_devel) LABEL_2005_06_20_1300 hardware components(NSCU Board): - Freescale MPC855TVR66D4(66Mhz) on a TQ systems TQM855-AC(32MB SDRAM/16MB flash) - Ethernet Controller LXT971A http://developer.intel.com/design/network/products/LAN/applnots/24940101 .pdf (single port)

2 1

[U-Boot-Users] [PATCH 1/2] fdt: do board setup based on fdt address specified on bootm line
by Kim Phillips 18 Jul '07

18 Jul '07

The last fdt patch to bootm did board setup based on the address specified by a prior fdt address command invocation. The bootm code, as its call to fdt_chosen does, should use the fdt specified by the user on the bootm command. Note this restores full functionality for the 8360's existing default boot environment values, e.g. 'run nfsboot' (i.e. no having to 'fdt addr $fdtaddr' before booting a kernel). Signed-off-by: Kim Phillips <kim.phillips(a)freescale.com> --- common/cmd_bootm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c index c8825b6..bf21919 100644 --- a/common/cmd_bootm.c +++ b/common/cmd_bootm.c @@ -982,7 +982,7 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int flag, #endif #ifdef CONFIG_OF_BOARD_SETUP /* Call the board-specific fixup routine */ - ft_board_setup(fdt, gd->bd); + ft_board_setup(of_flat_tree, gd->bd); #endif #endif /* CONFIG_OF_LIBFDT */ #if defined(CONFIG_OF_FLAT_TREE) -- 1.5.2.2

4 4

[U-Boot-Users] U-boot to mpc8260
by xyyiezi 18 Jul '07

18 Jul '07

Dear sir: I am in an IC design company.And there ia an object of my company it is about mpc8260.We have the circuit netlist of mpc8260,but we cann't guarantee the circuit netlist to be correct.The circuit netlist was on a SUN server which supported Linux and Cadence. We want to use the u-boot as a software verification tool to verificate the netlist. We have write a platform which was used as an hardware in the verification. And we want to load the u-boot code mpc8260 to the RAM block of the circuit netlist.In this method,we could verificate the circuit netlist by both u-boot and the platform.It will be a mode of hardware and software co-verification. But the difficult is I don't kown how to load the u-boot.Now I have read the source code of the mpc8260 in the u-boot,and I kown I could use the GCC to translate them.I didn't kown how to configure the mpc8260.What material should I read?In my opinion,the circuit netlist will be similar to the hardware mpc8260 expect the speed while it is running.But the hardware mpc8260 has its board ,for example mpc8260ads,which is not in the circuit netlist in the SUN server.And I don't kown whether I could configure the u-boot take the board information. I earnest hope to obtain your help! Thank you! Yours xyyiezi

3 2

[U-Boot-Users] want to know scenario
by sapirf fersht 18 Jul '07

18 Jul '07

How u-boot treats the following commands: setenv ipaddr 192.168.2.202 saveenv printenv reset go printenv vs saveenv printenv reset go printenv (is there a possiblity of failure in this command)? Thanks in advance

2 1

[U-Boot-Users] (no subject)
by Jo N. Bonilla 18 Jul '07

18 Jul '07

1 0

[U-Boot-Users] In kernel mkimage
by Josh Boyer 18 Jul '07

18 Jul '07

Hi All, As part of my on-going 4xx work in the arch/powerpc kernel, I've been toying with the idea of creating an in-kernel copy of the mkimage tool, similar to how we have a mktree tool for the older OpenBIOS firmware. The main reason is that there isn't a stand-alone mkimage tool. Currently, it's only available after you build u-boot itself for a particular platform. Ideally, you would be able to do 'make tools/mkimage' and have it build, but that doesn't seem to be the case. And since it's a bit odd to require developers to build u-boot before building a kernel I thought having an in-kernel copy would be more efficient. The tool itself doesn't get frequent updates, so keeping it in sync shouldn't be a large issue. However, I'd like to hear what other people think of the idea before going off and doing that. josh

4 8

[U-Boot-Users] CONFIG_MEM_INIT_VALUE == 0xDeadBeef
by robert lazarski 17 Jul '07

17 Jul '07

Hi all, is this an english language pun ? #define CONFIG_MEM_INIT_VALUE 0xDeadBeef I see that the #DEFINE is used in SPD: cpu/mpc85xx/spd_sdram.c: ddr->sdram_data_init = CONFIG_MEM_INIT_VALUE; I'm porting my board which has the mpc8548e and the same exact DDR2 that the CDS reference board has. I'm using SPD in my code. The CDS board has DeadBeef assigned to CONFIG_MEM_INIT_VALUE. I don't have a CDS board to test. My board will arrive in a few weeks - I'm trying to prepare the best I can. Should I leave CONFIG_MEM_INIT_VALUE as is or will this make my board DeadBeef ? Thanks, Robert

4 4

[U-Boot-Users] [PATCH 2/2] fdt: allow for builds that don't want env and bd_t nodes
by Kim Phillips 17 Jul '07

17 Jul '07

protect fdt_env and fdt_bd_t invocations, fix codingstyle while in the area. Signed-off-by: Kim Phillips <kim.phillips(a)freescale.com> --- common/cmd_fdt.c | 38 +++++++++++++++----------------------- 1 files changed, 15 insertions(+), 23 deletions(-) diff --git a/common/cmd_fdt.c b/common/cmd_fdt.c index 9ddec47..571b8f1 100644 --- a/common/cmd_fdt.c +++ b/common/cmd_fdt.c @@ -293,36 +293,28 @@ int do_fdt (cmd_tbl_t * cmdtp, int flag, int argc, char *argv[]) return err; } } - + } #ifdef CONFIG_OF_BOARD_SETUP - /******************************************************************** - * Call the board-specific fixup routine - ********************************************************************/ - } else if (argv[1][0] == 'b') { + /* Call the board-specific fixup routine */ + else if (argv[1][0] == 'b') ft_board_setup(fdt, gd->bd); #endif - /******************************************************************** - * Create a chosen node - ********************************************************************/ - } else if (argv[1][0] == 'c') { + /* Create a chosen node */ + else if (argv[1][0] == 'c') fdt_chosen(fdt, 0, 0, 1); - /******************************************************************** - * Create a u-boot-env node - ********************************************************************/ - } else if (argv[1][0] == 'e') { +#ifdef CONFIG_OF_HAS_UBOOT_ENV + /* Create a u-boot-env node */ + else if (argv[1][0] == 'e') fdt_env(fdt); - - /******************************************************************** - * Create a bd_t node - ********************************************************************/ - } else if (argv[1][0] == 'b') { +#endif +#ifdef CONFIG_OF_HAS_BD_T + /* Create a bd_t node */ + else if (argv[1][0] == 'b') fdt_bd_t(fdt); - - /******************************************************************** - * Unrecognized command - ********************************************************************/ - } else { +#endif + else { + /* Unrecognized command */ printf ("Usage:\n%s\n", cmdtp->usage); return 1; } -- 1.5.2.4

1 0