June 2005 - U-Boot

[U-Boot-Users] Erase in UBoot
by Bharathi Subramanian 30 Jun '05

30 Jun '05

Hello All, We are using UBoot 1.0.0, During continuous 2nd erase operation, the no .of DOT is increased. I like to know whether this is something do with UBoot or flash chip or is it normal behavior ?? ROM # erase B0100000 B07FFFFF .............................................. done Erased 111 sectors ROM # erase B0100000 B07FFFFF ..................................................... done Erased 111 sectors ROM # Thanks, -- Bharathi S

3 2

[U-Boot-Users] [PATCH] - OMAP242x/ARM1136 + H4 board (30-Jun-2005)
by Woodruff, Richard 30 Jun '05

30 Jun '05

Hello Wolfgang, Hopefully, this is the last update for a while. As they are slow to enter the tree I've been refreshing the patch. Please discard previous ones and use this one. This patch is against a 30 Jun 05 CVS head. I look forward to you getting time to actually working some of the backlog. Additional updates in this patch include ability to run the DDR in lock or unlock mode, and a fix to make all newer 2422 chips work. * Patch by Richard Woodruff, 30 Jun 2005: OMAP242x H4 board update, 30 June 05 - fix for ES2(.05,.1) differences. - switch to using the cfi_flash driver. - fix SRAM build address - fix for GP device operation - unlock SRAM for GP devices. - display more device information at startup. - fix potential deadlock in omap24xx_i2c driver. - fix DLL load values to match dpllout*1 operation. - fix 2nd chip select init for combo DDR device. - fix for 2422 rev > ES2 mono DDR. - add conditional DDR lock/unlock usage. drivers/serial.c,ns16550.c - remove obsolete APTIX conditionals. cfi_flash.c - add support for CFI Intel 28F256L18 on H4 board. Regards, Richard W. > -----Original Message----- > From: Woodruff, Richard > Sent: Tuesday, May 31, 2005 3:56 PM > To: u-boot-users(a)lists.sourceforge.net; 'Wolfgang Denk' > Subject: [PATCH] - OMAP242x/ARM1136 + H4 board. > > Hello Wolfgang, > > Here is an updated patch for the OMAP242x against the CVS as of 31 May 05. > This code runs against all current versions of the OMAP242x chip on the H4 > reference platform. > > All updates are confined to 242x specific directories except for a small > change to the CFI driver. The CFI driver makes some small incorrect > assumptions when it comes to Intel parts which have partitioning in > addition to sectoring. > > I sent out a now somewhat stale patch a couple months back in which I have > _not_ heard any comment on. Please discard that one and apply this > instead. If there any problems with this please let me know. > > OMAP242x H4 board update, 31 May 05 > - fix for ES2(.05,.1) differences. > - switch to using the cfi_flash driver. > - fix SRAM build address > - fix for GP device operation > - unlock SRAM for GP devices. > - display more device information at startup. > - fix potential deadlock in omap24xx_i2c driver. > - fix DLL load values to match dpllout*1 operation. > - fix 2nd chip select init for combo DDR device. > cfi_flash.c > - add support for CFI Intel 28F256L18 on H4 board. > > Regards, > Richard W.

1 0

RE: RE: [U-Boot-Users] Does u-boot relocate absolute symbols?
by Rune Torgersen 30 Jun '05

30 Jun '05

