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@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@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
-
Mike Banon