[Eshtaartha Basu]

Hello Dusty,

I will look into this issue and get back to you by the beginning of next week.

[Eshtaartha Basu]

Hello samy03,

We’re glad to know that you were able to fix the issue.

On an Ubuntu PC, you will have to install and configure dtc manually. We believe your original error was related to dtc path or configuration on your Ubuntu PC. But, the RED image and all BeagleBoard Debian images come preinstalled with dtc.  This is the reason you haven’t faced any dtc related issues when you switched to the RED platform.

Please let us know if you have any other questions.

[Eshtaartha Basu]

Hello Dusty,

The Board ID continues to matter as long as U-Boot is in control (i.e., even after the Board ID check). Because, the Board ID not only helps U-Boot choose the right “dtb” but also affects other U-Boot environment variables. You can understand this better if you go through the U-Boot patch code that helps you bypass Board ID check. The patches make sure U-Boot boot process continues normally even without the Board ID. From the code you should be able to infer the other uses of Board-ID:

https://rcn-ee.com/repos/git/u-boot-patches/v2018.03/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

https://rcn-ee.com/repos/git/u-boot-patches/v2018.03/0002-U-Boot-BeagleBone-Cape-Manager.patch

OSD335x EEPROM During Boot (https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/) gives you more information about the usage of the above patches.

Both BeagleBoard Debian images and TI SDK are fine for development but we do not know the status of development/support for TI SDK. But, we do know that the BeagleBoard Debian is being actively developed, maintained and supported.

 

[Eshtaartha Basu]

Hello Dusty,

It doesn’t look like there is anything wrong with your Device Tree. I think it is better if you do a clean re-build of your dtb and also re-flash your SD card and/or eMMC with a clean image and try again. If the problem persists, you can try probing the MDIO lines and observing the signals.

On researching about KSZ9031 PHY online, I found a couple of discussions of TI forum which talk about issues that are very similar to what you’re facing. Looks like many people have faced the same issue with this particular PHY:

1. https://e2e.ti.com/support/arm/sitara_arm/f/791/t/488807?Micrel-9031-on-Phy-address-0x0-is-not-working- (Pay attention go Biser Gatchev-XID’s comments)

2. https://e2e.ti.com/support/arm/sitara_arm/f/791/t/182794 (Check if any of the recommendations done by Mugunthan V N applies to your case)

This may be a reset timing issue as explained by Biser. If your current setup supports external control of PHY’s reset pin, I would suggest experimenting with it. Also, try experimenting with PHY address by changing it to 0, 2,3 or 4 (although your PHY is on 1) as done by the person from forum post (1) above.

[Eshtaartha Basu]

Hello Dusty,

You’re welcome.

Make sure there are no issues in the custom pin muxing and device tree bindings in your custom device tree. Have you checked if phy_id is correct on your device tree? Your ethernet PHY (KSZ9031) has 3 address pins: 35, 15 and 17. I don’t know what these are set to on your board. But, make sure it matches your phy_id. 

For example, in the RED device tree, phy_id is as follows:

phy_id = <&davinci_mdio>, <4>;

It is set to “4” because the phy_addr pins of our Eth PHY are set to “4” in RED hardware. Also make sure your Eth PHY is powered up properly and not held in reset.

You can also use dmesg command and kernel log ( /var/log/kern.log ) to better debug your design and quickly find the source of the problem.

 

[Eshtaartha Basu]

Hello anewcomb,

Sorry for the delay in response. The delay was due to the July 4th holiday.

The Device Tree Bindings in your Device Tree will help the Linux Kernel recognize all the available hardware on your board. Hence, it is important to make sure your device tree bindings are correct.

Please send the output of dmesg command and also the Kernel log ( /var/log/kern.log ) to help us debug the problem.

[Eshtaartha Basu]

Hello Dusty,

It is better to always keep the “dtb-rebuilder” at home directory ( /home/debian ) to avoid permission issues. The permissions on some of your files might have gotten altered when you copied dtb-rebuilder to PocketBeagle. Check the file permissions of fixdep file by running ls -l command in /dtb-rebuilder-4.4-ti/scripts/basic directory. The permissions for this file should be 755 (-rwxr-xr-x). If you have something different, change the permissions using chmod.

