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

[Stefan Roese]

Hi Bin,

On 16.01.2016 15:08, Bin Meng wrote:
> 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.

It is connected to the Winbond UART. So we need to enable and use it.
But how can I disable the BayTrail internal legacy UART? So that the
Winbond one is really used?

>>
>> --<--------
>> #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.

Let me double-check this.

>> /* 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.

It looks like those 0x2A comes from the FSP to signal some DDR
issues. I've seen 0x2B as well. And have in the meantime been
able to boot further into U-Boot with some tuned settings.

But still, without any serial output this is hard to debug.

Thanks,
Stefan