[U-Boot] U-Boot v2015.04, x86 Intel Baytrail, and hsuart0 configuration

[Bin Meng]

Hi Tim,

On Wed, Oct 7, 2015 at 11:26 PM, Timothy Scott <tescott425 at gmail.com> wrote:
> Bin,
>
> Thanks for the response.  I've got things working with v2015.04, but it took
> some tweaking.  Here's what I learned:
>
> 1) PCI is initialized AFTER the code was attempting to configure hsuart0.
> Since hsuart0 is on the PCI bus, the various registers being read were
> coming up 0xFFFF and therefore hsuart0 access was invalid.

Yes, in v2015.04, Intel Crown Bay codes did this by defining
CONFIG_SYS_EARLY_PCI_INIT and calling the PCI enumeration in
arch_cpu_init() manually. With DM conversion on the latest
u-boot/master branch, this is not needed as the enumeration will be
triggered as needed.

> 2) I'm swapping between PCU_UART (legac y) and SIO_UART at run-time, while
> using the ns16550 driver in both instances.  The code that underlies
> ns16550_writeb() and ns16550_readb() expects things to be configured at
> compile time via CONFIG options instead of something you can jack with at
> run-time.
>

This can be enhanced by converting the ns16550 CONFIG options to a
device tree bindings, however I don't know if there is any plan to do
this. My only concern of doing it via device tree is that some
performance degradation might be observed.

> My workarounds:
> - created hsuart_init() in serial-uclass.c, patterned off of
> serial_find_console_or_panic().  This references a unique chosen option I
> named "hsuart-path" and loads up hsuart device for me.  I do this to get the
> hsuart0 probed and loaded.  (If there's a better way to force a device
> probe, please let me know.)
> - created initr_hsuart_serial() in board_r.c, and invoked this via the
> init_sequence_r[] table, after initr_pci.
> - updated ns16550.c's ns16550_platdata with a "mem_map" parameter.  I added
> a "mem-map" parm to the hsuart DTS entry, and load this value in via
> ns16550_serial_ofdata_to_platdata.  This is then referenced in
> ns16550_writeb() and ns16550_readb() to perform a memory mapped access,
> instead of whatever the CONFIG options have defined.  In my case, CONFIG
> options result in a port mapped access.
>
> All this is pretty hackish but works for my purposes.
>
> Thanks again,
> --tim
>
>

Regards,
Bin