elfboot

[Xavier Pegenaute]

Hi,

any one can help me with this ?

I was thinking that after crt0.S in ROMBASE (0x80000 for Matsonic) copy
the LinuxBios (the payload) into DRAM (RAMBASE 0x4000 for Matsonic)
follow the code to hardwaremain() initialitizing all hardware and arrive
in write_tables that prepare the memory to let information about the
hardware to the next O.S., and now we can choose between:

1) We want start an ELF binary (not payload) that is in DoC (p.e.) after
LinuxBios. Then we execute elfboot() that look inside the ROM for the
next code starting with a valid ELF header, build the segments, copy the
segments and give the control to the program.

No problem in this case, i think.

2) We want start a Linux Kernel that is recorded (neither payload) after
LinuxBios binary in DoC (p.e.), then we execute linuxbiosmain() and in
the end of this function we make a long jump to 0x90000.

Here, i don't see what function in linuxbiosmain() copy the code of
Kernel to DRAM.Any one know it ?

Thanks. 
Xavi.

Xavier Pegenaute  writes:
> Hi,
>
> any one can help me with this ?
>
> I was thinking that after crt0.S in ROMBASE (0x80000 for Matsonic) copy
> the LinuxBios (the payload) into DRAM (RAMBASE 0x4000 for Matsonic)
> follow the code to hardwaremain() initialitizing all hardware and arrive
> in write_tables that prepare the memory to let information about the
> hardware to the next O.S., and now we can choose between:
> We want start an ELF binary (not payload) that is in DoC (p.e.) after
>
> LinuxBios. Then we execute elfboot() that look inside the ROM for the
> next code starting with a valid ELF header, build the segments, copy the
> segments and give the control to the program.
>
> No problem in this case, i think.

Sounds like standard use.
> We want start a Linux Kernel that is recorded (neither payload) after
>
> LinuxBios binary in DoC (p.e.), then we execute linuxbiosmain() and in
> the end of this function we make a long jump to 0x90000.

Linuxbiosmain() is deprecated code and it always jumps to 0x100000 1MB.
Anything is not done.  And everyone is encouraged not to use linuxbiosmain
for new deployments.
> Here, i don't see what function in linuxbiosmain() copy the code of
> Kernel to DRAM.Any one know it ?

It is the gunzip part.  But please don't use that.

Eric

[Xavier Pegenaute]

Hi,

On Tue, 2003-07-08 at 02:03, Eric W. Biederman wrote:
> > We want start an ELF binary (not payload) that is in DoC (p.e.) after
> >
> > LinuxBios. Then we execute elfboot() that look inside the ROM for the
> > next code starting with a valid ELF header, build the segments, copy the
> > segments and give the control to the program.
> >
> > No problem in this case, i think.
>
> Sounds like standard use.
> > We want start a Linux Kernel that is recorded (neither payload) after
> >
> > LinuxBios binary in DoC (p.e.), then we execute linuxbiosmain() and in
> > the end of this function we make a long jump to 0x90000.
>
> Linuxbiosmain() is deprecated code and it always jumps to 0x100000 1MB.
> Anything is not done.  And everyone is encouraged not to use linuxbiosmain
> for new deployments.
> > Here, i don't see what function in linuxbiosmain() copy the code of
> > Kernel to DRAM.Any one know it ?
>
> It is the gunzip part.  But please don't use that.

The problem, is that, if i follow the instructions of
freebios/HOWTO/SiS630, the linux kernel binary generated doesn't has
elfheader.

Then if i want to use the standard use, i have apply some external
utility to generate an elf file (mkelfImage) and put in config file
"fileoption USE_ELF_BOOT=1". Is it right ?

Another think, i thought that the Linux Kernel alone has the code to
decompress himself (in the same way that we can put Kernel in a floppy
disk and it decompress alone. (dd if=kernel of=/dev/fd0))

Thanks.
Xavi.

Xavier Pegenaute  writes:
> Hi,
>
> On Tue, 2003-07-08 at 02:03, Eric W. Biederman wrote:
> > > We want start an ELF binary (not payload) that is in DoC (p.e.) after
> > >
> > > LinuxBios. Then we execute elfboot() that look inside the ROM for the
> > > next code starting with a valid ELF header, build the segments, copy the
> > > segments and give the control to the program.
> > >
> > > No problem in this case, i think.
> >
> > Sounds like standard use.
> > > We want start a Linux Kernel that is recorded (neither payload) after
> > >
> > > LinuxBios binary in DoC (p.e.), then we execute linuxbiosmain() and in
> > > the end of this function we make a long jump to 0x90000.
> >
> > Linuxbiosmain() is deprecated code and it always jumps to 0x100000 1MB.
> > Anything is not done.  And everyone is encouraged not to use linuxbiosmain
> > for new deployments.
> > > Here, i don't see what function in linuxbiosmain() copy the code of
> > > Kernel to DRAM.Any one know it ?
> >
> > It is the gunzip part.  But please don't use that.
>
> The problem, is that, if i follow the instructions of
> freebios/HOWTO/SiS630, the linux kernel binary generated doesn't has
> elfheader.
>
> Then if i want to use the standard use, i have apply some external
> utility to generate an elf file (mkelfImage) and put in config file
> "fileoption USE_ELF_BOOT=1". Is it right ?

Essentially correct.  MkelfImage takes a standard x86 linux kernel and
wraps so it is a bootable ELF executable.

The latest mkelfImage can be found at:

ftp://ftp.lnxi.com/pub/mkelfImage/
> Another think, i thought that the Linux Kernel alone has the code to
> decompress himself (in the same way that we can put Kernel in a floppy
> disk and it decompress alone. (dd if=kernel of=/dev/fd0))

The strange choices in linuxbios main where it decompresses the kernel
instead of using the kernels own decompressor, are among the many
reasons it is deprecated.

Eric

[ron minnich]

On 8 Jul 2003, Eric W. Biederman wrote:
> The strange choices in linuxbios main where it decompresses the kernel
> instead of using the kernels own decompressor, are among the many
> reasons it is deprecated.

no strange at all in 2000, when we figured to boot many other kernels that 
did not have their own decompressor.

ron

ron minnich  writes:
> On 8 Jul 2003, Eric W. Biederman wrote:
> > The strange choices in linuxbios main where it decompresses the kernel
> > instead of using the kernels own decompressor, are among the many
> > reasons it is deprecated.
>
> no strange at all in 2000, when we figured to boot many other kernels that 
> did not have their own decompressor.

I agree it makes sense from the context in which it was written.  I was just
to lazy to fill in the context for a deprecated feature.

Eric