In message <E1FA7DW-00073g-00@chiark.greenend.org.uk>, Ben Harris writes:
>It's a long time since I played with this kind of thing when first getting
>NetBSD/arm26 (as it was then) to go, but I remember some of the techniques I
>used.  I wrote a little piece of assembler that would do something obvious
>if it got executed.  One of these filled screen memory with a particular
>colour, for instance.  In your case, an infinite loop might be a good start,
>since you can tell the difference between that and a reboot.  Then I
>inserted this code at various points in the system startup to check that
>everything was working.  The first place to try is right at the start of the
>kernel, to make sure the bootloader's setting things going at the right
>point.  Then, you can move the tell-tale code around and home in on the
>point where it stops getting called.
>
>Once you've got a working console, things get much less painful.

Yes.

The problem turned out to be this:

#define BASE_BAUD (((400*1000000)/((0x3C>>1)+1))/16)

This is from the Linux kernel.  Now, can you GUESS what this does?

It determines a number which is 1/16 of the correct value for COM_FREQ, which
ought to be (processor speed / 31).

What I don't get is...

Why would anyone write "/31" as "/((0x3C>>1)+1)"?

Anyway, I'm up to the part where it panics because I never got around to
cloning openbios_board_init.  So I'm implementing the required bits of
board_info, which are easy because everything's constant.

-s