option rom size problem

[Jason Wang]

Hi all,
   Since i am working with adding libpayload usb stack to option rom, i have
been blocked with the usb_initialize function. I find that the size of
libpayload is 104K, but the max size of option rom is oxff * 512bytes. which
means 127.5K.
I am afraid our option rom can not works fine with usb stack properly. Is
there any other method for us to expand the rom size?

[Stefan Reinauer]

On 20.07.2009 17:40 Uhr, Jason Wang wrote:
> Hi all,
>    Since i am working with adding libpayload usb stack to option rom,
> i have been blocked with the usb_initialize function. I find that the
> size of libpayload is 104K, but the max size of option rom is oxff *
> 512bytes. which means 127.5K.
> I am afraid our option rom can not works fine with usb stack properly.
> Is there any other method for us to expand the rom size?

I think only those parts of libpayload that are actually used are
getting linked into the final binary,  since the objects are packed into
an "ar" archive. Do you exceed the rom size with libpayload and your
code already, or is this rather a theoretical issue?

-rw-r--r--   1 stepan  staff  114826 Jul 20 17:50 libpayload.a

-rw-r--r--   1 stepan  staff    1192 Jul 20 17:50 colors.o
-rw-r--r--   1 stepan  staff    1624 Jul 20 17:50 console.o
-rw-r--r--   1 stepan  staff    1940 Jul 20 17:50 coreboot.o
-rw-r--r--   1 stepan  staff    1720 Jul 20 17:50 ctype.o
-rw-r--r--   1 stepan  staff     514 Jul 20 17:50 exec.S.o
-rw-r--r--   1 stepan  staff     692 Jul 20 17:50 exec.o
-rw-r--r--   1 stepan  staff    5928 Jul 20 17:50 getopt_long.o
-rw-r--r--   1 stepan  staff     896 Jul 20 17:50 head.S.o
-rw-r--r--   1 stepan  staff     703 Jul 20 17:50 ipchecksum.o
-rw-r--r--   1 stepan  staff    1384 Jul 20 17:50 keyboard.o
-rw-r--r--   1 stepan  staff    4592 Jul 20 17:50 lar.o
-rw-r--r--   1 stepan  staff    1328 Jul 20 17:50 lib.o
-rw-r--r--   1 stepan  staff     920 Jul 20 17:50 main.o
-rw-r--r--   1 stepan  staff    3224 Jul 20 17:50 malloc.o
-rw-r--r--   1 stepan  staff    1076 Jul 20 17:50 memory.o
-rw-r--r--   1 stepan  staff    1432 Jul 20 17:50 nvram.o
-rw-r--r--   1 stepan  staff    1608 Jul 20 17:50 options.o
-rw-r--r--   1 stepan  staff    2160 Jul 20 17:50 pci.o
-rw-r--r--   1 stepan  staff    6660 Jul 20 17:50 printf.o
-rw-r--r--   1 stepan  staff     816 Jul 20 17:50 rand.o
-rw-r--r--   1 stepan  staff    1756 Jul 20 17:50 readline.o
-rw-r--r--   1 stepan  staff    9016 Jul 20 17:50 sha1.o
-rw-r--r--   1 stepan  staff    1032 Jul 20 17:50 speaker.o
-rw-r--r--   1 stepan  staff    2648 Jul 20 17:50 string.o
-rw-r--r--   1 stepan  staff     712 Jul 20 17:50 sysinfo.o
-rw-r--r--   1 stepan  staff    1808 Jul 20 17:50 time.o
-rw-r--r--   1 stepan  staff    1448 Jul 20 17:50 timer.o
-rw-r--r--   1 stepan  staff   10224 Jul 20 17:50 tinycurses.o
-rw-r--r--   1 stepan  staff   11436 Jul 20 17:50 uhci.o
-rw-r--r--   1 stepan  staff    2384 Jul 20 17:50 uhci_rh.o
-rw-r--r--   1 stepan  staff    5560 Jul 20 17:50 usb.o
-rw-r--r--   1 stepan  staff     884 Jul 20 17:50 usb_dev.o
-rw-r--r--   1 stepan  staff    1576 Jul 20 17:50 usbinit.o
-rw-r--r--   1 stepan  staff    5704 Jul 20 17:50 usbmsc.o
-rw-r--r--   1 stepan  staff     524 Jul 20 17:50 util.S.o
-rw-r--r--   1 stepan  staff    2032 Jul 20 17:50 vga.o
-rw-r--r--   1 stepan  staff    2848 Jul 20 17:50 video.o
-rw-r--r--   1 stepan  staff     582 Jul 20 17:50 virtual.o

