February 2007 - U-Boot

[U-Boot-Users] [DNX#2007020542000039] [PATCH] Add sync at the end of flas [...]
by OTRS Notification Master 05 Feb '07

05 Feb '07

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2007020542000039] was created: <snip> > On 2/5/07, Haiying Wang <r54964(a)freescale.com> wrote: > > Add sync at the end of flash_write_cmd for MPC86xx > > to ensure write command are really finished before reading data > > > > Signed-off-by: Haiying Wang <haiying.wang(a)freescale.com> > > --- > > According to Tolunay's first suggestion, this patch for cfi_flash > > driver fixed the flash operation error on MPC8641HPCN board. Since there > > is not such flash error reported on 85xx, 83xx platform and as Tolunay > > said, there is not a PowerPC macro to define, I just use CONFIG_MPC86xx > > for now. I also tested his second suggestion(adding udelay directly > > after reset command), but flash still failed to work. > > Given that this is already looks to have been an issue on blackfin and > now PPC (and probably some MIPS also), I would suggest it's better to > define a macro in the CPU definition for your arch and blackfin and do > a generic test like so: > > #ifdef SYNC > SYNC; > #endif > > Maybe you can come up with a more descriptive name than SYNC :-) > > I had e-mailed Tolunay about this and he concurred. > > -- > Hardware, n.: > The parts of a computer system that can be kicked. </snip> Your U-Boot support team

1 0

