etherboot-developers — Discussion of developer issues

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

>Cool.  Next round since the relocation basically works for you, as you
>can use a comppressed etherboot on your machine, could you add
>-DRELOCATION in the config file.  That should fix the clash in low
>memory.  

Will do.

>And then the big mystery.  NBI's appear to work for you, and not for
>others.  Why and where their first packet is getting corrupted is a
>mystery. 

I think it's because I'm using mkelf-linux and they are using
mknbi-linux. If that's the case then I think the FreeDOS image will crash
the same way as theirs (DOS has to be a real mode entry image).

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

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

> Ok, did more testing. Booted a 5.1.2 (up to CVS) unrelocated compressed
> image using a 5.0.7 ROM. Menu comes up ok and I can load menus ad
> infinitum. I can load an ELF bzImage and initrd ok but it stops after
> loading has finished, probably jumps into hyperspace. 

Hmm.  That isn't good.  There was a fix I put into virt_to_phys
a couple of days ago where it relocated the stack pointer and used
it before fixing everything up.

The ELF case I am fairly certain works here, I will have to try a build
without MULTI boot support and see what happens.  This is the main
case I have been testing....

> I cannot load a
> tagged FreeDOS image, it complains about the clash in low memory.

Cool.  Next round since the relocation basically works for you, as you
can use a comppressed etherboot on your machine, could you add
-DRELOCATION in the config file.  That should fix the clash in low
memory.  

Actually I am very happy that the menu code works.  I hadn't
had a chance to test the return to etherboot code to see if it
really worked in practice :)  (No menus).  The largest change 
I did on that code path is the reprobe code.  Instead of testing
a flag to see if the image will return, and not shutting everything
down, I shut everything down irregradless and reprobe the same NIC 
to bring it back to live.  It makes life easier and more robust
if it works.

And then the big mystery.  NBI's appear to work for you, and not for
others.  Why and where their first packet is getting corrupted is a
mystery. 

Eric

Re: [Etherboot-developers] I've just checked and ...

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

Ronald G Minnich <rmi...@la...> writes:

> On 29 Aug 2002, Eric W Biederman wrote:
> 
> > That certainly looks like a piece of it.  Given the rough granularity
> > of i/o to port 0x80.  I would rather calibrate the counter on
> > something more precise, if I had the option.
> 
> I wish I could think of something.
> 
> > Does Linux need a special patch to run on the smartcore?  Or how does
> > it calibrate the tsc?
> 
> You know, I don't know. We just diagnosed the problem and applied this
> fix, and linux seemed to be happy. I never looked at this. Now you've made
> me curious :-)

If Linux has something fairly universal for x86 we can use that,
otherwise I want a config option.

As much as possible I prefer precise delays, so that things work
as much the same as possible between different machines.  Already
the user base is spread out enough it can be a challenge to reproduce
another users problems.

Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

"Timothy Legge" <tl...@ro...> writes:

> > I don't have any good ideas but if you have a null modem cable I
> > have a set
> > of easy to use serial port debug print statements.
> 
> The only null cable modem I have goes to a palm iii.  Next time I am out, I
> will look for one.  I guess I better do some research on how to use it,
> right now I could only use it for a neck tie.

Having a simple assembly routine that dumps to the video display works
as well.  The advantage of a null modem cable is that you capture
all of the output on another machine, with scroll back and other
nice amenities.  And if you already have 2 machines it is quite
handy.

The easiest program to hook up and get something going with is minicom
although there are other options.

Eric

Re: [Etherboot-developers] I've just checked and ...

[Ronald G M. <rmi...@la...>]

On 29 Aug 2002, Eric W Biederman wrote:

> That certainly looks like a piece of it.  Given the rough granularity
> of i/o to port 0x80.  I would rather calibrate the counter on
> something more precise, if I had the option.

I wish I could think of something.

> Does Linux need a special patch to run on the smartcore?  Or how does
> it calibrate the tsc?

You know, I don't know. We just diagnosed the problem and applied this
fix, and linux seemed to be happy. I never looked at this. Now you've made
me curious :-)

ron

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

Ok, did more testing. Booted a 5.1.2 (up to CVS) unrelocated compressed
image using a 5.0.7 ROM. Menu comes up ok and I can load menus ad
infinitum. I can load an ELF bzImage and initrd ok but it stops after
loading has finished, probably jumps into hyperspace. I cannot load a
tagged FreeDOS image, it complains about the clash in low memory.

RE: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Timothy L. <tl...@ro...>]

> I don't have any good ideas but if you have a null modem cable I
> have a set
> of easy to use serial port debug print statements.

