[U-Boot] x86: Bay Trail support with W83627DHG

[Bin Meng]

Hi Stefan,

On Fri, Jan 15, 2016 at 10:37 PM, Stefan Roese <sr at denx.de> wrote:
> Hi Simon, Hi Bin!
>
> I'm currently busy with porting U-Boot to a Bay Trail board.
> Equipped with an Intel Atom E3845 and additionally the
> Nuvoton / Winbond W83627DHG Super IO chip.
>
> My staring point for this port is the Minnowboard MAX, which
> works very well btw. I've used the same binaries as described
> in the README.x86 as on the MinnowMAX for this new Bay Trail
> board. But am not able yet to see any output on the DEBUG_UART.
>
> Bin, you already mentioned in a previous mail, that I need to
> enable the legacy UART in the Super IO chip for this. I've
> started adding a small driver for this, similar to the one
> you've introduced for the SMSC:

Ah, looks I delivered inaccurate information before! I just remember
BayTrail SoC integrates a legacy UART at I/O 0x3f8 and it is enabled
by FSP by default. If you use a debug version of FSP (only gold4
release provides a debug version FSP), you will se lots of useful
debug information printed on the serial port (the one connected to the
SoC legacy UART). But, why does your board have an additional Nuvoton
/ Winbond W83627DHG Super IO chip? I guess it's for other legacy
peripherals like 8042 KBC, etc? We need figure out the serial port you
are trying to enable is connected to which chip. If it is connected
directly to BayTrail SoC, then you don't need program this W83627DHG.

>
> --<--------
> #define WINBOND_ENTRY_KEY       0x87
> #define WINBOND_EXIT_KEY        0xAA
>
> /* Enable configuration: pass entry key '0x87' into index port dev. */
> static void pnp_enter_conf_state(u16 dev)
> {
>         u16 port = dev >> 8;
>
>         outb(WINBOND_ENTRY_KEY, port);
>         outb(WINBOND_ENTRY_KEY, port);
> }
>
> /* Disable configuration: pass exit key '0xAA' into index port dev. */
> static void pnp_exit_conf_state(u16 dev)
> {
>         u16 port = dev >> 8;
>
>         outb(WINBOND_EXIT_KEY, port);
> }
>
> /* Bring up early serial debugging output before the RAM is initialized. */
> void winbond_enable_serial(uint dev, uint iobase, uint irq)
> {
>         pnp_enter_conf_state(dev);
>         pnp_set_logical_device(dev);
>         pnp_set_enable(dev, 0);
>         pnp_set_iobase(dev, PNP_IDX_IO0, iobase);
>         pnp_set_irq(dev, PNP_IDX_IRQ0, irq);
>         pnp_set_enable(dev, 1);
>         pnp_exit_conf_state(dev);
> }
> --<--------
>
> This is called via:
> --<--------
> /* I/O address of Winbond Super IO chip */
> #define WINBOND_IO_PORT         0x2e
>

If the serial port is connected to winbond, we need make sure this I/O
port 0x2e is correct. Normally the chipset will have several optional
addresses, and which one is used is determined by some strap pins.

> /* Logical device number */
> #define W83627DHG_SP1           2       /* Com1 */
>
>         winbond_enable_serial(PNP_DEV(WINBOND_IO_PORT, W83627DHG_SP1),
>                               UART0_BASE, UART0_IRQ);
> --<--------
>
> As you may notice, this is ported from coreboot. But still, this
> is not enough to get some output on the UART.
>
> Debugging (without JTAG debugger and without DEBUG_UART but with
> POST output) shows, that the board hangs somewhere in the FSP code.
> When called via fsp_init(). POST shows 0x2A in this case. And
> FSP does not return to fsp_continue() at all.
>

0x2A seems to be a U-Boot postcode.

> Do you have any hints what could be missing for the DEBUG
> UART to work on this board? Or what might cause the board
> to hang in the FSP code? Or what the meaning of the FSP 0x2A
> POST code is?
>

If the fsp_init() never returns, the most suspectable one is DDR
initialization failure. If it's a memory-down configuration, you may
need check the DDR chipset datasheet and fill in correct values in the
device tree file.

Regards,
Bin