[Neeraj Kumar Reddy Dantu]

Memaher,

The default behavior of Beagle u-boot is to check the EEPROM first, select the device tree based on the ID and then over ride that selection based on the variable set in uEnv.txt. You can see this behavior in the OSD3358-SM-RED image we host on the website.

We believe that the multiple boot sources and uEnv.txt files that are being sourced could be causing the overrides. We have verified that modifying /boot/uEnv.txt with the correct ‘dtb’ variable name(and corresponding dtb file sitting in /boot/dtbs/[kernel version]) and commenting out everything else in the file did not load any device tree overlays on the latest Beagle image (9.9).

Please let us know if you need further assistance.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Memaher,

From the logs it looks like the following is happening:

1. Processor recognizes MMC0 interface, presumably with the SD card as boot source

2. Check for uEnv.txt in /boot/ folder

3. Check for uEnv.txt in /(root) folder

4. Loading environment from /uEnv.txt

5. Checking for uEnv.txt again??

6. Switching to MMC1, presumable eMMC

7. Checking for /boot/uEnv.txt

8. Loaded environment from /boot/uEnv.txt on eMMC

 

Is ’emanip-arm-ctrl.dtb’ file present in /boot/dtbs/[Kernel Version]/ folder of eMMC?

 

9. Device tree is switching to dtb=am335x-boneblack-uboot-univ.dtb (line 105)

10. Loading several overlays

The questions are the following:

1. Which boot source are you intending to boot from? (SD card/eMMC) If you are booting from the eMMC, please remove the SD card

2. Which uEnv.txt file are you intending for the processor to read? Is the board reading the correct uEnv.txt file?

3. Is the Device tree file present in the correct location on the desired boot source?

You have both the values debug: ‘[enable_uboot_overlays=0] ...’ and ‘[enable_uboot_cape_universal-0] …’. You can remove all the other variables from your uEnv.txt file to remove any confusion for the processor.

Hope this helps.

Neeraj

[Neeraj Kumar Reddy Dantu]

Kartik,

We have not faced this issue with the RED board. In light of your issue, we will make a note to update the PHY RESET circuit when we Rev the board. Thanks for the inputs.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Kartik,

Based on the schematics we have, the RESET line for the PHY is pulled up to the 3.3V line. If you have a GPIO pin connection on this pin or a RESET supervisor, it would have been possible to modify software to bring the PHY out of RESET later.

So, unfortunately, we think a design change is necessary. Please let us know if you need any more help from Octavo.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

olmoDalco,

If you don’t want to program the eMMC, you don’t need to use the resources described in the Application note.

Please review the following links that describe how to use g_mass_storage to expose part of the storage as a mass storage device:

1. https://linux-sunxi.org/USB_Gadget/Mass_storage

2. https://developer.ridgerun.com/wiki/index.php?title=How_to_use_mass_storage_gadget

If you are using Beagle images, you can look into the Kernel build configuration file located in /boot/ folder to verify if g_mass_storage is built-in/module in the current kernel for the Beagle Image.

Finally, the page you linked from Digikey(https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black) shows how to build a kernel, build the kernel modules and install the kernel and modules on an SD card if you need to.

Please let us know if you have further questions.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Roger,

In addition to Eric’s inputs, if you are not planning to update the bootloader, or if you plan to make this modification for future revisions of the bootloader, there is no need to program the EEPROM.

The advantage of having the EEPROM programmed is that the board will be able to run Beagle distros out of the box, while this modification will be required if the EEPROM is not programmed.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Mat,

It would be good to verify that the correct device tree and no overlays are being loaded while booting. For this, we will have to look at logs before the kernel starts on UART0. The bootloader log will show whether any overlays are being loaded.

The logs both working and not working only show 1 Ethernet port, while you should see eth0 and eth1 come up.

