[Etherboot-developers] Re: Pushing LinuxBIOS inspired changes back to etherboot.

[ollie l. <ol...@si...>]

On Fri, 2002-07-26 at 13:54, Eric W Biederman wrote:
> > 
> > > Though it should be noted that working with different drives and
> > > different controlles seems to give some noticeably different results
> > > so even after the code looks solid to everyone we need to keep our
> > > eyes peeled for a while.
> > > 
> > 
> > I think a proper controller driver and Identify/Set feature sequence
> > is necessary to to cope with various IDE drives.
> 
> In this case all I have identified so far is the need for proper error
> checking :) But we will see.
> 

Well, we encountered various problems with those flash IDE devices.
These device works fine under Linux but have problems with etherboot.

> Let me summarize for you what changes I have been making to support
> LinuxBIOS better, in etherboot.  And we can figure out where to work
> your stuff in from there.
> 
> Currently I have cvs access, and etherboot has a cvs development
> branch open on sourceforge that I have been pushing my changes into
> when the look like the will work.  I don't intend to stop until
> everything works again but there has been a little bit of breakage.
> 
> 1) I have added relocation code so that etherboot now will relocate
>    itself to the top of memory after it has loaded, and I have done
>    most of the surgery so this works with normal etherboot as well.
>    With the relocation code in place we are free to expand the code
>    size of etherboot to > 64K.

I saw this on Etherboot mail list archive last week. So you use virtual
memory to achieve relocation ?? BTW, how do you remap physical memory
to virtual memory ?? Identical mapping ??

> 2) I have ported the compressor to 32bit code allowing the LinuxBIOS
>    etherboot romimage to be self uncompressing.  
> 3) I have done most of the work so that the etherboot drives will now
>    use virt_to_bus, bus_to_virt && ioremap allowing them to be
>    portable.

One problem of the GRUB file system code (or Etherboot itself) is that
it has no idea of memory allocation nor virtual address space. For
example, it used a predefined FSYSxxx as a pointer to some physical
address and uses it as buffer for disk I/O, I believe there are various
other places in the code which assume logical address == physical
address.

> 4) I have discussed on the mailing list and have gotten some approval
>    on how to do disk support when configuration via DHCP is in
>    control.  Basically: ``filename "file::///disk0"'' or if we have a
>    filesystem, "file:///disk0/{partion number}/{filesystem path}

IIRC, I proposed something similiar on the list long time ago, we need
something like URL for both networked and filesystem boot.

> 5) I have incorporated your windows ce loader into etherboot, though
>    it isn't as clean as it might be.
> 
> As for menuing and how to be more interactive with users as your code
> does I'm not certain.  But take each each issue up on the list and I
> am fairly certain we can work something out.
> 

I have no idea if the interactive mode is vital for general users. It
is good for us to debugg since 550 does not have a serial port, I 
believe we will remove all the interactive stuff in the production
image.

Ollie