[Neeraj 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 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 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 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 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 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 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 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 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 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 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

[Neeraj Dantu]

Mnagibulla,

We apologize for the delayed response. Can you please check when the 24HMz clock signal comes up in relation to the power rails? We suspect a delay in the clock signal could be holding up the processor from booting.

Another thing to check is the boot mode configuration(See Table 26-7 of the AM335x Technical Reference Manual: https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf) The device may be getting ‘stuck’ in a boot source that has precedence over UART/MMC. If you can, please verify the SYSBOOT configuration and post here.

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

Best,

Neeraj.

[Neeraj Dantu]

Hey Memaher,

A couple of changes are suggested for the device tree attached: emanip-arm-ctrl.txt.

1. pinctrl-names ‘default’ and ‘sleep’ are defined but ‘sleep’ pin mux definitions are not linked in the @mac node.

2. The pin mux definitions in ‘mii_pins_default‘ set the pins for GMII and RGMII modes instead of the MII mode that they need to be set to

3. This is more of a clean up action, but please get rid of the pinmux nodes that are not being used for clarity.

These changes might fix the issues you are having. In case they do not, please attach a complete log output of dmesg(failed upload in your last post) so that we can examine how the processor is probing the PHYs and initializing the interfaces

In addition, note that only 1 1.5K pull-up is enough on MDIO_DATA and 2 pull-ups in parallel could be stronger than necessary,

Hope this helps. Please let us know how your debug goes.

Neeraj

[Neeraj Dantu]

Thanks for the update!

Neeraj

[Neeraj Dantu]

Aliberal,

You are right, the current version of the cube-MX does not generate a GPIO specific pinctlr node. Instead, the generated device tree files include the https://github.com/STMicroelectronics/linux/blob/v4.19-stm32mp/arch/arm/boot/dts/stm32mp157-pinctrl.dtsi. So, you will have to edit this file to set the pin multiplexing for GPIO.

ST has iterated the tool a couple of times since the release of the MP1 and we noticed that they are adding additional features. We assume the MX tool is still getting worked on to make the generation of the device trees more specific. We will forward this feedback to the ST team.

Best,

Neeraj

[Author]

Posts