Some updates regarding the experiments:
1. Switched SeaBIOS back to master and it turned out this time all Mike Banon's patches applied successfully, so those patches were indeed for master. Not sure why some of these patches are marked as "Failed in applying to current master" in patchew.org's catalog. I can now properly choose which floppy image (or real device) to boot. Still, I'd like to be able to change some boot orders later on so I can let the system auto-boot to the first hard disk if needed.
2. I disabled the serial console as it appeared that memtest is actually outputting things there as well... something like: [LINE_SCROLL;24r[H[2J[37m[44m[0m[37m[44m[1;1HMemtest86+ 5.01 coreboot 002[0m[6;61H| Time: 0:00:00[2;31HPass %[3;31HTest %[4;31HTest #[5;31HTesting: [6;31HPattern: [2;1HCLK: (32b Mode)[3;1HL1 Cache: Unknown [4;1HL2 Cache: Unknown [5;1HL3 Cache: None [6;1HMemory : [7;1H------------------------------------------------------------------------------[8;1HCore#:[9;1HState:[10;1HCores: Active / Total (Run: All) | Pass: 0 Errors: 0 [11;1H------------------------------------------------------------------------------[8;40H| Chipset : Unknown[9;40H| Memory Type : Unknown[1;29H| [2;29H| [3;29H| [4;29H| [5;29H| [6;29H| [25;1H(ESC)exit (c)configuration (SP)scroll_lock (CR)scroll_unlock[6;12H128[6;15HG[1;31HAMD Opteron(tm) Processor 6386 SE[2;11HMHz[2;6H2800[3;11H K [3;13H64[3;24HMB/s[3;18H28867[4;11H K [4;11H2048[4;24HMB/s[4;18H23932[5;12H K [5;13H12[5;15HM[5;24HMB/s[5;19H8383[19;19H==> Press F1 to enter Fail-Safe Mode <==[20;16H==> Press F2 to force Multi-Threading (SMP) <==[19;19H [20;16H [8;8H0[9;8HS[10;21H1[8;10H(SMP: Disabled)[9;10HRunning...[8;42HRAM: [8;47H800 [8;51HMHz ([8;56HDDR3-[8;61H1600[8;65H)[8;67H- BCLK: [8;76H87[9;42HTimings: CAS [9;55H11[9;57H-[9;58H11[9;60H-[9;61H11[9;63H-[9;64H28[9;67H@ 128-bit Mode[24;34HASUS[24;39HKGPE-D16[13;1HMemory SPD Informations[14;1H--------------------------[9;32H22[8;27H| CPU Temp[9;27H| C[2;17HPAE Mode)[2;17HX64 Mode)[6;24HMB/s[4;37H2 [4;40H[Address test, own address Parallel] [9;8HW[10;9H1[9;8H-[6;57HR[5;43H0[5;44HK[5;46H- [5;50H32[5;52HM[5;58H32[5;60HM[5;62Hof [5;66H128[5;69HG[6;42Haddress [3;37H0[2;37H0[6;77H1[9;32H24
However, disabling serial console made little difference as the situation is the same as usual (memtest crashes with the same glitched screen). I checked about the post regarding the hangs, but it seems coreboot itself has changed so much over time that there were way too many differences in the .config file.
3. After some testing, using the following combinations for 16GB sticks can also make the system bootable with all 128GB recognized: D1/D2, B1/B2, F1/F2, H1,H2. For 64GB (4 sticks), using the 1 (orange) slots would do. However, this also does not make any difference. I currently don't have any 8GB registered sticks at hand for testing, but does fully populating the slots with 8GB (16 x 8GB = 128GB) work? If so, does brand (Samsung/Micron/Hynix) matter?
4. It seems at present, not everything works out-of-box, and I think the issue of "Not enough memory creating EHCI periodic frame list." might require some immediate attention (something like changing the stack and heap sizes, which might also affect other stuffs).
The system is currently at best usable for booting some popular floppy images (and discover some interesting use cases). I've tested some floppy images, like Menuet64, tatOS, Floppybird, and they are currently working without major issues. I still have a few more images included for testing, and I think I may consider booting something else to check whether the current memory configuration is really the root cause of some issues or not.