[U-Boot-Users] u-boot for Vertex4-based board.
Hi:
I'm porting u-boot on Vertex-4 based board (with PPC405 inside); I'm trying use ml403 u-boot as example. I have first stage boot loader, taking my u-boot image from serial and loading it to SDRAM, u-boot is configured to boot from main memory.
Several questions:
1) I'm using ELDK 3.1.1 as crosstool; which target should I choose: ppc_4xxFP or ppc_4xx?
2) My board unlike ML403 has UARTLITE for serial interface. Can I use serial_xuartlite.c from microblaze directory?
Thanks,
Leonid.
Dear Leonid,
"Leonid" Leonid@a-k-a.net writes:
I'm porting u-boot on Vertex-4 based board (with PPC405 inside); I'm trying use ml403 u-boot as example. I have first stage boot loader, taking my u-boot image from serial and loading it to SDRAM, u-boot is configured to boot from main memory.
Are you aware that this setup is strongly discouraged? Have you read this:
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted... ?
Regards
Markus Klotzbuecher
-- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
On 2/13/07, Markus Klotzbücher mk@denx.de wrote:
Dear Leonid,
"Leonid" Leonid@a-k-a.net writes:
I'm porting u-boot on Vertex-4 based board (with PPC405 inside); I'm trying use ml403 u-boot as example. I have first stage boot loader, taking my u-boot image from serial and loading it to SDRAM, u-boot is configured to boot from main memory.
Are you aware that this setup is strongly discouraged? Have you read this:
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarted... ?
That's not necessarily relevant when using the virtex parts. His only option might be to boot from SDRAM. I've got a number of Virtex designs where the SystemACE (FPGA loader hardware) loads code into SDRAM after the FPGA is configured.
That being said; I actually use a 3 stage loading process. I have an early boot loader which fits into Block RAM (BRAM, on chip memory) in the fpga. Earlyboot loads a u-boot image off of the CF card which is attached to the system ace. When u-boot starts, it is already in RAM. In the past, I have bypassed the relocation code so I can run u-boot from where it was linked; but now I link u-boot to the base of ram and let the standard relocation code move it to the top of ram. It's kind of an unnecessary copy; but I don't need to fiddle with the code as much.
BTW, Leonid; You want to use ppc_4xx, not ppc_4xxFP. I don't know about the uartlite driver.
Cheers, g.
Regards
Markus Klotzbuecher
-- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Behalf Of Grant Likely On Wednesday, February 14, 2007 6:28 AM Grant Likely:
Are you aware that this setup is strongly discouraged? Have you read
That's not necessarily relevant when using the virtex parts. His only option might be to boot from SDRAM. I've got a number of Virtex designs where the SystemACE (FPGA loader hardware) loads code into SDRAM after the FPGA is configured.
[Leonid] It's also not relevant for many ARM platforms as I wrote in my answer on Marcus' posting. In any rate I don't see anything specifically evil in such setup, quite opposite, it's much more convenient for debug since allows to reload code very quickly. I think I could resort to traditional for PPC (and probably for u-boot, being in the past PPCboot) loading algorithm in future if will see it fit.
That being said; I actually use a 3 stage loading process. I have an early boot loader which fits into Block RAM (BRAM, on chip memory) in the fpga. Earlyboot loads a u-boot image off of the CF card which is attached to the system ace. When u-boot starts, it is already in RAM.
[Leonid] I do precisely the same on many platforms. U-boot doesn't work on this particular board yet, but that to be expected - the board is new.
In the past, I have bypassed the relocation code so I can run u-boot from where it was linked;
[Leonid] You just commented out relocation function? Can you send me your change if you have saved one to try?
but now I link u-boot to the base of ram and let the standard relocation code move it to the top of ram. It's kind of an unnecessary copy; but I don't need to fiddle with the code as much.
[Leonid] Agree.
BTW, Leonid; You want to use ppc_4xx, not ppc_4xxFP. I don't know about the uartlite driver.
[Leonid] I use ppc_4xx, now I'm running Kegel cross tool - all the same.
BTW, could you manage source level debug for you target? I download elf file via XMD and then try to connect GDB remotely, but addresses GDB show have nothing to do with real address (u-boot is located on 0x01f00000):
leonid@mylinux u-boot-1.1.4]$ ~/gdb-ppc/gdb/gdb -symbols=u-boot.map u-boot GNU gdb 6.4 Copyright 2005 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "--host=i686-pc-linux-gnu --target=powerpc-linux"... (gdb) target remote 192.168.0.70:1234 Remote debugging using 192.168.0.70:1234 0x00000000 in ?? () (gdb) where #0 0x00000000 in ?? () #1 0x01f0c8fc in env_init () at env_flash.c:270 #2 0x01f0c8fc in env_init () at env_flash.c:270 #3 0x01f0c8fc in env_init () at env_flash.c:270 #4 0x01f0c8fc in env_init () at env_flash.c:270 #5 0x01f0c8fc in env_init () at env_flash.c:270 Previous frame inner to this frame (corrupt stack?) (gdb)
Thanks,
Leonid.
On 2/14/07, Leonid Leonid@a-k-a.net wrote:
Behalf Of Grant Likely
In the past, I have bypassed the relocation code so I can run u-boot from where it was linked;
[Leonid] You just commented out relocation function? Can you send me your change if you have saved one to try?
It's pretty trivial stuff. I don't have a patch for you, but go into start.S and look for the relocate_code symbol. All the stuff between there and clear_bss is strictly relocation code. I just exported the clear_bss symbol and called it from board_init_f! (but I had to fix up some of the calling parameters first. *HUGE* hack, but it worked. :) I don't do this any more though.
(hint: add #define DEBUG above the includes in board.c)
BTW, Leonid; You want to use ppc_4xx, not ppc_4xxFP. I don't know about the uartlite driver.
[Leonid] I use ppc_4xx, now I'm running Kegel cross tool - all the same.
BTW, could you manage source level debug for you target? I download elf file via XMD and then try to connect GDB remotely, but addresses GDB show have nothing to do with real address (u-boot is located on 0x01f00000):
You need to load the symbol table at an offset. I think you use the add-symbol-file command. The details are in the u-boot documentation somewhere.
Cheers, g.
On Wednesday, February 14, 2007 9:35 AM Grant Likely:
I don't do this any more though.
Actually, I have got u-boot working without that "dirty trick" already.
You need to load the symbol table at an offset. I think you use the add-symbol-file command. The details are in the u-boot documentation somewhere.
Well, I expect that BEFORE relocation it must work without any special table be loaded. DULG says so and I have personal experience with Yosemite board. After all, ELF file is compiled with 0x01f00000 address and that where u-boot is loaded...
Thanks a lot,
Leonid.
On Tuesday, February 13, 2007 10:55 PM Markus Klotzbücher:
I'm porting u-boot on Vertex-4 based board (with PPC405 inside); I'm trying use ml403 u-boot as example. I have first stage boot loader, taking my u-boot image from serial and loading it to SDRAM, u-boot is configured to boot from main memory.
Are you aware that this setup is strongly discouraged? Have you read this:
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarte%... dInRAM?
[Leonid] The answer in DULG FAQ chapter you are referring to doesn't say that such practice is bad, it simply states that u-boot doesn't support such an option. That could be truth in the time of DULG FAQ writing but now there are many platforms, naturally using 3-stage booting. For example, ATMEL ARM boards have small boot program which fetches u-boot from flash, loads it to RAM and then starts. I would like to hear why do you think it's so bad, but in any case this way u-boot is normally used for such boards (at91rm9200-ek for instance).
In my case I probably could change EDK project to put flash on the end of the memory, but I prefer to load u-boot via XMD debugger or serial directly to RAM - much more convenient for debugging - since otherwise I will need to burn flash each time I change something and I cannot use BDI2000 on this board. Xilinx tools are not that convenient for frequent flash burning.
Regards
Leonid.
Dear Leonid,
"Leonid" Leonid@a-k-a.net writes:
On Tuesday, February 13, 2007 10:55 PM Markus Klotzbücher:
I'm porting u-boot on Vertex-4 based board (with PPC405 inside);
I'm
trying use ml403 u-boot as example. I have first stage boot
loader,
taking my u-boot image from serial and loading it to SDRAM, u-boot
is
configured to boot from main memory.
Are you aware that this setup is strongly discouraged? Have you read this:
http://www.denx.de/wiki/view/DULG/CanUBootBeConfiguredSuchThatItCanBeStarte%...
dInRAM?
[Leonid] The answer in DULG FAQ chapter you are referring to doesn't say that such practice is bad, it simply states that u-boot doesn't support such an option. That could be truth in the time of DULG FAQ writing but now there are many platforms, naturally using 3-stage booting. For example, ATMEL ARM boards have small boot program which fetches u-boot from flash, loads it to RAM and then starts. I would like to hear why do you think it's so bad, but in any case this way u-boot is normally used for such boards (at91rm9200-ek for instance).
I didn't say it's bad to do this, I just wanted to point out that starting U-Boot from RAM is not the standard way and you might experience difficulties. Having said that, yes, I'm well aware there are boards doing this, to be honest I have done it myself. Sometimes there is no other way.
In my case I probably could change EDK project to put flash on the end of the memory, but I prefer to load u-boot via XMD debugger or serial directly to RAM - much more convenient for debugging - since otherwise I will need to burn flash each time I change something and I cannot use BDI2000 on this board. Xilinx tools are not that convenient for frequent flash burning.
Well, I guess I would still burn U-Boot to flash if I had the choice. This setup has been tested much better. But as you seem to know what you are doing, it's ok.
Best Regards
Markus
-- DENX Software Engineering GmbH, HRB 165235 Munich, CEO: Wolfgang Denk Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Hi:
Can somebody send me code or location of PLB TMAC drivers for ML403 u-boot? I have got some u-boot tree which presumably supports ML403 (//www.xilinx.com/ml410-p/designs/u-boot.zip), but drivers there are for some different core (under board/xilinx/xilinx_enet) - XEMAC instead of XTEMAC. XTEMAC drivers are present in EDK tree, but I assume that many people have already ported them to u-boot - can anybody please share this code with me? I have everything working in u-boot but Ethernet...
Thanks,
Leonid.
In message 406A31B117F2734987636D6CCC93EE3CB05891@ehost011-3.exch011.intermedia.net you wrote:
[Leonid] The answer in DULG FAQ chapter you are referring to doesn't say th at such practice is bad, it simply states that u-boot doesn't support such an option. That could be truth in the time of DULG FAQ writing but now there
No, it does not say that U-Boot doesn't support this, it sais that this is difficult, unsupported, and fraught with peril.
And "unsupported" means that: you might not get any support doing this.
are many platforms, naturally using 3-stage booting. For example, ATMEL ARM boards have small boot program which fetches u-boot from flash, loads it
And in which way is this a 3-stage procedure? I see only two stages. Also, in some cases this is absolutely not "naturally".
to RAM and then starts. I would like to hear why do you think it's so bad, but in any case this way u-boot is normally used for such boards (at91rm9200-ek for instance).
This has been discussed in lenght before. See the archives.
Best regards,
Wolfgang Denk
Leonoid,
I am working on a similar project: Avnet Virtex 4 mini-module configured with MPMC2 to 64Mb of x16 DDR OPB EMC to 4Mb x16 linear flash OPB to UARTLITE PLB to TEMAC
I also would like uartlite and temac drivers for both u-boot and linux 2.6.xx. Where did you get to? I am also considering the GSRD, but right now I just want to get a bootloader working
My boot sequence (planned) step 1 Hardware and initial bootloader (executing from BRAM, later from cache ALA Ultra Controller?) placed in platform flash Load U-boot to memory, or jump to U-boot in flash?
step 2 Load linux image from either flash or from TFTP server
What is assumed by the existing drivers in terms of interrupts and DMA?
Mike
Leonid-4 wrote:
Hi:
I'm porting u-boot on Vertex-4 based board (with PPC405 inside); I'm trying use ml403 u-boot as example. I have first stage boot loader, taking my u-boot image from serial and loading it to SDRAM, u-boot is configured to boot from main memory.
Several questions:
- I'm using ELDK 3.1.1 as crosstool; which target should I choose:
ppc_4xxFP or ppc_4xx?
- My board unlike ML403 has UARTLITE for serial interface. Can I use
serial_xuartlite.c from microblaze directory?
Thanks,
Leonid.
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
Hi:
Xilinx Spartan-3e Starter kit board has SPI serial flash on it, but standard EDK project, supplied with this kit doesn't contain SPI IP core or SW application which can be used with it.
Does somebody have such EDK project/SW application?
Thanks,
Leonid.
participants (5)
-
Grant Likely -
Leonid -
Markus Klotzbücher -
mikeIngle -
Wolfgang Denk