[Neeraj Dantu]

Aleix,

The flasher script should copy all the contents of the SD card to the eMMC. If you can verify activity on the eMMC interface by probing the CMD and CLK lines of the MMC1 interface, that would confirm that the board is trying to boot from the eMMC.

Another thing to verify is whether the eMMC is flashed. You can boot from the SD card and mount the eMMC to browse and verify the right root file system.

Based on your description of nothing on the UART0(normally, if the processor does not find a boot source it will print “CCCC” on UART0 console), it looks like the unpatched(without your updates for disabling the RTC) version of u-boot is getting executed. I know you mentioned that you overwrote the u-boot multiple times manually. One thing you can try is to erase the blocks of eMMC that contain the u-boot as described in “Erase partition table/labels on microSD card:”(needs to be done to the eMMC instead of the SD card) in https://eewiki.net/display/linuxonarm/BeagleBone+Black and then flash the eMMC using the updated SD card you have.

Hope this helps. Please let us know if you have any updates.

Best,

Neeraj

[Neeraj Dantu]

memaher,

The pinmux tool generates a device tree include file that only sets the pin multiplexing for the pins.  This file can be included in the device tree source file for the board. You just have to fill out the incomplete structures in the source include file that the pinmux tool generated and make sure that all the correct pins are being grouped appropriately to be referenced in the peripheral node.

In the device tree for the OSD3358-SM-RED, this pinmux setting is done as part of the board device tree source file. Note that the device tree file de-references the am33xx_pinmux node here: https://github.com/octavosystems/OSD335x-Device-Tree/blob/master/OSD3358-SM-RED/osd3358-bsm-refdesign.dts#L165 and sets up the hardware pin multiplexing similar to the output of the pinmux tool.

Using the source include or making the hardware pin multiplexing part of the source file for the board are both valid ways to go about getting a device tree together. If you are starting with the osd3358-bsm-refdesign.dts and want to  use the source include file generated by the pinmux tool, you can include the file in your device tree source file, delete the reference to am33xx_pinmux node in the osd3358-bsm-refdesing.dts and make sure the appropriate pinmux nodes(from the source include file generated by pinmux tool) are referenced in the peripheral initialization nodes.

[Neeraj Dantu]

memaher,

