[Erik Welsh]

Dave,

Glad you were able to figure out and work around the issue.

Yes, approximately 2.9V is reasonable for the voltage on the input line with a 100K pull up. If you look at the DC Electrical Characteristics of the AM3358 for “All other LVCMOS pins (VDDSHVx = 3.3 V; x = 1 to 6)” (See page 91 of the AM3358 datasheet, http://www.ti.com/lit/ds/symlink/am3358.pdf), you can see that Input leakage current and Ioz are both a max of 18uA.  Based on the voltage drop and the pullup resistance, you can see that there is about 4uA of current being consumed which is well within these leakage current limits.

You will see this same behavior on the OSD3358-SM-RED.

Thanks,

Erik

[Erik Welsh]

Mario,

You are correct. The above scheme with the secure NOR does not provide security against physical attacks.

One way you can counter replacing a HS device with a GP device is to use encryption on a portion or all of the boot image with a secret known only to the device. Therefore, the boot image not only has to be authenticated but also some of it must be decrypted in order to be executed. If you are interested in security, there are a number of different books and websites on the fundamentals of encryption, authentication, etc. that are very interesting. It is a fun topic to dive into.

[Erik Welsh]

Mario,

Unfortunately, we do not offer a high-secure variant of the OSD335x.   The AM335x inside the OSD335x family is a general purpose (GP) processor and does not support the TI secure boot flow nor the Trustzone extensions within the Cortex A8.  In order to achieve secure boot, you must have external circuitry, i.e. a TPM (Trusted Platform Module) and secure NOR flash.  You can find these components on the OSD3358-SM-RED (https://octavosystems.com/octavo_products/osd3358-sm-red/).

If you look at the AM335x Linux boot process (https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/osd335x-lesson-2-linux-boot-process-with-the-osd335x/), you can see that there are 4 main components: ROM Bootloader, Secondary Program Loader (SPL), U-Boot, and Linux kernel.  Given that the ROM bootloader is read-only and cannot be modified, from a security perspective, you only need to validate the integrity of the other pieces (depending on the application, you may or may not want to verify the integrity of the file system or a piece of the file system).  Unfortunately, the ROM Bootloader does not perform an integrity check (i.e. signature verification) of the SPL.  Therefore, in order to have a hardware-based root of trust, you must make the SPL read-only and un-modifiable. The easiest way to do this is to use a small SPI based flash that has a one time, non-reversable lock, which is what has been included on the OSD3358-SM-RED board (see the “Security and write protection” sections of the flash memory datatsheet). Once the SPL has verified the integrity of U-Boot using the TPM to verify the signature, you can use a secure version of U-Boot to continue the chain of trust for secure boot.

 

In general, microSD/SD cards are not flexible enough to implement the above scheme. However, if you are able to make the entire microSD card un-modifiable (i.e. write protected) and only use a RAM disk or a secondary memory for things that need to be written, then you would not need to implement the SPL in the SPI boot flash. A couple of resources that you can look at to help with secure boot:

 

TPM datasheet and capabilities:

• http://ww1.microchip.com/downloads/en/DeviceDoc/Atmel-8883S-TPM-AT97SC3205T-Datasheet-Summary.pdf  
• https://csrc.nist.gov/csrc/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp2014.pdf

BeagleBone CryptoCape:

• https://www.sparkfun.com/products/retired/12773  (see Documents section)
• https://cryptotronix.com/products/cryptocape/

Secure U-Boot:

• https://github.com/theopolis/u-boot-sboot 

Cryptographic cores within the AM335x:

• http://processors.wiki.ti.com/index.php/Cryptography_Users_Guide
• http://processors.wiki.ti.com/index.php/AM335x_Crypto_Performance
• https://datko.net/2013/10/03/howto_crypto_beaglebone_black/?

Blogs describing process of securing U-Boot:

• https://prosauce.org/blog/2013/2/11/embedded-trust-p2-u-boot-secured-boot.html

 

[Erik Welsh]

That component looks like it will work. Just make sure that your design follows the guidelines outlined in the app note referenced above.

[Erik Welsh]

The OSD3358-SM-RED board uses a standard 153 ball eMMC (11.5mm x 13mm). While it might be hard to source the exact part number, you can always swap it with footprint compatible eMMC parts that can be found at the major distributors (Arrow, Mouser, DigiKey, or Avnet). The only caveats are: 1) make sure that the part uses the 153 ball eMMC footprint and not the 169 or 100 pin footprints; 2) make sure that you have done the necessary things in layout to support the newer eMMC versions (this was not done on the OSD3358-SM-RED layout but will be done on the next revision of the board). See the Designing for Flexibility around eMMC app note for more information.

