[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 <mail.gery at 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 <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/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 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/20171219/8fdbe0d5/attachment.html>