[okl4-developer] More NSLU2 debugging

[Geoffrey Lee]

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.

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?

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?

>
> - Josh
>

	-gl