etherboot-developers

Re: [Etherboot-developers] Etherboot 5.1.7 (development) released

[<ke...@us...>]

>Actually saying start16.S is still needed is exactly backwards.
>
>To clarify.
>A binary image is built by first building .img and the taking things
>in front of it.

Thanks, that's saved me some work when it comes to documenting how it
all works. I was under the impression that the .img files had a 16-bit
entry point.

Re: [Etherboot-developers] Etherboot 5.1.7 (development) released

[<ke...@us...>]

>Older code like the floppy loader always builds the .rom files and looks like
>:
>floppyprefix rom_header start16 .img
>
>Things are simpler in the makefile for .dsk images because it happens
>in two separate steps instead of just one.  

Hmm, that suggests that it's possible to remove the rom_header from this
chain and have boot1a.s load the rest, perhaps with the help from an
auxiliary script to set a word in boot1a.s indicating how many blocks to
load. Then boot1a.s would not be subject to the 127.5 kiB limitation of
ROM images.

In the past the floppy loader was used to check that the ROM image would
work, but I think the production process is reliable enough that we can
believe that prepending loader.S will produce a valid ROM.

Re: [Etherboot-developers] Etherboot 5.1.7 (development) released

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >Older code like the floppy loader always builds the .rom files and looks like
> >:
> >floppyprefix rom_header start16 .img
> >
> >Things are simpler in the makefile for .dsk images because it happens
> >in two separate steps instead of just one.  
> 
> Hmm, that suggests that it's possible to remove the rom_header from this
> chain and have boot1a.s load the rest, perhaps with the help from an
> auxiliary script to set a word in boot1a.s indicating how many blocks to
> load. Then boot1a.s would not be subject to the 127.5 kiB limitation of
> ROM images.

Yep.  That is the direction I have been going in 5.1.x.

The floppy loader was checking checksums etc, and it was non-trivial
enough that I simply have not done the work to make that case work.

I would have to check but I think the floppy loader may actually be the
last holdout.
 
> In the past the floppy loader was used to check that the ROM image would
> work, but I think the production process is reliable enough that we can
> believe that prepending loader.S will produce a valid ROM.

And also note that loader.S is now very much simpler, as the 16->32 bit
code and the decompresser have been move out of it.

Eric

Re: [Etherboot-developers] Etherboot 5.1.7 (development) released

[<ke...@us...>]

>The floppy loader was checking checksums etc, and it was non-trivial
>enough that I simply have not done the work to make that case work.

Hmm, I think you mean the bit where it's looking for signature 55AA at
the beginning of the file? I think that and getting the block count from
the third byte are the only things it expects in the ROM image.

I had a look at it and it uses dh,dl to pass the block count,drive
number) to the xread.1 subroutine. We'll have to find a way to pass a
word.

Re: [Etherboot-developers] Etherboot 5.1.7 (development) released

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >The floppy loader was checking checksums etc, and it was non-trivial
> >enough that I simply have not done the work to make that case work.
> 
> Hmm, I think you mean the bit where it's looking for signature 55AA at
> the beginning of the file? I think that and getting the block count from
> the third byte are the only things it expects in the ROM image.

It also computes the checksum of the rom image at least that is
what I recall. 

> I had a look at it and it uses dh,dl to pass the block count,drive
> number) to the xread.1 subroutine. We'll have to find a way to pass a
> word.

Interesting...

If we can get etherboot.dsk to work reliably we will definitely have
something.

Eric

Re: [Etherboot-developers] Etherboot 5.1.7 (development) released

[<ke...@us...>]

>It also computes the checksum of the rom image at least that is
>what I recall. 

I think you mean genrom, which computes the checksum of the RUM image
and stores it in a byte in the ROM header. This will be out of the
picture if we bypass the ROM header.

Re: [Etherboot-developers] Etherboot 5.1.7 (development) released

[<ebi...@ln...>]

ke...@us... (Ken Yap) writes:

> >It also computes the checksum of the rom image at least that is
> >what I recall. 
> 
> I think you mean genrom, which computes the checksum of the RUM image
> and stores it in a byte in the ROM header. This will be out of the
> picture if we bypass the ROM header.

Hmm. I looked again I thought the floppy loader was actually verifing that
checksum but I don't see that currently.  Oh well.

Eric