Re: [coreboot] Early debugging

[Gergely Kiss]

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  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  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 
> > wrote:
> > > On Mon, Dec 4, 2017 at 2:44 PM, Gergely Kiss 
> > > 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
> > > >