Device Tree Rebuilder
- This topic has 17 replies, 2 voices, and was last updated 6 years, 8 months ago by
.
-
-
Hello,
I followed the instructions in the “OSD335x Lesson 2: Linux Device Tree” App Note to modify and rebuild our custom board device tree.
I ran into this issue when trying to compile using Robert Nelson’s Device Tree Rebuilder:
dusty@dusty-VirtualBox:/media/dusty/rootfs/tmp/dtb-rebuilder-4.4-ti$ sudo make src/arm/WV_OSD3358-SM__066.dtb DTC src/arm/WV_OSD3358-SM__066.dtb Error: src/arm/am335x-osd335x-sm.dtsi:1399.17-18 syntax error FATAL ERROR: Unable to parse input tree Makefile:148: recipe for target 'src/arm/WV_OSD3358-SM__066.dtb' failed make[1]: *** [src/arm/WV_OSD3358-SM__066.dtb] Error 1 Makefile:112: recipe for target 'src/arm/WV_OSD3358-SM__066.dtb' failed make: *** [src/arm/WV_OSD3358-SM__066.dtb] Error 2 dusty@dusty-VirtualBox:/media/dusty/rootfs/tmp/dtb-rebuilder-4.4-ti$
Attached are the two input files located in the /src/arm/ folder.
What am I doing wrong?
Thank you,
Dusty -
Thank you Eshtaartha.
I included the osd335x-sm.dtsi file you referenced and (believe) I fixed the invalid references.
Please see error message below… did I miss something? Attached are the two input files used.
Thank you,
Dustydusty@dusty-VirtualBox:/media/dusty/rootfs/tmp/dtb-rebuilder-4.4-ti$ sudo make src/arm/WV_OSD3358-SM__066.dtb [sudo] password for dusty: DTC src/arm/WV_OSD3358-SM__066.dtb In file included from src/arm/WV_OSD3358-SM__066.dts:11:0: src/arm/osd335x-sm.dtsi:1330:10: fatal error: dt-bindings/mfd/tps65217.h: No such file or directory #include dt-bindings/mfd/tps65217.h ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. Makefile:148: recipe for target 'src/arm/WV_OSD3358-SM__066.dtb' failed make[1]: *** [src/arm/WV_OSD3358-SM__066.dtb] Error 1 Makefile:112: recipe for target 'src/arm/WV_OSD3358-SM__066.dtb' failed make: *** [src/arm/WV_OSD3358-SM__066.dtb] Error 2 dusty@dusty-VirtualBox:/media/dusty/rootfs/tmp/dtb-rebuilder-4.4-ti$ -
Dusty,
We apologize for the inconvenience. During our most recent update, we had modified all of the device tree files so that they could be built under the mainline Linux build flow. Unfortunately, we did not also make sure that they were able to be used within the dtb_rebuilder mentioned in the tutorials. We have now posted a version of the device tree files that can be used in the dtb_rebuilder. You can find them here:
https://github.com/octavosystems/OSD335x-Device-Tree
I was able to successfully build your custom device tree file (WV_OSD3358-SM__066.dts) after pairing it with the new tested .dtsi file (osd335x-sm.dtsi) and making the following changes:
a. I corrected an improper reference to “pruss” node (have added comment in file to indicate the same).
b. I commented out a reference to non-existent node “emmc_pins” (have added comment in file to indicate the same).
I was also able to login to Debian (I used the latest BeagleBoard Debian Image 9.4 LXQT) using WV_OSD3358-SM__066.dtb.
Before making further modifications to your device tree files, I would suggest building the files I’ve sent on your setup to make sure you have a good starting point.
Please let us know if you have any other questions.
-
Thank you Eshtaartha.
The PHYAD[2:0] strap-in options are set in hardware to 001b.
In the dts I have used phy addr 1 at emac0:
&mac { slaves = <1>; active_slave = <0>; // select emac0 pinctrl-names = "default", "sleep"; pinctrl-0 = <&cpsw_default>; pinctrl-1 = <&cpsw_sleep>; status = "okay"; }; &davinci_mdio { pinctrl-names = "default", "sleep"; pinctrl-0 = <&davinci_mdio_default>; pinctrl-1 = <&davinci_mdio_sleep>; status = "okay"; }; &cpsw_emac0 { phy_id = <&davinci_mdio>, <1>; // select phy address 1 phy-mode = "rgmii-txid"; };Interesting part is that the PHY seems to be detected
[ 1.107314] davinci_mdio 4a101000.mdio: davinci mdio revision 1.6, bus freq 1000000 [ 1.107330] davinci_mdio 4a101000.mdio: detected phy mask fffffffd [ 1.121731] libphy: 4a101000.mdio: probed [ 1.121760] davinci_mdio 4a101000.mdio: phy[1]: device 4a101000.mdio:01, driver Micrel KSZ9031 Gigabit PHY [ 1.122759] cpsw 4a100000.ethernet: Detected MACID = 98:5d:ad:4e:ab:fd [ 1.122867] cpsw 4a100000.ethernet: initialized cpsw ale version 1.4 [ 1.122877] cpsw 4a100000.ethernet: ALE Table size 1024 [ 1.122917] cpsw 4a100000.ethernet: cpts: overflow check period 1250 (jiffies)
but still fails to load properly
[ 9.032486] net eth0: initializing cpsw version 1.12 (0) [ 9.034143] libphy: PHY 4a101000.mdio:04 not found [ 9.055525] net eth0: phy "4a101000.mdio:04" not found on slave 0, err -19 [ 9.102887] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 12.505488] nf_conntrack version 0.5.0 (8192 buckets, 32768 max) [ 13.915683] using random self ethernet address [ 13.915703] using random host ethernet address [ 14.103888] net eth0: initializing cpsw version 1.12 (0) [ 14.105546] libphy: PHY 4a101000.mdio:04 not found [ 14.152930] using random self ethernet address [ 14.152939] using random host ethernet address [ 14.171795] net eth0: phy "4a101000.mdio:04" not found on slave 0, err -19 [ 14.261069] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
Wondering why it is trying to find the PHY at addr 4, although I have specified 1?
Since you mentioned the RED uses addr 4… following the app note, I programmed the board ID to being an Octavo Systems OSD3358-SM-RED board
AA 55 33 EE 41 33 33 35 42 4E 4C 54 4F 53 30 30 .U3.A335BNLTOS00 00 00 00 00 00 00 00 00 00 00 00 00 FF FF FF FF ................
Suspecting this to be the issue, I reprogrammed the board ID to the BeagleLogic Standalone, which uses the same PHY at the same address (https://github.com/RobertCNelson/omap-image-builder)
=> i2c md 0x50 0x00.2 20 0000: aa 55 33 ee 41 33 33 35 42 4c 47 43 30 30 30 41 .U3.A335BLGC000A
Now the boot process stalls at ‘Starting Kernel…’
U-Boot 2018.03-00002-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500), Build: jenkins-github_Bootloader-Builder-47 CPU : AM335X-GP rev 2.1 I2C: ready DRAM: 512 MiB No match for driver 'omap_hsmmc' No match for driver 'omap_hsmmc' Some drivers were not found Reset Source: Power-on reset has occurred. RTC 32KCLK Source: External. MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 Loading Environment from EXT4... ** File not found /boot/uboot.env ** ** Unable to read "/boot/uboot.env" from mmc0:1 ** Failed (-5) Model: BeagleLogic not set. Validating first E-fuse MAC Net: eth0: MII MODE Could not get PHY for cpsw: addr 0 cpsw, usb_ether Press SPACE to abort autoboot in 2 seconds board_name=[A335BLGC] ... switch to partitions #0, OK mmc0 is current device SD/MMC found on device 0 ** Bad device 0:2 0x82000000 ** ** Bad device 0:2 0x82000000 ** switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... gpio: pin 56 (gpio 56) value is 0 gpio: pin 55 (gpio 55) value is 0 gpio: pin 54 (gpio 54) value is 0 gpio: pin 53 (gpio 53) value is 1 switch to partitions #0, OK mmc0 is current device gpio: pin 54 (gpio 54) value is 1 Checking for: /uEnv.txt ... Checking for: /boot.scr ... Checking for: /boot/boot.scr ... Checking for: /boot/uEnv.txt ... gpio: pin 55 (gpio 55) value is 1 2107 bytes read in 42 ms (48.8 KiB/s) Loaded environment from /boot/uEnv.txt debug: [dtb=WV_OSD3358-SM__066.dtb] ... Using: dtb=WV_OSD3358-SM__066.dtb ... Checking if uname_r is set in /boot/uEnv.txt... gpio: pin 56 (gpio 56) value is 1 Running uname_boot ... loading /boot/vmlinuz-4.14.49-ti-r54 ... 10453504 bytes read in 691 ms (14.4 MiB/s) loading /boot/dtbs/4.14.49-ti-r54/WV_OSD3358-SM__066.dtb ... 51190 bytes read in 155 ms (322.3 KiB/s) uboot_overlays: [fdt_buffer=0x60000] ... uboot_overlays: loading /lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo ... 3513 bytes read in 323 ms (9.8 KiB/s) loading /boot/initrd.img-4.14.49-ti-r54 ... 4034122 bytes read in 293 ms (13.1 MiB/s) debug: [console=ttyO4,115200n8 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet] ... debug: [bootz 0x82000000 0x88080000:3d8e4a 88000000] ... ## Flattened Device Tree blob at 88000000 Booting using the fdt blob at 0x88000000 Loading Ramdisk to 8fc27000, end 8ffffe4a ... OK reserving fdt memory region: addr=88000000 size=6e000 Loading Device Tree to 8fbb6000, end 8fc26fff ... OK Starting kernel ...
If I abort autoboot, I can talk to the PHY at address 1 through mii commands so I don’t suspect an MDIO issue talking to the PHY.
Can the board ID be the problem?
Thank you again,
Dusty
-
- You must be logged in to reply to this topic.