Just like the power up sequencing, there is a shutdown power sequencing when the system shuts down. By default, this sequence follows the reverse order of the power-up sequence(see section 8.3.1.2 of PMIC datasheet: http://www.ti.com/lit/ds/symlink/tps65217.pdf). For specific power up sequence for TPS65217C see section 10 in this application note: http://www.ti.com/lit/ug/slvu551i/slvu551i.pdf.

As you can see from the above documents, the first two steps of the power up sequence are that the PWR_EN which is an input to the PMIC is asserted after RTC subsystem is powered. In a power down sequence, PWR_EN would be pulled low by the processor after which SYS_RTC_1P8V would go down.  So, PMIC_POWER_EN(N10) can be monitored to know when the processor is de-asserting this signal to know when the shutdown has occurred. As this is the last action that will be taken by the processor, this would be the moment of powerdown as you describe it.

Best,

Neeraj

[Neeraj Dantu]

DanG,

First, please make sure that the schematic circuit for USB is correct. Examples for USB host and client can be found in the reference design: https://octavosystems.com/docs/osd3358-sm-red-schematics-pdf/ . Design files(EAGLE) are also available on https://octavosystems.com/octavo_products/osd3358-sm-red/ .

From the files that you attached, looks like there USB storage(for host mode) has not been enabled in kernel config: “# CONFIG_USB_STORAGE is not set”.  The default device tree for 4.19 should work as it includes structures for USB. Please change the kernel config to enable mass storage and see if that works.

For additional info on USB kernel configuration, please see:

1. http://processors.wiki.ti.com/index.php/AM335x_USB_Driver%27s_Guide

2. http://processors.wiki.ti.com/index.php/UsbgeneralpageLinux-v3p1

Hope that helps.

Best,

Neeraj

[Neeraj Dantu]

Willis,

You should be able to use images on Beagleboard.org on the RED board. Please make sure that the image boots with the RED device tree for proper board configuration

Best,

Neeraj

[Neeraj Dantu]

Samy,

CEC is currently not supported on the RED board. However, all the hardware including the 12MHz oscillator and signal interfacing between the framer/processor/port is present on board.

tda998x driver(https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/i2c/tda998x_drv.c) seems to support the CEC functionality. Device tree bindings are given here: https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/display/bridge/tda998x.txt

If you can modify the OSD3358-SM-RED device tree(https://github.com/octavosystems/OSD335x-Device-Tree/blob/master/OSD3358-SM-RED/osd3358-bsm-refdesign.dts) to include GPMC_A9 as interrupt, that should work in principle. We have not tried this.

Best,

Neeraj

[Neeraj Dantu]

Great and thanks for sharing the guide with the community! This is much appreciated

Coming to the eMMC booting issue, the first thing to check is the boot configuration resisters. LCD_DATA[4:0] are latched during boot sequence to determine which interfaces need to be probed for the second stage bootloader(SPL) and in what order. See table 26-7 in TRM(https://www.ti.com/lit/ug/spruh73p/spruh73p.pdf) for boot sequence on each setting.

In your design, if OSD_BOOT_SD# is being pulled low, the boot sequence would not include MMC1 which is the interface the eMMC is on. This might result in the RBL(ROM Bootloader) not checking the eMMC for SPL. So, please make sure that T2 is not ON pulling the LCD_DATA2 signal LOW.

Hope that helps. Keep us updated!

Best,

Neeraj

[Neeraj Dantu]

Replied offline. Copying here for reference:

The include file is available in Octavo’s official device tree git repository: https://github.com/octavosystems/OSD335x-Device-Tree. This should have been pointed out in the tutorial. Thank you for letting us know. We will make a change in the tutorial.

Please see https://github.com/octavosystems/OSD335x-Device-Tree/blob/master/OSD3358-SM-RED/osd3358-bsm-refdesign.dts for an example of a device tree(.dts) file. As you can see in this file, ‘#include “osd335x-sm.dtsi”‘ works as intended and dtb-rebuilder does not give any errors. Please use the dtb-rebuilder to build your device tree binary as that is a method we have tested and is proven to be working.

The first thing to verify is whether the setup is correct. You already have the dtb-rebuilder cloned. Here are the steps to build the device tree for OSD3358-SM-RED to verify whether the setup is good(Note that these steps are executed on an OSD3358-SM-RED or an AM335x development/evaluation board):

1. Copy osd3358-bsm-refdesign.dts(https://github.com/octavosystems/OSD335x-Device-Tree/blob/master/OSD3358-SM-RED/osd3358-bsm-refdesign.dts) and osd335x-sm.dtsi(https://github.com/octavosystems/OSD335x-Device-Tree/blob/master/osd335x-sm.dtsi) to dtb-rebuilder/src/arm directory.

2. Change directory to dtb-rebuilder from current directory(please edit this command as required): cd dtb-rebuilder/

3. Clean earlier builds: make clean

4. Build all device tree blobs: make all

If this is successful and builds osd3358-bsm-refdesign.dtb, now copy the device tree file that you are intending to compile in dtb-rebuilder/src/arm directory. Then execute steps 2,3 and 4.

If it gives you a syntax error, please look at the exact line it is giving you an error on. The error must specify an line number at which the error has occurred. “Error: am335x-evm.dts:10.1-9 syntax error” indicates an error in line 10.

As long as the dtc version is the same, both 4.14 and 4.9(https://github.com/RobertCNelson/dtb-rebuilder/tree/4.9.x) versions of the dtb-rebuilders should work.

If you are still facing issues, please send us the exact error message and the device tree file you are using in order for us to take a closer look.

Best,

Neeraj

 

[Neeraj Dantu]

Aleix,

Please find it attached here
[Update] Looks like the file is too big. Google Drive link instead: https://drive.google.com/open?id=1zVDnXMCFixzQWZXQgELNrt6Ysjj0UfVp

Best,

Neeraj

• This reply was modified 5 years, 10 months ago by Neeraj Dantu.

[Neeraj Dantu]

Willis,

You should be able to enable capes by editing /boot/uEnv.txt file.

If you haven’t already, you can enable overlays by uncommenting the line “enable_uboot_overlays=1”. Then, each overlay can be invoked by editing “#uboot_overlay_addrx=/lib/firmware/<file0>.dtbo”. Note that you will have to disable cape_universal by commenting the line “enable_uboot_cape_universal=1” to disable the universal cape that gets loaded automatically and may conflict with overlays you are invoking.

Best,

Neeraj

[Neeraj Dantu]

Aleix,

Good to hear on getting the board to boot!

Based on your post and the schematics/layout we have, it doesn’t look like there is anything wrong. Some inputs on debug:

1. Check for any shorts on the SDIO and UART/BT data lines. It looks like the driver comes up and the kernel modules are inserted. But, WL_EN goes low and that could be because the processor could not load proper firmware for the module.

2. Check the part orientation on MOD1(WL1831). Pin 1 should be on the lower right corner of the module.

3. Since you are using the WL1831 as opposed to WL1835 on the Beaglebone Blue, you might have to change the compatibility string in the device tree(https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/net/wireless/ti%2Cwlcore.txt). There were no firmware loading differences that we could notice in /lib/firmware/ti-connectivity for different modules, but the HCI command timeouts are suspicious.

4. I was able to build the device tree without issue on a Beaglebone Blue. Note that you will need dtb-rebuilder version 4.9 vs master(4.14): https://github.com/RobertCNelson/dtb-rebuilder/tree/4.9-ti

 

Coming to the cellular modem, relevant boot message: “[    3.487453] usb 1-1: device descriptor read/64, error -71”. This indicates that the module did not respond to USB enumeration. Please verify voltages on the module and make sure that it is not being held under reset. In particular, +3V3_CELL needs to be ~3.8V. As you have access to SARA_RESET and SARA_POWER_ON, you could try and reset the module manually to see if it comes up.

Hope this helps, as always, let us know if you have an update.

Best,

Neeraj

 

[Neeraj Dantu]

Aleix,

Thanks for the update. This is great progress!

Since you have the RTC subsystem disabled, you will need to stop the kernel from initializing the subsystem also. This can be done through device tree. Please take a look at related thread on TI forums: https://e2e.ti.com/support/processors/f/791/t/485319?AM335x-RTC-disable-mode-SW-setting

It would be good to start to disable the RTC via device tree first to see if it works. For the device tree that you are using: am335x-boneblack.dtb(https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-boneblack.dts) RTC node is referenced in am33xx.dtsi, am335x-boneblack-common.dtsi(https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-boneblack-common.dtsi) and am335x-bone-common.dtsi(https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-bone-common.dtsi). You can remove the rtc node references in bone-common.dtsi and boneblack-common.dtsi and disable the rtc node in am33xx.dtsi. You will have to rebuild the device tree and replace the one in the file system on the SD card you are using to boot.

For further information on device tree and how to modify and rebuild a custom device tree, see: https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/. The tool used: https://github.com/RobertCNelson/dtb-rebuilder

Another change you can make is to remove “quiet” argument from the ‘console’ environment variable defined in /boot/uEnv.txt. This will give you more verbose kernel debug messages on the UART console.

Hope this helps. Please let us know if you have an update.

Best,

Neeraj

[Neeraj Dantu]

Thank you for the documentation!

Best,

Neeraj

[Neeraj Dantu]

Thanks Stefan! We will forward your feedback.

Best,

Neeraj

[Neeraj Dantu]

Willis,

There was most likely an issue with a driver instantiation or peripheral definition in the device tree overlay.

If you have a USB to UART converter cable, you can use a serial terminal application like Putty on your computer to look at the boot messages and determine where the board is getting stuck.

The procedure to boot from the SD card interface and flash the eMMC is described in https://octavosystems.com/forums/topic/flash-the-emmc-of-the-octavo-red/. If you want to recover from the error with the device tree overlay without loosing your files in the eMMC, you would have to boot from the SD card, mount the eMMC and edit the boot/uEnv.txt file to disable the problematic device tree overlay by commenting the line in which it is assigned to uboot_overlay_addrx.

Hope that helps.

Best,

Neeraj

[Author]

Posts