[coreboot] Early debugging

Mon Dec 18 15:32:27 CET 2017

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 <rminnich at 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.malkki at gmail.com>
> wrote:
>
>> On Mon, Dec 4, 2017 at 2:44 PM, Gergely Kiss <mail.gery at 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/
>> mainboard/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 at coreboot.org
>> > https://mail.coreboot.org/mailman/listinfo/coreboot
>>
>> --
>> coreboot mailing list: coreboot at coreboot.org
>> https://mail.coreboot.org/mailman/listinfo/coreboot
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20171218/75027c9a/attachment.html>