Need help Understanding initial memory conditions.

Need help Understanding initial memory conditions.

[David H. Lynch Jr]

    What exactly is the minimal startup system state the Linux 2.6.13 
Kernel expects ?

    I am trying to bring up a xilinx V4 ppc 405 board.
    It has flash based at 0x0 and DRAM based at ox98000000.
    I already have a working monitor/program loader and a filesystem of 
the flash. I can fairly easily compile and load onto the filesystem and 
run standalone PPC apps on the board.
    All memory is as configured by the base hardware. The MMU, BAT, ... 
are all at their powerup state.

    I have put together a Linux config based heavily on an abbreviated 
version of the Xilinx ML-300 config.
    If I try to load it it just goes bye-bye.
   
    I am trying to decipher the initial machine state Linux 2.6.13 expects.
    u-boot seems to completely setup the MMU, but also seems to expect 
to start execution from flash or ROM.
    scanning the Linux code seems to indicate that the only entry that 
needs to be setup for the MMU is the one for block Linux starts 
executing out of.
    I am also being somewhat confused by references to physical address 
0 and virtual address 0xc000000.
    I thought Linux executed from virtual address 0, and the actual 
physical address was a function of the hardware.

   

   
   
   
   
   

Re: Need help Understanding initial memory conditions.

[Kalle Pokki]

David H. Lynch Jr wrote:

>    What exactly is the minimal startup system state the Linux 2.6.13 
> Kernel expects ?

It's pretty hard to describe the system state fully, as there are so 
many registers it may depend on. However, I can point out a few things 
from your setup:

1. Put RAM to 0x0000000 and flash to some location it mirrors to your 
boot vector. Linux always expects your physical memory to be at zero. It 
is then mapped to virtual address 0xC0000000.

2. You don't need to have MMU enabled.

3. Make sure your boot arguments are passed properly to the kernel. This 
includes the settings in registers r3 ... r7 and the bd_info structure . 
There are many variants of that structure, make sure you use the same 
ones in the boot loader and in Linux.

Re: Need help Understanding initial memory conditions.

[David H. Lynch Jr.]

Kalle Pokki wrote:

> David H. Lynch Jr wrote:
>
>>    What exactly is the minimal startup system state the Linux 2.6.13 
>> Kernel expects ?
>
>
> It's pretty hard to describe the system state fully, as there are so 
> many registers it may depend on. However, I can point out a few things 
> from your setup:
>
> 1. Put RAM to 0x0000000 and flash to some location it mirrors to your 
> boot vector. Linux always expects your physical memory to be at zero. 
> It is then mapped to virtual address 0xC0000000.

    In both this list and elsewhere I have seen several references to 
the difficulty setting up Linux with a physical RAM base other than 0x0. 
I was hoping that I could bypass that by re-arranging physical memory 
using the BAT's or MMU.
I am gathering that while this is possible, that it not sufficient. That 
if memory is re-arranged after power-on it has to be done by something 
Linux is not aware of.

>
> 2. You don't need to have MMU enabled.

    There is a god. I am a compitent developer with lots of low level 
experience, but I have thus far completely missed out on both PPC 
assembler and memory management.

>
> 3. Make sure your boot arguments are passed properly to the kernel. 
> This includes the settings in registers r3 ... r7 and the bd_info 
> structure . There are many variants of that structure, make sure you 
> use the same ones in the boot loader and in Linux.

    That I should have no problem with.


>
>

Thank You very much

Re: Need help Understanding initial memory conditions.

[Kalle Pokki]

David H. Lynch Jr. wrote:

> Kalle Pokki wrote:
>
>> 1. Put RAM to 0x0000000 and flash to some location it mirrors to your 
>> boot vector. Linux always expects your physical memory to be at zero. 
>> It is then mapped to virtual address 0xC0000000.
>
>    In both this list and elsewhere I have seen several references to 
> the difficulty setting up Linux with a physical RAM base other than 
> 0x0. I was hoping that I could bypass that by re-arranging physical 
> memory using the BAT's or MMU.
> I am gathering that while this is possible, that it not sufficient. 
> That if memory is re-arranged after power-on it has to be done by 
> something Linux is not aware of.

I'm afraid you cannot fool Linux that way... it will take control of the 
BATs and MMU. Even as a concept, you cannot re-arrange physical memory 
with the MMU at all - it's virtual memory when you do the address 
translation. The only way to arrange physical memory is to program the 
memory controller. I don't know how flexible the OCM controller in 
ppc405 is, but I'd be surprised if one couldn't freely set the addresses 
to whatever suits best.

