[Neeraj Kumar Reddy Dantu]

Hey Anthony,

The error log for the dtb rebuilder indicates that there is an error in line 14 of file am33xx.dtsi. Did you change anything in this file?

Please see the device tree tutorial: https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/ and pinmux tutorial for dtb-rebuilder usage: https://octavosystems.com/app_notes/osd335x_pinmux/

Note that the USB RNDIS adapter gadget is started by a startup script: https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh and it checks for the model name “/proc/device-tree/model” against the strings here: https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L113(may vary for different Beagle images). The model is set in the device tree like: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.14-ti/src/arm/am335x-boneblack.dts#L16. If you are using a custom device tree, you may want to copy Beaglebone Black model name and compatibility string in the device tree.

For the board, if you are able to see the ethernet gadget for a little while, the board has indeed booted and is at least running the internal ROM code.

We suggest you use one of the BLANK images from Beagle from https://rcn-ee.com/rootfs/bb.org/testing/ without any patch being necessary. These images do not check for a Beagle ID in the EEPROM. For example: BBB-blank-debian-9.5-iot-armhf-2018-10-07-4gb.img.xz

You should also verify all the output voltage rails and clock on the SD card CLK line to make sure that the board is not failing and is probing the SD card for an image to boot.

Please let us know how it goes and if you have more questions.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Hey Aliberal,

The DDR type and specification used in OSD32MP1 is the same as the one on the DK2 board. So, DDR configuration for both can be interchangeable. The tuning parameters might differ a little. But, they can be easily regenerated with CubeMX DDR testing suite. We have tested the <OCATVO PART NUMBER>_MinimalConfig.ioc on a standard DK2 board and it works.

Please let us know if you have more questions.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Hi Randy,

The best way to decide would be to see if these displays have Linux drivers and whether the driver support is enabled via kernel modules in your system.

Out of the 4, it looks like ILI9327(https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/display/panel/ilitek,ili9322.txt) and HX8352(https://github.com/torvalds/linux/blob/master/Documentation/devicetree/bindings/display/himax,hx8357d.txt) have potentially compatible drivers.

You can find out if the drivers were built as kernel modules by searching the device driver specific config variable in the kernel compilation config file. This file is available in /boot/ directory for the Beagle images.

Regarding choice of display, we would suggest you look at Display capes for Beaglebone Black/Wireless such as https://4dsystems.com.au/4dcape-70t

or

https://www.mouser.com/new/newhaven-display/newhaven-beaglebone-cape/

Using existing display designs will make your prototyping much easier than bringing up a new display.

Best,

Neeraj

[Neeraj Kumar Reddy Dantu]

Thanks for the feedback! We will include the download links on the top of our article.

Best,

Neeraj

[Neeraj Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 Kumar Reddy 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 6 years ago by Neeraj Kumar Reddy Dantu.

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

 

[Author]

Posts