[U-Boot] U-Boot v2015.04, x86 Intel Baytrail, and hsuart0 configuration
Timothy Scott
tescott425 at gmail.com
Wed Oct 7 17:26:50 CEST 2015
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.
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.
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
On Wed, Oct 7, 2015 at 3:10 AM, Bin Meng <bmeng.cn at gmail.com> wrote:
> Hi Tim,
>
> +Simon and U-Boot ML.
>
> On Wed, Oct 7, 2015 at 12:22 AM, Timothy Scott <tescott425 at gmail.com>
> wrote:
> > Bin,
> >
> > I've seen your name associated with U-boot repo commits relating to the
> > ns16550 and the UARTs that are sitting on the PCI bus for the Intel
> > Baytrail. I'm working on setting up a board based on the Intel E3815
> > (Baytrail) and am having difficulty redirecting the console to hsuart0.
> > Things work great for the legacy COM port @ address 0x3F8, but fail (ie.
> > continuous U-Boot resets) when I try to change things to use hsuart0.
> With
> > the hsuart0 defined in the DTS, I'd expect "coninfo" to reflect the
> hsuart0
> > device, but I do not see it. "dm tree" shows the device present but
> that it
> > is unprobed.
> >
> > Note that I'm working against U-Boot v2015.04. I tried updating to
> v2015.07
> > to see if that would help, but that ended up killing other devices that
> are
> > working fine on v2015.04 so I'm trying to stick with that.
> >
>
> Can you please rebase your working tree based on commit
>
> commit b21b208184721eed198bdf59204b452716986377
> Author: Bin Meng <bmeng.cn at gmail.com>
> Date: Wed Dec 31 16:05:14 2014 +0800
>
> x86: crownbay: Add pci devices in the dts file
>
> This is the initial commit that was the first time to support PCI UART
> and verified on Intel Crown Bay.
>
> At some time later there was a change in the dev_get_addr() API that
> broke the PCI UART codes but I can't remember when that regression was
> introduced. This was later fixed by commit:
>
> commit 236efe36be6d1c544f9477f10fdf38a17cd7a869
> Author: Simon Glass <sjg at chromium.org>
> Date: Sun Aug 2 18:13:50 2015 -0600
>
> Revert "fdt: Fix fdtdec_get_addr_size() for 64-bit"
>
> The symptom you observed (continuous U-Boot reset) is probably due to
> this. As when U-Boot does not find a working serial console, it simply
> resets.
>
> > Here's my current DTS file. I used the crownbay.dts configuration as a
> > reference. Not sure if you can see anything wrong with my config, but a
> > second pair of eyes on it would help!
> >
> > /dts-v1/;
> >
> > /include/ "skeleton.dtsi"
> > /include/ "serial.dtsi"
> >
> > / {
> > model = "Yukon"; /* my board name */
> > compatible = "intel,yukon", "intel,baytrail";
> >
> > aliases {
> > serial0 = "/serial";
> > serial1 = "/pci/serial at 1e,3";
> > };
> >
> > config {
> > silent_console = <0>;
> > };
> >
> > chosen {
> > stdout-path = "/serial"; /* switching this to &hsuart0; results in
> > continuous resets. Configuration as-is works fine but uses the PCU uart
> on
> > the baytrail part. */
> > };
> > pci {
> > #address-cells = <3>;
> > #size-cells = <2>;
> > compatible = "simple-bus"; /* I had to change this from intel,cpi to
> > simple-bus in order for 'dm tree' to show this node and the hsuart0
> node/ */
> > device_type="pci";
> >
> > hsuart0: serial at 1e,3 {
> > compatible = "pci8086,0f0a","x86-uart";
> > u-boot,dm-pre-reloc;
> > reg = <0x0200F310 0x0 0x0 0x0 0x0>; /* memory-mapped, PCI 0/30/3
> > device, config @ address 0x10 */
> > reg-shift = <0>;
> > clock-frequency = <1843200>;
> > current-speed = <115200>;
> > };
> > };
> > };
> >
> > Here is the output of "coninfo" with the above DTS definitions:
> >
> > => coninfo
> > List of available devices:
> > serial 00000003 .IO stdin stdout stderr
> > sserial 80000003 SIO
> > nulldev 80000003 SIO
> > nc 80000003 SIO
> > cbmem 00000002 ..O
> >
> > Here is the output of "dm tree" and "dm uclass" with the above DTS
> > definition:
> >
> > => dm tree
> > Class Probed Name
> > ----------------------------------------
> > root [ + ] root_driver
> > serial [ + ] |-- serial
> > simple_bus [ ] `-- pci
> > serial [ ] `-- serial at 1e,3
> > => dm uclass
> > uclass 0: root
> > - * root_driver @ 7aa12058
> >
> > Cannot find uclass for id 1: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 2: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 3: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 4: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 5: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 6: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > uclass 7: simple_bus
> > - pci @ 7aa12158
> >
> > uclass 8: gpio
> > uclass 9: serial
> > - * serial @ 7aa120d0, 0
> > - serial at 1e,3 @ 7aa121b0, 1
> >
> > Cannot find uclass for id 10: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 11: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 12: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 13: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 14: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 15: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 16: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 17: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> > Cannot find uclass for id 18: please add the UCLASS_DRIVER() declaration
> for
> > this UCLASS_... id
> >
> >
> > Thanks for any and all help! I've been banging my head on this for
> about a
> > week now and have not made much progress.
> >
>
> The other option for you is to try latest u-boot/master branch and
> build a u-boot.rom from there. Compared to the original commit, the
> latest branch has been switch to DM to support PCI UART. But you need
> also port your boards codes to use DM. See Intel Crown Bay board codes
> for how DM conversion is done.
>
> Regards,
> Bin
>
More information about the U-Boot
mailing list