Hi Aaron,
On Wed, 16 Oct 2019 at 11:56, Aaron Williams awilliams@marvell.com wrote:
Hi Simon,
On Friday, October 11, 2019 4:42:55 PM PDT Simon Glass wrote:
Hi Aaron,
On Wed, 25 Sep 2019 at 22:08, Aaron Williams awilliams@marvell.com wrote:
Hi Simon,
On Wednesday, September 25, 2019 8:40:48 PM PDT Bin Meng wrote:
External Email
+Simon
Hi Aaron,
On Thu, Sep 26, 2019 at 11:10 AM Aaron Williams awilliams@marvell.com
wrote:
Hi all,
I have an issue where I have a nexus driver and a sub serial driver on top of it. The base nexus driver is getting bound and probed properly, however the serial drivers (pci-console) below it are not.
My device tree looks something like this: pci-console-nexus@0x03000000 {
/* Remote PCI console buffer location */ compatible = "marvell,pci-console-nexus";Is this a PCI controller node?
No, actually it points to a location in memory which is shared by a PCI host with the software. It is a software only structure with no actual hardware behind it. We use this as a serial console across the PCI bus, but it's just shared memory. There is a nexus device then multiple consoles underneath it. U-Boot will initialize the data structures (if needed) and claim one of the consoles while it is use. The data structures may or may not already be initialized by earlier bootloaders or the ATF. The ATF may also claim one of the consoles.
What uclass is this node? Does that uclass have a post_bind method that calls dm_scan_fdt_dev()?
status = "okay"; #address-cells = <2>; #size-cells = <1>; skip-init; num-consoles = <8>; reg = <0 0x03000000 0 0x40000>; ranges = <0 0 0 0x3000100 0x4000>, <1 0 0 0x3004100 0x4000>, <2 0 0 0x3008100 0x4000>, <3 0 0 0x300c100 0x4000>, <4 0 0 0x3010100 0x4000>, <5 0 0 0x3014100 0x4000>, <6 0 0 0x3018100 0x4000>, <7 0 0 0x301c100 0x4000>; console@0 { compatible = "marvell,pci-console";If this is a PCI device, it can be handled by the PCI codes.
status = "okay"; reg = <0 0 0x4000>; tx-buffer-size = <0x2f80>; rx-buffer-size = <0x1000>; };...
console@7 { compatible = "marvell,pci-console"; status = "okay"; reg = <7 0 0x4000>; tx-buffer-size = <0x2f80>; rx-buffer-size = <0x1000>; }; };When U-Boot binds the drivers it sees and binds pci-console-nexus but it never even attempts to go any deeper in the device tree. Both drivers are used. The nexus datastructure is a shared resouce that can be used by ATF.
I added a bind function in the nexus driver that basically does: dev_for_each_subnode(node, parent) {
ret = device_bind_driver_to_node(parent, DRIVER_NAME, ofnode_get_name(node), node, &dev); get_uclass(UCLASS_SERIAL, &uc); dev->uclass = uic; }With this I see the consoles in the dm tree and uclass list, but the sequences don't seem to be getting set.
What I notice when I type dm uclass is: uclass 60: serial
- serial@87e028000000 @ 7fbeb3360, seq 0, (req 0)
- serial@87e029000000 @ 7fbeb3430, seq -1, (req 1)
- console@0 @ 7fbeb3660
- console@1 @ 7fbeb3780
- console@2 @ 7fbeb38a0
- console@3 @ 7fbeb39c0
- console@4 @ 7fbeb3ae0
- console@5 @ 7fbeb3c00
- console@6 @ 7fbeb3d20
- console@7 @ 7fbeb3e40
- pci-bootcmd@0x03fff000 @ 7fbeb3f60, seq 1, (req -1)
Does anyone have any ideas on how I should properly handle this? It seems that whatever I'm doing is overly complicated and I'm missing something for the DM layer to not go deeper into the tree past the nexus layer.
static const struct udevice_id octeontx_pcie_console_nexus_serial_id[] = {
{ .compatible = "marvell,pci-console-nexus", }, { },};
U_BOOT_DRIVER(octeontx_pcie_console_nexus) = {
.name = DRIVER_NAME "-nexus", .id = UCLASS_MISC, .flags = DM_FLAG_PRE_RELOC, .of_match = of_match_ptr(octeontx_pcie_console_nexus_serial_id), .ofdata_to_platdata = octeontx_pcie_console_nexus_ofdata_to_platdata, .platdata_auto_alloc_size = sizeof(struct octeontx_pcie_console_plat_data), .bind = octeontx_pcie_console_nexus_bind, .probe = octeontx_pcie_console_nexus_probe, .priv_auto_alloc_size = sizeof(struct octeontx_pcie_console_nexus_priv),};
static const struct dm_serial_ops octeontx_pcie_console_ops = {
.setbrg = octeontx_pcie_console_setbrg, .getc = octeontx_pcie_console_getc, .putc = octeontx_pcie_console_putc, .pending = octeontx_pcie_console_pending, .clear = octeontx_pcie_console_clear,};
static const struct udevice_id octeontx_pcie_console_serial_id[] = {
{ .compatible = "marvell,pci-console", }, { },};
U_BOOT_DRIVER(octeontx_pcie_console) = {
.name = DRIVER_NAME, .id = UCLASS_SERIAL, .ops = &octeontx_pcie_console_ops, .of_match = of_match_ptr(octeontx_pcie_console_serial_id), .probe = octeontx_pcie_console_probe, .ofdata_to_platdata = octeontx_pcie_console_ofdata_to_platdata, .remove = octeontx_pcie_console_remove, .priv_auto_alloc_size = sizeof(struct octeontx_pcie_console_priv), .platdata_auto_alloc_size = sizeof(struct octeontx_pcie_console_plat_data), .flags = DM_FLAG_OS_PREPARE | DM_FLAG_PRE_RELOC,};
Regards, Bin
Regards,
Aaron
I found the issue and got it working. Now my issue is that I need it to carve out the block of memory so that Linux does not use it. I put in a reserved- memory section in the device tree, however, Linux crashes when it uses this memory block and U-Boot does not seem to be honoring this. It may be because we're at 2018.03 and I need to backport more fixes and changes or it may be due to the memory address range being used:
Or it may be that U-Boot doesn't support this? I'm not an expert here but it looks like U-Boot passes this reserved-memory info to Linux, but does not use it itself.
reserved-memory { #address-cells = <2>; #size-cells = <2>; ranges; /* The PCI console memory must be reserved */ console_reserved: pci-console-nexus@0x03000000 { compatible = "marvell,pci-console-nexus-memory"; reg = <0 0x03000000 0 0x40000>; no-map; }; };-Aaron
Regards, Simon