Hi Branden, On Sun, Nov 19, 2017 at 7:43 PM, Branden Waldner <scruff...@gmail.com> wrote: > Keith, I've attached the dmesg from running a build with the acpi > patch you had me listed as a reviewer on - > https://review.coreboot.org/#/c/22473/
> Also, I wouldn't really consider myself as qualified for reviewing > code, but I'll gladly test it. Thanks for your report. I used the "reviewer" mechanism as a way to let you know I have a patch up you'll want to test. > I guess that's it, I think I mentioned everything I was planning to. > I've got several things to look into and try to figure out. I also > have several other boards that have supported chipsets that might be > interesting to work on as well, but I should probably stick with this > one, for now, to try to get it sorted out better and to learn more > about about working with coreboot. BX is a good one to learn coreboot on, because it well predates ME or any of that crap. :) > It's still throwing acpi errors. Is having color codes in the log > okay? I can avoid them in the future if it's a bother. Your dmesg indicates the external ACPI nodes that this patch is supposed to remove remained in your copy. First try "make clean" and build again to make sure all the code that are to be patched are actually patched. Second, 22473 depends on 21671 which introduces the reworked PIIX4E ASL with the offending bits omitted, so make sure you have it applied to your build. 22473 itself then pulls ASL in 21671 and not the original, facilitating its removal. > > As for getting flashrom working, I didn't get anywhere. I tried > writing eash of the piix gpos high and low and that didn't help, > though I did end up killing the fan by setting gpo0 low. > > I actually flashed the asus p2b bios to it and the board booted and > ran fine. Flashrom still didn't work, but aflash still did. It doesn't > make sense, flashrom is supposed to work on the p2b and if there was > something needed for board enable on the p2-99 (and not p2b), then > aflash shouldn't work while running p2b bios. The boards look the same > though, the only differences I can find are the 440ZX northbridge, the > unpopulated third ram slot, and the lack of the hardware monitor chip > (fan and voltage). You have "-p internal" on the command line? > I'd like to try putting together a dual flash, but the wiki seems a > bit lacking in details. It sounds like the idea is to connect vcc to > the chip enable pin with a switch and pull up resister, but doesn't > actually specify much. Is leaving the chip enable on the other other > flash chip floating okay or should it really be connected to ground? > (With another resister?) Is there a simple and cheap hardware setup to > switch this electronically for automated testing /.recovery? I > shouldn't have a problem with the soldering, I'd just like to know a > bit more about it before trying it. I'd prefer not killing the board > by screwing it up ( or messing up a hot swap). Even without flashrom > support, this would allow me to keep the asus bios on one chip and > coreboot on the other and just having the asus bios on one chip for > booting just to switch back and flash the other chip. I've been hotswapping chips on my p2b-ls. I only lightly press my chip into the socket, just tight enough it won't pop out on its own, but loose enough I can lift it off by finger. > > Anyway, back to the actual system. There's is a couple of quirks / > issues I need to look into yet. > > When booting with only one ram stick, the keyboard doesn't work with > seabios and loading grub 2 from disk. This has happened otherwise > (with two ram sticks), but rarely. Even with the seabios keyboard > delay set really high (5000 milli seconds), it still doesn't work. > Linux has no problem once it's booted though. > > Now for the really stange part, that got me to try removing a ram > stick in the first place. When rebooting from a uclibc hardened gentoo > (kernel 4.12) system and running memtest86+, it throws errors in > test(s) 3/4. This only happens after rebooting from that setup - not > debian stretch with linux 4.9 or 4.12bpo - and not after another > reboot. This happens with the debian, gentoo uclibc hardened, or > coreboot versions of memtest86+. This doesn't happen with the factory > bios. I tested this numerous times to verify what was happening - > marking down each test I ran.. > > Coreboot seems to setup the ram differently then the factory bios. > Memtest86+ lists the ram speed as 217MB/s (coreboot) vs 258MB/s > (bios), but with much better sysbench memory results with coreboot - > with the gentoo uclibc hardened setup with a 10 second test it got > double the bios did and with debian and sysbench memory set to 1600MB > (what the coreboot / gentoo uclibc hardened setup got in 10 seconds) > the debian it performed around four times better with coreboot vs > bios. And this is with passing eight couninous passes of memtest86+ > when not running into the issue above. Is coreboot just using more > aggressive settings then the factory bios uses? I'm fine with coreboot > resulting in better performence then the factory bios! When you build again, enable: - Debugging/Verbose RAM init debug messages - Console/Send console output to a CBMEM buffer Then get us the console log via # cbmem -c You'll also need to do some BX configuration dumps with OEM and coreboot, so I can compare where the differences are. If possible I'd like to catch a dump with all memory combinations - 1, 2, 1+2. One set with coreboot and one set with OEM. The command to do this dump is: # lspci -s 0:0:0 -xxx I can disassemble my copy of P2B bios and see what it does. But do know that when I did the 440BX ram init code in 2010, I only did for boards with 4 slots, 3-slot boards were never really done because I don't have such a board. Plus, the logic is modeled after the ram init code in the oem boot block, with just enough init to get ram going for later stages and made no attempts to optimize for latency or speed. There probably is room for improvement. > Another note, several of the P2* board wiki pages list the L2 cache as > not working with coreboot. I ran into the L2 cache not working when I > originally tested this board with coreboot while running a pentium 2 > at 400MHz. It seems that this was an issue with pentium 2 L2 cache > enablement, should the wiki document this as an issue with pentium 2 > processsors? (specific versions?) The jumpers on the board were > actually set to 5.5 multiplier @ 100 MHz (like the current pentium iii > setup) and it didn't seem to have any affect - coreboot or bios. I > didn't do any benchmark tests though. I ported the Pentium II/III L2 cache init from coreboot v1 also around 2010 and L2 should work now. Wiki likely hasn't been updated in forever... If in doubt, the console output should tell if L2 cache works. The CPU of this era just don't look at the multiplier setting at all. To overclock we have to crank up the bus frequency. > I also ended up testing the system with a pair of floppy drives, since > it's marked as untested on the p2b wiki page. Both worked fine with > the bios, but they didn't show up with seabios or after booting linux. > I don't particularly care about floppy support though, unless I wanted > to run it diskless and didn't have enough room on the flash for a > proper ipxe setup. PS/2 mouse works fine though - it is also marked > untested. > Thanks for these reports. Double check the devicetree.cb. Does it have pnp device 3f0.0 "on"? This is the floppy. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
