UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Visitor mythdraenor
Visitor
8,419 Views
Registered: ‎03-20-2008

PPC 440 Boot

I apologize for the formating of this message.  It was an email thread that I thought would be useful to post here for everyones' edification.

 

________________

Todd:

 

 Hi,

I have a question about the boot process used for the linux kernel you
provide and the ML507 board.  Our system is very simple and contains a
64KB BRAM covering the reset vector of the PPC and a 256 MB SDRAM
covering the first 256 MB of the address space.  When I use XMD, I
notice that I can download the kernel image and the script sets the PC
to the start of the zImage decompression routine (0x0040082c).  I am
wondering what code is loaded into the BRAM if any.  Is the simple
bootloop.s code loaded at the reset vector waiting for the debugger
(or the sysace controller?) to load the kernel image and reset the PC
to the proper start address?  The reason I ask is that I need to run
the system without loading the kernel image automatically (via the ace
file) and I would like to understand how much initialization code I
will have to load into the BRAM (which I can package into the ace
file).  Do I just need to jump to the zImage decompression start
address?  Do I need to initialize the cpu before doing that?  If so,
how much is necessary?

 

Thanks!

-Todd

 

_________________________

 John:

 

I haven't tried that honestly. I would say that you would jump to the
start of the decompression address unless you take the vmlinux elf file
and try to use it. I don't know if that's doable but I was thinking it
was.

I would practice this all using the Xilinx Cable pod as you should be
able to emulate some of it then automate it more I would think.

Thanks
John

________________________________

Todd:

 

Hi John,

That is kind of what I thought since I couldn't find any code (besides
the bootloop) that would even possibly reside in the BRAM's address
space.  I will try using XMD to control this explicity as you
suggested.

Thanks!
-Todd

____________________________

John:

 

I'm copying Brian on this, an Apps Eng, as he's pretty sharp and had more things like this.

He has a small boot loader I think that he put in flash, should be the same concept I would think. It's just whether it's stored in BRAM of the FPGA image or in flash.

Have you checked on http://forums.xilinx.com, in the Embedded Linux forum as they might be some info there?

-- John

_____________________________

Brian:

 

Todd,
Take a peek at XAPP1140 which has the simple bootloader John mentioned. In the appnote it runs from flash (the system has the flash at the boot vector, and no bram), but there is no reason it couldn't run from bram as well.

-Brian

______________________________

Todd:

 

Hi John, Brian,

I am checking out the forums...  Should I post this question there for
everyones' benefit?

Are these bootloaders necessary to boot linux?  i.e. does XMD somehow
put a bootloader at the reset vector which just happens to map to BRAM
in my case when I download my vmlinux.initrd.virtex image?  or are
they just interesting examples that I can reference?  I would
ultimately prefer to have 2 or 3 instructions loaded at the reset
vector just so I can jump to the linux kernel if that is all I need.
(I just need the one if I use XMD to change the PC value).  I am not
adverse to writing or using a complete bootloader, I just would like
to know what is absolutely necessary to have in the BRAM to get the
system to boot before I spend time writing a bootloader...

Does that make sense?

Thanks!
-Todd

_____________________________

Brian:

 

Todd,
XMD places you elf file wherever it was linked to, and sets the PC to the start address specified in the ELF file.  Is also does some "magic".  That is, it sets up 1:1 TLB entries and other minimal processor initialization.  A few assembly instructions at the boot vector to jump somewhere else would not accomplish that (but a very simple standalone application to jump somewhere else would -- the bsp performs some basic initialization).

-Brian

______________________________

Todd:

 

Brian,

That was what I was suspecting.  I will check out the appnote.  BTW:
my experiment finally finished synthesizing and it did not work
(simply jumping to the proper address in the kernel didn't work).  I
will need to load some boot code into my BRAM so it initializes the
CPU properly before jumping.

Thanks!
-Todd

0 Kudos
4 Replies
Visitor mythdraenor
Visitor
8,411 Views
Registered: ‎03-20-2008

Re: PPC 440 Boot

Looking at XAPP1140, it appears the source for loader.bin is not included.  If it is not possible to get a copy of it, could you at least tell me if it initializes the interrupt vectors, debug registers, etc?  I am just trying to get a basic feel for how complete it needs to initialize the cpu before it jumps to linux.

 

Thanks!

-Todd

0 Kudos
Anonymous
Not applicable
8,406 Views

Re: PPC 440 Boot

0 Kudos
Visitor mythdraenor
Visitor
8,403 Views
Registered: ‎03-20-2008

Re: PPC 440 Boot

Yes.  That is where I found loader.bin.  There exists a loader.c file, but that does not contain the boot code.  The linker script references a boot.o object file, but no boot.s or boot.S exists in the zip file.  I am looking for the entirety of what would be loaded at 0xFFFE0000 to 0xFFFFFFFF which I believe is boot.o.  Does that exist somewhere else?

 

Thanks!

0 Kudos
Anonymous
Not applicable
8,394 Views

Re: PPC 440 Boot

The boot code is in the EDK install - when you buid the loader application from withing XPS, it will pull in the things it needs during libgen/application build.. You should only need to be concerned with everything after main, which is in loader.c.. 

 

Terry

 

Message Edited by toneal on 08-20-2009 10:38 AM
0 Kudos