Also, resolve time skew warnings by running make clean command in /dtb-rebuilder-4.4-ti directory. If that doesn’t fix it, run the touch * command in the dtb-rebuilder directory and the dtb-rebuilder/src, dtb-rebuilder/src/arm sub-directories to update the file modification time of all files to resolve the warning.

[Eshtaartha Basu]

Hello Dusty,

You’re welcome. I’m glad you were able to build the device tree on your setup.

I built your dtb on my development board (OSD3358-RED) running latest Debian 9.4. I did not get any warnings. I believe your compiler version is different from mine since you’re  using dtb-rebuilder on Ubuntu.

All BeagleBoard images and RED image come with a “dtc” (Device Tree Compiler). You can find it under /usr/bin of BeagleBoard Debian image or RED image. dtb-rebuilder uses this compiler to compile your dts into dtb. I don’t know which version of dtc you’ve installed on your Ubuntu machine (Keep in mind that dtb-rebuilder does not come with a dtc).

I would recommend copying dtb-rebuilder (or you could just clone the git repo) directly to one of the directories of your dev board (hope you have one of BeagleBoards or RED board) running Debian 9.4 and building device tree files directly on the dev board as described in Device Tree article. This should resolve the warnings.

[Eshtaartha Basu]

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.

• This reply was modified 6 years, 4 months ago by Eshtaartha Basu.

Attachments:

1. YourCustomDT.zip

[Eshtaartha Basu]

Thanks Dusty. I’m currently working on resolving your issue and will get back to you shortly.

[Eshtaartha Basu]

Hello Dusty,

Could you please tell me which Debian image you’re using (RED Debian image or one of the BeagleBoard Debian images)?

This will help me use the same kernel version while debugging this problem so that I can give you the right solution.

 

[Eshtaartha Basu]

Hello Mahmoud,

 FL2400135Z looks good. You can use it as a replacement for 7A-24.000MAAJ-T.

Yes, you could use an oscillator too instead of a crystal.

Thanks for sharing your design files with us. We will review it and get back to you.

[Eshtaartha Basu]

Hello Dusty,

It looks like you’re using v4.17 OSD335x Device Tree files. These files are incompatible with v4.4 dtb-rebuilder. To get around this problem, you should use v4.4 OSD335x Device Tree files.

You can get them here: https://github.com/octavosystems/OSD335x-Device-Tree/tree/v4.4.

You can also manually navigate to this page on our Github Device Tree page by clicking on “Branches” drop down menu > Tags > v4.4. I’ll soon update the Lesson 2 webpages to directly point to this version.

While going through your device tree files, I found few other issues that you will have to fix once you get around the version problem.

1. In line 139 of WV_OSD3358-SM__066.dts, small brackets “( )” are not allowed as part of node names. This will lead to syntax error (Check Table 2.2 of Device Tree Spec v0.2 for all the allowed characters).

2. In the same file, there are references to the following non-existent nodes/labels which will lead to invalid reference error:

mmc1_pins

emmc_pins

cpsw_default

cpsw_sleep

davinci_mdio_sleep

Also, make sure all the new pin muxing nodes you’ve added are properly referenced/used by suitable nodes to make sure your hardware operates as intended.

Please let us know if you have any other questions.

[Eshtaartha Basu]

You’re welcome. Please let us know if you need any other information as you proceed with the design.

[Eshtaartha Basu]

Hello jgoodwin,

The OSD335x-SM does support RGMII. The OSD3358-SM-RED board uses the MII1 interface (in RGMII mode) of OSD335x-SM to communicate with AR8035 Gigabit Ethernet PHY.

The OSD3358-SM-RED design files are available on our website.

RED product page: https://octavosystems.com/octavo_products/osd3358-sm-red/

RED schematics: https://octavosystems.com/docs/osd3358-sm-red-schematics-pdf/

RED design files: https://octavosystems.com/files/osd3358-sm-red-eagle-files/

You can use the RED design as a reference to build your design.

NOTE: On the RED schematics, the signal names of MII1 interface match the pin names but the MII1 interface is being used in Mode 2 (RGMII). You can go through the Pin Attributes section of AM335x datasheet (http://www.ti.com/lit/ds/symlink/am3352.pdf) to know more about GPIO pin modes.

[Author]

Posts