RE: [OpenBIOS] Starting linux aint much easy ?

[Attarian, Gary]

Oops, this was my bad.  after looking back at your previous posts, Jörg, I
think Ronald is correct.  Which brings me back to an earlier question.
Namely are you loading a zImage or a bzImage?  If you carefully look through
the head.S code, you will notice it deciding whether the kernel is loaded
high or low.  I believe it does this by checking a value generated at
compile time.  Anyway, my understanding is that the big (bzImage) kernels
are loaded high 0x101000 and the smaller (zImage) kernels are loaded into
low memory  at 0x1000.

Assuming OpenBIOS puts the processor into protected mode with a 4g address
space (a good bet as Ronald has already confirmed this), all you should have
to do is jump to the kernel.  If you already have access to the 4g address
space while you are loading the kernel from flash this should be the case.

One last question though, did you say you were loading a vmlinux image
(uncompressed) into memory?  If so, head.S assumes the image is compressed
and trys to uncompress it.  
    Gary
> -----Original Message-----
> From:	Ronald G. Minnich [SMTP:[e-mail]]
> Sent:	Tuesday, February 15, 2000 12:56 PM
> To:	[e-mail]
> Subject:	Re: [OpenBIOS] Starting linux aint much easy ?
>
> I don't think you should fall back into real mode. There's no good reason
> to. I think you should look at how LOBOS does its thing, which is to boot
> linux entirely in protected mode, and emulate that in your bios.
>
> Falling into real mode is a mess. Also, once you drop to real mode, you
> can't address 0x100000 any more. This is probably not what you want, since
> your code is at 0x101000.
>
> ron
>
> To unsubscribe: send mail to [e-mail]
> with 'unsubscribe openbios' in the body of the message

Starting linux aint much easy ?

[Ronald G. Minnich]

On Tue, 15 Feb 2000, Attarian, Gary wrote:
> One last question though, did you say you were loading a vmlinux image
> (uncompressed) into memory?  If so, head.S assumes the image is compressed
> and trys to uncompress it.

you can even bypass this step. Openbios very nicely will do the gunzip for
you. So here is what james hendricks and dale webster cooked up to build
an NVRAM 'image':

#!/bin/bash

# Let's use variable to make the size dynamic
# Enter in the image size in kbytes
export BIOS_SIZE=512

# Well, we don't need kB, we need bytes minus 64kB
export FILLER=`echo 1024*($BIOS_SIZE-64) | bc`

# Setup done, let's rock & roll :)
echo Reading in 'vmlinux' and 'rom.bin'

# Strip and Zip the linux kernel
echo Stripping and compressing the kernel...
objcopy -O binary -R .note -R .comment -S vmlinux /tmp/$$-tmp-linux
gzip -f -3 /tmp/$$-tmp-linux

# Make a filler file
echo Making a ${BIOS_SIZE}k BIOS image...
dd if=/dev/zero of=/tmp/$$-tmp-filler bs=1 \
count=`ls -l /tmp/$$-tmp-linux.gz | awk '{print "'$FILLER' - " $5}' | bc`
\
> & /dev/null

# Put it all together   
echo Outputting bios.img...
cat /tmp/$$-tmp-linux.gz /tmp/$$-tmp-filler rom.bin > bios.img

# Eventually we could dynamically setup ldbios.asm and the other stuff.
# nasm ldbios.asm -f bin -o ldbios.com
# (cd start32; make)

# Remove temp files
echo Cleaning up...
rm /tmp/$$-tmp-filler /tmp/$$-tmp-linux.gz

echo All done.
------------------------------------------------

The key step in there you can see is taking the vmlinux image and gzip'ing
it. openbios gunzips linux to 0x100000 and jumps to the 'right place', and
away you go. This means you don't need all of arch/i386/boot and you can
even skip linking the gunzip code into the kernel. Very nice.

ron

-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message