Note that the PHY address for Beaglebone Black is set to 0. PHY address for the RED board is set to 4. I suspect that the device tree is not loading correctly? See model in the boot logs “[    0.000000] OF: fdt: Machine model: Octavo Systems OSD3358-SM-RED” while the string you have in your device tree is “model = “Seaeye eManip Arm controller”;”

You can also check the model name in command line: “cat /proc/device-tree/model”

Hope this helps.

Neeraj

 

 

[Neeraj Kumar Reddy Dantu]

Mat,

Can you please attach the dmesg logs for 1. when both ports come up and work and 2. Both ports do not work. You are right that the processor scans the MDIO bus to see where the PHYs are located. But, in our experience, having a wrong address in the device tree still results in the ethernet port not working.

Best,

Neeraj

 

[Neeraj Kumar Reddy Dantu]

Memaher,

As you pointed out, the MDIO probe is finding 2 PHYs, but only 1 PHY is being initialized after. This could be related to the pinmux declaration. Please let us know how the system behaves after the device tree updates.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

MC,

Thanks for the update.

We came over some interesting discussion on this issue: https://lists.gt.net/linux/kernel/2352859. The discussion does seem to indicate a limitation as to the handling capability of the UART interface at higher speeds.

As the USB interface can handle much higher data rates, the CPU is not being tasked as much. Glad you were able to find a solution that works.

Please let us know if you have more questions.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

MC,

Please accept my apologies for this delayed reply.

Coming to the issue at hand, the screenshot attached indicates a number of kworker threads indicating internal kernel activity that may/may not be related to the UART transfers. Have you tried to alter the test parameters such as speed/period to see how it effects the CPU usage?

It is clear that the DMA is functional as the CPU activity would be way higher for the test parameters. Can you provide an update here on the issue?

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Mnagibulla,

This is interesting. The SYSBOOT configuration looks fine. Is there anything else on the LCD interface? The theory being the BOOT configuration is not being latched properly.

If that is not the case, we might have to take a closer look at your rev 2 and 3 schematics. Please contact our sales manager at martin.burgos(at)octavosystems.com.

Finally, are you seeing this issue on more than one board?

Neeraj

[Neeraj Kumar Reddy Dantu]

olmoDalco,

Apologies for the delayed response here.

Please take a look at the application note: https://octavosystems.com/app_notes/programming-emmc-with-usb/ which describes the process of programming the on board eMMC by exposing it to a host computer as a mass storage device. The application note takes you through creating the Linux image and the script for exposing the eMMC as a mass storage device is also shown. Note that g_mass_storage module needs to be compiled into the Linux kernel being used in the image.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Ben,

We believe you have received our offline reply. For reference, inputs are also provided below:

The delay is being caused because the Gigabit Ethernet PHY is taking too long for auto-negotiation during boot up. Setting the PHY to boot in 10/100MBit mode allows the PHY to be configured correctly from the get go so it can transmit packets as instructed by the ROM code. You could verify this by holding the processor in reset for a while after applying power and then looking at the Ethernet activity to see if there is a BOOTP request from the already configured Ethernet PHY.

Please let us know if you have additional questions.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Slisgrinder,

We apologize for the delayed response. Can you compare ‘dmesg’ output logs between a good ethernet configuration and a bad ethernet configuration? Specifically, look at the MDIO address of the PHY detected when the processor probes the MDIO interface and verify whether that address matches with the hardware address being set in the PHY circuit.

Another issue can be the the PHY is being brought out of reset prematurely. You could try and hold the PHY in reset for a longer period of time during boot up and see if that helps.

We would also advise you to compare your design with the known good working RED board(as you are using the same Ethernet PHY: https://octavosystems.com/octavo_products/osd3358-sm-red/)

The errata 1.0.23 seems to indicate that the CPSW peripheral reset cannot be isolated from the processor reset. As such, it is unrelated to the issue you are seeing.

Please let us know how the debug is going or if you have additional questions.

Best,

Neeraj

[Author]

Posts