Re: Etherboot and gpxe

Here is the output of the size. They looked similar:
In etherboot;
   text    data     bss     dec     hex filename
  20937      48   96624  117609   1cb69 xxxx.o

In gPXE:
   text    data     bss     dec     hex filename
  21461      40   96624  118125   1cd6d xxxx.o

What can I do for the config/defaults.h?
------------------------------------
% cat defaults.h
#ifndef CONFIG_DEFAULTS_H
#define CONFIG_DEFAULTS_H

#define CONFIG_DEFAULTS(_platform) <config/defaults/_platform.h>

#include CONFIG_DEFAULTS(PLATFORM)

#endif /* CONFIG_DEFAULTS_H */
--------------------------------------

If the ROM images has to be more than 32k, it become useless in all my 
systems. There are other I/O cards share 128k Option ROM space in these 
systems.

Thanks,
Joyce



On 08/06/09 12:21, Joshua Oreman wrote:
> On Thu, 2009-08-06 at 11:52 -0700, Joyce Yu wrote:
>   
>> I spent sometime to look at the new gPXE API. I think it takes a few 
>> days to port and debug a driver. But I am looking for a few other things 
>> before I do the actually porting work. So I did a quick porting using 
>> the legacy etherboot interfaces. What I found is the gPXE ROM image size 
>> is too large. In the etherboot environment, I was able to control the 
>> image size to be 32k by changing 'makerom.pl' to 'makerom.pl -s 0', and 
>> make bin/xxxx.zrom. In the gPXE environment, the ROM image size of the 
>> same driver is 64k which cause the option overflow in my system.  I can 
>> see that my xxxx.o in gPXE (quick port using legacy interfaces) is five 
>> times larger  than my xxxx.o in the etherboot.
>>     
>
> That is very strange, and given the emphasis we put on small code I'm
> surprised at the apparent difference in the same code compiled under
> each environment. Generally, comparing the file size of object files is
> misleading; could you post the output of running the `size' command on
> each?
>
> That said, in terms of final ROM size, gPXE contains many more features
> than Etherboot, and they do take up some room. I know people have had
> success cramming gPXE into 32kb in the past, but I'm not quite sure how
> they managed it; hopefully someone else on this list can provide
> suggestions. In quick testing I was able to get a rtl8139 ROM down to
> 38,400 bytes by simply disabling things in config/defaults.h - perhaps
> you could try that?
>
>   
>> I also have a question regarding the usages of the iobuf in the TX in 
>> gPXE. If the packet in the iobuf was copied to a pre-allocated buffer 
>> and sent to the HW to be kicked to the wire, iobuf can be set to NULL to 
>> be re-used by the stack after the kick, and there is no need to look at 
>> the TX completion in the xxx_poll(), right?
>>     
>
> The I/O buffer passed to your transmit() function is still owned by the
> netdevice layer, and must eventually be freed by calling
> netdev_tx_complete() on it. You should never free_iob() that I/O buffer
> yourself. Theoretically, you could copy the contents into a preallocated
> iobuf and call netdev_tx_complete() immediately in transmit(), but that
> uses extra memory and time for the copy, robs the netdevice layer of
> status information if the TX fails, and you'll still have to reap that
> descriptor eventually. I recommend against this approach.
>
> -- Josh
>
>   
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>   
> ------------------------------------------------------------------------
>
> _______________________________________________
> Etherboot-discuss mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/etherboot-discuss
>   


--

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july

_______________________________________________
Etherboot-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/etherboot-discuss