Wow.... This surprises me... I have alwayts thought that *test and test[] would be the same thing. Only solutionI can see is to change the definition in common.c to be *test, this will still get the address of test[] defined elsewhere. (See attached files) > Sure, I've tried this. This is the point, where my problem > arose. Attached you find two > small files, you can easily compile under linux (gcc -o > arrtest -I ./ ./common.c > ./array.c). The file "common.c" represents the code I can't > (don't want to) touch. > "array.c" represents my project dependent code. If you run > arrtest it will show to you,

2 1

[U-Boot-Users] 8540 and L1 cache mapping
by Charles J Gillan 30 Jun '05

30 Jun '05

Recently I have been studying the boot sequence for the 8540 based boards in U-Boot. I have a question on the location of the initial C stack. As I understand it, cpu/mpc85xx/start.S uses L1 data cache as the location for the C stack prior to the relocation into RAM. CFG_INIT_RAM_ADDR is defined within the relevant config file for each 6540 based board. I see in the 8540 User Manual that there is a register which can be used to position L2 cache in physical address space but there does not appear to be a similar register for L1 cache. However, I see that in the init.S files, for each board, entries are placed into TLB0 for memory at address CFG_INIT_RAM_ADDR. This is declared as cacheable and non-garded. Am I correct in thinking that this is all that is required to position the C run-time stack in L1 D-cache ? Thanks, Charles. -------------------------------------------------------------------------- Dr Charles J Gillan The Institute of Electronics, Communications and Information Technology (ECIT), Queen's University Belfast, Titanic Quarter Queens Road, Queens Island, Belfast, BT3 9DT Northern Ireland, UK Tel: +44 (0) 2890 971847 Fax: +44 (0) 2890 971702 ---------------------------------------------------------------------------

2 1

[U-Boot-Users] [PATCH] expand macros in bootargs env var for bootm command
by Murray.Jensen＠csiro.au 30 Jun '05

30 Jun '05

This patch expands $(...) macros present in the bootargs environment variable for the bootm command. Same code could be (and probably should be, for consistencies sake) used in other boot commands. Required exposing the "process_macros()" function in common/main.c. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 5

[U-Boot-Users] [PATCH] limit length of kernel command line in bootm
by Murray.Jensen＠csiro.au 30 Jun '05

30 Jun '05

This patch limits the length of the command line that the bootm command will pass to the kernel. Note that as it stands, it uses CFG_BARGSIZE which must be <= the size of the command line array used in the kernel (most boards have this set to CFG_CBSIZE, which in turn is usually 256 - which is usually ok). I use 1024 for both, and have a kernel patch which increases the command line aray to 1024. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 4

[U-Boot-Users] [PATCH] allow flash "ranges" to default to end of flash
by Murray.Jensen＠csiro.au 30 Jun '05

30 Jun '05

This patch modifies the flash "range" code slightly to allow a range to "default" to the "end of the bank". Currently, you must specify "<first>-<last>" where <first> and <last> are sector numbers (zero based) within the "bank". This code allows you to say "<first>-" and <last> will default to the sector number of the last sector in the "bank". I thought I needed this - but now I don't use it anymore. However, the code might still be useful to someone. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 4

[U-Boot-Users] [PATCH] fix build without CONFIG_NET_MULTI
by Murray.Jensen＠csiro.au 30 Jun '05

30 Jun '05

This is an older patch which fixed building without CONFIG_NET_MULTI. I'm not sure if its still required or not, since I now use CONFIG_NET_MULTI when building for my boards. I guess it might help someone if they search the list after striking a similar problem. I would think this would need some testing before it gets applied to the central repository. Cheers! Murray... -- Murray Jensen, CSIRO Manufacturing & Infra. Tech. Phone: +61 3 9662 7763 Locked Bag No. 9, Preston, Vic, 3072, Australia. Fax: +61 3 9662 7853 Internet: Murray.Jensen(a)csiro.au To the extent permitted by law, CSIRO does not represent, warrant and/or guarantee that the integrity of this communication has been maintained or that the communication is free of errors, virus, interception or interference. The information contained in this e-mail may be confidential or privileged. Any unauthorised use or disclosure is prohibited. If you have received this e-mail in error, please delete it immediately and notify Murray Jensen on +61 3 9662 7763. Thank you.

2 2

RE: [U-Boot-Users] Does u-boot relocate absolute symbols?
by Rune Torgersen 30 Jun '05

30 Jun '05

I just have to comment on this. > It does not work (because it's simply wrong) to declare > fpgadata as follows in pf5200.c > (although looking good in the first place, if you think about > it, the compiler needs to > handle both declarations differently): > > const unsigned char *fpgadata = 0x400000; /* (with 0x400000 > being the address to store > the image with TFTP at) */ > Have you tried to do this? Because it should work (even if one is declared char [] and the other char *) I use something similar to access a FPGA binary image stored in flash (after U-Boot relocation) and it works.

4 7

[U-Boot-Users] EP8248 as a PCI card
by Nishant Galange 30 Jun '05

30 Jun '05

Thanks, Yuli Got the patch, u-boot 1.1.2 installed and running on my ep8248 board. In standalone mode. When I try to use the EP8248 (with u-boot 1.1.2) as a PCI card in my PC (desktop), the PC doesn't even power up. But when the same card, with PlanetCore bootloader (the bootloader that came with the card), is inserted in the same PCI slot, the PC powers on, Windows XP starts up and even detects the card as a "Other PCI bridge" device. What change(s) do I have to make in the u-boot code to make it work as a PCI card in my PC? I have already tried the following: #define CONFIG_PCI in include/configs/EP8248.h Because of the above #define, I had to write a pci_init_board() function in board/ep8248/ep8248.c This function simply creates a pci_controller 'hose' and calls pci_mpc8250_init(&hose); With all this, now my PC boots up with the EP8248 + u-boot, but Windows can't detect the card. How do I proceed? What changes should I make? Waiting, Nishant -----Original Message----- From: Yuli Barcohen <yuli(a)arabellasw.com> To: "Nishant Galange" <nishant.subs(a)myrealbox.com> Date: Wed, 29 Jun 2005 11:42:55 +0300 Subject: Re: where is the EP8248 patch? >>>>> Nishant Galange writes: Nishant> Hi Yuli On 12 Dec 2004, You posted a patch for the Embedded Nishant> Planet EP8248 board. How do I download this patch? >From the GMANE archive which was mentioned many times on this list. Nishant> Is it already included in u-boot 1.1.2? No AFAIK. It's probably on Wolfgang's list. Nishant> Once I have all the necessary source code (with the patch Nishant> incorporated), what command(s) do I give to compile u-boot Nishant> 1.1.2 for the EP8248 board? Nishant> Will the following work: Should be OK. Nishant> $ export CROSS_COMPILE=ppc_82xx- Nishant> $ export PATH=[path_to_ELDK]:$PATH Nishant> $ make EP8248_config Nishant> $ make -- ======================================================================== Yuli Barcohen | Phone +972-9-765-1788 | Software Project Leader yuli(a)arabellasw.com | Fax +972-9-765-7494 | Arabella Software, Israel ========================================================================

2 1