[Erik Welsh]

We had the same issue with the APX811 datasheet.  The typical application circuit in the APX811 implies an internal pull-up resistor, but the datasheet never explicitly says that there is an internal pull-up resistor, nor does it list its value.  However, the APX811/APX812 is a footprint compatible replacement for the MAX811/MAX812  (https://datasheets.maximintegrated.com/en/ds/MAX811-MAX812T.pdf) which does list an internal pull-up resistance on the MR# pin of 20kOhms.  Since the APX811 was a cheaper part than the MAX811, we purchased a part and measured the resistance between MR# and VCC and found it was approximately 20kOhms.  Therefore, we felt confident using that part as the reset supervisor but we included the note in the reference design schematics since the APX811 datasheet was not explicit about the pull-up resistor.

[Erik Welsh]

Table 2.1 of the OSD335x-SM datasheet describes the passive components that are contained within the SiP that you need to be aware of from a design perspective.  This is not the recommended amount of capacitance on the given pin but the amount of capacitance that is already there.

The amount of additional capacitance that you add to your input and output power rails depends on your design.  For example, the OSD335x-SM-RED design adds a number of components for input power protection as well as a large capacitor in case of power stability issues from the AC adapter.  You need to have stable power planes so add bulk capacitance to places where you feel you need additional help to make sure that you maintain stable power planes.

[Erik Welsh]

If you look at the TI Pinmux Tool (https://dev.ti.com/pinmux/app.html), you can see that the IO Sets for

DCAN0 (TX/RX):

• gmii1_txd3/gmii1_txd2
• uart0_rxd/uart0_txd
• uart1_ctsn/uart1_rtsn

DCAN1 (TX/RX):

• uart0_ctsn/uart0_rtsn
• uart1_rxd/uart1_txd
• mmc0_clk/mmc0_cmd

From this, you can see that you can get both DCAN peripherals by using all of UART1, all of UART0, or some of the MII1 and MMC0 pins.  Given you need UART0 for the Linux console, then you can use UART1.  If you still need to use the MII1 pins for the DCAN, then you can use MII2 peripheral, which uses the GPMC_A0 – GPMC_A11 pins, for Ethernet.

In order to make everything work under Linux, you will need to modify the device tree to configure the correct peripherals.  Also, be careful about the IO Sets for each peripheral.  Even though a peripheral may be muxed to many pins, not all combinations of pins are legal.  You can use the TI Pinmux tool to understand the IO Sets associated with each peripheral.  Then for the OSD335x-SM, you will need to map the pin numbers in the Pinmux tool using the pin mapping guide: https://octavosystems.com/app_notes/osd335x-family-pin-assignments/

[Erik Welsh]

The values in the datasheet are the current that you can use externally. We de-rate the LDOs from the PMIC for the current that we use within the SiP. Also, from the other response, you can see the discussion about SYS_VDD2_3P3V.

[Erik Welsh]

Calvin,

Thanks.  When we did the production run our manufacturer swapped those out with the black ones.  Same functionality but I agree that the green ones look cooler 🙂

Erik

[Erik Welsh]

Unfortunately, the TL5209 cannot be disabled in either the OSD335x or OSD335x-SM. The LDO enable is tied high internally within the SiP. We will look to address this type of issue in future products.

Thanks.

[Erik Welsh]

For SYS_VDD3_3P3V, we purposefully spec’d a lower output current than LDO4 can supply due to the fact that it will primarily be used to supply current for the VDDSHVx pins. The 50mA is what can be used externally when the rail is supplying all of the I/O voltage pins. If you plan to use 1.8V I/O and instead supply the VDDSHVx pins using SYS_VDD_1P8V, then you can increase the external current supplied by SYS_VDD3_3P3V. However, that rail is used internally for I/O voltages that must be 3.3V so that maximum draw can only be up to 350mA given that all the VDDSHVx pins are supplied using SYS_VDD_1P8V.

The reason that there are a lot more balls for SYS_VDD3_3P3V is to make connecting the VDDSHVx pins easy. See section 3.7 of the Layout Guide for more information.

For SYS_VDD2_3P3V, that is a typo. In our testing, that rail has margin to supply 150mA but the datasheet should read 100mA. Thanks for catching that.

[Erik Welsh]

Colby,

Thanks for the feedback.  What web browser were you using so we can make sure to add that to our future testing.

Thanks,
Erik

[Author]

Posts