Hey Andy,
If you don’t specify a device tree, by default the Bealgebone black device tree will be invoked (Along with some cape overlays depending on what is in uEnv.txt).
You can eliminate the device tree as the source of the error by using the Beaglebone Black device tree.
Instead of recompiling the whole kernel building the rtc_omap driver and inserting it in run-time can cut down on the debug effort here: https://github.com/RobertCNelson/ti-linux-kernel/blob/linux-4.14.y/drivers/rtc/rtc-omap.c#L431. Adding debug messages to the ‘static void omap_rtc_poweroff’ function and dumping the registers of the RTC module along with the ‘struct rtc_time tm’ to somewhere in the SD card would help understand the state the module is in. The error is probably occurring in ‘static int tm2bcd()’ (https://github.com/RobertCNelson/ti-linux-kernel/blob/linux-4.14.y/drivers/rtc/rtc-omap.c#L273) function.
Looking at the crystal, VIH and VIL for RTC_XTAL_IN are 0.65*VDDS_RTC and 0.35*VDDS_RTC. As long as the signal is oscillating across these two voltage levels, the signal is fine. However, there are specifications for the RTC oscillator circuit in “Figure 6-13. OSC1 (ZCZ Package) Crystal Circuit Schematic” (http://www.ti.com/lit/ds/symlink/am3358.pdf). You could try experimenting with values of C1 and C2 in the figure 6-13 of the datasheet.
Thanks for documenting the steps. Looking forward to the results.
Best,
Neeraj
Hey JF,
First addressing the custom board boot, do you have your EEPROM programmed with a Beagle compatible ID? Check: https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/
There is an am335x_evm_norboot_defconfig (https://github.com/u-boot/u-boot/blob/master/configs/am335x_evm_norboot_defconfig) which has CONFIG_SPI_FLASH_WINBOND=y.
Try changing to CONFIG_SPI_FLASH_SPANSION=y and rebuild. The procedure to rebuild and replace the existing u-boot with the new u-boot is provided step-by-step here: https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black. Specifically, you will need sections ‘ARM Cross Compiler: GCC’, ‘Bootloader: U-Boot’ and first 3 steps of ‘Set up MicroSD card’
Hey JF,
Did you populate J11 to complete the electrical connections between the SPI NOR and the AM335x SPI interface? The first step would be to verify the electrical connectivity and monitor whether the communication signals are reaching the NOR flash. Once you have verified the connectivity, verifying the communication between the AM335x and the NOR flash via for example, spidev on Linux would be the next thing to do. Scoping the interface pins including for whether the chip select pin is going low, the clock is being exercised and the data is being transferred via D0 and D1 would also narrow down where the issue is.
The OSD335x integrates and exposes all the peripheral functions of the AM335x processor (Except for internal DDR). So, all the defconfigs that work with the AM335x processor should also work for OSD335x.
Andy,
While we have not used it ourselves, the DP83867 is a good candidate for a Gigabit Ethernet PHY. You can find a reference design that integrates the DP83867 and AM335x here:http://www.ti.com/tool/TIDA-00204#technicaldocuments. Documentation: http://www.ti.com/lit/ug/tidu832b/tidu832b.pdf
The schematics are also available: http://www.ti.com/lit/df/tidrdr0a/tidrdr0a.pdf
Note that AM335x supports MII, RMII and RGMII interfaces. There are other devices from Microchip(https://www.microchip.com/ParamChartSearch/chart.aspx?branchID=1635) that have good Linux support.
Best regards,
Neeraj
Andy,
Please use the version of the kernel that you are currently working with.
As mentioned earlier, you can build a Beagle image by following the steps in https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black
You can also use build environments like Buildroot and Yocto to make custom images. Buildroot is the easier option. Both of them have extensive documentation and support for AM335x. Take a look at https://e-ale.org/elc2018/ for a start.
If you programmed your EEPROM after booting up, you will not need to have the patched version of u-boot. So, you can try upgrading the bootloader to see if there is an initialization issue for the RTC subsystem.
Best,
Neeraj
Andy,
Please see https://groups.google.com/forum/#!topic/rtc-linux/yKfIpoD5gRI for the power off procedure. The RTC module is responsible for turning off the PMIC and shutting itself off.
You could add some debug statements to omap_rtc_power_off function: https://github.com/RobertCNelson/ti-linux-kernel/blob/linux-4.14.y/drivers/rtc/rtc-omap.c#L431 to get more information about what is happening.
Please also see: https://groups.google.com/forum/#!msg/beagleboard/_vZba5Qu1FY/ezoF_EsfBAAJ. May be worth a try to set the RTC module to use internal clock.
Best,
Neeraj
Andy,
Please check the interface between PMIC and AM335x is correct in your system. You can compare the connections on your board to those in OSD3358-SM-RED(Design files available here): https://octavosystems.com/octavo_products/osd3358-sm-red/.
Do you have the 32KHz oscillator for the RTC subsystem on your board? If so, please verify that there is a proper 32KHz clock input to the OSD335x from the oscillator. Similar issue resolved as faulty oscillator: https://e2e.ti.com/support/processors/f/791/t/612270?Linux-TPS65910-Kernel-panic-at-shutdown#pi239031349=3
Best,
Neeraj
The name of the product is: Sabrent USB-SBCV USB 2.0 Sound Card – Stereo
Here is a link to the project: https://beagleboard.org/p/beaglefriends-octavosystems/adding-text-to-speech-to-pocketbeagle-projects-3ab078
Best,
Neeraj
Hey Andy,
The McASP subsystem supports multiple channel outputs and is able to interface with different kinds of audio codecs. Please see(TI BSP): http://processors.wiki.ti.com/index.php/AM335x_Audio_Driver%27s_Guide. TI has several audio codecs that can work: http://www.ti.com/audio-ic/converters/codec/products.html#p1339=2;2.
Also take a look at BELA: https://github.com/BelaPlatform/Bela/wiki. It is a platform designed to be used for audio applications.
We have used USB audio cards in our projects before. They are a good way to go and definitely requiring the least amount of effort. The ALSA subsystem will be able to maintain route multiple audio channels for you. Couple of resources you could look at:
https://www.alsa-project.org/main/index.php/Documentation
https://www.tldp.org/HOWTO/pdf/Alsa-sound.pdf
Best,
Neeraj
Mario,
pruss-rproc: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am33xx-pruss-rproc.dtsi
Will fix the repo. Thanks for pointing out!
Neeraj
These are Ferrite beads that help with noise reduction on the power rail. The values depend on the board and are chosen as needed. For this particular board, we used the following components:
FB1: MPZ2012S601AT000
FB2: BLM21AG151SN1D
Hope that helps.
Best,
Neeraj
Andy,
Can you use an newer Beagle image to boot the board and see if that fixes the issue? There might be one bad process that is hanging when it is closing and that might be causing the panic. A newer kernel could have patched the bug that is causing the panic.
If you do not have a display in your system, the IOT images from Beagle’s page: https://beagleboard.org/latest-images will work better because all the GUI applications and processes are removed.
You can also build your own image. Here is a procedure to building a Beagle image: https://www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black
Best,
Neeraj
Hey T,
The following things can be implemented to achieve higher current on USB host terminal:
– Switch TPS2051 current switch as you mentioned with a switch with a higher capacity.
– You are also right that you would have to move the supply voltage rail for VBUS to an different 5V supply other than SYS.
Best,
Neeraj
Hi Steven,
Please make sure that you have the latest image on PocketBealgle. The image requirements for different clicks can be found on this page: https://github.com/beagleboard/pocketbeagle/wiki/Click-boards%E2%84%A2
All the device tree overlays reside in /lib/firmware/. So, a good way to verify the device tree overlay was invoked properly or where it failed is to go through the boot log. You can see the boot log on UART0 terminal while the board is booting or you can find it in /var/log folder.
Can you attach the boot log file here?
Thank you very much for documenting the procedure! Very helpful
Neeraj
Octavo Systems LLC all rights reserved
OCTAVO is registered in the U.S. Patent and Trademark Office. OSD, C-SiP, and the Octavo Logo are trademarks of Octavo Systems LLC.
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields
"*" indicates required fields