Thanks, Mark.
That information is exactly what I needed. I've now got a
SD flash with a larger initrd partiton that boots.I must
have been close all along, as I did get the three progress
dots, just no further boot. I simply repeated the whole
process, paying close attention to every detail, and it
worked. I must have initially done overlooked some detail.
So, to rephrase your explanation of the boot process, with
some context that may be more familiar to some who might
see this later: the FPGA performs the function analogous
to the BIOS of a conventional x86 box, by loading the
first stage boot loader from the MBR. It sounds like the
FPGA also does more at that point, by also loading the
kernel, and only then transferring control to the second
stage of the bootloader. Do I have that right?
The reason I ask, is that my long term goal would be to
use a more flexible bootloader; something grub-like or
isolinux-like (PXE-Linux actually). My present theory is
that I could substitute my own second-stage bootloader in
the MBR, and let it load subsequent bootloader stages,
ignoring the already loaded kernel, but loading a
runtime-specified kernel and kernel commandline. Does this
sound realistic/possible?
I believe I recall seeing published assembler source code
for the MBR, but I can't seem to locate it any more. Is
that still available?
Thanks for the help.
--- rod.
--- In ,
Mark Featherston m("...","mark");"><> wrote:
>
> Rod,
>
> The TS-BOOTROM consists of two parts, the code in the
FPGA which does
> low level initialization of the CPU and MMU. It reads
the first 512
> bytes of the SD card, and jumps execution to the
binary there. The code
> in the MBR looks at the partition table for the first
partition of type
> 0xda, and loads this to memory 0x8000. The second
partition of type
> 0xda is loaded into memory at 0x1000000. This also
sets up the ATAGS
> which are used by the kernel to identify the
hardware, and so it knows
> where to load the initrd. After that it jumps into
execution at 0x8000
> to the kernel. The kernel will recognize the ATAGS
(which are in a
> standard location for ARM at 0x100) and it will see
the initrd as
> /dev/ram0. If you look at the default kernel config,
we define the
> cmdline as: "root=/dev/ram0 rw init=/linuxrc
lpj=498688 console=null"
>
> If you don't have the MBR, you can take the first 446
bytes of our image
> and write it to yours (dd if=<ourimage>
count=446 bs=1 of=<yourimage>).
>
> >Anyone know how to interpret these?
>
> >> TS-BOOTROM - built Sep 24 2008
> >> Copyright (c) 2008, Technologic Systems
> >> Booting from SD card...
> . < Loaded the MBR
> . < Loaded the Kernel
> . < Loaded the initrd
>
> > Some things I've tried have resulted in fewer
dots being printed
> The last 2 dots are printed out from the MBR. If this
is missing it
> will not attempt to load the kernel and initrd.
>
> > Is there some special constraints on the
partitioning?
> Only that the 0xda partitions must be on primary
partitions. After that
> it is up to Linux to handle any other partitions.
>
> >My Debian 6 host's fdisk can't seem to create
partitions that are not
> aligned on cylinder boundaries. Does this matter?
> Try using fdisk with the -uc option which should work
on Debian 6. It
> should still boot without doing this but we still
recommend having your
> partitions aligned at 512 byte sectors.
>
> >I would like to be able to add a few MB, and load
a small number of
> extra programs to allow me to run the board entirely
from ram disk.
> A few MB should be fine, but keep in mind the
watchdog is armed by
> default. If it takes too long to load the kernel and
initrd into memory
> and begin execution, you will trip the watchdog and
the board will
> reboot. We disable it by default in the linuxrc
script. (peekpoke 16
> 0x600ff0d6 0x3 disables the watchdog).
>
> Try enabling the console so you get more debug output
from the kernel.
> Rebuild it and set the cmdline to be:
> "root=/dev/ram0 rw init=/linuxrc lpj=498688
console=ttyAM0,115200"
>
> If it continues to print absolutely nothing, then it
is either being
> loaded too slowly, there is a bug with any other
drivers you may be
> adding, or the file is somehow corrupt/incomplete. In
that case make
> sure it fits in the kernel partition, or
redownload/rebuild the kernel.
> If it does print something, then you will at least
have more information
> to go off of.
>
> Best Regards,
>
__________________________________________________________
> Mark Featherston, Technologic Systems | voice: (480)
837-5200
> 16525 East Laser Drive | fax: (480) 837-5300
> Fountain Hills, AZ 85268 | web: www.embeddedARM.com
>
>