[U-Boot-Users] [DNX#2007020542000021] [PATCH] Add sync at the end of flash_write_cmd for MPC86xx
by U-Boot patch tracking system 05 Feb '07

05 Feb '07

Dear Mr. U. Boot, thank you for your contribution to the U-Boot project. Your e-mail was registered at our system under the ticket number [DNX#2007020542000021]. Please keep this ticket ID string in the subject line of any e-mail replies!!! Your U-Boot support team Powered by OTRS (http://otrs.org/)

1 0

[U-Boot-Users] [DNX#2007020542000021] [PATCH] Add sync at the end of flash_write_cmd for [...]
by OTRS Notification Master 05 Feb '07

05 Feb '07

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2007020542000021] was created: <snip> > Add sync at the end of flash_write_cmd for MPC86xx > to ensure write command are really finished before reading data > > Signed-off-by: Haiying Wang <haiying.wang(a)freescale.com> > --- > According to Tolunay's first suggestion, this patch for cfi_flash > driver fixed the flash operation error on MPC8641HPCN board. Since there > is not such flash error reported on 85xx, 83xx platform and as Tolunay > said, there is not a PowerPC macro to define, I just use CONFIG_MPC86xx > for now. I also tested his second suggestion(adding udelay directly > after reset command), but flash still failed to work. > > Based on my tests before (I added udelay after the flash_write_cmd() > which switched flash to CFI read mode, and it worked as well) and the > test with this patch, I think that most possible fix of this issue > should > be that we should make sure command has been fully executed before > return to data read mode(as in his first suggestion). So please review > this patch below: > > drivers/cfi_flash.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/drivers/cfi_flash.c b/drivers/cfi_flash.c > index 696f9a4..a93e94d 100644 > --- a/drivers/cfi_flash.c > +++ b/drivers/cfi_flash.c > @@ -971,6 +971,9 @@ static void flash_write_cmd (flash_info_t * info, > flash_sect_t sect, uint offset > #endif > break; > } > +#ifdef CONFIG_MPC86xx > + asm("sync;"); > +#endif > } > > static void flash_unlock_seq (flash_info_t * info, flash_sect_t sect) </snip> Your U-Boot support team

1 0

[U-Boot-Users] [DNX#2007020542000011] [PATCH] Fix initrd length miscalculation in bootm command
by U-Boot patch tracking system 05 Feb '07

05 Feb '07

Dear Mr. U. Boot, thank you for your contribution to the U-Boot project. Your e-mail was registered at our system under the ticket number [DNX#2007020542000011]. Please keep this ticket ID string in the subject line of any e-mail replies!!! Your U-Boot support team Powered by OTRS (http://otrs.org/)

1 0

[U-Boot-Users] [DNX#2007020542000011] [PATCH] Fix initrd length miscalculation in bootm [...]
by OTRS Notification Master 05 Feb '07

05 Feb '07

Hello list, inside the automatic U-Boot patch tracking system a new ticket [DNX#2007020542000011] was created: <snip> > The do_bootm_linux() function was using the same variable ('len') to > calculate > the the dtu length and the initrd length, which meant that the initrd > length > was incorrect. This patch creates renames 'len' and 'data' to > 'initrd_len' > and 'initrd_data', thereby preventing any future confusion. It also > deletes > 'len' and 'data' because the dtu calculations don't actually need them. > > Signed-off-by: Timur Tabi <timur(a)freescale.com> > --- > common/cmd_bootm.c | 57 > +++++++++++++++++++++++---------------------------- > 1 files changed, 26 insertions(+), 31 deletions(-) > > diff --git a/common/cmd_bootm.c b/common/cmd_bootm.c > index 7aae8a6..0c092c7 100644 > --- a/common/cmd_bootm.c > +++ b/common/cmd_bootm.c > @@ -518,11 +518,10 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl > int verify) > { > ulong sp; > - ulong len, checksum; > - ulong initrd_start, initrd_end; > + ulong checksum; > + ulong initrd_start, initrd_end, initrd_data, initrd_len; > ulong cmd_start, cmd_end; > ulong initrd_high; > - ulong data; > int initrd_copy_to_ram = 1; > char *cmdline; > char *s; > @@ -626,7 +625,7 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl > /* Look for a '-' which indicates to ignore the ramdisk argument */ > if (argc >= 3 && strcmp(argv[2], "-") == 0) { > debug ("Skipping initrd\n"); > - len = data = 0; > + initrd_len = initrd_data = 0; > } > else > #endif > @@ -647,13 +646,10 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl > do_reset (cmdtp, flag, argc, argv); > } > > - data = (ulong)&header; > - len = sizeof(image_header_t); > - > checksum = ntohl(hdr->ih_hcrc); > hdr->ih_hcrc = 0; > > - if (crc32 (0, (uchar *)data, len) != checksum) { > + if (crc32 (0, (uchar *) &header, sizeof(image_header_t)) != checksum) > { > puts ("Bad Header Checksum\n"); > SHOW_BOOT_PROGRESS (-11); > do_reset (cmdtp, flag, argc, argv); > @@ -663,13 +659,13 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl > > print_image_hdr (hdr); > > - data = addr + sizeof(image_header_t); > - len = ntohl(hdr->ih_size); > + initrd_data = addr + sizeof(image_header_t); > + initrd_len = ntohl(hdr->ih_size); > > if (verify) { > ulong csum = 0; > #if defined(CONFIG_HW_WATCHDOG) || defined(CONFIG_WATCHDOG) > - ulong cdata = data, edata = cdata + len; > + ulong cdata = initrd_data, edata = cdata + initrd_len; > #endif /* CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG */ > > puts (" Verifying Checksum ... "); > @@ -687,7 +683,7 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl > WATCHDOG_RESET(); > } > #else /* !(CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG) */ > - csum = crc32 (0, (uchar *)data, len); > + csum = crc32 (0, (uchar *) initrd_data, initrd_len); > #endif /* CONFIG_HW_WATCHDOG || CONFIG_WATCHDOG */ > > if (csum != ntohl(hdr->ih_dcrc)) { > @@ -718,17 +714,17 @@ do_bootm_linux (cmd_tbl_t *cmdtp, int fl > SHOW_BOOT_PROGRESS (13); > > /* skip kernel length and terminator */ > - data = (ulong)(&len_ptr[2]); > + initrd_data = (ulong)(&len_ptr[2]); > /* skip any additional image length fields */ > for (i=1; len_ptr[i]; ++i) > - data += 4; > + initrd_data += 4; > /* add kernel length, and align */ > - data += ntohl(len_ptr[0]); > + initrd_data += ntohl(len_ptr[0]); > if (tail) { > - data += 4 - tail; </snip> Your U-Boot support team

1 0

[U-Boot-Users] I can't debug U-BOOT after relocation in ram
by Patrick URIE 05 Feb '07

05 Feb '07

Hello, I try to debug U-boot in flash with GDB version 6.5 + BDI 2000. I have followed topic about RAM relocation from DENX web. but when U-BOOT is relocated in Ram, I cant stop it at board_init_r(). My custom Board configuration is: Hardware : --------------- -MPC875, -64MB (Top address 0x4000000) -2MB flash Software : --------------- U-BOOT 1.4.4 in flash at 0xFE000000 Relocation address (read in R5 register) is 0x3FB00000 DER register value is 0x2006000F Thank you for your reply. --------------------------------------- Urié Patrick Software engineer ReFLEX Custom Embedded Systems 6, rue du Velay - SILIC 1743 Lisses 91047 EVRY Cedex - FRANCE Phone : +33 (0) 169 870 255 (ext. 140) Fax : +33 (0) 164 972 859 ---------------------------------------

2 2

[U-Boot-Users] [PATCH] gth2 board variable
by Thomas Lange 05 Feb '07

05 Feb '07

Remove locally declared variable from board file since it already exists in common/cmd_ide.c. Signed-off-by: Thomas Lange <thomas(a)corelatus.se>

1 0

[U-Boot-Users] smsc lan9115
by Junior 03 Feb '07

03 Feb '07

Hello, Have anyone written a driver for the smsc LAN9115 ethernet device as yet? Thanks, --jr.

1 0

[U-Boot-Users] [Attn: Joe Loelinger] Re: [PATCH] Fix up flash_read_uchar() to read uchar more safely in cfi_flash.c.
by Tolunay Orkun 02 Feb '07

02 Feb '07

I have to send this to Joe Loelinger through the list due to an blacklisting issue. Direct mail bounced with the following error: ----- The following addresses had permanent fatal errors ----- <jdl(a)jdl.com> (reason: 550-sender IP address 207.115.20.70 is locally blacklisted here. If you think) I have to send via my ISP mail server "smtp.sbcglobal.net" even though I am using orkun.us as my email. The IP is assigned by PPPoE. Regards, Tolunay Tolunay Orkun wrote: > Jon Loeliger wrote: >> From: Zhang Wei <wei.zhang(a)freescale.com> >> >> Signed-off-by: Zhang Wei <wei.zhang(a)freescale.com> >> Signed-off-by: Jon Loeliger <jdl(a)freescale.com> >> >> --- >> Tolunay, >> >> What do you think of this proposed solution to the problem >> of handling the flash read width issue that we were having >> with the 8641 HPCN board? >> >> If you think this is an acceptable approach, I can resubmit >> this patch to the U-Boot list if you'd like. >> >> Thanks, >> jdl >> > > I think the approach is sound except I have a few comments below. > > Meanwhile, the debugging lead me to conclude the flash_read_uchar() is > not really the root cause of your problem. > > Please refer to email exchange I had with Haiying yesterday. We > probably need to add "asm("sync;"); to flash_write_cmd() and/or > udelay(); after reset. > >> drivers/cfi_flash.c | 30 ++++++++++++++++++++++++++---- >> 1 files changed, 26 insertions(+), 4 deletions(-) >> >> diff --git a/drivers/cfi_flash.c b/drivers/cfi_flash.c >> index 696f9a4..d109c5e 100644 >> - --- a/drivers/cfi_flash.c >> +++ b/drivers/cfi_flash.c >> @@ -255,13 +255,35 @@ #endif >> */ >> inline uchar flash_read_uchar (flash_info_t * info, uint offset) >> { >> - - uchar *cp; >> + union { >> + u8 c; >> + u16 s; >> + u32 l; >> + u64 ll; >> + u8 b[FLASH_CFI_64BIT]; >> + } cp; >> > Instead of a anonymous union use cfiword_t and cfiptr_t just like > flash_write_cmd() does. Remember to use "volatile" for pointer of type > cfiptr_t. > > You will need to augment cfiword_t union for byte access to individual > bytes (i.e. u8 b[FLASH_CFI_64BIT]); > > In addition to this, we need to rework, flash_read_ushort() and > flash_read_long() similarly for portwidth based accesses. Currently, > like flash_read_uchar() these are reading single bytes; > > Best regards, > Tolunay >

2 1

[U-Boot-Users] Query : How to change PLL1 frequency of u-boot
by Rahul Patel 02 Feb '07

02 Feb '07

Hello, I want to make change in frequency of PLL1. For that I made change in multiplier register of PLL1 in board/<board-name>/platform.S file. But it didn't get reflect. So, Can you please guide me What should I do to make change in PLL1 o/p frequency? Thanks & Regards, *Rahul K. Patel,* Embedded Engineer, eInfochips Ltd., Ahmedabad - 380006.

1 0