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.
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