The only null cable modem I have goes to a palm iii.  Next time I am out, I
will look for one.  I guess I better do some research on how to use it,
right now I could only use it for a neck tie.

Tim

Re: [Etherboot-developers] I've just checked and ...

[Eric W B. <ebi...@ln...>]

Ronald G Minnich <rmi...@la...> writes:

> The 5.0.5 timer.[ch] is identical it seems with the 5.0.7 version. So my
> 5.0.5 version should be fine with 5.0.7. My version has the "don't use
> timer2" patch. I am attaching it for all of you to take a look see and
> comment. I think this might help with my current problems as Smartcore
> systems don't actually have a TIMER2 -- all timeouts go to 0.

That certainly looks like a piece of it.  Given the rough granularity
of i/o to port 0x80.  I would rather calibrate the counter on
something more precise, if I had the option.

Does Linux need a special patch to run on the smartcore?  Or how does
it calibrate the tsc?

Beyond the calibration issues it looks like a good idea.  When I have
a moment I will see what I can do about incorporating this into 5.1.x.

Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Eric W B. <ebi...@ln...>]

"Timothy Legge" <tl...@ro...> writes:

> > Just to tripple check you are not loading a compressed image?
> 
> Just to clarify, do you mean is the file listed in /etc/dhcpd.conf
> compressed? 

No.  I mean the etherboot image that locks up.

> Since the 486 never gets to the point of recognizing the nic,
> it hardly matters.  The rom was created via make bin32/3c509.fd0 

O.k. not make bin32/3c509.lzfd0.  So it is not compressed.

> and file
> being grabbed from the dhcp server is either a ltsp kernel or a boot rom
> that was created via mknbi-linux bin32/3c509.rom > /tftproot/lts/bootrom.  I
> could not tell you whether either of those files are compressed if my life
> depended upon it.  However, etherboot was compiled with the default options.
> 
> > Other than that I would guess I accidentally introduced an instruction
> > that doesn't exist on your 486.
> 
> Any idea how to track it down?

What I normally would do is write a little assmebly routine that outputs
to the screen, or even better the serial port (if you have a null modem cable
setup).  And sprinkle it through the assembly.

The steps through:
loader.S start16.S and start32.S are not too difficult to trace.

Another option is include a ``.arch i386'' instruction in the assmebly files,
but I just tried that and I didn't get any warnings ;(

A second possibility is that the stack pointer is at an unfortunate location.
But in this case we use the stack from boot1a.s so that should be constant
across machines.

I don't have any good ideas but if you have a null modem cable I have a set
of easy to use serial port debug print statements.

Eric

RE: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Timothy L. <tl...@ro...>]

> Just to tripple check you are not loading a compressed image?

Just to clarify, do you mean is the file listed in /etc/dhcpd.conf
compressed?  Since the 486 never gets to the point of recognizing the nic,
it hardly matters.  The rom was created via make bin32/3c509.fd0 and file
being grabbed from the dhcp server is either a ltsp kernel or a boot rom
that was created via mknbi-linux bin32/3c509.rom > /tftproot/lts/bootrom.  I
could not tell you whether either of those files are compressed if my life
depended upon it.  However, etherboot was compiled with the default options.

> Other than that I would guess I accidentally introduced an instruction
> that doesn't exist on your 486.

Any idea how to track it down?

Tim

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Eric W B. <ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> On Thu, 29 Aug 2002, Timothy Legge wrote:
> > > > > >Of course, "fixed it" in this context merely means "getting
> > > the correct
> > The current cvs allows me to transfer both the rom and ltsp kernel.  Of
> > course, both report Unable to load file and this is true with both the 3c509
> > and 3c515
> 
> Yep, that seems to match the state that mine is in.  It no longer locks up
> in endless loops, but bombs out because it can't find the section to
> execute in the NBI image.  Since the same thing is happening with 3c509,
> 3c515 and rtl8139, it probably isn't a driver problem.

Likely.  The problem happens with the first 512 bytes of the first
tftp packet received.  It might be worth adding some print statements
and tracing the packet from poll to tagged_probe.

The first few bytes are correct but something else is wrong.

Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Eric W B. <ebi...@ln...>]

"Timothy Legge" <tl...@ro...> writes:

> Hi
> 
> > Current my 486 still freezes hard before the driver is loaded.
> 
> >From what I can tell, it freezes between:
> 
> boot1a.S:196
> 
> msg_r1:	.asciz " Done\r\n"
> 
> and
> 
> main.c:152
> 
> printf("ROM segment %#hx length %#hx reloc %#x\n", rom.rom_segment,
> 		rom.rom_length << 1, (unsigned long)_text);
> 
> I thought it was the printf, so I commented it out but it still froze hard.
> My assembly is non-existant, so that is about the best I can do.