Re: Need help Understanding initial memory conditions.

[David H. Lynch Jr]

Kalle Pokki wrote:

> David H. Lynch Jr. wrote:
>
>> Kalle Pokki wrote:
>>
>>> 1. Put RAM to 0x0000000 and flash to some location it mirrors to 
>>> your boot vector. Linux always expects your physical memory to be at 
>>> zero. It is then mapped to virtual address 0xC0000000.
>>
>>
>>    In both this list and elsewhere I have seen several references to 
>> the difficulty setting up Linux with a physical RAM base other than 
>> 0x0. I was hoping that I could bypass that by re-arranging physical 
>> memory using the BAT's or MMU.
>> I am gathering that while this is possible, that it not sufficient. 
>> That if memory is re-arranged after power-on it has to be done by 
>> something Linux is not aware of.
>
>
> I'm afraid you cannot fool Linux that way... it will take control of 
> the BATs and MMU. Even as a concept, you cannot re-arrange physical 
> memory with the MMU at all - it's virtual memory when you do the 
> address translation. The only way to arrange physical memory is to 
> program the memory controller. I don't know how flexible the OCM 
> controller in ppc405 is, but I'd be surprised if one couldn't freely 
> set the addresses to whatever suits best.
>
>
    I have built a Kernel - that is something I am pretty compitent at. 
My system is fairly similar to an abreviated xilinx ml-300, and I have 
added it to the Linux configuration and made what adjustments I beleive 
were needed (mostly eliminating hardware I do not have or want). The 
resulting Kernel is configured and successfully built.

Alright I have RAM at physical 0x0 now.  I throw a copy of a compressed 
linux image into RAM (anywhere special ?) load the assorted registers 
with the appropriate values, fill the board info struct., and just jump 
to the start of the image and pray that load text starts coming out my 
serial port ?

    Once this sucker gets through the code in head_4xx.S I should be in 
business, or atleast to a point where I can deal with whatever crops up.

Re: Need help Understanding initial memory conditions.

[Kalle Pokki]

David H. Lynch Jr wrote:

> Alright I have RAM at physical 0x0 now.  I throw a copy of a 
> compressed linux image into RAM (anywhere special ?) load the assorted 
> registers with the appropriate values, fill the board info struct., 
> and just jump to the start of the image and pray that load text starts 
> coming out my serial port ?

Basically, but the exact thing to do depends which image you take. The 
build process results in a few different image files. I usually just 
take the vmlinux ELF file, and then my own scripts objcopy it to binary, 
compress, objcopy to an object file, and link the compressed image 
directly to the boot loader. The boot loader is then, of course, 
responsible of uncompressing the image to RAM to 0x00000000.

I think the kernel build can also create some "self-extracting" images, 
but I have never tried those. Maybe they don't even work anymore, as 
many (most?)  people just use the U-boot images.

Re: Need help Understanding initial memory conditions.

[Andrei Konovalov]

Kalle Pokki wrote:
> David H. Lynch Jr wrote:
> 
>> Alright I have RAM at physical 0x0 now.  I throw a copy of a 
>> compressed linux image into RAM (anywhere special ?) load the assorted 
>> registers with the appropriate values, fill the board info struct., 
>> and just jump to the start of the image and pray that load text starts 
>> coming out my serial port ?
> 
> Basically, but the exact thing to do depends which image you take. The 
> build process results in a few different image files. I usually just 
> take the vmlinux ELF file, and then my own scripts objcopy it to binary, 
> compress, objcopy to an object file, and link the compressed image 
> directly to the boot loader. The boot loader is then, of course, 
> responsible of uncompressing the image to RAM to 0x00000000.
> 
> I think the kernel build can also create some "self-extracting" images, 
> but I have never tried those.

Yes, this is exactly the way ML300 is booted (as regards to the code
currently in www.kernel.org's 2.6 tree).
Use 'make zImage' or 'make zImage.initrd' to get zImage.elf or zImage.initrd.elf.

> Maybe they don't even work anymore, as 
> many (most?)  people just use the U-boot images.

There is U-Boot port for ML300 by Peter Ryser from Xilinx,
but I haven't tried using it (yet). IIRC there is an appnote
on Xilinx web site that describes how to boot the 2.4 kernel
with U-Boot (few modifications need to be done to the kernel).


Best regards,
Andrei