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

[Mike Banon]

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