Just to tripple check you are not loading a compressed image?

Other than that I would guess I accidentally introduced an instruction
that doesn't exist on your 486.

Eric

RE: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Timothy L. <tl...@ro...>]

Hi

> Current my 486 still freezes hard before the driver is loaded.

From what I can tell, it freezes between:

boot1a.S:196

msg_r1:	.asciz " Done\r\n"

and

main.c:152

printf("ROM segment %#hx length %#hx reloc %#x\n", rom.rom_segment,
		rom.rom_length << 1, (unsigned long)_text);

I thought it was the printf, so I commented it out but it still froze hard.
My assembly is non-existant, so that is about the best I can do.

Tim

RE: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Michael B. <mb...@fe...>]

On Thu, 29 Aug 2002, Timothy Legge wrote:
> > > > >Of course, "fixed it" in this context merely means "getting
> > the correct
> The current cvs allows me to transfer both the rom and ltsp kernel.  Of
> course, both report Unable to load file and this is true with both the 3c509
> and 3c515

Yep, that seems to match the state that mine is in.  It no longer locks up
in endless loops, but bombs out because it can't find the section to
execute in the NBI image.  Since the same thing is happening with 3c509,
3c515 and rtl8139, it probably isn't a driver problem.

Michael Brown
http://www.fensystems.co.uk

RE: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Timothy L. <tl...@ro...>]

> > > >Of course, "fixed it" in this context merely means "getting
> the correct

The current cvs allows me to transfer both the rom and ltsp kernel.  Of
course, both report Unable to load file and this is true with both the 3c509
and 3c515


Current my 486 still freezes hard before the driver is loaded.

Tim

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Michael B. <mb...@fe...>]

On 29 Aug 2002, Eric W Biederman wrote:
> > That is one address I forget to check to see if it is safe to load.  Want to
> > take a look at that?
> In particular something like:
> 	printf("(NBI)");
> 	/* Zero all context info */
> 	memset(&tctx, 0, sizeof(tctx));
> 	/* Copy first 4 longwords */
> 	memcpy(&tctx.img, data, sizeof(tctx.img));
> 	/* Memory location where we are supposed to save it */
> 	tctx.segaddr = tctx.linlocation =
> 		((tctx.img.u.segoff.ds) << 4) + tctx.img.u.segoff.bx;
> +	if (!prep_segment(tctx.segaddr, tctx.segaddr + 512, tctx.segaddr + 512,
> +		0, 512) {
> +		return 0;
> +	}
> 	/* Grab a copy */
> 	memcpy(phys_to_virt(tctx.segaddr), data, 512);
> 	/* Advance to first segment descriptor */
> 	tctx.segaddr += ((tctx.img.length & 0x0F) << 2)
> 		+ ((tctx.img.length & 0xF0) >> 2);
> 	/* Remember to skip the first 512 data bytes */
> 	tctx.first = 1;

Have added the patch, didn't make any difference so it wasn't that that
was the problem anyway.  In tagged_download(), I added an abort if
sh.length == 0 (same defence as before).  Etherboot will now download the
image (or something that looks to be the right size) but fails to boot
because it can't find the segment with (sh.flags & 0x04) set.  At least it
doesn't lock up and force me to reboot each time I want to test it now!
:-)

It looks as though the downloaded image is being corrupted somehow.  I'm
using an image that is known to work with Etherboot 5.0.6 through to
current 5.0.x HEAD, so it's not the image itself.

Progress, albeit slow, is happening.

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Eric W B. <ebi...@ln...>]

Eric W Biederman <ebi...@ln...> writes:
 
> That is one address I forget to check to see if it is safe to load.  Want to
> take a look at that?

In particular something like:

	printf("(NBI)");
	/* Zero all context info */
	memset(&tctx, 0, sizeof(tctx));
	/* Copy first 4 longwords */
	memcpy(&tctx.img, data, sizeof(tctx.img));
	/* Memory location where we are supposed to save it */
	tctx.segaddr = tctx.linlocation = 
		((tctx.img.u.segoff.ds) << 4) + tctx.img.u.segoff.bx;
