August 2010 - U-Boot

Re: [U-Boot] [RFD] store env size in env area (+ cookie + len)
by Matthias Weißer 12 Aug '10

12 Aug '10

Am 12.08.2010 09:54, schrieb Frans Meulenbroeks: > 2010/8/12 Matthias Weißer<weisserm(a)arcor.de>: >> Why not store the size of the environment sector as env variable? The size >> should be only needed for storing the environment and not for loading (as it >> is terminated by a '\0'). So we could load the environment, check for >> "env_size" and if its not there take the value from fw_env.config > > Currently the crc of the environment is calculated and if it does not > match with the stored crc the default environment is used. > For determining the crc the size is needed so storing the size in the > env creates some form of catch-22. Of course the code could be > modified to first peek at the unverified env to find the size. > That is a different approach. Imho not too neat. I see. I was thinking that the CRC is only calculated over the environment until the '\0' end mark is reached. But after checking my environment code I see that the CRC is calculated over the whole sector. > Wrt the format: I understood from the mail from Reinhard that the way > the env is stored is going to change anyway. I saw the patches of > Wolfgang pass by, but didn't have time to study them yet. I also didn't go that deep into Wolfgangs patches but from what I understand the "on disk format" will not change. Will it? Maybe the size could be added at the end of the environment (behind the '\0'). So we wouldn't loose compatibility. Matthias

3 7

[U-Boot] Urgent Attention.
by Mr. Paul Wolfenden 12 Aug '10

12 Aug '10

-- Good Day I am Mr. Paul Wolfenden, Manager of formal ABN AMRO BANK which has been bought out by the RBS BANK 250 Bishopsgate, London EC2M 4AA . I have a business proposal valued at GBP£21,000,000.00 (Twenty-One Million Pounds) from my Branch.Get back to me to enable me furnish you with full information concerning this letter via by email. Email: paul_wolfenden_00(a)w.cn Regards. NOTE = direct your response to this email for more information and for the sake of confidentiality [ paul_wolfenden_00(a)w.cn] ________________________________________________ This message was sent using Dodo Webmail - www.dodo.com.au

1 0

[U-Boot] Urgent Attention.
by Mr. Paul Wolfenden 12 Aug '10

12 Aug '10

-- Good Day I am Mr. Paul Wolfenden, Manager of formal ABN AMRO BANK which has been bought out by the RBS BANK 250 Bishopsgate, London EC2M 4AA . I have a business proposal valued at GBP£21,000,000.00 (Twenty-One Million Pounds) from my Branch.Get back to me to enable me furnish you with full information concerning this letter via by email. Email: paul_wolfenden_00(a)w.cn Regards. NOTE = direct your response to this email for more information and for the sake of confidentiality [ paul_wolfenden_00(a)w.cn] ________________________________________________ This message was sent using Dodo Webmail - www.dodo.com.au

1 0

[U-Boot] [PATCH] USB-CDC: Added debug output to ether.c
by Stefano Babic 12 Aug '10

12 Aug '10

Use DEBUG as usual to print debug output. Signed-off-by: Stefano Babic <sbabic(a)denx.de> --- drivers/usb/gadget/ether.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/usb/gadget/ether.c b/drivers/usb/gadget/ether.c index 3d871fa..e0ebf75 100644 --- a/drivers/usb/gadget/ether.c +++ b/drivers/usb/gadget/ether.c @@ -31,7 +31,11 @@ #include "gadget_chips.h" #define USB_NET_NAME "usb0" +#ifdef DEBUG +#define dprintf printf +#else #define dprintf(x, ...) +#endif #undef INFO #define INFO(x, s...) printf(s) #define dev_err(x, stuff...) printf(stuff) -- 1.6.3.3

3 4

[U-Boot] BDI3000 configuration for AppliedMicro 460EX revB
by Felix Radensky 12 Aug '10

12 Aug '10

Hi, Can someone please share a BDI3000 configuration for u-boot/kernel debugging on 460EX revB. Thanks a lot in advance. Felix.

2 2

[U-Boot] [RFD] store env size in env area (+ cookie + len)
by Frans Meulenbroeks 12 Aug '10

12 Aug '10

