Re: [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 
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/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
> >