[okl4-developer] More NSLU2 debugging

[Geoffrey Lee]

On Mon, Jun 23, 2008 at 04:40:18PM +1000, Joshua Root wrote:
> Geoffrey Lee wrote:
>> On Mon, Jun 23, 2008 at 03:59:20PM +1000, Joshua Root wrote:
>>>> Yes, possibly something has gone wrong there.  Just a side note
>>>> we never set the lower bound of the physical range to be zero.
>>>> In the machines.py description file can you try changing the 
>>>> physical range to be something else (say 0x100000L), clean out
>>>> the build and then do a full rebuild?
>>>>
>>>> If the contents of __phys_addr_ram is zero that would probably make 
>>>> sense since your lower bound for physical range is set to zero,
>>>> but it might have assumed zero to mean something else.
>>> OK, now I'm confused. The pointer physbase gets set to what I specify 
>>> as  the start of physical memory in machines.py. But when 
>>> initialising  kspace_phys, virt_to_phys_init() adds an offset to what 
>>> physbase points  to, not to the value of the pointer itself. How can 
>>> that work?
>>
>> At this point the MMU is not turned on.  However due to the way that
>> the kernel is linked the addresses need to be converted back to physical
>> addresses.
>
> Right, and that's done by taking the offset from the kernel's virtual  
> base address and adding it to the address of the start of physical  
> memory, yes?
>
> The part I don't get is that "the address of the start of physical  
> memory" seems to be physbase, but the calculation is done with *physbase.

Our resident kernel experts tell me that it is actually a struct which
consists of the physbase for RAM and the physbase for ROM, which might 
be the cause of some of your confusion.   Both are filled in by the 
build system.  The located at address physbase
i.e. *physbase is the start of the physical section, similar for
ROM.



>
>> Hence, you get "start" and "end", which are physical.  In  
>> add_mapping_init() you do
>>
>> add_mapping(space, phys_to_virt(addr), addr, cache attrib);
>>
>> Can you confirm that this is what you see?
>
> With physical memory configured to start at 1 MB I'm getting  
> start=0xe73ffed7 and end=0xcffaffff, which is of course nonsense.

This does not seem very good.  Can you print out the following:

*physbase
start_ram
end_kernel

and see what their values are?


>
>> I'd still be interested in the result of setting a non-zero lower
>> bound for the physical address range.  If you set it to say, 0x10000
>> do you get the same crash?
>
> Whether I start RAM at 0 or 1 MB, I get bad addresses from the  
> initialisation of kspace_phys onwards.
>
> - Josh
>

--