[okl4-developer] More NSLU2 debugging

[Joshua Root]

Geoffrey Lee wrote:
> 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.

This all makes sense now. Most of my confusion was actually due to 
misinterpreting my own debug output (see below).

>>> 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?

Disregard what I said about start and end before. Their actual values 
are 0x00100000 and 0x0012e000, which seems reasonable. So also:

*physbase  = 0x00100000
start_ram  = 0xf0020400
end_kernel = 0xf002e000

What does seem to be wrong is that on the hardware, find_kernel_heap is 
returning start_bootmem_phys=0 and bootmem_size=0, while on the 
simulator it sets them to 0x00400000 and 0x00200000 respectively.

I'll investigate what's happening inside find_kernel_heap.

- Josh