I've seen a few times that people get a u-boot with their board and want to use fw_setenv under linux to tweak with environment variables. This requires them to come up with an fw-env.config (if not provided). One of the things that I've seen, that some people have trouble with it is obtaining the proper size of the environment area to be stuffed in that file. This is something that could be resolved quite easily by adding the size of the environment area to the header preceding the environment (which now contains a checksum and, in case of redundant areas, a flag byte) Pro: no more need to give sizes in fw-env.config Con: uses a 2-4 more bytes (personally I'd say size is 4 bytes just to be safe) Con: not compatible with current env layout so (without precautions) a new u-boot cannot use the old env and vice versa. If compatibility is deemed important, we could extend the header also with a magic cookie and a version number. If absent it is an old style env, if present it is a new style env. Version number then can also be used should there be future changes in the env layout. (if compatibility is not deemed important of course this is not needed). Btw thinking about cookies: if the env were to have a cookie in either the header or e.g. as first env var, fw_setenv would not even need fw-env.config at all. It could just seek in /dev/mtd (I'm assuming env in flash here) for the cookie. This seeking should not take too much time if we can assume (or have a config var) a certain alignment (e.g. on flash page size). After finding the cookie of course still a crc check would be done to validate the area. If desired I can do some implementation work for this and submit a patch, but before investing time in it I would like to find out if there is actual interest in this and if this is considered useful. Summarizing the questions: - is it desirable to have the env length added to the env header - is it desirable to have a cookie added to the env header - is it desirable to have a version number added to the env header Best regards, Frans. PS: if we are going to touch the env header, I would suggest to always have the redundant flag in the header even if there is only one environment. It will probably make the code to load the env a little bit simpler).

5 5

[U-Boot] hi
by justina benson 12 Aug '10

12 Aug '10

My Name is justina i am seeking for a honest partner i hope you don't mind if you don't mind please reply my mail so i can tell you more about myself and we can exchange picture too

1 0

[U-Boot] [PATCH] mpc5xxx_fec/motionpro: disable PHY initialization on motionpro board
by Ilya Yanok 12 Aug '10

12 Aug '10

Historically PHY intialization was disabled on motionpro board. Then at some point PHY init was enabled and only comment message was left. It worked somehow provided that PHY init was done at the early stage. But after commit f5cf2ef the driver initializes PHY only when it is actually needed and now Ethernet on motionpro board is broken again. I haven't managed to find the true reason of such behavior so I've just disabled PHY initialization on motionpro board. Signed-off-by: Ilya Yanok <yanok(a)emcraft.com> --- drivers/net/mpc5xxx_fec.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/mpc5xxx_fec.c b/drivers/net/mpc5xxx_fec.c index c88e596..5ea87f1 100644 --- a/drivers/net/mpc5xxx_fec.c +++ b/drivers/net/mpc5xxx_fec.c @@ -429,6 +429,7 @@ static int mpc5xxx_fec_init_phy(struct eth_device *dev, bd_t * bis) * PHY initialization for the Motion-PRO board, until a proper fix is found. */ +#ifndef CONFIG_MOTIONPRO if (fec->xcv_type != SEVENWIRE) { /* * Set MII_SPEED = (1/(mii_speed * 2)) * System Clock @@ -561,6 +562,7 @@ static int mpc5xxx_fec_init_phy(struct eth_device *dev, bd_t * bis) if (fec->xcv_type != SEVENWIRE) mpc5xxx_fec_phydump (dev->name); #endif +#endif /* CONFIG_MOTIONPRO */ #if (DEBUG & 0x1) -- 1.7.0.4

1 1

[U-Boot] [PATCH] cmd_elf: add an option for loading ELFs according to PHDRs
by Mike Frysinger 12 Aug '10

12 Aug '10

