[coreboot] Early debugging
rminnich at gmail.com
Mon Dec 4 18:49:51 CET 2017
don't forget, you can write code that runs in user mode and drives the
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.
On Mon, Dec 4, 2017 at 9:43 AM Kyösti Mälkki <kyosti.malkki at gmail.com>
> 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
> > 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
> > 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
> 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
> > up absolutely fine.
> > I'd like to find out why Coreboot would not start but don't know what
> > 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
> > for all models so I believe using the common code for ITE SIO chips
> > 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?
> > 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
> > 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:
> > 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
> > --
> > coreboot mailing list: coreboot at coreboot.org
> > https://mail.coreboot.org/mailman/listinfo/coreboot
> coreboot mailing list: coreboot at coreboot.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the coreboot