Eshtaartha Basu
Forum Replies Created
- AuthorPosts
Hello memaher,
In case of a dual ethernet design, the pin mux for both PHYs should be declared under the same phandle (&mii1n2_pins_default) instead of two separate ones.
AM335x Starter Kit reference design has Gigabit Dual Ethernet support (http://www.ti.com/tool/TMDSSK3358#technicaldocuments). It would be best if you use their device tree source file as a good functional reference while tweaking your own device tree. Their device tree source can be found here – https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/am335x-evmsk.dts. Furthermore, don’t forget to set additional properties mentioned in point 6 under section 4 of our Ethernet app note (https://octavosystems.com/app_notes/ethernet-am335x-system-in-package/) that are critical for Dual Ethernet design. Keep in mind that if your PHY is different from what is present on AM335x Starter Kit, the Mux Mode for the pins may need to be suitably changed in the pin mux depending on the mode of communication your PHY supports (MII, GMII or RGMII).
Hello willisNGC_39,
Overall, the behavior you’re seeing is intentional.
1. It says minimal…..but if used with the current Bone Debian OS 9.5 /Kernel 4.14, you do not get eth0.
[Octavo]: By “Minimal” we mean putting together only the mandatory peripherals around the SiP to boot Linux and communicate with it. Since having an Ethernet PHY is not mandatory for Linux boot, it is not included. Please refer “Figure 5 Lesson 2 complete schematic” of https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/osd335x-lesson-2-linux-bring-up/ to know more about the intended Lesson 2 hardware setup.
2. The am335x-sm.dtsi does not come with everything needed to keep eth0 active (pin configurations and definitions). I created another overlay and left it all in and when I check using ifconfig in terminal, eth0 is back.
[Octavo]: We believe you’re talking about “osd335x-sm.dtsi”. The purpose of SoC or SiP “.dtsi” files like “am33xx-dtsi” or “osd335x-sm.dtsi” is to capture all the peripherals within the SoC or SiP. However, these “dtsi” files are generic and not board specific. Hence, most of the peripherals will be “disabled” and pinmux will not be setup within these files. To describe the hardware on a specific board, it is necessary to create a main “dts” file that includes the SiP/SoC “.dtsi” file and enables board specific hardware and sets up board specific pinmux. This is what we’ve tried to explain in Section 1.3 of https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/. This is also why all Beagle device trees consist of several files instead of just one.
3. I think with the new Bone Debian, if you use a created dtb, it will not use the default dtb for am335x-boneblack.dts, am33xx-dtsi, am335x-bone-common.dtsi, or am335x-boneblack-common.dtsi when the dtb is created using make. If I simply remove my previous dtb being defined in uEnv.txt (where eth0 wasn’t present) and reboot, it reappears.
[Octavo]: This is also expected behavior common to most Beagle/RED Debian images. Configuration of “uEnv.txt” is used to override the default boot parameters in U-Boot. If no “dtb” is set in uEnv.txt, U-Boot will choose a default device tree based on board specific “Board ID” present in the EEPROM. We believe you’re using one the BeagleBone Blacks. Hence, U-Boot is recognizing the board by reading the board ID and enabling the device tree corresponding to Black. Since Black has Ethernet on-board and it is enabled in its default tree, you’re able to see “eth0” when you remove your “dtb” declaration and reboot.
We’d recommend reading the following app notes to get a better idea:
1. All the app notes under Lesson 2 (they’re in a sequence and inter-related): https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/
2. EEPROM during boot (This app note explains the role of EEPROM and Board ID during Linux boot): https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/
Hello ivan.ivanov,
The U-boot loads the appropriate linux device tree for the board based on the Board ID (also called as Magic Number) in the board’s EEPROM.
You can observe the U-boot boot messages on UART0 serial console to see which device tree was loaded. Alternatively, you can also halt U-Boot boot sequence and get into U-Boot’s command line by pressing SPACE key on the keyboard within first 2 seconds of boot. Once you get into U-Boot’s command line, type in “printenv”. This will list all the environment variables of U-Boot. These variables will help you understand how exactly U-Boot chooses different device trees based on board name.
Since OSD335x devices use the same AM335x processor that is used in BeagleBone Black, you can refer the following app notes to learn more about boot process and EEPROM:
2. https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/
Please note that this forum mainly focusses on OSD335x family on devices. Hence, for all queries that are related to BeagleBone Black, we recommend using the official BeagleBoard forum: https://groups.google.com/d/categories/beagleboard/beaglebone-black
June 20, 2019 at 10:31 am in reply to: Differences in Schematics for Connecting to WiFi Module #8485Hello ifenta,
1. The signals GPIO3-1-1v8, WL_BT_OE, DCAN1_SILENT_1V8, GPIO3_2_1V8, SPI1_SS1_1v8 are not necessary to interface Wifi module with the SM SiP. Since all the signals shown in Figure 5.17 belong to VDDSHV5 (1.8V) power domain, the signals GPIO3-1-1v8, DCAN1_SILENT_1V8, GPIO3_2_1V8, SPI1_SS1_1v8 are routed to 1.8V to 3.3V voltage level translators (U18) before being used elsewhere in the design. Similarly, WL_BT_OE is being used as an enable signal for the 1.8V to 3.3V voltage level translator (U13) of BT Audio McASPx signals.
2. Unfortunately we do not have the Eagle files because it’s not our design. Let us know when you have finalized your schematic and we’ll gladly review it to maximize your chances of first-pass success. Please work the review process through Martin Burgos and his sales team.
Hello DanG,
Thanks for pointing this out.
The pin mux of the hardware interrupt pin (GPIO3_2) was not fully initialized in the RED device tree. Since the MPU9x50 driver was not able to read any interrupt signals from the sensor module, the data was not being read into the buffer. We have fixed our device tree files to bind GPIO3_2 interrupt pin with appropriate GPIO controller (You can now see a new phandle “&ocp” under osd3358-bsm-refdesign.dts).
If you wish to use our RED image (Debian 9.1) or any custom image before Debian 9.5, use https://github.com/octavosystems/OSD335x-Device-Tree/tree/v4.9-2 device tree files
If you wish to use Debian 9.5 or later image, use https://github.com/octavosystems/OSD335x-Device-Tree/tree/4.14-2
We were able to verify the sensor data on the RED board:
# cd /sys/bus/iio/devices/iio:device1
# for en in scan_elements/*_en; do echo 1 > “$en”;done
# echo 100 > buffer/length
# echo 1 > buffer/enable
# hexdump /dev/iio\:device1Hello DanG,
Please provide a little more information so that we can help you further:
1. We assume you’re using the OSD3358-SM-RED board. Is that right?
2. Are you using the RED Debian image from our website or one of the Beagleboard images?
3. Which version of the Debian image are you using (E.g., 8.7 or 9.1 or 9.3 etc)?
4. Please provide the outputs of “uname -a” and “cat /etc/debian_version” commands.
5. It looks like your previous attachments (kernel.config and .dts file) did not get uploaded successfully due to security reasons. Please add the files to a ZIP archive and re-upload them.
JarekD,
A good way to know if the pin (GPMC_A4) is configured is to check the device tree of the Linux Image being used.
Yes, you could replace the inverter with a 0ohm jumper similar to what we have done in the RED design.
The SBC reference board was designed to mimic the BeagleBoard Black (BBB) design while using the OSD335x SiP. U6 was added to SBC design since BBB design had it. The Ball Reset Release State of GPMC_A4 is “L” (High Impedance with Active Pull Down Resistor). Hence, the inverter has been used to prevent eMMC reset after processor’s power on reset. However, since there is a 10K pull up attached to the RSTn line of the eMMC, it will override the weak internal pull down resistor of GPMC_A4 pin. Therefore, an inverter is not necessary. We have replaced the inverter with a 0ohm jumper in all our later reference designs (including the RED) for the same reason.
JarekD,
The latest eMMC 5.x standards document may not be available for free. But, all the previous versions should be available for download once you sign up for a free user account on JEDEC website.
Hello NirAlon,
Orcad Symbol Library for C-SiP is available on the C-SiP product page (https://octavosystems.com/octavo_products/osd335x-c-sip/) under “Symbols” section. Please let us know if you need anything else.
Hello NirAlon,
C-SiP Orcad symbol is still under development. We may publish it soon. Please follow our official twitter page (https://twitter.com/octavosystems) to get notifications about new symbol updates, new app notes and other supporting documentation.
- This reply was modified 5 years, 10 months ago by
Eshtaartha Basu.
Hello JarekD,
eMMC memories are less susceptible to data corruption compared to SD card due to their integrated memory controllers (load balancer). However, you may lose temporary files stored on DDR3 because of a power loss.
Please refer the following forum thread for information on using VIN_BAT for backup:
The size of the super capacitor required depends on the power consumption figures for your specific design. We have not tested any super capacitor with OSD335x. Hence, we do not recommend any particular super capacitor. We do not provide any additional hardware/software solution to prevent data corruption. As discussed in the above thread, to prevent data corruption, choose a temporary power source (super cap in your case) that could power your board long enough for it to shutdown properly after PMIC_PB_IN is asserted (due to main power loss) by an external logic.
Hello memaher,
a. can the standard battery source be used to prop the system up long enough to power down?
The TPS65217C PMIC used in OSD335x family of devices supports 1S Li-ion/Li-polymer battery. The battery life depends on the average power consumption figures for your specific design and the capacity (mAh value) of the battery chosen. In general, a 1S battery would be able to power the OSD335x long enough for shutdown.
b. any ideas on how to notify of power fail – can the PMIC signal the processor, or is this best done with external logic?
The PMIC considers the VIN_BAT input as one of its primary power inputs. VIN_BAT is not considered as a backup input. Hence, PMIC will not signal the processor when it switches from VIN_AC/VIN_USB to VIN_BAT. However, you can use an external logic to assert the power button (PMIC_PB_IN) when VIN_AC fails. MSP430FR2xxx Ultra Low Power MCU can be a good fit for low power external control logic.c. how to configure the OS to drop everytihng and power down?
You can do this by asserting the power button (PMIC_PB_IN) through an external logic. When the power button is pressed, an interrupt is sent to the processor by the PMIC. The BeagleBoard.org and RED Debian images facilitate an orderly shutdown (by default) by saving files and un-mounting drives once they receive this interrupt. Keep in mind that this is not an instant shutdown. The system will take a while to shutdown. However, you could modify how Linux interprets the interrupt from the PMIC by making suitable software modifications.Hello memaher,
Please use SYS_VDD_1P8V as the power source for silicon oscillators.
Hello JarekD,
We had not considered eMMC 5.x standard at the time of creating the RED design. RED design is not compatible with eMMC 5.x standard. However, we wrote the Designing for Flexibility around eMMC app note (https://octavosystems.com/app_notes/designing-for-flexibility-around-emmc/) to address the compatibility issues and help customers use eMMC 5.x standard in their design.
Yes, it is a good idea to follow the app note for eMMC 5.x standard.
You can find information about the latest eMMC standards on JEDEC website (https://www.jedec.org/standards-documents/technology-focus-areas/flash-memory-ssds-ufs-emmc/e-mmc). JEDEC is responsible for publishing eMMC standards.
To completely future proof your design, you can use very thin traces and route without overlapping any eMMC pads. But then, you will have to make sure your trace width and design rules are within the capabilities of your PCB manufacturer. They may charge you more for extended manufacturing (tighter design rules).
Our latest SiP, OSD335x C-SiP (https://octavosystems.com/octavo_products/osd335x-c-sip/), comes with an integrated eMMC in addition to all the features of OSD335x-SM. You can take a look at it and see if it matches your design requirements. OSD335x C-SiP should help you to easily get around eMMC sourcing and design issues.
Hello JarekD,
Thank you for catching the error in comments. Looks like this is a copy/paste error while updating the comments. We will fix it soon.
On the SBC Reference Design, SYSBOOT[5] should be pulled high (enabled) because CLKOUT1 is being used to supply clock signal to HDMI framer through a clock divider. However, on the RED design, SYSBOOT[5] should be pulled low (disabled) because an external MEMS oscillator is used to provide clock for the HDMI framer and CLKOUT1 is no longer used.
Even though some of the SYSBOOT[15:0] pins are “don’t care” for the ROM code, it is recommended to pull them up/down because all SYSBOOT values are latched into the CONTROL_STATUS register and may be used by software after ROM execution has completed. You can find a discussion on the same at TI forum:
The same information is also available under Table 26-7 (SYSBOOT Configuration Pins Notes) of AM335x TRM (SPRUH73P).
- This reply was modified 5 years, 10 months ago by
- AuthorPosts
