I have made some progress since yesterday and now I have much better results:
* Adding a setting to romstage to disable PCI-PCI bridge and enabling its pins as GPIO (that's what the datasheet says) made it possible to initialize the PCIe bridge @00:02.1. * Adding the base address 0x0 to unused resources helped silenting resource allocation errors reported, no side effects so far * Now that the PCIe bridge is properly initialized, I have a fully working system! Ubuntu 16.04 boots up and runs absolutely error-free and stable, even the suspend functionality works as expected. * Adding the option HAVE_CMOS_DEFAULT to the board's Kconfig file helped to make get_option() working as expected The only major issue left is the unstable operation of the USB keyboard with SeaBIOS. I have found no build parameters to fine tune keyboard-related settings like timeouts so I guess I'll have to create a patch to get this fixed. Any ideas are welcome on how to fix this. Thanks, Gergely On 18 December 2017 at 15:32, Gergely Kiss <mail.g...@gmail.com> wrote: > Hi, > > thanks for all the advice, so far! > > I've made a lot of progress here: after configuring all the low-level > registers (drive strength control, oscillator clock control, SIO GPIO/EC > registers) as per the vendor BIOS, coreboot finally started to boot up! > > Here's what's working so far: > > * Serial console > * GPIO & EC configuration > * Loading the VGA BIOS blob through SeaBIOS - I have text mode console > output through the D-SUB interface (other outputs need to be tested) > * Low level CPU and RAM initialization works perfectly. I have run one > pass of memtest for an hour, it could read the SPD chip and the test > completed without errors > * Coreboot boots up somewhat fine. It shows some resource allocation > issues but still, the boot process reaches to payload execution phase. > SeaBIOS, nvramcui & memtest payloads can be booted without any issues. > * Starting a bootloader through SeaBIOS works - tested with ISOLINUX & > Windows bootloader, so far > > Some problems I'm facing: > > * USB keyboard support is quite unstable with SeaBIOS, most of the time > the keyboard is not detected (it works about once every five-six boots), > regardless of what other USB devices are connected to the board > * The PCIe Bridge interface of the northbridge (@00:02.1) cannot be > configured for some reason. I can see Coreboot correctly identifies and > configures the device as a bridge but sending cmd 07 (not sure what that > means) to the device completely halts the system. Disabling the device in > devicetree makes it possible to avoid the lockup but I think I should not > let the device unconfigured. > * Booting up an OS does not work, yet, both Linux and Windows halts while > loading. This is most likely due to some resource allocation or IRQ routing > issue (I'll need to take a look at boot logs to see what's happening) > * TianoCore does not boot, it halts the system with a "division by zero" > exception displayed on the serial console. I guess it won't be easy to > debug this one so it is kind of low priority as of now. > > The questions I have: > > * How could I fix the USB keyboard issues with SeaBIOS? Is there some > timeout value I could raise to have more stable support for the keyboard? I > have tried disabling OHCI & XHCI support in SeaBIOS but that did not help. > * I can see a few resources allocation errors on the console output. For > some of these errors, the missing resources are actually unused by the > board (eg. the secondary & tertiary base address for the environment > controller). Shall I allocate the I/O address 0x0 to such devices or simply > ignore the errors? > * For the SATA controller, coreboot reports that there are 4 memory > address spaces that are not being allocated. Checking the devicetree of > other similar boards, I can see these resources are not allocated there, > either. Is it safe to ignore this error? > * Any ideas how to debug the lockup caused by the PCIe Bridge device > configuration? What does "cmd 07" mean? > * I'd like to read some settings from the CMOS memory both in romstage & > ramstage. What's the correct way to do so? Using get_option() seems not to > work at all while using read_option_lowlevel() returns a warning that I > should use get_option() in non-ROMCC stages. Is there some better way to > store user-configurable HW settings? nvramcui looks to be a "user-friendly" > tool to configure NVRAM settings, is there a similar user interface > available for CBFS, too? > > Thanks & Regards, > Gergely > > On 4 December 2017 at 18:49, ron minnich <rminn...@gmail.com> wrote: > >> don't forget, you can write code that runs in user mode and drives the >> superio. >> >> This is a handy way to test superio chips you're not sure about. >> >> use iopl(3) to enable arbitrary Io port access, then inb/outb to try to >> get some idea what's going on. >> >> This is obviously a little limited, since the firmware has already done >> lots of setup, but I've been able to learn things using this technique. >> >> ron >> >> On Mon, Dec 4, 2017 at 9:43 AM Kyösti Mälkki <kyosti.mal...@gmail.com> >> wrote: >> >>> On Mon, Dec 4, 2017 at 2:44 PM, Gergely Kiss <mail.g...@gmail.com> >>> wrote: >>> > Hi, >>> > >>> > I'm working on porting Coreboot to the ASUS AM1I-A motherboard and I'm >>> a bit >>> > stuck. >>> > >>> > I could successfully build Coreboot but after flashing the ROM, my >>> board >>> > looks to be bricked... >>> > >>> > Once powering on the board, the CPU fan spins up but then nothing >>> happens, I >>> > can't see any output on the serial console (the connection was tested >>> prior >>> > to flashing by running a getty on the COM port and it was working >>> fine). >>> > >>> >>> Common errors: Forgetting to use correct super-IO config base address >>> (0x2e vs 0x4e) and not providing 48MHz reference clock for the uart >>> baudrate divisor. AMD hardware often uses configurable GPIO pins for >>> this purpose, the code copied from biostar/am1ml may not be right for >>> asus/am1l-a. >>> >>> You can dump those GPIO configurations eg. with iotools or even dd >>> from /dev/mem. Related datasheets for the Kabini family should be >>> available without NDAs. >>> >>> > The board is not fried as I can load back the vendor firmware and it >>> boots >>> > up absolutely fine. >>> > >>> > I'd like to find out why Coreboot would not start but don't know what >>> tool >>> > would be the most suitable for debugging. >>> > >>> > The chipset and the CPU is already supported by Coreboot but the >>> SuperIO >>> > chip is not. It looks to me the serial interfaces of ITE chips work >>> the same >>> > for all models so I believe using the common code for ITE SIO chips >>> should >>> > work but I'm unsure (no datasheet available). >>> >>> AM1 socket support is a hack anyways, grep for >>> FORCE_AM1_SOCKET_SUPPORT. Your mileage may vary. >>> >>> It's not uncommon that PNP LDNs for the UARTs change within one vendor. >>> Did you run util/superiotool and dump SIO settings from vendor boot? >>> >>> > >>> > Shall I use a PCIe serial interface card or rather try EHCI debugging? >>> I'm >>> > afraid in case the boot process halts at some early stage (like before >>> > romstage) then I won't see any useful output using any of those. >>> > >>> >>> EHCI debug should be fine nowadays with AGESA, still not my first >>> choice here for you. >>> PCIe serial cards are untested, probably do not work early enough to >>> be useful for you. >>> Traditional serial port debug will also be silent before romstage... >>> >>> > Using a POST card would be a better approach I think but my board has a >>> > single PCIe 4x slot which seems to be unsupported by POST cards I >>> could find >>> > on the web (except one from a Chinese vendor but it costs about $1k >>> which is >>> > way too expensive). >>> >>> Those mini-PCI-e POST cards with 7-seg displays are about 4 USD and >>> your mainboard TPM connector seems to carry the required LPC signals. >>> Remember to enable and route POSTs to LPC (kconfig POST_DEVICE_LPC). >>> >>> > >>> > Here's my WIP code for reference: >>> > >>> > https://github.com/kissg1988/coreboot/tree/master/src/mainbo >>> ard/asus/am1i-a >>> > >>> > Any idea how to proceed? >>> > >>> >>> Get one of those POST cards, try to show vendor/device ID registers >>> from superio on the 7-seg display. >>> >>> > Thanks, >>> > Gergely >>> > >>> > >>> >>> HTH, >>> Kyösti >>> >>> > -- >>> > coreboot mailing list: coreboot@coreboot.org >>> > https://mail.coreboot.org/mailman/listinfo/coreboot >>> >>> -- >>> coreboot mailing list: coreboot@coreboot.org >>> https://mail.coreboot.org/mailman/listinfo/coreboot >> >> >
-- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot