Lots of folks have given sage advice already but from my experience of booting
SA-1100 based systems, here's my contribution:

[1] Turning off the I and D caches (and write buffer) in proc-sa110.S is
a _good_ thing.

[2] If you're booting via angel, you may not be in the right mode, interrupts
may be enabled and you may be not be in supervisor mode.   You can, if
you have an ARM toolkit (SDT/ADS) step through the early code
(in head-armv.S) - right up until the first (temporary) page tables are
set up.   You cannot step through the first page table set up but what helps
me is that in our angel ports we usually map the SA-1100's memory to
0x0000.0000 and it's physical address 0xC000.0000.    That 0xC000.0000
is very handy.

[3] I always enable enough IO space (in head-armv.S) to light leds.  This
way I can tell where I am in the boot sequence.   Once you get past setup.c
(mostly a case of recognising the CPU correctly), the MMU setup is
the hardest bit.   I use mm-armv.c and include a table.   Getting through
MMU setup is straight forward (although I have been terminally confused
here myself).

[3a] There's a gotcha in the memory initialisation.   You need to set up
the initial page tables so that 0xC000.0000 is the physical address of
the base of memory and NOT 0x0000.0000 (sorry, this is SA-1100
only).   Look at mm/mm-rpc.c in init_dram_banks() - it's the line
current->tss.memmap = __virt_to_phys().   Otherwise, once you have
booted, when the idle task cuts in, it will crash.

[4] On both ports that I've done (Integrator and Prospector), I've
mapped the IO areas into (0xF000.0000 OR (IO-addr>>4)).
This is not the same as Nico has done (I need to merge my SA-1100
stuff with his) but it does give a nice logical way of mapping this
stuff accurately.   Chip/system designers love having lots of locations
for a few registers!

[5] I've used a very simple serial driver so that console messages come
out easily (polled).    Consoles are wierd - Linux uses the first console
registered during the boot but quite which device that is when /sbin/init
runs depends on your file system (what does /dev/console point to?).
I use /dev/console as character device 5,1.

[6] Go serial only with the SA-1100 (in the kernel configuration).

[7] My init process comes from Pocket Linux and is statically linked.
It's easier that way to get a basic system going.

[8] I use the LEDs to show the idle task running and the timer tick
going off.

Dave


Russell King - ARM Linux Admin wrote:

> Chris Blazie writes:
> > mcr     p15, 0, r0, c1, c0
> >
> >       At this point r0 = 0xc000517d; mmu, write buffer, and all caches
> > on.  Is all of that really supposed to happen here?  Or is r0 getting
> > incorrectly set in __create_page_tables?
>
> Yep.  r0 looks 100% correct.
>
> >       I remember someone else reporting a freeze when the MMU is
> > switched on (SA1110 also).  Any ideas?
>
> How are you debugging this?  If you're using a debugger, then I can
> imagine you loosing control of the debugger at this point.
>    _____
>   |_____| ------------------------------------------------- ---+---+-
>   |   |        Russell King       [EMAIL PROTECTED]      --- ---
>   | | | |            http://www.arm.linux.org.uk/            /  /  |
>   | +-+-+                                                     --- -+-
>   /   |               THE developer of ARM Linux              |+| /|\
>  /  | | |                                                     ---  |
>     +-+-+ -------------------------------------------------  /\\\  |
>
> unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
> ++        Please use [EMAIL PROTECTED] for           ++
> ++                        kernel-related discussions.                      ++

--
----------------------------------------------------------------------
David A Rusling   Consulting Engineer
    ARM Limited
    Liberty House,
    Moorbridge Road,
    Maidenhead, SL6 8LT

    Tel: UK-(0)1628-427754
    Fax: UK-(0)1628-780551
    e-mail: [EMAIL PROTECTED]
----------------------------------------------------------------------



unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
++        Please use [EMAIL PROTECTED] for           ++
++                        kernel-related discussions.                      ++

Reply via email to