[okl4-developer] More NSLU2 debugging

[Joshua Root]

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.

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

> 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