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 <> 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
>
>
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|