Subject: Re: Got angleboot to work

From: Dave Borja <[email-masked]>
Date: Wed, 03 Nov 1999 15:57:02 -0800

>Dave Borja writes:
>> I posted a while ago about angleboot problems with our
>> ebsa110 type board. Turns out I was able to get it to work
>> by cutting down the size of the data packet sent for the image
>> download. This was hardcoded at 2016. Cutting it in half gets
>> the download to work.
>
>This sounds like a problem with something not being able to fragment
>packets on ethernet correctly.
>
>> Getting things to boot is another matter. I compiled a kernel
>> (based on 2.2.12) with  arm and brutus/sa1100 patches. Tried
>> building with the ebsa110 option and with minimal support (basically
>> just the serial ports, ram disk as initd, etc). We plunk this down
>> into base address 0x8000 and put the ram disk up there in 0x00100000.
>> Since we only have 8mb of memory and the ram disk is a little over 6mb
>> uncompressed, things are tight.
>
>I hope you're using either the Image or zImage files?  Also, a 6MB ramdisk
>in 8MB isn't really going to leave much room at all for the user-mode.
>Do you get any kernel messages from the serial port?  (and you did
>specify "console=ttyS0,19200n8" or similar during the build?  Also,
>check that r0 and r1 are being passed the correct values.

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. And,
I assume r0 should be 0 and r1 should have index for the architecture?

In any case, thanks for the input, we are certainly having our troubles,
mostly due to
us all being low on the learning curve (we lost our main embedded
systems man who flew off to a job at intel)...

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.

The sa110 is on a 32 bit bus along with the dram & flash. There's a CPLD
chip that
buffers the 16 bit isa bus. On that we've got a Natioinal Semi super i/o
where we
hang the standard perpherials (serial ports, parallel port, ide, GPIO
lines). Also there
is a cs89000 ethernet chip on the bus as well as the eprom w/angel.

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....

Thanks,
 Dave Borja

unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Russell King - ARM Linux Admin <[email-masked]>
Date: Thu, 4 Nov 1999 21:25:38 +0000 (GMT)

Dave Borja writes:
> 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 ;)

> 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.

> 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.
> 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-masked]      --- ---
  | | | |  http://www.arm.linux.org.uk/~rmk/armlinux.html    /  /  |
  | +-+-+                                                     --- -+-
  /   |               THE developer of ARM Linux              |+| /|\
 /  | | |                                                     ---  |
    +-+-+ -------------------------------------------------  /\\\  |
unsubscribe: body of `unsubscribe linux-arm' to [email-masked]

---

From: Francois Desloges <[email-masked]>
Date: Fri, 5 Nov 1999 11:17:32 -0400

> 5. call it at that address
 
That's exactly what I was looking for!

In the normal situation (in EBSA-285 BIOS 1.05 init/boot.c):

The BIOS .data is loaded at 0x1000
The  struct param_struct is created at 0x100
The kernel is loaded at 0x8000.

Is there a reason for these address choices?

I don't want to load the kernel from the network.
I ultimately want to read it from a DiskOnChip device, but to begin with, I
will probably use an IDE drive (although using the flash is probably a good
idea as well).

I've found very few information regarding how to place a kernel on a hard drive
an loading it. Most document recommend to use lilo, but I doubt this would be a
good idea ;-)  Anybody has a pointer to a document about bootstraping?

From, my i386 PC, I've created a linux partition on the disk, mkfs ext2 on it
that will eventually become root, mkdir boot on that file (trying to be
standard here), copy zImage in this boot directory, run lilo in order to
create a mapfile for the kernel.

Now, there's no doc about the mkboot utility that comes with the kernel but I
presumed I can use it to write the boot sector of my partition with the
start_sector of the mapfile the BIOS needs.  How do I calculate this
OFFSET mkboot require?

And in order for me to better understand the BIOS kernel loading process, where
can I found the descrtiption of the partition table structure?
(I deducted that it begins at offset 0x1be inside the boot sector, that the
first byte is the partition type, and that mkboot write the mapfile
start_sector at 1c6, but that's all). 

Thank you for any insight

-- 
François Desloges
[email-masked]