+	if (!prep_segment(tctx.segaddr, tctx.segaddr + 512, tctx.segaddr + 512,
+		0, 512) {
+		return 0;
+	}
	/* Grab a copy */
	memcpy(phys_to_virt(tctx.segaddr), data, 512);
	/* Advance to first segment descriptor */
	tctx.segaddr += ((tctx.img.length & 0x0F) << 2)
		+ ((tctx.img.length & 0xF0) >> 2);
	/* Remember to skip the first 512 data bytes */
	tctx.first = 1;

Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Eric W B. <ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> On Fri, 30 Aug 2002, Ken Yap wrote:
> > >Of course, "fixed it" in this context merely means "getting the correct
> > >E820 map".  It still locks up at "Loading 10.1.0.1:boot-8139too.nbi
> > >...(NBI)" and requires a hard reset. :-(
> > >Next set of ideas?
> > I wager that this is now a relocation problem in the 8139 driver. Are you
> > building with or without relocation? Have you got an I/O only NIC like
> > the 3c509 or NE2000 you can try the latest fixes on first?
> 
> OK, have overcome another layer of the problem.  The prep_segment loop in
> tagged_probe() in osloader.c was never exiting; the exit condition was
> incorrect.  It was testing for sh->flags & 0x04 (last segment flag), which
> is not always present.  

Very strange looking at the code from 5.0.6 the same test is performed
is performed as an exit condition.  We never attempt to execute the image
if that case isn't found.

> Additionally, it would have skipped the last segment itself.  

That sounds like a bug I introduced, though at worst that should simply
forget to zero the bss.

> I have changed the code to check for sh->length == 0 and
> sh->flags & 0x04 as exit conditions.  This gets me past that hurdle, but I
> don't know if it is a correct solution.

I think I would look into why sh->flags &0x04 is not present.  I find that
very suspcious, as the image is not bootable if that is the case.

Exiting the loop when sh->length == 0 sounds like good defensive programming.
I wonder if tctx.linlocation is overlapping etherboot in the non-relocated case?

That is one address I forget to check to see if it is safe to load.  Want to take
a look at that?

Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Eric W B. <ebi...@ln...>]

Michael Brown <mb...@fe...> writes:

> On Fri, 30 Aug 2002, Ken Yap wrote:
> > >Of course, "fixed it" in this context merely means "getting the correct
> > >E820 map".  It still locks up at "Loading 10.1.0.1:boot-8139too.nbi
> > >...(NBI)" and requires a hard reset. :-(
> > >Next set of ideas?
> > I wager that this is now a relocation problem in the 8139 driver. Are you
> > building with or without relocation? Have you got an I/O only NIC like
> > the 3c509 or NE2000 you can try the latest fixes on first?
> 
> Have been building with the default Config file, which doesn't define
> -DRELOCATE.

Which is half of it.  The other part is not to build a compressed image.
Only non-compressed images load at RELOCADDR.  Compressed images load
there, and then the decompressor moves them up in memory by a few bytes.

> Can someone post a rough outline of what needs to be done to a driver in
> order to make it work with 5.1.x?  When building without -DRELOCATE,
> should the old drivers work "as is"?

To work with 5.1.x a driver needs to have the appropriate virt_to_bus,
bus_to_virt, and ioremap calls added.  The goal is to make the
relocation overhead just what is needed for portability anyway.


Etherboot retains a 1-1 mapping of virtual to physical address, but the
mapping is no longer an identiy mapping.  At some point the ioremap
code may need to play with page tables, but at this point we don't
need that.

I only think we have one or two drivers that need ioreamp, and we need
a helper function to give the size of a pci bar, before we convert
those.  But the rest of the driver should be straight forward.

Eric

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Michael B. <mb...@fe...>]

On Fri, 30 Aug 2002, Ken Yap wrote:
> >Of course, "fixed it" in this context merely means "getting the correct
> >E820 map".  It still locks up at "Loading 10.1.0.1:boot-8139too.nbi
> >...(NBI)" and requires a hard reset. :-(
> >Next set of ideas?
> I wager that this is now a relocation problem in the 8139 driver. Are you
> building with or without relocation? Have you got an I/O only NIC like
> the 3c509 or NE2000 you can try the latest fixes on first?

OK, have overcome another layer of the problem.  The prep_segment loop in
tagged_probe() in osloader.c was never exiting; the exit condition was
incorrect.  It was testing for sh->flags & 0x04 (last segment flag), which
is not always present.  Additionally, it would have skipped the last
segment itself.  I have changed the code to check for sh->length == 0 and
sh->flags & 0x04 as exit conditions.  This gets me past that hurdle, but I
don't know if it is a correct solution.

On to the next bug...

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Michael B. <mb...@fe...>]

