Syslinux - Jan 2010 - Booting Embedded x86 - Looking for Information

Hi All,

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.

I'm now at a bit of a sticking point...

I have cloned Linux 2.6.33rc5 kernel source from the git repository,
performed a rough config and build and now have a vmlinux and bzImage.

The old (broken) x86 U-Boot port appeared to include support for
booting a (b)zImage via a Real-Mode trampoline and very basic BIOS
interupt services. I think that I may have this working to some level
as I have put some raw serial outputs in the interrupt service routine
and I'm getting hits on IRQs 0x10, 0x15 and 0x16. I then hacked
__putstr() in arch/x86/boot/compressed/misc.c to output to the serial
port rather than video memory but got no additional output so it
looks like I'm not getting to the point of kernel decompression

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

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

Any help or pointers to documentation would be greatly appreciated

Regards,

Graeme

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.