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

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:
--<-------- #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
/* 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.
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?
Thanks, Stefan

Hi Stefan,
On 15 January 2016 at 07:37, Stefan Roese sr@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:
--<-------- #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
/* 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.
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?
I have seen the FSP crash when the wrong microcode is provided.
Regards, Simon

Hi Stefan,
On Fri, Jan 15, 2016 at 10:37 PM, Stefan Roese sr@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

Hi Bin,
On 16.01.2016 15:08, Bin Meng wrote:
On Fri, Jan 15, 2016 at 10:37 PM, Stefan Roese sr@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

Hi Bin,
On 17.01.2016 03:35, Stefan Roese wrote:
On 16.01.2016 15:08, Bin Meng wrote:
On Fri, Jan 15, 2016 at 10:37 PM, Stefan Roese sr@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?
Okay. I was able to work around this problem with the included legacy UART in the Bay Trail Atom. By moving the IO base address of the Winbond COM1 from 0x3f8 to a different (unused) location. And then using this new address as the UART base address. U-Boot boots to the prompt with the "fixed" memory-down DDR parameters to the FSP in this configuration.
Still I would really like to disable the internal legacy UART and only use the Winbond UART(s) at the default address. Disabling the Bay Trail legacy UART by clearing the "UART_CONT.COM1EN" bit, as described in the "Intel AtomTM Processor E3800 Product Family Datasheet", does not seem to fix this problem. I need to double check this tomorrow though.
Bin, Simon, do you have any ideas on how to disable this Atom legacy UART instead. It must be possible, as when booting into Linux with the original BIOS, the Winbond COM1 works just fine at 0x3f8.
Thanks, Stefan

Hi Stefan,
On Mon, Jan 18, 2016 at 1:44 AM, Stefan Roese sr@denx.de wrote:
Hi Bin,
On 17.01.2016 03:35, Stefan Roese wrote:
On 16.01.2016 15:08, Bin Meng wrote:
On Fri, Jan 15, 2016 at 10:37 PM, Stefan Roese sr@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?
Okay. I was able to work around this problem with the included legacy UART in the Bay Trail Atom. By moving the IO base address of the Winbond COM1 from 0x3f8 to a different (unused) location. And then using this new address as the UART base address. U-Boot boots to the prompt with the "fixed" memory-down DDR parameters to the FSP in this configuration.
This is great!
Still I would really like to disable the internal legacy UART and only use the Winbond UART(s) at the default address. Disabling the Bay Trail legacy UART by clearing the "UART_CONT.COM1EN" bit, as described in the "Intel AtomTM Processor E3800 Product Family Datasheet", does not seem to fix this problem. I need to double check this tomorrow though.
Bin, Simon, do you have any ideas on how to disable this Atom legacy UART instead. It must be possible, as when booting into Linux with the original BIOS, the Winbond COM1 works just fine at 0x3f8.
I checked FSP VPD of BayTrial, looks Intel does not expose a config option to enable/disable the legacy UART integrated into the SoC, neither an option to move its I/O address, instead it enables the legacy UART always and has a fixed address 0x3f8. Per my understanding of the datasheet, I think you are right, "UART_CONT.COM1EN" bit should be the key to enable/disable the legacy UART. But I suspect FSP turns it on again during every call to the FSP API (like fsp_init(), fsp_notify()).
You may try: after each call to fsp_init() and fsp_notify(), try adding the codes to turn off the "UART_CONT.COM1EN" bit and see what's going on there.
Regards, Bin

Hi Bin,
On 18.01.2016 04:03, Bin Meng wrote:
On Mon, Jan 18, 2016 at 1:44 AM, Stefan Roese sr@denx.de wrote:
Hi Bin,
On 17.01.2016 03:35, Stefan Roese wrote:
On 16.01.2016 15:08, Bin Meng wrote:
On Fri, Jan 15, 2016 at 10:37 PM, Stefan Roese sr@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?
Okay. I was able to work around this problem with the included legacy UART in the Bay Trail Atom. By moving the IO base address of the Winbond COM1 from 0x3f8 to a different (unused) location. And then using this new address as the UART base address. U-Boot boots to the prompt with the "fixed" memory-down DDR parameters to the FSP in this configuration.
This is great!
Still I would really like to disable the internal legacy UART and only use the Winbond UART(s) at the default address. Disabling the Bay Trail legacy UART by clearing the "UART_CONT.COM1EN" bit, as described in the "Intel AtomTM Processor E3800 Product Family Datasheet", does not seem to fix this problem. I need to double check this tomorrow though.
Bin, Simon, do you have any ideas on how to disable this Atom legacy UART instead. It must be possible, as when booting into Linux with the original BIOS, the Winbond COM1 works just fine at 0x3f8.
I checked FSP VPD of BayTrial, looks Intel does not expose a config option to enable/disable the legacy UART integrated into the SoC, neither an option to move its I/O address, instead it enables the legacy UART always and has a fixed address 0x3f8. Per my understanding of the datasheet, I think you are right, "UART_CONT.COM1EN" bit should be the key to enable/disable the legacy UART. But I suspect FSP turns it on again during every call to the FSP API (like fsp_init(), fsp_notify()).
You may try: after each call to fsp_init() and fsp_notify(), try adding the codes to turn off the "UART_CONT.COM1EN" bit and see what's going on there.
This seems to work. Thanks. I'll prepare a patch to support the non-internal legacy UART on BayTrail for this.
Thanks, Stefan
participants (3)
-
Bin Meng
-
Simon Glass
-
Stefan Roese