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 21:08:30 +0800

Oh, maybe I made some mistake in version ---- the Makefile.am in my CVS
tree has -DPCI_CONFIG in NET_CFLAG. :'-(
I just got a Dual P4 Xeon with e1000 card in the lab. I will check the
driver on it. And, etherboot updated it's "epic100" "via-rhine" and
"tg3" drivers yesterday, I'll made all these in a new patch soon.
Thank everybody's help very much :-)

-----Original Message-----
From: R CHAN [mailto:address@hidden 
Sent: Wednesday, November 19, 2003 5:26 PM
To: Feng Shuo
Cc: address@hidden
Subject: Re: Migration to Etherboot-5.3 discussion

Very nice - so far so good with e1000.o.
But CONFIG_PCI is not defined for e1000 when I used
./configure --enable-diskless --enable-e1000

Are you short of a -DCONFIG_PCI in netboot/Makefile.in
for e1000?

Feng Shuo wrote:
> 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]