Re: kernel course no. 1

Hi,

Beware, when doing such debugging, that the IOs you use for your LED are
actually mapped in virtual memory space before accessing them.

The head.S entry does approximately this:

 - first it calls early_init(). It does so before touching the MMU
or changing anything to the CPU setup, it's still running at whatever
address it was loaded, early_init() handles interaction with the
firmware, like grabbing the OF device-tree on OF based machines.

[snip]

You are talking about arch/ppc/kernel/head.S, but we're using head_4xx.S,
because we are using IBMs 405gp CPU.
In our case 'early_init()' isn't called before start_here(), but in
start_here(). MMU is initialized before even calling start_here() and is
turned on when 'rfi' is called - at this stage our system freezes.

So unless you have done some io_block_mapping calls or ioremap calls
inside MMU_init for your board, your LEDs will not be available neither
at start_kernel time. You have to ioremap them before use. You may have

When I spoke about my 'hardware debugger' (two LEDs on 0x58000000 physical
address - they are controlled by CPLD which is mapped on CS3) - we were
writing on this address after turning on MMU (after 'rfi' call),
apparently this crashed the system. But the question is - how can I write
to this physical address ( = to which virtual address is CS3 mapped)?

Thanks...

Jure


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/