[coreboot] Re: Could not find a bounce buffer... Payload not loaded. Intel 440BX/LX Board
Hi Christian, Both Keith Hei and I [Branden] have 440BX boards that still run up-to-date/recent coreboot (though they do need a bit of work). I also have an Intel 440LX board [Trigem Florida-TG (COGNAC)] that I was intending on trying to get coreboot to run on yet, but I wanted to get it reworked at the local maker/hackerspace to socket the flash chip which I haven't been able to get done. >From old messages on the mailing list, it looked like the 440BX code did run on the 440LX and I have had it run at 66MHz fsb speed on the 440BX. Though maybe the memory settings could be an issue if the ram is rated for faster than the [older] chipset can handle (I'm not sure about the details of it)? I probably can't help much though and Keith has been working on a Haswell board recently, so I'm not sure how much time he has had to work on the older boards. I just figured I make sure to mention it at least. Branden PS Necroware on Youtube / scorp on Vogons forum has the same board as you [in the video: Too nice to be true? Intel i440LX was upset about my plans] and has expressed interest in open source works, so maybe he might be interested as well? I haven't tried messaging him about it. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] 440BX meminit changes testing
Hi Keith So far I've only tested the complete patch train (73888) like previously mentioned and didn't have my serial console set up at the time. I dug out the cable from behind my desk and got it run to my work bench again, so that should help out. I'm assuming you would want logs with raminit debug enabled though and I didn't have that set last time. You had mentioned you wanted me to test 74036 specifically? I checked out the ram I was using with decode-dimms, but didn't check any other ram yet. It looks like they are both rated for CL3 @100mhz and the 133mhz stick seems to run at it's timings for 133 instead of 100? I'm running a 100mhz fsb coppermine cpu and the memory is supposed to run at the fsb speed right? It doesn't seem to use (or at least display it is using) the 100mhz timing on the oem bios either - though I haven't done enough testing to be confident of what's going on. I have some high density 256mb memory that runs at 128mb with this chipset, so I could check what the timings are on that yet. I really should have just tried to find a lot of 512mb high density to just fill out whatever sdram usage I could have. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Running coreboot on M1 Mac or Arm64 platforms
> Dear coreboot community, > I just started coreboot and getting the hang of it. I am considering getting > a M1 MacBook for my > development work. > May I will will coreboot work well on M1 MacBook? I am doing the coreboot > work for x86 > platforms. > I understand that coreboot is using i386 cross GC Compiler, does it works on > M1? There is > another option that I could run a Linux OS virtual box on M1 but it will > still run on arm64 arc. > Thanks for the help. > Best Regards, > Cory I've built crossgcc-i386 on armv6 (raspberry pi B) and it produced a working rom for my asus/p2b. I don't know about how well it would work with any other targets though. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] asus p2b logs - change: cpu/x86/lapic: Move LAPIC configuration to MP init
With https://review.coreboot.org/c/coreboot/+/58387 merged, my p2b board hangs at seabios. I've attached serial logs from a rom of this commit and the previous one. Branden coreboot-4.15-1377-g7261b5ade5 Sat Feb 5 07:56:48 UTC 2022 bootblock starting (log level: 7)... FMAP: Found "FLASH" version 1.1 at 0x0. FMAP: base = 0xfffc size = 0x4 #areas = 3 FMAP: area COREBOOT found @ 200 (261632 bytes) CBFS: Found 'fallback/romstage' @0x80 size 0x4480 BS: bootblock times (exec / console): total (unknown) / 27 ms PROG_RUN: Setting MTRR to cache XIP stage. base: 0xfffc, size: 0x8000 coreboot-4.15-1377-g7261b5ade5 Sat Feb 5 07:56:48 UTC 2022 romstage starting (log level: 7)... Romstage stack size limited to 0x1000! SMBus controller enabled CBMEM: IMD: root @ 0x17fff000 254 entries. IMD: root @ 0x17ffec00 62 entries. MTRR Range: Start=1780 End=1800 (Size 80) MTRR Range: Start=fffc End=0 (Size 4) FMAP: area COREBOOT found @ 200 (261632 bytes) CBFS: Found 'fallback/postcar' @0x1b5c0 size 0x420c Loading module at 0x17fd3000 with entry 0x17fd3031. filesize: 0x3f60 memsize: 0x8250 Processing 155 relocs. Offset value of 0x15fd3000 BS: romstage times (exec / console): total (unknown) / 53 ms coreboot-4.15-1377-g7261b5ade5 Sat Feb 5 07:56:48 UTC 2022 postcar starting (log level: 7)... FMAP: area COREBOOT found @ 200 (261632 bytes) CBFS: Found 'fallback/ramstage' @0xbdc0 size 0xd955 Loading module at 0x17faa000 with entry 0x17faa000. filesize: 0x1c2d8 memsize: 0x27b08 Processing 1890 relocs. Offset value of 0x171aa000 BS: postcar times (exec / console): total (unknown) / 30 ms coreboot-4.15-1377-g7261b5ade5 Sat Feb 5 07:56:48 UTC 2022 ramstage starting (log level: 7)... Enumerating buses... Root Device scanning... CPU_CLUSTER: 0 enabled DOMAIN: enabled DOMAIN: scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/7190] enabled PCI: 00:01.0 [8086/7191] enabled PCI: 00:04.0 [8086/7110] enabled PCI: 00:04.1 [8086/7111] enabled PCI: 00:04.2 [8086/7112] enabled PCI: 00:04.3 [8086/7113] enabled PCI: 00:0c.0 [1106/3106] enabled PCI: 00:01.0 scanning... PCI: pci_scan_bus for bus 01 PCI: 01:00.0 [1002/5960] enabled PCI: 01:00.1 [1002/5940] enabled scan_bus: bus PCI: 00:01.0 finished in 8 msecs PCI: 00:04.0 scanning... PNP: 03f0.0 enabled PNP: 03f0.1 enabled PNP: 03f0.2 enabled PNP: 03f0.3 enabled PNP: 03f0.5 enabled PNP: 03f0.7 enabled PNP: 03f0.8 enabled PNP: 03f0.9 enabled PNP: 03f0.a enabled scan_bus: bus PCI: 00:04.0 finished in 16 msecs PCI: 00:04.3 scanning... scan_bus: bus PCI: 00:04.3 finished in 0 msecs scan_bus: bus DOMAIN: finished in 67 msecs scan_bus: bus Root Device finished in 78 msecs done BS: BS_DEV_ENUMERATE run times (exec / console): 0 / 87 ms found VGA at PCI: 01:00.0 A bridge on the path doesn't support 16-bit VGA decoding!Setting up VGA for PCI: 01:00.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:01.0 Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Allocating resources... Reading resources... Setting RAM size to 384 MB PNP: 03f0.8 missing read_resources PNP: 03f0.9 missing read_resources Done reading resources. === Resource allocator: DOMAIN: - Pass 1 (gathering requirements) === PCI: 00:01.0 io: size: 0 align: 12 gran: 12 limit: PCI: 01:00.0 14 * [0x0 - 0xff] io PCI: 00:01.0 io: size: 1000 align: 12 gran: 12 limit: done PCI: 00:01.0 mem: size: 0 align: 20 gran: 20 limit: PCI: 01:00.0 30 * [0x0 - 0x1] mem PCI: 01:00.0 18 * [0x2 - 0x2] mem PCI: 01:00.1 14 * [0x3 - 0x3] mem PCI: 00:01.0 mem: size: 10 align: 20 gran: 20 limit: done PCI: 00:01.0 prefmem: size: 0 align: 20 gran: 20 limit: PCI: 01:00.0 10 * [0x0 - 0x7ff] prefmem PCI: 01:00.1 10 * [0x800 - 0xfff] prefmem PCI: 00:01.0 prefmem: size: 1000 align: 27 gran: 20 limit: done === Resource allocator: DOMAIN: - Pass 2 (allocating resources) === DOMAIN: io: base: 0 size: 0 align: 0 gran: 0 limit: update_constraints: PCI: 00:04.0 01 base limit 0fff io (fixed) update_constraints: PNP: 03f0.0 60 base 03f0 limit 03f7 io (fixed) update_constraints: PNP: 03f0.1 60 base 0378 limit 037f io (fixed) update_constraints: PNP: 03f0.2 60 base 03f8 limit 03ff io (fixed) update_constraints: PNP: 03f0.3 60 base 02f8 limit 02ff io (fixed) update_constraints: PNP: 03f0.5 60 base 0060 limit 0060 io (fixed) update_constraints: PNP: 03f0.5 62 base 0064 limit 0064 io (fixed) update_constraints: PNP: 03f0.7 60 base limit io (fixed) update_constraints: PNP: 03f0.7 62 base limit 0001 io (fixed) update_constraints: PCI: 00:04.3 01 base e400 limit e43f io (fixed) update_constraints: PCI: 00:04.3 02 base 0f00 limit 0f0f io (fixed) DOMAIN: : Resource ranges: * Base: 1000, Size: d400, Tag: 100 * Base: e440, Size: 1bc0, Ta
[coreboot] Re: My Asus P2B-LS is still having fun with coreboot/SeaBIOS/flashrom. Now I have questions.
Hi > I have to calmly tell it "laptop=this is not a laptop" and then it works as > usual. I don't remember > ever having to do this before. Why? If I have a clue I can code up and submit > a patch. If I recall correctly both my p2b and p2-99 boards do that while running vendor firmware, though I don't recall ever seeing it while running coreboot (which I just checked to verify it still doesn't show up). > Back to how it failed to boot in the first place. The hard disk booting > stalled after SeaBIOS. Took > me hours but eventually I found a line in my serial log that there has been a > DMA timeout. > Turning UDMA off in devicetree.cb and flash again made it boot again. So I > would have to revert > 576315e1 (aka CB:40961), but I'm hesitant because that seemed like the > reasonable thing to do > and it should have worked. So I'm also unsure why it didn't. I've had the occasional issue with my p2-99 in the past, but I've always got it booting again after reseating chips (flash/memory/cpu card). I guess I should be making sure to have the serial link set up more often, I normally only use it when I have a known bad version of coreboot flashed. I actually have the cable connected between the two boards right now, which seems to work decently for testing. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: i440bx PARALLEL_MP testing WAS: Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
I tested https://review.coreboot.org/c/coreboot/+/59693/ nb/intel/i440bx: Use PARALLEL_MP patchset 6 on my p2-99 and it appears to work properly. The work around of disabling including the config in the rom to free up space wasn't enough with this patchset though, so I just disabled including microcode updates for now. I'm hoping the LTO and romstage sources inside the bootblock will make in it yet, since they both saved s[pace. I only attached a specific portion of the log, since it got rather long with spew set. Branden Waldner Initializing devices... CPU_CLUSTER: 0 init CPU: . Setting up local APIC 0x0 Initializing CPU #0 CPU: vendor Intel device 681 CPU: family 06, model 08, stepping 01 MTRR: Physical address space: 0x - 0x000a size 0x000a type 6 0x000a - 0x000c size 0x0002 type 0 0x000c - 0x2000 size 0x1ff4 type 6 0x2000 - 0x4000 size 0x2000 type 1 0x4000 - 0x0001 size 0xc000 type 0 MTRR: Fixed MSR 0x250 0x0606060606060606 MTRR: Fixed MSR 0x258 0x0606060606060606 MTRR: Fixed MSR 0x259 0x MTRR: Fixed MSR 0x268 0x0606060606060606 MTRR: Fixed MSR 0x269 0x0606060606060606 MTRR: Fixed MSR 0x26a 0x0606060606060606 MTRR: Fixed MSR 0x26b 0x0606060606060606 MTRR: Fixed MSR 0x26c 0x0606060606060606 MTRR: Fixed MSR 0x26d 0x0606060606060606 MTRR: Fixed MSR 0x26e 0x0606060606060606 MTRR: Fixed MSR 0x26f 0x0606060606060606 call enable_fixed_mtrr() CPU physical address size: 36 bits MTRR: default type WB/UC MTRR counts: 3/2. MTRR: UC selected as default type. MTRR: 0 base 0x mask 0x000fe000 type 6 MTRR: 1 base 0x2000 mask 0x000fe000 type 1 MTRR check Fixed MTRRs : Enabled Variable MTRRs: Enabled FMAP: area COREBOOT found @ 200 (261632 bytes) CBFS: 'cpu_microcode_blob.bin' not found. CPU #0 initialized On 11/30/21, Keith Hui wrote: > Hi guys, > > Just a heads-up. Soon after I confirmed the issue with Arthur's > patches (and he told us of his fix), I ran into major stability issues > with all my boards to the point I couldn't reliably boot any of them. > Granted they were sitting naked between a desk lamp and the power > supply so EMI could be an issue. I don't know, and I probably won't > find out for sure until next week when I can house them properly. > > Branden, I'll appreciate if you can confirm whether Arthur's SSE2 > workaround fix the issue. > > Thanks > Keith > > On Tue, 30 Nov 2021 at 15:15, Branden Waldner wrote: >> >> On 11/30/21, Keith Hui wrote: >> > I suffered an unexpected exception after applying the patch train. >> > Serial log at the end of this email. I probably could leave out >> > bootblock/romstage/postcar, but it's here for completeness. Next: >> > bisect. >> >> I had a similar result testing on my P2B. I'm working on recovering it >> and I was planning on trying a build with log level spew on the P2-99 >> since it is easy for me to recover with the way I have it setup right >> now. >> >> Branden Waldner > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] i440bx PARALLEL_MP testing WAS: Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
On 11/30/21, Keith Hui wrote: > I suffered an unexpected exception after applying the patch train. > Serial log at the end of this email. I probably could leave out > bootblock/romstage/postcar, but it's here for completeness. Next: > bisect. I had a similar result testing on my P2B. I'm working on recovering it and I was planning on trying a build with log level spew on the P2-99 since it is easy for me to recover with the way I have it setup right now. Branden Waldner ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Suggestion for deprecation: LEGACY_SMP_INIT & RESOURCE_ALLOCATOR_V3
I wasn't really sure that I wanted to comment on this, but seeing as how I have some of the affected boards I guess I should. Angel Pons wrote: > Besides AMD AGESA boards, the other boards that need to be updated are AOpen > DXPL > Plus-U (a dual-socket server board that uses Netburst Xeons, no other board > in the tree uses > the same chipset code) and various Asus P2B boards (which support Pentium 2/3 > CPUs, these > boards are older than me). Even though I only know two people who still have > some of these > boards (and they don't have the same boards), they're still supported because > the code has > been maintained so far. I am one of the two with Asus P2B boards, with Keith Hui being the other. I've got a P2B and a P2-99 and I believe Keith Hui has a P2B-LS. So far there have not been very many changes and Keith Hui and others have worked on them, all I've done is test master and relevant patch sets every once in a while. I know I have not been uploading board_status results and I have not gotten around to fixing the variant set up for the P2-99 so I'm not uploading results that are uncertain about which board they are for. Not really relevant, but I think it is pretty neat to be running coreboot on boards older then some of the contributors. Mike Banon wrote: > I am often build-testing my boards (didn't notice a > https://review.coreboot.org/c/coreboot/+/59636 problem for a while, but only > because I've been > re-using the previously built toolchains to save time). Also, I am actively > tech-supporting all the > people who would like to build coreboot for AMD boards from this list, even > right now I am in an > active message exchange with >10 people who are switching to these boards to > run coreboot > on them - and any user may give back to the project one day. I actually have a few AMD boards and laptops that might be viable for porting to, but I've never looked in to it much because of the state support is in coreboot and the fact most of the hardware was actively being used. Arthur Heymans wrote: > The first one I'd like to deprecate is LEGACY_SMP_INIT. This also includes > the codepath for > SMM_ASEG. This code is used to start APs and do some feature programming on > each AP, but > also set up SMM. This has largely been superseded by PARALLEL_MP, which > should be able > to cover all use cases of LEGACY_SMP_INIT, with little code changes. The > reason for > deprecation is that having 2 codepaths to do the virtually the same increases > maintenance > burden on the community a lot, while also being rather confusing. > > A few things are lacking in PARALLEL_MP init: - Support for !CONFIG_SMP on > single core > systems. It's likely easy to extend PARALLEL_MP or write some code that just > does CPU > detection on the BSP CPU. - Support smm in the legacy ASEG (0xa - > 0xb) region. A > POC showed that it's not that hard to do with PARALLEL_MP > https://review.coreboot.org/c/coreboot/+/58700 I didn't even know that was a problem until now. I doubt there is much I can do about it myself at this point in time, though I can try to look through it I guess. Branden Waldner ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Installing coreboot with SeaBIOS
> /bin/sh: 1: python: not found > make[2]: *** [Makefile:168: out/romlayout16.lds] Error 127 I ran in to this error the other day in a clean build environment and was going to mention it in the thread about python in the build system, but Peter Surge already commented here on it. If you are on Ubuntu or Debian you likely need to install "python-is-python3", which symlinks python to python3, since Debian kept python as python2 and makes python3 programs require that they use run as python3 not just python. With the removal of python2, they remove the original python link that pointed to the python version. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Build error/warning on 32bit host?
A bit of a follow up, I verified it happens in a 32 bit (i686) Debian sid chroot and not in 32 bit Debian Bullseye (actual install on hardware). Should I be properly reporting this on the issue tracker? I don't have an account on the coreboot redmine tracker, though I probably should make one. I can't even find where the upstream vboot utils issue tracker is, unless it's just under the main chromium/chromiumos? I didn't post the end of the error message, but it's from building in vboot_lib. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Build error/warning on 32bit host?
I've been working on testing current coreboot on my asus/p2b and asus/p2-99 for the upcoming release, but ran in to problems trying to build it on my p2b with Gentoo with gcc 11.2.0. It (ironically) did build and work on the p2-99 with Debian Buster (oldstable) with gcc 8.3.0. It also built on my main system with Debian sid 64bit and gcc 11.2.0. CChost/lib/extract_vmlinuz.o In file included from /usr/include/string.h:519, from host/lib/extract_vmlinuz.c:9: In function 'memcpy', inlined from 'ExtractVmlinuz' at host/lib/extract_vmlinuz.c:67:2: /usr/include/bits/string_fortified.h:29:10: error: '__builtin_memcpy' specified bound between 2147483648 and 4294967295 exceeds maximum object size 2147483647 [-Werror=stringop-overflow=] 29 | return __builtin___memcpy_chk (__dest, __src, __len, | ^ 30 | __glibc_objsize0 (__dest)); | ~~ host/lib/extract_vmlinuz.c: At top level: cc1: note: unrecognized command-line option '-Wno-unknown-warning' may have been intended to silence earlier diagnostics cc1: all warnings being treated as errors It looks like I might have to do a better job of regular testing of self hosting the build on these old 32-bit systems. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Mailing list archive not updating
I was just checking the mailing list archive and noticed that it isn't showing any new messages since September 9. I wasn't able to determine if there was a mailing list admin address to send this to, so I hope just sending it to the list is okay. (I did see this "mail...@coreboot.org alias for mailman admins" while searching, but wasn't sure about it, since it doesn't actually show up on the available lists page.) ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: link time optimization testing
> Hi Branden, > >VultureProg was mentioned - even a DIY emulator would be fairly >straightforward; that's a nice microcontroller project. > > >That seems a bit overkill, but then again flash chips seem to be more >expensive then microcontrollers these days. I don't think I'm up to >working on something like that right now though. > > Not sure if that might be what you're looking for, but I have successfully > used a memSIM2 > emulator on a similarly old platform. It's basically an SRAM, some level > shifters and a > microcontroller to program the SRAM via USB. There's some open source > software that can > talk to the device; never tested the vendor software. Beware though that you > must make sure > that there are no +12V on the two pins that might be used for programming > voltage; if +12V is > present on the socket on the mainboard and you plug the emulator in there, > it'll fry the emulator. > I ended up plugging a socket with those two pins removed between the socket > on the mainboard > and the emulator. > > Regards, > Felix While it looks like one of those emulators is available for surprisingly cheap compared to most (parallel) flash emulators, it is still quite a bit to spend on an old system just for messing around. It seems kind of weird that it doesn't have proper isolation for the higher programming voltages commonly found on eeprom, though using a socket with those pins removed doesn't seem like too much work. > Peter Stuge wrote: > Hi Branden, > > > > > I haven't had much luck in finding options for recovery. Ideally I'd > > > > like something like the dual switched bios in the old wiki but > > > > toggle-able electronically ie. gpio pin from spare router w/ Openwrt. > > > > > > That's the product BIOS Savior RD1 from Taiwanese IOSS, switched by a > > > jumper which could be replaced by e.g. a 2N7000 FET driven by a GPIO. > > > > > > https://www.coreboot.org/Developer_Manual/Tools#BIOS_Savior > > > https://www.overclockers.com/bios-savior/ > > > > > > There were a few different versions, IIRC one being for parallel 5V. > > > > > > They seem no longer available, but you could add a watch on ebay or such. > > > > I was thinking specifically of the "dual flash 'pie'" on that page, > > Ah like this: > > https://www.coreboot.org/Developer_Manual/Tools/Dual_Flash > > Yes, that's a nice solution, if basic. > > > > though really anything would be nice, even just the dip32 risers would > > probably come in handy. > > A couple of "precision" style DIP32-sockets might do that job? > > https://www.digikey.ca/en/products/detail/mill-max-manufacturing-corp/110-44-632-41-001000 > /947066 I'm thinking that ordering some dip32 and dip32-to-plcc32 sockets might be most cost effective for now. I think I already have some plcc32 parallel chips and I can get order more if I need and they are a lot easier to remove and insert then dip32 chips. > > > VultureProg was mentioned - even a DIY emulator would be fairly > > > straightforward; that's a nice microcontroller project. > > > > That seems a bit overkill, but then again flash chips seem to be more > > expensive then microcontrollers these days. I don't think I'm up to > > working on something like that right now though. > > What capabilities do you have available? Any soldering equipment at all > or not under current circumstances (hackerspace mention)? I do have some basic soldering equipment and experience, but not a lot. I was hoping for some recommendations for more/better tools if I visited/joined the hackerspace. > > > Where are you located? > > > > I'm in southern Manitoba, Canada. > > Okay, so not Europe, but maybe I could send you something. I just have a hard time justifying spending money just messing around with old hardware. Even just finding the correct hardware you want/need can be tricky a lot of the time. I would really appreciate it if you think you have extra/spare hardware that I could use though. > > I had been interested in checking out the hackerspace (skullspace) in > > Winnipeg sometime and seeing if anybody could help me with out with > > anything but never got around to it. It isn't really local to me > > though (~2hr drive), and isn't really an option right now for obvious >> reasons. > > It's a great idea, I'm sure they would be able to help, but 2hr is > not so great and yeah not feasible at the moment anyway. I had still been considering messaging them, but I'm not sure that would help at this time. > > > > > > > That's great to hear. I hope you didn't need to build crossgcc-i386 on > > > > > the P2B, though! :P > > > > > > > > Well, it's got a gentoo install that has to build it's own updates, > > > > including the system compiler, as well as crossgcc-i386. > > > >.. > > > > It would probably be a lot faster if I could get a better cpu > > > > > > You can use Gentoo releng's catalyst tool to build an i686 stage4 on > > > any x86_64 build machine in half an hour or so, you'll just ne
[coreboot] Re: DiskonChip 2000 testing (& old coreboot_v1/linux_bios)
On 6/7/21, Rao G wrote: > Please look into this document too about Disk On Chip > https://www.coreboot.org/images/9/97/LinuxBIOS.pdf > I'll check it out yet. >> Branden wrote... >> >> In the first place, I think my assumption of it exposing a large rom >> was wrong, it looks like they only actually only expose a small amount >> as regular bios boot rom space. While that sounds annoying, it would >> probably still be workable though. >> >>… >> >>I'm hoping that somebody still remembers a bit about them and maybe >>knows something about how I can get the chip working, confirm that >>it's not working, or just tell me I'm doing it wrong. > > Andy wrote... > > It has been a long time since I have used one of these (and never with > coreboot) but from what I > remember the device needed something like 16KB in > the expansion ROM area (between 640KB > and 1MB). > > The DiskOnChip contained firmware that was executed as a BIOS extension / > option ROM. For > DOS based systems the firmware hooked onto int 13h (disk > services) so that it got allocated a > drive letter and also handled the the > flash paging / erasing / reading / writing. I used devices> with > capacities ranging from 2MB to 256MB and they all only needed the same amount > of space > in the ROM area. > My first question… what have you plugged the DiskOnChip into? Is it a > motherboard that was > designed to accept them or is it a plug in card with > a ROM socket on it? (M-Systems initial> evaluation board was an ISA > card). I tried it in both my p2b and a sis 630 board. I don't have an evaluation board and though I have some pci and isa cards with dip32 sockets, I'm not sure that they would load an option rom properly or even be (io) compatible. I don't even know if the option rom firmware would be on the chip, because it looks like it is programmable and it could have been wiped or had an incompatible version. Obviously the option rom is not going to be loaded/ do anything when hotswapping though. > Peter wrote: > On hardware level the device exposes only a window of its full capacity > at a time. The electrical interface which it plugs into only has a > limited address space. Software must have not only a driver for the > device which knows how to move the window around but also an > abstraction layer for memory access so that the driver can move the > window at the correct time. > > This is not in place for current coreboot boards. I figured it operated something like that, though I didn't really think of that before I got it. If it worked, had enough space in the boot block for a functioning rom/bios, and could load the option rom it in theory should still be usable in some form though. >> Going by the "HOWTO" documentation in the coreboot_v1 branch I figured >> I could just hotswap it and load the diskonchip kernel module, > > Good thinking, I believe this ought to work as long as the driver > supports your device. Well, I couldn't really find much information about if mainline linux _ever_ even properly supported the diskonchip 2000. Some of what I found referred to 2.4, which I'm definitely not messing with unless I absolutely have to. If I could find proper info on a 2.6 or later kernel supporting it natively it probably wouldn't be to hard to test, though I'd likely still need to use an old distro image. >> but I can't find any information about whether that actually supports >> the diskonchip 2000 or has been tested recently. > > Also good thinking - please be aware that DiskOnChip and DiskOnChip 2000 > are different products which are *not* compatible. Yeah, search engines don't seem to realize there is a difference either, which was pretty annoying. Well the DiskOnChip 2000 at least sort of makes sense (as a main firmware boot rom), none of the rest of their products seem to. Using an adapter card for "proprietary" nand storage doesn't make sense and branded cf cards don't really offer an advantage over any other cf card supplier - though it is possible they had better controllers, I have my doubts. Now a days, even though I've seen lots of recommendations for ide to cf adapter and cf card usage for retro computing, I found a pci to sata adapter to work fine and not have the issue of expensive cf cards with unknown controller quality. Obviously that wouldn't work for pre-pci systems, but I don't think any of those are supported by coreboot anyways :). >> I tried the dos utils on freedos as well and couldn't get them to >> detect it either. > > If that doesn't work, nothing else will. Well, that's what I was afraid of. I only managed to find working links for the dos utils (and much of the other software) from here: http://www.digital-circuitry.com/MyLAB_IC_PROG_DISKONCHIP.htm I tried V4.20 and V5.14 of the ms-dos software utilities, but couldn't detect it. The chip I have is branded "Ver. 5.1.2", but I'm not sure how much that matters. >> I'm hoping that somebody st
[coreboot] DiskonChip 2000 testing (& old coreboot_v1/linux_bios)
Well, I'm finally getting around to writing this, though I'm still not all that comfortable bringing it up. I purchased a diskonchip 2000 266mb a while ago just to mess around with. It took a long time in shipping though and then it took me a while to actually try to test it out. I had thought I could just use it as a large flash chip or maybe for trying to test the original linux_bios/coreboot_v1 on a motherboard I have with a supported chip set (specifically sis 630), but it hasn't worked out well for me. In the first place, I think my assumption of it exposing a large rom was wrong, it looks like they only actually only expose a small amount as regular bios boot rom space. While that sounds annoying, it would probably still be workable though. The real problem is that I can't seem to get it to work at all and I am not sure if what I am trying is supposed to work or if the chip is bad. The seller does/did specify a doa guarantee, but I'm not even sure if it is actually bad or if what I'm trying to do is unsupported. Going by the "HOWTO" documentation in the coreboot_v1 branch I figured I could just hotswap it and load the diskonchip kernel module, but I can't find any information about whether that actually supports the diskonchip 2000 or has been tested recently. It just returned unable to detect device (or something similiar). I tried the dos utils on freedos as well and couldn't get them to detect it either. It took a bit of effort just to find the dos utils, since the site I managed to find them on wasn't showing up on most of the searches I tried and there doesn't seem to be any other mirror of them. It would have been nice if they were properly on the internet archive, but there is just documentation on there. I'm hoping that somebody still remembers a bit about them and maybe knows something about how I can get the chip working, confirm that it's not working, or just tell me I'm doing it wrong. I'm also hoping that it's not too off topic. I know the old wiki did mention sending a message to the mailing list about working on forward porting old supported chips, but I never felt comfortable about it. I've actually never managed to get very far with programming in general, never mind what is needed for low level bootstrapping. Though I have long since figured out what it was I having problems with in the past and how to fix them, I've had too much other stuff going on to get in to it again. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: link time optimization testing
>> I haven't had much luck in finding options for recovery. Ideally I'd >> like something like the dual switched bios in the old wiki but >> toggle-able electronically ie. gpio pin from spare router w/ Openwrt. > >That's the product BIOS Savior RD1 from Taiwanese IOSS, switched by a >jumper which could be replaced by e.g. a 2N7000 FET driven by a GPIO. > >https://www.coreboot.org/Developer_Manual/Tools#BIOS_Savior >https://www.overclockers.com/bios-savior/ > >There were a few different versions, IIRC one being for parallel 5V. > >They seem no longer available, but you could add a watch on ebay or such. I was thinking specifically of the "dual flash 'pie'" on that page, though really anything would be nice, even just the dip32 risers would probably come in handy. >VultureProg was mentioned - even a DIY emulator would be fairly >straightforward; that's a nice microcontroller project. That seems a bit overkill, but then again flash chips seem to be more expensive then microcontrollers these days. I don't think I'm up to working on something like that right now though. >Where are you located? I'm in southern Manitoba, Canada. I had been interested in checking out the hackerspace (skullspace) in Winnipeg sometime and seeing if anybody could help me with out with anything but never got around to it. It isn't really local to me though (~2hr drive), and isn't really an option right now for obvious reasons. >>> That's great to hear. I hope you didn't need to build crossgcc-i386 on >>> the P2B, though! :P >> >> Well, it's got a gentoo install that has to build it's own updates, >> including the system compiler, as well as crossgcc-i386. >.. >> It would probably be a lot faster if I could get a better cpu > >You can use Gentoo releng's catalyst tool to build an i686 stage4 on >any x86_64 build machine in half an hour or so, you'll just need to use >a profile with i686 (17.0 should work) and possibly an older snapshot. > >If you're interested in trying that I could help with a spec file, >catalyst isn't very well documented. I'm not sure that catalyst is really what I want, though it did occur to me now that you mentioned that I could probably use it for a different project. It would be nice if you could just have portage/emerge on the client system request the build server to just make and send binary packages it wants to update - either everything or just whatever has a history of taking more then a certain amount of time on the client - even if it needed to cross compile and/or use qemu. I've seen at least one project that attempted this, but it was abandoned. Even on binary distros it's not that clear how autobuilding/crossbuilding can be done locally with minimal effort. So far I've gotten by just by leaving it running to finish whatever it is working on,. >//Peter Hopefully that didn't end up getting too off topic. PS. I hope the quoting turns out alright, I really need to get a proper email client setup yet. I had to do it all manually, since it wouldn't pull from the digest properly for some reason. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: link time optimization testing
On 6/1/21, Angel Pons wrote: > Hi Branden, list, > > On Tue, Jun 1, 2021 at 2:10 AM Branden Waldner wrote: >> >> The LTO patches seem to both compile and work/boot for me on the p2b. >> >> I built it both on a debian sid x86_64 system and on the gentoo i686 >> setup I currently have for the p2b, both with the coreboot >> crossgcc-i386 toolchain. > > That's great to hear. I hope you didn't need to build crossgcc-i386 on > the P2B, though! :P Well, it's got a gentoo install that has to build it's own updates, including the system compiler, as well as crossgcc-i386. I have to leave it to run for quite a while to do updates or build a new first of crossgcc-i386 on it. It's some pretty tough hardware though, it manages to handle it just fine, even though it is _really_ old for computer hardware at this point. It would probably be a lot faster if I could get a better cpu (w/ proper voltage handling) and the proper ram for it. I do have an ssd attached via a pci sata adapter (which is a bottleneck), but didn't really notice much of an improvement. I guess some people would use (like?) a system like it for retro gaming/computing, but I've never really found a use for it besides testing coreboot on it. >> It looks like it uses the system linker though (or something similiar, >> I don't remember exactly), at least according to the executable path >> it shows in the build log. I'm not sure if that's actually what's >> desired or if I'm just misinterpreting something. > > It might be intentional, but it's not desired: using the system > toolchain to build coreboot will wreak havoc when cross-compiling. Thankfully, I misunderstood what I was seeing in the logs, it was just while it was building tools that it was using the system toolchain. But, it was using LTO settings for them, which I wasn't expecting. I was assuming it would only use them for actually building the rom, not the utils, but I guess I don't see why not. >> It still looks like it needs more test reports yet, though I guess I'm >> not helping either by not commenting on gerrit. > > Yes, it needs more test reports. It would be great if you could > comment on the Gerrit change, so as to keep all test reports in one > place. I'll try to get around to commenting on the Gerrit change set yet. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: link time optimization testing
The LTO patches seem to both compile and work/boot for me on the p2b. I built it both on a debian sid x86_64 system and on the gentoo i686 setup I currently have for the p2b, both with the coreboot crossgcc-i386 toolchain. It looks like it uses the system linker though (or something similiar, I don't remember exactly), at least according to the executable path it shows in the build log. I'm not sure if that's actually what's desired or if I'm just misinterpreting something. It still looks like it needs more test reports yet, though I guess I'm not helping either by not commenting on gerrit. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: link time optimization testing - Was: Re: asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
On 5/25/21, Paul Menzel wrote: > Dear Branden, > > > Am 22.05.21 um 20:03 schrieb Branden Waldner: >> On 5/21/21, Arthur Heymans wrote: > >>> Thanks for sharing your findings. The flash is 256K big, which is quite >>> small these days. >>> When building coreboot with default settings but without a payload I >>> find >>> that there is 69K empty space left for payloads. >>> >>> Some future developments I have been working on might give a bit more >>> breathing space. >>> - I want to make romstage optional and include the sources in the >>> bootblock: That should shave off roughly 10K of romstage. >>> - I have compressing postcar working (maybe you can also disable the >>> postcar console to reduce size). That's also 2-3k size gains >>> at likely the const of a tiny bit of boot performance on this platform. >>> - I also have some WIP code to merge postcar into ramstage which would >>> save >>> 15k. >>> >>> Maybe on coreboot release 4.15 you will have a better time building a >>> fully >>> working image with the default configuration. > >> I didn't realize there was development going on to save rom space, >> that's good to know. > > I just built the asus/p2b from commit d981c490 (mb/google/mancomb: > Enable some PCIe power saving features) with the Debian sid/unstable > toolchain (gcc (Debian 10.2.1-6) 10.2.1 20210110). > > There, wasn’t enough space to add SeaBIOS’ configuration file to CBFS. > Not setting `INCLUDE_CONFIG_FILE`, there wasn’t any error, the coreboot > image built fine. > > ``` > FMAP REGION: COREBOOT > Name Offset Type Size Comp > cbfs master header 0x0cbfs header32 none > fallback/romstage 0x80 stage 17336 none > cpu_microcode_blob.bin 0x44c0 microcode 83968 none > fallback/ramstage 0x18d00stage 53376 LZMA > (112168 decompressed) > build_info 0x25e00raw89 none > fallback/dsdt.aml 0x25e80raw 5514 none > cmos_layout.bin0x27440cmos_layout 704 none > fallback/postcar 0x27740stage 16888 none > fallback/payload 0x2b980simple elf 69886 none > (empty)0x3cac0null 1956 none > bootblock 0x3d280bootblock 11088 none > ``` > > Building with Jacob’s link time optimization changes [1], which he > thankfully rebased, saved 13 kB, so the configuration file would fit in > too. > > ``` > FMAP REGION: COREBOOT > Name Offset Type Size Comp > cbfs master header 0x0cbfs header32 none > fallback/romstage 0x80 stage 14752 none > cpu_microcode_blob.bin 0x3ac0 microcode 83968 none > fallback/ramstage 0x18300stage 46277 LZMA > (95496 decompressed) > build_info 0x23840raw89 none > fallback/dsdt.aml 0x238c0raw 5514 none > cmos_layout.bin0x24e80cmos_layout 704 none > fallback/postcar 0x25180stage 14872 none > fallback/payload 0x28c00simple elf 69886 none > (empty)0x39d40null15012 none > bootblock 0x3d800bootblock9664 none > ``` > > (If you have a recovery option and some spare time, it’d be great if you > tested the LTO patches.) I could probably test them out, though I'm not sure I'll get around to it right away. Does the patch set require anything special? It looks like it just uses a Kconfig to add the choice to use the LTO compiler options. Does it work with the coreboot crossgcc or should I try using the system compiler on the build machine like you did (Debian sid x86_64), or maybe it would be best to try both? My recovery method isn't very good right now though. If I've got a boot failure I change the rom to a known good one and hot swap back to the chip with the bad rom to reflash it. It's pretty annoying, but I haven't messed up yet. I did try to get some (cheap) zif adapter sockets, but they didn't work out for me - not enough space and they don't seat in a socket, they seem to be meant to be soldered to a board, not used in a socket. I haven't had much luck in finding options for recovery. Ideally I'd like something like the dual switched bios in the old wiki but toggle-able electronically ie. gpio pin from spare router w/ Openwrt. That sounds like a lot of work though and I never managed to find much online as examples. > > Kind regards, > > Paul > > > [1]: https://review.coreboot.org/c/coreboot/+/40815/ > (whole series) > Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
On 5/21/21, Arthur Heymans wrote: > Hi > > Thanks for sharing your findings. THe flash is 256K big, which is quite > small these days. > When building coreboot with default settings but without a payload I find > that there is 69K empty space left for payloads. > > Some future developments I have been working on might give a bit more > breathing space. > - I want to make romstage optional and include the sources in the > bootblock: That should shave off roughly 10K of romstage. > - I have compressing postcar working (maybe you can also disable the > postcar console to reduce size). That's also 2-3k size gains > at likely the const of a tiny bit of boot performance on this platform. > - I also have some WIP code to merge postcar into ramstage which would save > 15k. > > Maybe on coreboot release 4.15 you will have a better time building a fully > working image with the default configuration. > > Kind regards > > Arthur Heymans > I didn't realize there was development going on to save rom space, that's good to know. I should really be looking at more of the changes going on. > On Fri, May 21, 2021 at 7:08 AM Paul Menzel wrote: > >> Dear Branden, >> >> >> Am 21.05.21 um 05:36 schrieb Branden Waldner: >> > When testing the latest coreboot code before the 4.14 release, I found >> > I couldn't build a working image with the default (or what I usually >> > use) config for the asus/p2b. I figured out that it failed to build >> > with an error of not enough space in cbfs after the merge to enable >> > bootblock console for intel 440bx. >> > Following this, I just disabled microcode firmware to free up space >> > and it worked fine, even without the microcode update. Specifically >> > selecting the microcode for the cpu I'm using would probably be better >> > though. >> > I'm just commenting on my findings, not really expecting anything. I >> > had intended on trying to obtain some larger flash chips yet, though I >> > never got around to it. It would still leave a broken default build >> > config though with the standard rom size. >> >> Thank you for sharing your findings. All default configurations are >> tested – without a payload though I believe –, so please attach your >> configuration, `defconfig` created by `make savedefconfig`, and your >> payload and size. >> >> >> Kind regards, >> >> Paul I just did a make distclean and selected vendor asus and board p2b, which doesn't make for much of a defconfig to show. I've just been using seabios as the default/only payload, partly because that's all it needs to work and partly because there was no space for anything else before anyways. Thanks for the replies, Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] asus/p2b - not enough space in cbfs for default build since i440bx bootblock console enable
When testing the latest coreboot code before the 4.14 release, I found I couldn't build a working image with the default (or what I usually use) config for the asus/p2b. I figured out that it failed to build with an error of not enough space in cbfs after the merge to enable bootblock console for intel 440bx. Following this, I just disabled microcode firmware to free up space and it worked fine, even without the microcode update. Specifically selecting the microcode for the cpu I'm using would probably be better though. I'm just commenting on my findings, not really expecting anything. I had intended on trying to obtain some larger flash chips yet, though I never got around to it. It would still leave a broken default build config though with the standard rom size. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: System gcc requirements
Well, this seems to be really going off topic. My only intention was to ask what the required/recommended host(system) compiler was and what documentation there was for that. Branden Waldner wrote: > Is there an expected minimal system gcc version and if so, is it > documented? I couldn't find it noted anywhere. Nico Huber Wrote: > I don't think it's documented. As you already noticed, we depend on a > 3rdparty library (vboot), > so we actually don't know the minimum. I think it would be nice to document the expected compatible version(s), especially if it can done in a version/release relevant way. Trying to build "old" projects without any build system documentation can get pretty frustrating for example. Julius Werner wrote: > So I think the "official" rule is basically that the minimum requirement for > host utilities is the > same compiler and version that crossgcc uses, which I think makes some amount > of sense > (otherwise we'll just have to keep tracking and deploying two separate > versions). It's kind of hard to say it's a rule when it's not written anywhere. Also, while it sounds okay in theory to _require_ and test against a specific version of gcc, that ends up leading to some practicality issues in potentially needing to build a specific version of gcc on the host if it's not packaged, followed by the usual crossgcc build. Though in my situation, updating from Debian Stretch to Buster would likely fix the problem for now (and be significantly faster then compiling gcc as well (I would also likely already have most of the packages cached locally)). Following up on that, if Jenkins only tests using the same version of gcc as the current coreboot crossgcc, doesn't that leave out testing potential compatibility problems with newer (or older) versions of gcc (or clang?) that could be automatically tested for and identified as early as possible? Of course, that could end up with orders of magnitude more work for the build bot to do, which could end up being impractical. Julius Werner wrote: > FWIW I do seem to recall that this already came up back when > __attribute__((fallthrough)) was > added to vboot, and back then everyone seemed to agree that it was reasonable > to assume the > same version for the host compiler that we use in crossgcc. I would consider "assuming" the same host compiler as crossgcc to be a bug, since a coded check can do a lot better then that, with the the required maintenance of only being changed (automatically?) when crossgcc is updated. I don't recall when I first noticed the problem, but I "assumed" it was a regression that would be fixed, not that my system no longer had a new enough version of gcc. It was also confusing why vboot was being pulled in even though I didn't have it selected. While it sounds simple enough that cbfstool builds in crypto/hash support from vboot, it also doesn't really seem that big a deal to expect it to be able to option it out either. Of course there is some extra maintenance involved in that, but with cbfs being a stable for quite a while (according to recent posts at least), there shouldn't be too many changes? That is not necessarily tied in to the host gcc problem though - I realize that I need a newer version and didn't specifically complain about it, other then it being for rather trivial reasons. Also, an interesting reference for the required build environment is the linux kernel of course: https://www.kernel.org/doc/html/latest/process/changes.html (that url seems weird, but the page title is "Minimal requirements to compile the Kernel"). That likely requires some automated testing to verify and also probably ends up with a lot of work to maintain, but at least it's there. I hope I at least managed to add something of value to the conversation, though some of it just seems like me complaining... Branden Walder ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] System gcc requirements
I recently looked in to why I couldn't build coreboot on one of my systems any longer and I think I found the cause. It looks like vboot uses features not available in gcc 6 on Debian Stretch. I actually did manage to get it to build and work by commenting out the offending gcc warning flags and a fallthrough switch attribute, but that's kind of pointless. Is there an expected minimal system gcc version and if so, is it documented? I couldn't find it noted anywhere. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Any live usb for recovery flash coreboot?
I tested Nico's method for you with a Debian bios install, but it might be different for the Manjaro live usb. To stall grub from booting, you can press the left arrow key repeatedly, assuming that doesn't mess with tianocore loading first. Then you press e to edit the boot parameters. For my debian/grub2 install the kernel line was 14 lines down, so you just press the down 14 times. Then press end to go to the end of the line and add a space and iomem=relaxed and press ctrl+x or F10 to boot. As for rescue systems with flashrom neither grml (debian based rescue usb) or the old gentoo based systemrescuecd worked for me without adding iomem=relaxed. Most live systems seem to use a udf/iso setup making it hard to just edit the kernel command line directly. The old systemrescuecd actually uses a fat formatted partition and would let you edit it, but it is more complicated to set up then the usual livecds. You could also probably just chroot into your primary manjaro install from your live usb and then install the efi version of grub2 and use your extra usb as the boot drive, possibly copying over your /boot directory as well. Of course, just installing a full system to the extra usb with a ufi bootloader like you said you already did should have worked as well. Does tianocore use/respect using boot/bootx64.efi? If so, you could copy grubx64.efi which should be on your efi partition, probably in a directory called manjaro, into a new directory called boot and rename it to bootx64.efi. See https://wiki.gentoo.org/wiki/GRUB2#Alternative:_using_the_default_UEFI_firmware_location or https://wiki.archlinux.org/index.php/GRUB#Default/fallback_boot_path for more information on that. That seems like a lot of rambling. Hopefully some of it helps you though. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Abandoned add asus p2-99 board patches
On 9/21/19, Nico Huber wrote: > > If nobody resurrects these changes, can you please squash the > commits? If you remove the Change-Id from the commit message, > a new should be generated and you could push it to Gerrit as > a new change. > I managed to squash the commits and resubmit the change, but it needs review(ers) again and I'm not sure if it's okay to just re-add the same people as the previous commits. I also didn't end up submitting it with a proper sign-off, so that needs to be fixed yet as well. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Abandoned add asus p2-99 board patches
I have tested coreboot on both the asus/p2b and asus/p2-99 and it seems to work fine. I had previously commented on the mailing list instead of these patches and then never really followed up on it. I meant to retest and comment on the change sets on gerrit (22977 and 22965) before they got abandoned, but got around to it too late. I wasn't sure what to do about it now, I commented on one of the patches, but it doesn't seem to send out emails with an abandoned status. I should have received a copy if it did, right? I originally only brought up that it worked since Keith Hui was working on updating Intel 440BX support. I haven't actually done anything to help with supporting coreboot though. Branden ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Coreboot support for Gigabyte GA-78LMT-USB3 (rev. 5.0)
I believe the recommendation is to start with one of the boards closest to what you have (ie. one of the boards with the same northbridge, southbridge, and superio), try to figure out any adjustments you can tell it needs and test and debug. The northbridge is part of the cpu and depends on which cpu you install. For the fx series it would be agesa family 15tn. I'm not sure how the cpu support works, depending on your build, you may only get support for certain processor families? I don't think the agesa code is very well supported. You posted your flashrom log in place of your superiotool log, but the manual says it has an ITE superio. There are amd sb700 boards on boardstatus with either the ITE IT8712F or ITE IT8718F. For flashing you would need a testclip and something to drive it. The dual bios feature won't help with coreboot, since it isn't jumper/ hardware switched based that I can tell. I was going to mention needing to figure out the option rom or graphics init for the onboard graphics, but it looks like your using a separate video card, so it can probably be ignored. Hopefully this helps you and I didn't get too much of it wrong. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] asus p2b and p2-99
I got an actual p2b motherboard a few months ago so that I could actually test it properly and not just claim the p2b build works on the p2-99. It seems to work fine and flashrom works on the p2b (but not the p2-99). I believe there was some discussion and a patch to setup the p2-99 as a variant of the p2b and if the patch is still around, it would probably be best to try to figure out if that is what we should do. I'd like to get around to doing some more work with coreboot yet, but I'll probably be too busy for a while and really haven't gotten around to it up until now either. Sorry for just making more work out of an old motherboard. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
Re: [coreboot] proposal: coreboot docs in separate repo
>> git bundles available over resumable http(s) can help a lot with that, >> but they are almost never provided. >I think this is a fair enough request, and maybe quite straightforward >to arrange. Do you already have some scripts to create a bundle every >now and then, that you could contribute? Sorry, I don't have any scripts to contribute. It seems like it doable with just a cron job running a git bundle create command and having it put it on a file server. I'm sure there would be more involved then that though. >> Board status was particularly bad, over 200 MB to clone, >Was that with git clone --depth=1 or did you clone complete history? The board_status.sh script does a full clone and I didn't want to mess with it and have it end up trying to upload an invalid commit. Maybe it would have worked with an empty initilized local repo? There is actually a fixme note in board_status.sh about it (line 419): # FIXME: the board-status directory might get big over time. # Is there a way we can push the results without fetching the # whole repo? >//Peter //Branden -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] proposal: coreboot docs in separate repo
Not everyone has access to decent reliable internet and git is pretty much useless if it gets interrupted. I would prefer to be able to clone the source code[1] without the documentation without having to resort to some weird git commands to get it done. Of course, having git bundles available over resumable http(s) can help a lot with that, but they are almost never provided. Just about any use case is going to pull other repos for payloads, etc. anyway, so I don't see why having the documentation seperate would be a problem. [1] I already have the coreboot and board status repos cloned, but that doesn't change the fact that I had issues getting it done at first. Board status was particularly bad, over 200 MB to clone, over a gig as uncompressed text. all just for the script to upload a new commit - it shouldn't need all that to do it's job. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] Coreboot with an UEFI payload to boot (Clover) an Thinkpad X230 Hackintosh
Hello, If I'm understanding this correctly, you are unable to get Coreboot/TianoCore to correctly load/boot efi grub2 (on disk). If this isn't working your not even able to get to chainloading Clover. (Unless grub2 is working, but booting Ubuntu isn't?). You could either try to get your Coreboot/TianoCore working, or, as you mentioned you could try using Coreboot/SeaBIOS/Duet(Tianocore). Doesn't Clover already include using Duet as an option (to boot from mbr/non-uefi)? If you can get the original bios to boot only in legacy you could see if you can get a working Duet or mbr boot Clover setup working and then try to boot it with Coreboot/SeaBIOS. Some uefi bios's won't boot into legacy mode if they see a gpt disk or a ESP partition though. You should even be able to install a mbr boot block for grub2 from Ubuntu while otherwise keeping the efi grub installed (I think the full auto-install grub2 packages conflict though). Branden -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Asus P2-99: PS2 keyboard, time stamps, double logs
Hi Paul, My intention in uploading again to the board status repository was to do to it with the patches Keith made merged. It's failed though as make clean and make distclean didn't seem to clean up the old (external?) acpi code like when I first tested the patch for Keith (The kernel log shows acpi errors on lines 120 - 123). I might have ended up just removing everything and running git reset --hard or something last time to get it to work properly. I don't know how it ended up not being marked as dirty then, but I figured to was still okay to upload. I wasn't sure yet what to do about the board mismatch. I think Keith had recommended that I originally upload the board status as P2B to insure that it was marked as being worked on so as not to be removed by the upcoming coreboot release and clean up (that still hasn't happened). Although it looks like the P2B and P2-99 use the same PCB layout and my P2-99 having no problem with the P2B bios, without an actual P2B to test with it might be best to treat them seperately. That would basically mean that it would just be a straight copy of the P2B to P2--99 for now and that the P2B would end up being removed as not being tested recently. Does anyone want to make a call on that to clean up the situation? Of course, these boards are old and probably considered obsolete by alot of people, so I don't know who would be interested in it. As for the PS2 keyboard initialization, I had that set intending to see if the I could avoid SeaBIOS failing to init the keyboard occasionally. SeaBIOS throws "WARNING - Timeout at ps2_recvbyte:182!" and then I can't use the keyboard with grub2 (on disk/ not coreboot payload). I had tried setting a time-out with SeaBIOS before and it seemed to have just ignored it. It seems to be more of a problem when only having one ram stick, but all I have to do is hit the reset switch and it usually works after rebooting. I guess I shouldn't have had that set when uploading to board status, but alot of other entries are marked dirty even, so I figured a weird set of options was fine. I also wasn't really expecting a reply. The time stamp collection not getting any output is because 'cbmem -t' errors out with 'Could not open /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory'. I recall reading about other people having problems with it and noted in one of my mails to Keith when testing the acpi patch that I was having this issue, but don't know what to do about it. Does cbmem actually need this, or why does it fail on it? It doesn't really sound like something critical to it working. Is it part of the acpi that didn't end up getting setup properly on this build? As for the double boot log, yes, I did reboot before hand. I'd forgotten about cbmem/board_status saving multiple boot logs then. Thanks for the reply, Branden -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS P2-99 with P2B config
While testing the 22687 change set, I ended up having the board fail to boot after rebooting. After getting the logs organized I figured I check it out with a clean rom and sure enough, after rebooting from the grub prompt six times with ctl+alt+del, it ended up failing to boot. It looks to always be failing around the same point very early on. Just in case, I tried again with the bios chip fully inserted and it ended up failing on the first reboot. p2-99_change_22687_logs.tar.gz Description: GNU Zip compressed data p2-99_trunk_logging.cap.gz Description: GNU Zip compressed data -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS P2-99 with P2B config
Alright, I've finally got a follow up with the raminit logs and bx configuration dumps. Hopefully you'll find something interesting or useful in there. As expected, I had to use serial capture for the raminit logs, since the default cbmem size isn't large enough. I didn't get any logs from it completely failing though, kept forgetting to have the serial capture running when rebooting from memtest with the ram unstable. Sometimes it reboots from memtest fine (by pressing escape), but others it hangs or boots with the ram even more unstable then the first time. This unstablility is still only initially triggered after rebooting from the gentoo uclibc hardened install. As for the pentium ii, it seems that coreboot does fail to init the L2 cache. I hadn't even looked at the cbmem previously to see what was going on. It's a 400MHz Deschutes SL3D5. I have no idea what was all involved in figuring out the values for the latency table (intel documented or not?) - assuming that's what the problem is. It's not likely I'm going to actually use this processor normally anyway. For the multiplier jumpers, I had thought that the processors where multiplier locked/auto, but didn't understand why the board had jumpers for it then. Figured it was either for early pii's or special unlocked processors. They don't do anything, I must have just been having issues with the processor, ram, agp/pci cards, or bios chip not being seated right. I've had it fail to do anything a few times after messing with stuff. As for the bus frequency, I did end up playing around for a bit with that a bit. For being a lower end nb, the 440zx didn't seem to have any problems. I ran a piii 866MHz no problem, ram was stable even with 140 bus speed. Neither of the pair of agp video cards liked the agp bus being overclocked though. Probably not a good idea to be overclocking an almost 20 year old system, especially with it being the only p2b/p2-99 still being tested with coreboot and being the only board with coreboot running on it that I have. As for the floppy and devicetree.cb, it seems to be enabled. I'll have to try it again and see if anything shows up in the cbmem or for seabios. Maybe check the bios vs coreboot /proc/ioports a bit closer yet too. The seabios ps/2 keyboard init still seems to fail sometimes as well. It usually works fine after a reset though. I think when I tried to set a ps/2 init timeout for seabios I was using the master version and it didn't seem to do anything. I'll have to try it again with the serial console output and possibly some level of debug output from seabios, maybe even just use coreboot's ps/2 keyboard init. Thanks for the work you've done with these older systems, without support for them, I probably wouldn't have been willing to try coreboot. Most of the newer systems I have it wouldn't be practical to have them sitting on the workbench trying get coreboot to work on them, they're already in use. p2-99_logs.tar.gz Description: GNU Zip compressed data -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS P2-99 with P2B config
I tried the acpi patches again, and this time it worked properly. I don't know if I had just missed running make clean, ended up flashing the wrong rom with aflash, or messed something else up. As for flashrom, I'd posted logs from my attempts at running it on its mailing list [32m[0.00] [0mLinux version 4.12.0-0.bpo.2-686-pae (debian-ker...@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #1 SMP Debian 4.12.13-1~bpo9+1 (2017-09-28) [32m[0.00] [0m[33mx86/fpu[0m: x87 FPU will use FXSAVE [32m[0.00] [0m[33me820[0m: BIOS-provided physical RAM map: [32m[0.00] [0m[33mBIOS-e820[0m: [mem 0x-0x0009fbff] usable [32m[0.00] [0m[33mBIOS-e820[0m: [mem 0x0009fc00-0x0009] reserved [32m[0.00] [0m[33mBIOS-e820[0m: [mem 0x000f-0x000f] reserved [32m[0.00] [0m[33mBIOS-e820[0m: [mem 0x0010-0x1ff9efff] usable [32m[0.00] [0m[33mBIOS-e820[0m: [mem 0x1ff9f000-0x1fff] reserved [32m[0.00] [0m[33mBIOS-e820[0m: [mem 0xff80-0x] reserved [32m[0.00] [0m[33mNotice[0m: NX (Execute Disable) protection missing in CPU! [32m[0.00] [0mSMBIOS 2.7 present. [32m[0.00] [0m[33mDMI[0m: ASUS P2-99/P2-99, BIOS 4.6-2173-g6fd5a79d47 11/23/2017 [32m[0.00] [0m[33mtsc[0m: Fast TSC calibration using PIT [32m[0.00] [0m[33me820[0m: update [mem 0x-0x0fff] usable ==> reserved [32m[0.00] [0m[33me820[0m: remove [mem 0x000a-0x000f] usable [32m[0.00] [0m[33me820[0m: last_pfn = 0x1ff9f max_arch_pfn = 0x100 [32m[0.00] [0m[33mMTRR default type[0m: uncachable [32m[0.00] [0mMTRR fixed ranges enabled: [32m[0.00] [0m 0-9 write-back [32m[0.00] [0m A-B uncachable [32m[0.00] [0m C-F write-back [32m[0.00] [0mMTRR variable ranges enabled: [32m[0.00] [0m 0 base 0 mask FE000 write-back [32m[0.00] [0m 1 base 0C000 mask FE000 write-combining [32m[0.00] [0m 2 disabled [32m[0.00] [0m 3 disabled [32m[0.00] [0m 4 disabled [32m[0.00] [0m 5 disabled [32m[0.00] [0m 6 disabled [32m[0.00] [0m 7 disabled [32m[0.00] [0m[33mx86/PAT[0m: PAT not supported by CPU. [32m[0.00] [0m[33mx86/PAT[0m: Configuration [0-7]: WB WT UC- UC WB WT UC- UC [32m[0.00] [0m[33minitial memory mapped[0m: [mem 0x-0x1ddf] [32m[0.00] [0mBase memory trampoline at [c009b000] 9b000 size 16384 [32m[0.00] [0mBRK [0x1da5a000, 0x1da5afff] PGTABLE [32m[0.00] [0mBRK [0x1da5b000, 0x1da5cfff] PGTABLE [32m[0.00] [0mBRK [0x1da5d000, 0x1da5dfff] PGTABLE [32m[0.00] [0mBRK [0x1da5e000, 0x1da5efff] PGTABLE [32m[0.00] [0m[33mRAMDISK[0m: [mem 0x1e0f-0x1f240fff] [32m[0.00] [0m[33mACPI[0m: Early table checksum verification disabled [32m[0.00] [0m[33mACPI[0m: RSDP 0x000F70F0 24 (v02 CORE ) [32m[0.00] [0m[33mACPI[0m: XSDT 0x1FFB00E0 44 (v01 CORE COREBOOT CORE ) [32m[0.00] [0m[33mACPI[0m: FACP 0x1FFB0910 F4 (v01 CORE COREBOOT CORE 002A) [32m[0.00] [0m[33mACPI[0m: DSDT 0x1FFB0280 000684 (v02 CORE COREBOOT 0001 INTL 20161222) [32m[0.00] [0m[33mACPI[0m: FACS 0x1FFB0240 40 [32m[0.00] [0m[33mACPI[0m: FACS 0x1FFB0240 40 [32m[0.00] [0m[33mACPI[0m: SSDT 0x1FFB0A10 C3 (v02 CORE COREBOOT 002A CORE 002A) [32m[0.00] [0m[33mACPI[0m: TCPA 0x1FFB0AE0 32 (v02 CORE COREBOOT CORE ) [32m[0.00] [0m[33mACPI[0m: HPET 0x1FFB0B20 38 (v01 CORE COREBOOT CORE ) [32m[0.00] [0m0MB HIGHMEM available. [32m[0.00] [0m511MB LOWMEM available. [32m[0.00] [0m[33m mapped low ram[0m: 0 - 1ff9f000 [32m[0.00] [0m[33m low ram[0m: 0 - 1ff9f000 [32m[0.00] [0mZone ranges: [32m[0.00] [0m DMA [mem 0x1000-0x00ff] [32m[0.00] [0m Normal [mem 0x0100-0x1ff9efff] [32m[0.00] [0m HighMem empty [32m[0.00] [0mMovable zone start for each node [32m[0.00] [0mEarly memory node ranges [32m[0.00] [0m[33m node 0[0m: [mem 0x1000-0x0009efff] [32m[0.00] [0m[33m node 0[0m: [mem 0x0010-0x1ff9efff] [32m[0.00] [0mInitmem setup node 0 [mem 0x1000-0x1ff9efff] [32m[0.00] [0m[33mOn node 0 totalpages[0m: 130877 [32m[0.00] [0m[33mfree_area_init_node[0m: node 0, pg
Re: [coreboot] ASUS P2-99 with P2B config
I'm not sure that I'm setting up the acpi patches correctly then. I had just ran: git fetch https://review.coreboot.org/coreboot refs/changes/73/22473/1 && git checkout FETCH_HEAD originally. I think I had run make clean as well. I tried doing: git fetch https://review.coreboot.org/coreboot refs/changes/71/21671/2 && git fetch https://review.coreboot.org/coreboot refs/changes/73/22473/1 && git checkout FETCH_HEAD but I don't know if that's how it's supposed to work. My experience with git is just using it to pull trunk versions of software and that's about it. I finally started to read Pro Git though, to try to actually learn how git works. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS P2-99 with P2B config
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/ 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. Also, I wouldn't really consider myself as qualified for reviewing code, but I'll gladly test it. 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). 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. 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! 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 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. 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
Re: [coreboot] ASUS P2-99 with P2B config
I managed to get the board status uploaded earlier today. CONFIG_MAINBOARD_SMBIOS_PRODUCT_NAME was set to P2-99, other then that, it shows up as just a P2B. I guess I need to look in to figuring out how to get flashrom to work properly. I could check that the floppy, second serial port, and parallel port work as well. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] ASUS P2-99 with P2B config
I did manage to get a clean build that board_status wouldn't complain about being dirty. The problem was I couldn't clone board_status properly, have a crappy isp. I can probably clone it from some where else tommorrow, or else I'll have to wait a week. After using git clean I was able to actually build crossgcc-i386 on the 32bit debian stretch I've got setup with the p2-99. board_status didn't like the 64bit utils in the build directory after I copied everything over from the 64bit machine. Too bad I don't have a pata/sata adapter or use NFS, that would have made it easy to chroot into and build with a faster machine. I tried your cbmem patch https://review.coreboot.org/c/8/ applied with git fetch https://review.coreboot.org/coreboot refs/changes/28/8/1 && git checkout FETCH_HEAD. I've got a serial capture and the log of cbmem -c attached. cbmem -t fails with "Could not open /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq: No such file or directory". coreboot-4.6-1923-g53abca0b56 Mon Oct 30 03:28:38 UTC 2017 romstage starting... CBMEM: IMD: root @ 1000 254 entries. IMD: root @ 1fffec00 62 entries. CBFS: 'Master Header Locator' located CBFS at [100:3ffc0) CBFS: Locating 'fallback/ramstage' CBFS: Found @ offset 19d00 size ab09 coreboot-4.6-1923-g53abca0b56 Mon Oct 30 03:28:38 UTC 2017 ramstage starting... Moving GDT to 1fffe8c0...ok Enumerating buses... Show all devs... Before device enumeration. Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 DOMAIN: : enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:01.0: enabled 1 PCI: 00:04.0: enabled 1 PNP: 03f0.0: enabled 1 PNP: 03f0.1: enabled 1 PNP: 03f0.2: enabled 1 PNP: 03f0.3: enabled 1 PNP: 03f0.5: enabled 1 PNP: 03f0.7: enabled 1 PNP: 03f0.8: enabled 1 PNP: 03f0.9: enabled 1 PNP: 03f0.a: enabled 1 PCI: 00:04.1: enabled 1 PCI: 00:04.2: enabled 1 PCI: 00:04.3: enabled 1 Compare with tree... Root Device: enabled 1 CPU_CLUSTER: 0: enabled 1 APIC: 00: enabled 1 DOMAIN: : enabled 1 PCI: 00:00.0: enabled 1 PCI: 00:01.0: enabled 1 PCI: 00:04.0: enabled 1 PNP: 03f0.0: enabled 1 PNP: 03f0.1: enabled 1 PNP: 03f0.2: enabled 1 PNP: 03f0.3: enabled 1 PNP: 03f0.5: enabled 1 PNP: 03f0.7: enabled 1 PNP: 03f0.8: enabled 1 PNP: 03f0.9: enabled 1 PNP: 03f0.a: enabled 1 PCI: 00:04.1: enabled 1 PCI: 00:04.2: enabled 1 PCI: 00:04.3: enabled 1 Root Device scanning... root_dev_scan_bus for Root Device CPU_CLUSTER: 0 enabled DOMAIN: enabled DOMAIN: scanning... PCI: pci_scan_bus for bus 00 PCI: 00:00.0 [8086/7190] ops PCI: 00:00.0 [8086/7190] enabled PCI: 00:01.0 [8086/7191] enabled PCI: 00:04.0 [8086/7110] bus ops PCI: 00:04.0 [8086/7110] enabled PCI: 00:04.1 [8086/7111] ops PCI: 00:04.1 [8086/7111] enabled PCI: 00:04.2 [8086/7112] ops PCI: 00:04.2 [8086/7112] enabled PCI: 00:04.3 [8086/7113] bus ops PCI: 00:04.3 [8086/7113] enabled PCI: 00:0c.0 [1106/3106] enabled PCI: 00:01.0 scanning... do_pci_scan_bridge for PCI: 00:01.0 PCI: pci_scan_bus for bus 01 PCI: 01:00.0 [10de/0221] enabled scan_bus: scanning of bus PCI: 00:01.0 took 0 usecs PCI: 00:04.0 scanning... scan_lpc_bus for PCI: 00:04.0 PNP: 03f0.0 enabled PNP: 03f0.1 enabled PNP: 03f0.2 enabled PNP: 03f0.3 enabled PNP: 03f0.5 enabled PNP: 03f0.7 enabled PNP: 03f0.8 enabled PNP: 03f0.9 enabled PNP: 03f0.a enabled PNP: 03f0.6 enabled scan_lpc_bus for PCI: 00:04.0 done scan_bus: scanning of bus PCI: 00:04.0 took 0 usecs PCI: 00:04.3 scanning... scan_generic_bus for PCI: 00:04.3 scan_generic_bus for PCI: 00:04.3 done scan_bus: scanning of bus PCI: 00:04.3 took 0 usecs scan_bus: scanning of bus DOMAIN: took 0 usecs root_dev_scan_bus for Root Device done scan_bus: scanning of bus Root Device took 0 usecs done found VGA at PCI: 01:00.0 Setting up VGA for PCI: 01:00.0 Setting PCI_BRIDGE_CTL_VGA for bridge PCI: 00:01.0 Setting PCI_BRIDGE_CTL_VGA for bridge DOMAIN: Setting PCI_BRIDGE_CTL_VGA for bridge Root Device Allocating resources... Reading resources... Root Device read_resources bus 0 link: 0 CPU_CLUSTER: 0 read_resources bus 0 link: 0 CPU_CLUSTER: 0 read_resources bus 0 link: 0 done DOMAIN: read_resources bus 0 link: 0 PCI: 00:01.0 read_resources bus 1 link: 0 PCI: 00:01.0 read_resources bus 1 link: 0 done PCI: 00:04.0 read_resources bus 0 link: 0 PNP: 03f0.8 missing read_resources PNP: 03f0.9 missing read_resources PCI: 00:04.0 read_resources bus 0 link: 0 done DOMAIN: read_resources bus 0 link: 0 done Root Device read_resources bus 0 link: 0 done Done reading resources. Show resources in subtree (Root Device)...After reading. Root Device child on link 0 CPU_CLUSTER: 0 CPU_CLUSTER: 0 child on link 0 APIC: 00 APIC: 00 DOMAIN: child on link 0 PCI: 00:00.0 DOMAIN: resource base 0 size 0 align 0 gran 0 limit flags 40040100 index 1000 DOMAIN: resource base 0 size 0 align 0 gran 0 limit flags 40040200 index 1100 PCI: 00:00.0 PCI: 00:00.0 resource base 0 size 1000
[coreboot] ASUS P2-99 with P2B config
In reply to Keith. Probably won't show up as a reply since I wasn't subscribed to the list. I am now though, so it should work out now. I also had to rewrite this, since gmail didn't like noscript refreshing the page when I enabled javascript from google to register on gerrit. My config was actually just the unmodified P2B build originally, but not built with the coreboot toolchain. As for the modified config, it was just P2B with the naming changed to P2-99. Looking at the picture of the P2B board in the wiki again, the P2-99 may actually just be the same board with one of the ram sockets unpopulated and the 440ZX northbridge chip. I haven't been able to get flashrom to find the flash chip, despite it recognizing the chipset and using compatible eeproms - I flashed them with coreboot on a different board after all. Running a git build of flashrom didn't help either, still couldn't find the flash. It's got an AS97127F, not an AS99127F. I tried to use the trick you linked from the P3B-F, but i2cset just reported a failure to write. I had previously tried getting flashrom to use some other board enables and that didn't work either. I attached a dmesg log with the ACPI errors. I don't know whether it's related to a missing MBRS table as you said. It also shows "[Firmware Bug]: the BIOS has corrupted hw-PMU resources (MSR 186 is 40002e)" after a reboot. It did that with every build I've tried and not specific to the ACPI patched version. I just made a clean unmoddified build for P2B with the coreboot toolchain. Might only get to flashing it tommorrow though. I did get signed in on gerrit, so I should be able to run board_status on it. If you get the early cbmem init patch uploaded I'll try to test that right away as well. p2-99_dmesg_reboot_color Description: Binary data -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
[coreboot] ASUS P2-99 with P2B config
Hi all, I wasn't planning on posting unless I could actually contribute something, but since Keith Hui posted last month about his work on CBMEM for 440BX and ACPI, I figured I should do some proper testing and at least post if it worked out. I'm running coreboot on a ASUS P2-99 board with the config copied straight from P2B. It's not perfect, but it is stable and I haven't found anything that doesn't work that did with the original firmware. Testing I did over the past week: 1. Actually made a seperate P2-99 config, I'd been using vanilla P2B with no renaming for a few months on it. 2. Built it properly with coreboot crossgcc. Previously I couldn't build it on amd64 Debian Sid but worked fine with the Debian toolchain. Now it builds fine on amd64 sid and stretch, but fails patching gcc-6.3.0_nds32_ite.patch on i686 Debian stretch and jessiie. 3. Setup a serial console - seems to work fine. I was using I different board for flashing anyway, since flashrom doesn't know the board enable and the asus flasher only works on with original firmware to find the board enable - it can flash coreboot though if you use the right flag to tell it to flash the whole rom. 4. Tried Keith Hui's ACPI patches (https://review.coreboot.org/c/22067/). It has no problem booting or restarting, but linux complains about the acpi. Didn't really expect it to work properly on a different board anyway. As it stands now, all I've done is run it with a P2B config and not verified if everything is working as it should, I barely have beginner knowledge of C and nothing on low level x86 or acpi, so I can't actually do anything but testing. I can't upload board status for it since it's a P2-99 not P2B. I'm also still stuck with with using another board and hot swapping chips to flash roms. I should probably post on the flashrom list that the board I'm flashing with works as well as see if anyone knows anything about the asus board enable (it's getting pretty old). The main reason I'm posting is to say I can test patches the patches Keith Hui has been working on and post logs. I'd also be glad for any other recommendations on what I can do to help with this system. -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
