[SeaBIOS] [PATCH] ramdisk: search for all available floppy images instead of one

[Mike Banon]

Dear Kevin,

Please could you tell me, why the memory allocation functions like
malloc_tmphigh() are failing at do_boot() stage? (boot.c) . Because of
this "VARVERIFY32INIT" problem described in my letter above -
https://mail.coreboot.org/pipermail/seabios/2018-November/012575.html
- I rewrote all my code to allocate the RAM for one floppy only (space
equal to max floppy size, which could be used by any selected floppy)
. But when I'm trying to boot that selected floppy - it is failing,
because these floppies are LZMA compressed inside CBFS and to
decompress them another malloc_tmphigh() is needed (from
cbfs_copyfile() / coreboot.c) / Although this code compiles fine (no
VARVERIFY32INIT problem) - this malloc_tmphigh() function is always
failing and SeaBIOS is freezing.

Spent all my weekend debugging this problem and really stuck, any help
will be highly appreciated

Best regards,
Mike Banon
On Sat, Nov 17, 2018 at 2:30 AM Mike Banon <mikebdp2 at gmail.com> wrote:
>
> Thank you very much for clarifying, Kevin. I finally moved this ram
> allocation to do_boot function (line 800) at boot.c - after the
> printf("Booting from Floppy...\n") - but sadly it seems that
> memalign_tmphigh and similar malloc'ing functions (like
> malloc_tmphigh) are not allowed at this stage:
>
> ERROR: .data.varinit.. is VARVERIFY32INIT but used from
> ['.text.runtime..', '.text.do_boot', '.text.malloc_tmphigh']
> Makefile:162: recipe for target 'out/romlayout16.lds' failed
> make[2]: *** [out/romlayout16.lds] Error 1
>
> I can't understand this cryptic error, and especially why it's
> happening with "malloc functions" at do_boot while they're working
> fine at loadBootOrder function from the same boot.c file (line 50) :
> Bootorder = malloc_tmphigh(BootorderCount*sizeof(char*)); Out of
> curiosity I tried restoring do_boot to its' original state then
> inserted this line of code there ( Bootorder and BootorderCount are
> globally declared ) and got a similar error.
>
> Is it true that malloc'ing during the do_boot is impossible (why?) -
> and, if yes, what are the possible workarounds? Maybe I could rewrite
> it to leave a single "malloc_tmphigh" inside ramdisk_setup / ramdisk.c
> for the size of largest floppy (will look through the floppies at CBFS
> and find the largest one) and use this allocated RAM space for any
> floppy that would be selected later. <--- This way I would allocate
> just 1.4MB if there are 10 * 1.4M floppies and should be less code
> changes
> On Tue, Nov 13, 2018 at 9:06 PM Kevin O'Connor <kevin at koconnor.net> wrote:
> >
> > On Sun, Nov 11, 2018 at 02:12:09AM +0300, Mike Banon wrote:
> > > > However I'm concerned that this would reserve memory for all
> > > > of the floppy images in the e820 map (and thus the final OS
> > > > would not be able to use that memory).
> > >
> > > sorry Kevin I'm not fully understanding the consequences. Would
> > > reserving e820 memory for all the floppies - result in a slightly
> > > lower amount of available RAM to OS (e.g. just 14 MB lower if I add 10
> > > floppies) or there could be more serious problems?
> >
> > Just the loss of 14MB of ram.  It seems odd to reserve that ram when I
> > expect one would rarely use it.  Arguably, seabios shouldn't reserve
> > even 1.4MB of ram if one isn't actually booting from the given image,
> > but extending this to every image found when most wouldn't even be
> > accessible seems even worse.
> >
> > >When I've been
> > > testing this patch - together with "35 boot menu entries" patch by
> > > Ivan - https://mail.coreboot.org/pipermail/seabios/2017-June/011416.html
> > > - I added about 30 floppies and everything seemed to work perfectly.
> > > If there are no other possible problems, I am okay with slightly lower
> > > amount of RAM - and only the "multiple floppies" users will be
> > > affected. Also, what's good about this patch is that its' only a small
> > > change for SeaBIOS source code - mostly placing the "floppy searching"
> > > code inside the "for" cycle. But I could try to do something with the
> > > allocation part if that wouldn't turn out too difficult
> >
> > Okay, thanks.  We're planning to make a SeaBIOS release in a few days
> > and this change would be post release anyway.
> >
> > -Kevin