The current ELF loading function does a lot of work above and beyond a simple "loading". It ignores the real load addresses and loads things into their virtual (runtime) address. This is undesirable when we just want it to load an ELF and let the ELF do the actual C runtime init. So add a command line option to let people choose to load via either the program or section headers. I'd prefer to have program header loading be the default, but this would break historical behavior, so I'll leave section header loading as the norm. Signed-off-by: Mike Frysinger <vapier(a)gentoo.org> --- common/cmd_elf.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++------- 1 files changed, 53 insertions(+), 9 deletions(-) diff --git a/common/cmd_elf.c b/common/cmd_elf.c index 104d6e6..bf32612 100644 --- a/common/cmd_elf.c +++ b/common/cmd_elf.c @@ -25,7 +25,8 @@ DECLARE_GLOBAL_DATA_PTR; #endif int valid_elf_image (unsigned long addr); -unsigned long load_elf_image (unsigned long addr); +static unsigned long load_elf_image_phdr(unsigned long addr); +static unsigned long load_elf_image_shdr(unsigned long addr); /* Allow ports to override the default behavior */ __attribute__((weak)) @@ -61,19 +62,34 @@ int do_bootelf (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) { unsigned long addr; /* Address of the ELF image */ unsigned long rc; /* Return value from user code */ + char *sload, *saddr; /* -------------------------------------------------- */ int rcode = 0; - if (argc < 2) - addr = load_addr; + sload = saddr = NULL; + if (argc == 3) { + sload = argv[1]; + saddr = argv[2]; + } else if (argc == 2) { + if (argv[1][0] == '-') + sload = argv[1]; + else + saddr = argv[1]; + } + + if (saddr) + addr = simple_strtoul(saddr, NULL, 16); else - addr = simple_strtoul (argv[1], NULL, 16); + addr = load_addr; if (!valid_elf_image (addr)) return 1; - addr = load_elf_image (addr); + if (sload && sload[1] == 'p') + addr = load_elf_image_phdr(addr); + else + addr = load_elf_image_shdr(addr); printf ("## Starting application at 0x%08lx ...\n", addr); @@ -204,7 +220,7 @@ int do_bootvx (cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) */ if (valid_elf_image (addr)) { - addr = load_elf_image (addr); + addr = load_elf_image_shdr (addr); } else { puts ("## Not an ELF image, assuming binary\n"); /* leave addr as load_addr */ @@ -258,7 +274,33 @@ int valid_elf_image (unsigned long addr) * A very simple elf loader, assumes the image is valid, returns the * entry point address. * ====================================================================== */ -unsigned long load_elf_image (unsigned long addr) +static unsigned long load_elf_image_phdr(unsigned long addr) +{ + Elf32_Ehdr *ehdr; /* Elf header structure pointer */ + Elf32_Phdr *phdr; /* Program header structure pointer */ + int i; + + ehdr = (Elf32_Ehdr *) addr; + phdr = (Elf32_Phdr *) (addr + ehdr->e_phoff); + + /* Load each program header */ + for (i = 0; i < ehdr->e_phnum; ++i) { + void *dst = (void *) phdr->p_paddr; + void *src = (void *) addr + phdr->p_offset; + debug("Loading phdr %i to 0x%p (%i bytes)\n", + i, dst, phdr->p_filesz); + if (phdr->p_filesz) + memcpy(dst, src, phdr->p_filesz); + if (phdr->p_filesz != phdr->p_memsz) + memset(dst + phdr->p_filesz, 0x00, phdr->p_memsz - phdr->p_filesz); + flush_cache((unsigned long)dst, phdr->p_filesz); + ++phdr; + } + + return ehdr->e_entry; +} + +static unsigned long load_elf_image_shdr(unsigned long addr) { Elf32_Ehdr *ehdr; /* Elf header structure pointer */ Elf32_Shdr *shdr; /* Section header structure pointer */ @@ -312,9 +354,11 @@ unsigned long load_elf_image (unsigned long addr) /* ====================================================================== */ U_BOOT_CMD( - bootelf, 2, 0, do_bootelf, + bootelf, 3, 0, do_bootelf, "Boot from an ELF image in memory", - " [address] - load address of ELF image." + "[-p|-s] [address]\n" + "\t- load ELF image at [address] via program headers (-p)\n" + "\t or via section headers (-s)" ); U_BOOT_CMD( -- 1.7.2

1 0

[U-Boot] (G)PIO access trends, architecture independant solutions?
by Reinhard Meyer 12 Aug '10

12 Aug '10

Hello all, recently a patch for soft-i2c has been accepted that uses gpio_* functions. Supposedly they are generic, but grep-ing shows that such functions only exist in the nios2 architecture. Every architecture seems to have their own similiar but not identical way for gpio access. At91 even has two ways where the IMHO better way is depreciated... The better way IMHO is when Port and Bit are together in one parameter. I also like the possibility of some solutions to 'request' a pin. So, before potentially reworking the at91 solution(s), I'd like to have some input/insight if there is a tendency towards a generalization across all architectures? Ideally, that could start with introducing a "gpio.h" header file outside an architecture specific path. Naturally, the multitude of designs of GPIO ports might make it difficult to unify the access functions... Reinhard

2 1