[Neeraj Dantu]

Dman,

The boot mode configuration on the LCD pins is only relevant at boot. You can use the LCD pins as GPIOs during u-boot to set that pin the LOW. This would allow the flasher script to program the EEPROM.

You can also modify check_eeprom function in /opt/scripts/tools/eMMC/functions.sh to ignore the blank EEPROM. The function is called from /opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh script.

Best,

Neeraj

[Neeraj Dantu]

Hey Vinay,

Here are some inputs to resolve the issues:

1. Using the flasher image: The u-boot in the flasher image checks for the EEPROM ID in the EEPROM. If it doesn’t find a valid EEPROM ID, it will try to write a valid ID to the EEPROM and reset itself(reboot). So, the next time u-boot is loaded and executed, it should find the valid ID that was written the previous time. This however will not happen if EEPROM_WP(Write protect) pin is not grounded. The EEPROM_WP pin must be grounded in order to write anything to the EEPROM. Any write without this connection will fail, resulting in no EEPROM ID in the EEPROM and therefore an infinite loop u-boot.

2. Using the flashing script: From the log, this seems to be the same problem.

Checking for Valid bbb-eeprom header
==> Invalid EEPROM header detected
===> Writing header to EEPROM
0+1 records in
0+1 records out
27 bytes copied, 0.00524933 s, 5.1 kB/s
===> eeprom check: [\FF\FF\FF]
========================================
Failed to read reboot parameter file: No such file or directory
Rebooting.

If you connect the EEPROM_WP to GND, this should resolve both the issues.

 

Best,

Neeraj

[Neeraj Dantu]

Hey Deus,

Thanks for the detailed description. An interesting related post on TI forums: https://e2e.ti.com/support/processors/f/791/t/333494#pi320966=1

The description presents a scenario where there can be out of order CAN frames as they are read by the processor.

There are other references in the driver that indicate that out of order reading of frames could happen: https://github.com/torvalds/linux/blob/master/drivers/net/can/c_can/c_can.c#L857

I would suggest trying a lower speed(500K) to see if the issue persists as high utilization has been linked to this behavior. Another way to solve the issue would be to use a DMA. It looks like from Table 11-24 in AM335x TRM that DCAN1 can utilize the EDMA(https://elinux.org/images/6/65/Spruh73c.pdf). But, there is currently no reference to DMA in the CAN driver code. So, it would likely require a device tree + driver modification

The performance is likely a result of frequency of interrupt generation and servicing. Can you check dmesg CAN driver messages to indicate any bad initialization such as described in https://e2e.ti.com/support/legacy_forums/embedded/linux/f/354/t/370865?AM335x-DCAN-High-load-of-CPU?

Neeraj

[Neeraj Dantu]

Hey Verseau,

I was able to verify the Cube Programmer 2.2 (screenshotted) works for OSD32MP1 with no issues. Your hardware configuration seems to be correct. ST team suggests that you “sanity check” the setup with a STM32MP1-DK2 board.

There could be other hardware differences between the DK-2 and your custom board that could be causing the failure to flash like the HSE frequency. If you are still unable to resolve the issue, please contact our sales as we would have to take a closer look at your schematics. You can contact our Sales Manager Martin Burgos at martin.burgos(at)octavosystems.com

Thanks,

Neeraj

[Neeraj Dantu]

Looks great! Thanks for all the updates!!

Neeraj

[Neeraj Dantu]

Verseau,

A couple of things to check:

1. Size and type of SD card: I am not sure what size the SD card you are trying to flash is. If you have a 16GB card, please try using that. Also, please try a couple of different cards to see if there is an issue with the SD card itself.

2. Which MMC interface is the SD card connected to and does your board make use of the same pins as the DK-2 board? Note that there are several (.tsv) files for several types of storage devices such as eMMC, NOR, NAND etc.

Please let us know whether you are able to resolve this issue.

Best,

Neeraj

 

[Neeraj Dantu]

Sktz,

As described in the layout guide: https://octavosystems.com/app_notes/osd335x-c-sip-layout-guide/, the landing pad size is 0.5mm.

Thank you for pointing it out that the Altium symbol has a different landing pad size. We will rectify that ASAP.

best,

Neeraj

[Neeraj Dantu]

Olmo,

 

Thank you for getting back to us on the forum! I am glad you got the mass storage utility to work. We would very much appreciate it if you could post the procedure you followed on this thread.

Thank you very much for your efforts.

Best,

Neeraj

[Neeraj Dantu]

April,

Using bone-pinmux-helper could be used as a possible fix to the issue. Please also take a look at gpio sysfs(https://www.kernel.org/doc/Documentation/gpio/sysfs.txt) for a user space solution to the issue. You will not have to use the gpio0 node definition/device tree entry for this method.

I was able to replicate the issue on the RED board. This error is caused by the definition and claiming of the GPIO0 pins in the gpio0 node which includes the MMC0_CD pin(SPI0_CS1 – C14). This pin belonging to GPIO0 bank is used for card detection by the MMC driver. Somehow the GPIO driver is taking over this pin and as a result, the SD card interface(MMC0) interface is not being detected by the kernel. This results in the eMMC being declared as the MMC0 interface in the kernel(working configuration is MMC0=SD card, MMC1=eMMC). The u-boot however thinks the eMMC interface is MMC1 because it declared the SD card interface as MMC0. So, u-boot passes ‘root=/dev/mmcblk1p1’ as the parameter for root file system in the ‘bootargs’ environmental variable, which does not exist anymore and needs to be mmcblk0p1. So, the kernel fails to find the root file system and hangs.

Hopefully, my explanation made sense. Using sysfs gpio interface should work very nicely as an alternative to control the GPIO0 pins. Please let us know if you have further questions.

Best,

Neeraj

[Neeraj Dantu]

April,

From the boot messages, it looks like the kernel is unable to find mmcblk1 which is the eMMC on the board.

One issue in the device tree you attached is that there are multiple definitions of pinmux for the same pins. For example, pinmux definitions for eMMC pins are defined in node mmc1_emmc_pins_default(356) and node emmc_pins(line 450). Please make sure that you only include pinmux definitions once to avoid conflicts.

For debug, please monitor the voltage on the power rail for the eMMC to make sure there is no drop causing the eMMC to fault. Then, take a look at what the GPIOs that you have declared are doing and if they have any conflicts such as input/output definitions with the devices they are connected to.

We have your schematics. So, we will follow up offline with specific details regarding the issue.

Best,

Neeraj

[Neeraj Dantu]

apriltesche,

Can you upload the boot message log(UART0) for when the kernel does not boot?

None of the errors you have listed are critical and should no effect main functionality of the board. Please let us know if there is a particular issue with board functionality for us to review.

Best,

Neeraj

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

[Author]

Posts