[okl4-developer] More NSLU2 debugging

[Joshua Root]

Geoffrey Lee wrote:
> On Mon, Jun 23, 2008 at 03:07:21PM +1000, Joshua Root wrote:
>> Geoffrey Lee wrote:
>>> On Sun, Jun 22, 2008 at 07:42:35PM +1000, Joshua Root wrote:
>>>> So you'd expect something like:
>>>>
>>>> add_mapping_init( kspace_phys, 
>>>> (addr_t)(XSCALE_DEV_PHYS+CONSOLE_OFFSET),   
>>>> (addr_t)(XSCALE_DEV_PHYS+CONSOLE_OFFSET), uncached );
>>>>
>>>> to work if I do it at the same time as the other 1:1 mappings? And 
>>>> after  VM is turned on here (init.cc:353):
>>>>
>>>> /* Enable virtual memory, caching etc */
>>>>     write_cp15_register(C15_control, C15_CRm_default,
>>>>                     C15_OP2_default, C15_CONTROL_KERNEL);
>>>>
>>>> I should be able to write to the UART, yes? (And indeed I can in the  
>>>> simulator...) I've been doing pretty much what you suggest to 
>>>> pinpoint  where it's failing, but I can't get any output after that   
>>>> write_cp15_register call. Could kspace_phys be constructed 
>>>> incorrectly?
>>> Yes, I guess something hasn't been constructed properly.  I think if
>>> you turn off the MMU initialization you will actually get a bit  
>>> further - not saying that is the way to move forward, just that
>>> it properly is something that got put into the cpu which it didn't
>>> like.
>>>
>>> It might be a good idea to print out the contents of physbase to double
>>> check that it's been patched properly, and also the contents of the
>>> page table etc that you write to the hardware.
>> Good call. Turns out that the physbase pointer that's passed to  
>> init_memory is null. I guess this means that the build system is failing  
>> to set __phys_addr_ram?
> 
> 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?

- Josh