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 <[email protected]> wrote: > On Mon, Dec 4, 2017 at 2:44 PM, Gergely Kiss <[email protected]> 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: [email protected] > > https://mail.coreboot.org/mailman/listinfo/coreboot > > -- > coreboot mailing list: [email protected] > https://mail.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
