Dave Borja writes:
> Well, we want this to behave similar to the brutus, w/the console coming out
> of ttyS1 since the first serial port is being used by angelboot.
I won't bore you with the exact arguments to give for ttyS1. ;)
> And, I assume r0 should be 0 and r1 should have index for the architecture?
r0 should always be 0, and r1 should be the architecture number, which should
be allocated by my automatic number allocater (see Documentation/arm/README).
There is little point having an architecture number if it's not registered ;)
> We are concentrating on just getting this to boot. We need to figure out how
> to map the dram and i/o space since the map is different from the ebsa110 w/
> our dram starting at 0x40000000.
Have a look at the RiscPC stuff - generally it's the virt_to_phys and
phys_to_virt macros, and maybe a few else where depending on the kernel
version you have.
> Most of this may be a matter of patching the include/asm-arm *.h files to
> get the IRQs and memory map correct.. But we need to do some initialization
> for that super i/o chip. From reading the discussion on the bios, it's not
> clear where to put this.
> According to Philip, head-armv.S should remain as platform independend as
> possible. but this seems to be the only reasonable place to put this.
> Should this be in the bios instead? For now, we just want to get booted....
Phil and myself agree here - the whole point of architecture numbers, and the
code in head-armv.S is that it is well tested architecture independent code,
so to get the kernel running in C code as soon as possible. Therefore, all
you need to do in a BIOS is:
1. initialise the RAM
2. setup minimal hardware (eg, VGA chip, SuperIO, etc)
3. obtain the kernel at the correct address
(in your case, this would preferably be 0x40008000)
4. setup parameter page passing any information required (like RAM size,
root device, etc)
5. call it at that address
Depending on the flexibility of your machine configuration, (4) may
simply be a case of copying pre-constructed param structure and then
changing the RAM size to match the detected RAM size.
As an aside, 2.3 now knows about non-contiguous "banks" of RAM, which are
handled slightly differently. If you have contiguous RAM, ignore this
paragraph, else look at the RISC PC architecture in the latest 2.3 kernels.
_____
|_____| ------------------------------------------------- ---+---+-
| | Russell King [EMAIL PROTECTED] --- ---
| | | | http://www.arm.linux.org.uk/~rmk/armlinux.html / / |
| +-+-+ --- -+-
/ | THE developer of ARM Linux |+| /|\
/ | | | --- |
+-+-+ ------------------------------------------------- /\\\ |
unsubscribe: body of `unsubscribe linux-arm' to [EMAIL PROTECTED]