I would think there is some potential for optimization: lar, tinycurses,
vga, sha1, getopt_long, speaker, video, and probably some more stuff
could be removed?

Stefan

[Carl-Daniel Hailfinger]

On 20.07.2009 17:54, Stefan Reinauer wrote:
> On 20.07.2009 17:40 Uhr, Jason Wang wrote:
> > Since i am working with adding libpayload usb stack to option rom,
> > i have been blocked with the usb_initialize function. I find that the
> > size of libpayload is 104K, but the max size of option rom is oxff *
> > 512bytes. which means 127.5K.
> > I am afraid our option rom can not works fine with usb stack properly.
> > Is there any other method for us to expand the rom size?
>
> I think only those parts of libpayload that are actually used are
> getting linked into the final binary,  since the objects are packed into
> an "ar" archive. Do you exceed the rom size with libpayload and your
> code already, or is this rather a theoretical issue?

If you really exceed the allowed size, the problem is not only option
rom size but also where in RAM you can place that much code.
Compression can help if you have enough free RAM to place that option
ROM somewhere.

Where does the option ROM end up? Below 1M?

Regards,
Carl-Daniel

[Leandro Dorileo]

Hi Carl

On Mon, Jul 20, 2009 at 12:48 PM, Carl-Daniel
Hailfinger wrote:
> On 20.07.2009 17:54, Stefan Reinauer wrote:
> > On 20.07.2009 17:40 Uhr, Jason Wang wrote:
> > > Since i am working with adding libpayload usb stack to option rom,
> > > i have been blocked with the usb_initialize function. I find that the
> > > size of libpayload is 104K, but the max size of option rom is oxff *
> > > 512bytes. which means 127.5K.
> > > I am afraid our option rom can not works fine with usb stack properly.
> > > Is there any other method for us to expand the rom size?
> >
> > I think only those parts of libpayload that are actually used are
> > getting linked into the final binary,  since the objects are packed into
> > an "ar" archive. Do you exceed the rom size with libpayload and your
> > code already, or is this rather a theoretical issue?
>
> If you really exceed the allowed size, the problem is not only option
> rom size but also where in RAM you can place that much code.
> Compression can help if you have enough free RAM to place that option
> ROM somewhere.

Do you mean we can have a code to decompress the option ROM and jump to it?
> Where does the option ROM end up? Below 1M?

Do you mean in RAM? do you want to know when we move the option ROM to
RAM? if so, I can tell you that we are not moving the option ROM to
RAM,  we leave it to seabios, seabios is who moves the ROM code to
RAM.

Regards...

[Leandro Dorileo]

Hi Carl

On Mon, Jul 20, 2009 at 1:12 PM, Leandro Dorileo wrote:
> Hi Carl
>
> On Mon, Jul 20, 2009 at 12:48 PM, Carl-Daniel
> Hailfinger wrote:
> > On 20.07.2009 17:54, Stefan Reinauer wrote:
> > > On 20.07.2009 17:40 Uhr, Jason Wang wrote:
> > > > Since i am working with adding libpayload usb stack to option rom,
> > > > i have been blocked with the usb_initialize function. I find that the
> > > > size of libpayload is 104K, but the max size of option rom is oxff *
> > > > 512bytes. which means 127.5K.
> > > > I am afraid our option rom can not works fine with usb stack properly.
> > > > Is there any other method for us to expand the rom size?
> > >
> > > I think only those parts of libpayload that are actually used are
> > > getting linked into the final binary,  since the objects are packed into
> > > an "ar" archive. Do you exceed the rom size with libpayload and your
> > > code already, or is this rather a theoretical issue?
> >
> > If you really exceed the allowed size, the problem is not only option
> > rom size but also where in RAM you can place that much code.
> > Compression can help if you have enough free RAM to place that option
> > ROM somewhere.
>
> Do you mean we can have a code to decompress the option ROM and jump to it?
> > Where does the option ROM end up? Below 1M?
>
> Do you mean in RAM? do you want to know when we move the option ROM to
> RAM? if so, I can tell you that we are not moving the option ROM to
> RAM,  we leave it to seabios, seabios is who moves the ROM code to
> RAM.

Of course that I think in a (future)hack to configure the option ROM
to be used with seabios or not, so we can have a code to copy from ROM
to RAM and so on.

Regards....

[Leandro Dorileo]

Hi Stefan

