[syslinux] Booting Embedded x86 - Looking for Information

[Graeme Russ]

On Mon, Feb 1, 2010 at 12:09 PM, H. Peter Anvin <hpa at zytor.com> wrote:
> On 01/31/2010 03:11 PM, Graeme Russ wrote:
>>
>> I have a custom x86 board (using the AMD SC520 Elan CPU) which I am
>> trying to get Linux running on. This is a true embedded board, not
>> a mini PC / PC-on-a-chip arrangement. It has no disk drives (only DRAM
>> , NOR Flash, some battery backed SRAM, a couple of Realtek 8100B
>> Ethernet chips, LEDs, Hex Switches etc)
>>
>> I chose to use U-Boot as the bootloader as it claimed to already have
>> x86 support. This support turned out to be very stale (7 years since
>> last actively worked on) and very broken. I have spent the last 18
>> months of on-again off-again development (this is a little hobby for
>> home, not work related so I am very time-poor) to get the x86 port
>> of U-Boot to a state where I feel it can boot linux.
>>
>
> Well, this sort of automatically means this is offtopic for this list.
> This is about Syslinux, not U-Boot.

Yes, I know - and I am sorry for that, but nobody on the U-Boot ML has
any real knowledge beyond ARM and PPC. It was a long trek to here
(U-Boot -> Open Embedded -> CoreBoot). I have been scouring the net
but simply have not been able to find any definitive x86 embedded
information to help me out.

>
>> But, I really don't think this is the way I want to do it - U-Boot
>> has already put the CPU into protected mode, and I know the memory
>> organisation of the board and I have no video or disk support - It
>> seems a bit of a waste to a) bounce back into real mode and b) use
>> INT calls
>
> If you have a BIOS, this is the cleanest thing to do.  If you don't,
> then you don't have much of a choice.

The problem with going the BIOS route is that I am having extreme
difficulty debugging the boot process. I can't even guarantee that
the INT calls I am trapping are indeed issued by code in bzImage (let
alone the right place in bzImage)

>
>> Is there a clean way to:
>>   a) Jump straight to Kernel Decompression from Protected Mode
>>   b) Pass hardware data (memory layout etc) directly instead of via
>>      INT calls
>>   c) Output early debug messages to a serial port rather than video
>
> There is (see Documentation/x86 in the kernel directory), but a pretty
> big warning: it isn't as stable of an interface as it means you have to
> be able to match changes in the reference code in the kernel.

It looks like the section "**** 32-bit BOOT PROTOCOL" is what I am after,
but again, it leaves a few questions. I can definitely setup the
processor in protected mode as described in the final paragraph, but:

  a) What image file would I used (I assume vmlinux and not bzImage)
  b) Where in memory do I load it
  c) Does decompression of the kernel happen before setup of boot_params
  d) Where exactly is the "32-bit kernel entry point" and how can the
     bootloader (U-Boot) find it?

Sorry if all these questions sound stupidly naive, but this isn't my
day job

>
> Some severely misguided bootloader authors (*ahem* Grub2 *ahem*) seems
> to think this is a good idea even on BIOS-based platforms.  It is most
> definitely NOT!
>
>        -hpa

Thank you for the quick reply

Regards,

Graeme