Re: [U-Boot] U-Boot v2015.04, x86 Intel Baytrail, and hsuart0 configuration
Hi Tim,
+Simon and U-Boot ML.
On Wed, Oct 7, 2015 at 12:22 AM, Timothy Scott tescott425@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@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@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@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@1e,3 { compatible = "pci8086,0f0a","x86-uart"; u-boot,dm-pre-reloc; reg = <0x0200F310 0x0 0x0 0x0 0x0>; /* memory-mapped, PCI 0/30/3device, 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@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@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
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@gmail.com wrote:
Hi Tim,
+Simon and U-Boot ML.
On Wed, Oct 7, 2015 at 12:22 AM, Timothy Scott tescott425@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@gmail.com Date: Wed Dec 31 16:05:14 2014 +0800
x86: crownbay: Add pci devices in the dts fileThis 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@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@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@1e,3 { compatible = "pci8086,0f0a","x86-uart"; u-boot,dm-pre-reloc; reg = <0x0200F310 0x0 0x0 0x0 0x0>; /* memory-mapped, PCI 0/30/3device, 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@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@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
Hi Tim,
On Wed, Oct 7, 2015 at 11:26 PM, Timothy Scott tescott425@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:
- 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.
- 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
participants (2)
-
Bin Meng -
Timothy Scott