bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Migration to Etherboot-5.3 discussion


From: Feng Shuo
Subject: RE: Migration to Etherboot-5.3 discussion
Date: Wed, 19 Nov 2003 14:22:39 +0800

In fact, I have got such an 'interface' patch in my e1000 driver, but
since Okuji said that rewrite all the framework is better, I don't
release it out at all.

I also consider that rewriting is much better than just providing a
'translation layer' to the etherboot-5.3.3. By this, we can easily
support diskless machines with multiple Ethernet cards. We can also
support NFS just like local file systems --- the patch I provided hand
enclosed a file for RPC, but I don't have time to finish it :-(.

How about others think? :-)

-----Original Message-----
From: address@hidden
[mailto:address@hidden On Behalf Of R CHAN
Sent: Wednesday, November 19, 2003 9:53 AM
To: address@hidden
Subject: Migration to Etherboot-5.3 discussion

Hi,

Since others have brought it up, and it may not be rocket science,
I thought I'd start a thread on new functions in Etherboot-5.3
and how one might best migrate them to GRUB. As has pointed up,
others have tried and given up and it may not require a genious-level 
programmer, (but I'm currently at the moron-level).

Here are the global symbols needed by e1000.o
  U adjust_pci_device
  U mdelay
  U pci_bar_size
  U pci_bar_start
  U pcibios_read_config_byte
  U pcibios_read_config_word
  U pcibios_write_config_word
  U poll_interruptions
  U printf
  U udelay
  U virt_offset
and some questions on resolving them, please correct.

1. printf - no problem - map to etherboot_printf

2. udelay, mdelay usually macros in netboot/ code.
Should not be a problem, use new timer.c.

3. adjust_pci_device, pcibios_ functions - already in current netboot/ 
code. Only pci_bar_size, pci_bar_start are new but probably can
use new pci.c.

4. poll_interruptions() is new
Here is a code snippet - do you see any show-stoppers here?

void poll_interruptions(void)
{
         int ch;
#ifdef FREEBSD_PXEEMU
         if (pxeemu_nbp_active)
                 return;
#endif
         /* If an interruption has occured restart etherboot */
         if (iskey() && (ch = getchar(), (ch == K_ESC) || (ch == K_EOF) 
|| (ch == K_INTR))) {
                 int state = (ch != K_INTR)? -1 : -3;
                 longjmp(restart_etherboot, state);
         }
}


5. virt_offset - this is the main problem
Here is the declaration and usage in some inlines

/* Amount of relocation etherboot is experiencing */
extern unsigned long virt_offset;

/* Don't require identity mapped physical memory,
  * osloader.c is the only valid user at the moment.
  */
static inline unsigned long virt_to_phys(volatile const void *virt_addr)
{
         return ((unsigned long)virt_addr) + virt_offset;
}

static inline void *phys_to_virt(unsigned long phys_addr)
{
         return (void *)(phys_addr - virt_offset);
}

Unfortunately, virt_offset is defined in a .S file and I'm not
clear what it does - any thoughts on just setting it to 0?
It is used in two files start32.S, and pcibios.S

Here is where the value of virt_offset is set:


/***********************************************************************
***
START - Where all the fun begins....
************************************************************************
**/
/* this must be the first thing in the file because we enter from the
top */
         .text
         .arch i386
         .global _start
_start:
         .code32
         cli
         /* Save the initial ebp value */
         pushl   %ebp
 

         /*
          * See where I am running, and compute virt_offset
          */
         call    1f
1:      popl    %ebp
         subl    $1b, %ebp
         movl    %ebp, virt_offset(%ebp)

However, the variable is used and abused in many locations and
can change its value.

Awaiting edification,

Richard











_______________________________________________
Bug-grub mailing list
address@hidden
http://mail.gnu.org/mailman/listinfo/bug-grub





reply via email to

[Prev in Thread] Current Thread [Next in Thread]