On Fri, 30 Aug 2002, Ken Yap wrote:
> >Of course, "fixed it" in this context merely means "getting the correct
> >E820 map".  It still locks up at "Loading 10.1.0.1:boot-8139too.nbi
> >...(NBI)" and requires a hard reset. :-(
> >Next set of ideas?
> I wager that this is now a relocation problem in the 8139 driver. Are you
> building with or without relocation? Have you got an I/O only NIC like
> the 3c509 or NE2000 you can try the latest fixes on first?

Have been building with the default Config file, which doesn't define
-DRELOCATE.

Can someone post a rough outline of what needs to be done to a driver in
order to make it work with 5.1.x?  When building without -DRELOCATE,
should the old drivers work "as is"?

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

>Of course, "fixed it" in this context merely means "getting the correct
>E820 map".  It still locks up at "Loading 10.1.0.1:boot-8139too.nbi
>...(NBI)" and requires a hard reset. :-(
>
>Next set of ideas?

I wager that this is now a relocation problem in the 8139 driver. Are you
building with or without relocation? Have you got an I/O only NIC like
the 3c509 or NE2000 you can try the latest fixes on first?

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

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

>Fixed it!
>
>Problem was that %ebx was not zeroed before the first Int15:e820 call.
>Presumably, some BIOSes can cope with this and will correct for it, but
>others will just blindly use it as an offset into some table.
>
>I now get the correct E820 map returned in 5.1.x.  Fix is committed to
>pcbios.S.  It's a one-liner:
>  xorl %ebx, %ebx
>that somehow got lost between 5.0.x and 5.1.x.

Bravo! Looks like it's time for me to make another rc tarball.

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Michael B. <mb...@fe...>]

On Thu, 29 Aug 2002, Michael Brown wrote:
> > > > I think I'm seeing the same problem.  I'm getting total garbage in the
> > > > E820 map.  I added a config option IGNORE_E820_MAP that forces use of the
> > > > "fake" memory map used when the e820 calls fail, which gets it to the
> > > > point of "Loading 10.1.0.1:boot-8139too.nbi ...(NBI)" at which point it
> > > > locks up and requires a hard reset.
> > > The symptoms are certainly the same.
> > > > Ideas, toolchain test, etc. welcome.
> > > Could you see if the E820 issue is new?
> > > That is could you take a 5.0 series etherboot and dump the e820 map
> > > you get.
> > ...
> Fixed it!

Of course, "fixed it" in this context merely means "getting the correct
E820 map".  It still locks up at "Loading 10.1.0.1:boot-8139too.nbi
...(NBI)" and requires a hard reset. :-(

Next set of ideas?

Michael Brown
http://www.fensystems.co.uk

Re: [Etherboot-developers] [COMMIT] 5.1.2+ boot from disk.

[Michael B. <mb...@fe...>]

On Thu, 29 Aug 2002, Michael Brown wrote:
> > > I think I'm seeing the same problem.  I'm getting total garbage in the
> > > E820 map.  I added a config option IGNORE_E820_MAP that forces use of the
> > > "fake" memory map used when the e820 calls fail, which gets it to the
> > > point of "Loading 10.1.0.1:boot-8139too.nbi ...(NBI)" at which point it
> > > locks up and requires a hard reset.
> > The symptoms are certainly the same.
> > > Ideas, toolchain test, etc. welcome.
> > Could you see if the E820 issue is new?
> > That is could you take a 5.0 series etherboot and dump the e820 map
> > you get.
> Done.  Result with current 5.0.x CVS is sensible:
> [0000000000000000, 000000000009FC00) type 1
> [000000000009FC00, 00000000000A0000) type 2
> [00000000000F0000, 0000000000100000) type 2
> [00000000FFFF0000, 0000000100000000) type 2
> [0000000000100000, 00000000037F0000) type 1
> [00000000037F3000, 0000000003800000) type 3
> [00000000037F0000, 00000000037F3000) type 4
> Result from 5.1.x is genuine garbage, looking almost like random data.
> Short extract:
> ...
> [0F52506100000000, 1B5D5D6319190619) type 0
> [4000400010000800, 9050672860302028) type 690825260
> [C0325250291E2E2A, 61193E3649CF1F10) type 552004582
> ...

Fixed it!

Problem was that %ebx was not zeroed before the first Int15:e820 call.
Presumably, some BIOSes can cope with this and will correct for it, but
others will just blindly use it as an offset into some table.

I now get the correct E820 map returned in 5.1.x.  Fix is committed to
pcbios.S.  It's a one-liner:
  xorl %ebx, %ebx
that somehow got lost between 5.0.x and 5.1.x.

Michael Brown
http://www.fensystems.co.uk