[syslinux] Booting Embedded x86 - Looking for Information

[H. Peter Anvin]

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.

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

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

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

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.