On Mon, Jul 20, 2009 at 11:54 AM, Stefan Reinauer wrote:
> On 20.07.2009 17:40 Uhr, Jason Wang wrote:
> > Hi all,
> >    Since i am working with adding libpayload usb stack to option rom,
> > i have been blocked with the usb_initialize function. I find that the
> > size of libpayload is 104K, but the max size of option rom is oxff *
> > 512bytes. which means 127.5K.
> > I am afraid our option rom can not works fine with usb stack properly.
> > Is there any other method for us to expand the rom size?
>
> I think only those parts of libpayload that are actually used are
> getting linked into the final binary,  since the objects are packed into
> an "ar" archive. Do you exceed the rom size with libpayload and your
> code already, or is this rather a theoretical issue?

No, not theoretical we have reached the max limit, even with a minimal
configuration.
> -rw-r--r--   1 stepan  staff  114826 Jul 20 17:50 libpayload.a
>
> -rw-r--r--   1 stepan  staff    1192 Jul 20 17:50 colors.o
> -rw-r--r--   1 stepan  staff    1624 Jul 20 17:50 console.o
> -rw-r--r--   1 stepan  staff    1940 Jul 20 17:50 coreboot.o
> -rw-r--r--   1 stepan  staff    1720 Jul 20 17:50 ctype.o
> -rw-r--r--   1 stepan  staff     514 Jul 20 17:50 exec.S.o
> -rw-r--r--   1 stepan  staff     692 Jul 20 17:50 exec.o
> -rw-r--r--   1 stepan  staff    5928 Jul 20 17:50 getopt_long.o
> -rw-r--r--   1 stepan  staff     896 Jul 20 17:50 head.S.o
> -rw-r--r--   1 stepan  staff     703 Jul 20 17:50 ipchecksum.o
> -rw-r--r--   1 stepan  staff    1384 Jul 20 17:50 keyboard.o
> -rw-r--r--   1 stepan  staff    4592 Jul 20 17:50 lar.o
> -rw-r--r--   1 stepan  staff    1328 Jul 20 17:50 lib.o
> -rw-r--r--   1 stepan  staff     920 Jul 20 17:50 main.o
> -rw-r--r--   1 stepan  staff    3224 Jul 20 17:50 malloc.o
> -rw-r--r--   1 stepan  staff    1076 Jul 20 17:50 memory.o
> -rw-r--r--   1 stepan  staff    1432 Jul 20 17:50 nvram.o
> -rw-r--r--   1 stepan  staff    1608 Jul 20 17:50 options.o
> -rw-r--r--   1 stepan  staff    2160 Jul 20 17:50 pci.o
> -rw-r--r--   1 stepan  staff    6660 Jul 20 17:50 printf.o
> -rw-r--r--   1 stepan  staff     816 Jul 20 17:50 rand.o
> -rw-r--r--   1 stepan  staff    1756 Jul 20 17:50 readline.o
> -rw-r--r--   1 stepan  staff    9016 Jul 20 17:50 sha1.o
> -rw-r--r--   1 stepan  staff    1032 Jul 20 17:50 speaker.o
> -rw-r--r--   1 stepan  staff    2648 Jul 20 17:50 string.o
> -rw-r--r--   1 stepan  staff     712 Jul 20 17:50 sysinfo.o
> -rw-r--r--   1 stepan  staff    1808 Jul 20 17:50 time.o
> -rw-r--r--   1 stepan  staff    1448 Jul 20 17:50 timer.o
> -rw-r--r--   1 stepan  staff   10224 Jul 20 17:50 tinycurses.o
> -rw-r--r--   1 stepan  staff   11436 Jul 20 17:50 uhci.o
> -rw-r--r--   1 stepan  staff    2384 Jul 20 17:50 uhci_rh.o
> -rw-r--r--   1 stepan  staff    5560 Jul 20 17:50 usb.o
> -rw-r--r--   1 stepan  staff     884 Jul 20 17:50 usb_dev.o
> -rw-r--r--   1 stepan  staff    1576 Jul 20 17:50 usbinit.o
> -rw-r--r--   1 stepan  staff    5704 Jul 20 17:50 usbmsc.o
> -rw-r--r--   1 stepan  staff     524 Jul 20 17:50 util.S.o
> -rw-r--r--   1 stepan  staff    2032 Jul 20 17:50 vga.o
> -rw-r--r--   1 stepan  staff    2848 Jul 20 17:50 video.o
> -rw-r--r--   1 stepan  staff     582 Jul 20 17:50 virtual.o
>
> I would think there is some potential for optimization: lar, tinycurses,
> vga, sha1, getopt_long, speaker, video, and probably some more stuff
> could be removed?

Removing most of libpayload we can take something around 100k, I think
it`s not enough.

Regards...