[coreboot] Early debugging

[ron minnich]

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/20171204/109f0228/attachment.html>