[Neeraj Dantu]

Gil,

You should be able to use the kirkstone patches with 5.15.67. There are not any kernel level modifications that would affect the compilation.

Best,

Neeraj

[Neeraj Dantu]

Ray,

Since the only option for MII_COL is either PA3 or PH3, it won’t be possible to add 10/100 Ethernet to the BRK. However, RGMII configuration is possible.

Best,

Neeraj

 

Adding the RGMII configuration pins:

PD24 — ETH1_MDIO

PC24 — ETH1_MDC

PD22 — ETH1_RX_DV

PC20 — ETH1_RX_CLK

PC21 — ETH1_RXD0

PC19 — ETH1_RXD1

PD21 — ETH1_RDX2

PC11 — ETH1_RXD3

PD10 — ETH1_TX_EN

PC06 — ETH1_TX_CLK

PC07 — ETH1_TXD0

PD08 — ETH1_TXD1

PD14 — ETH1_TXD2

PD07 — ETH1_TXD3

 

• This reply was modified 1 year, 1 month ago by Neeraj Dantu.

[Neeraj Dantu]

FLeblanc,

For ES parts, QSPI boot is not supported as it is a NAND SPI that Xilinx does not support. That is why you are seeing “unrecognized JEDEC id bytes”. Production parts have QSPI that is supported in Xilinx ecosystem. Please check the datasheet for the version you need as there is a 1.8V part(-xFA) and 3.3V QSPI part(-xFB).

Best,

Neeraj

[Neeraj Dantu]

Thomas,

Can you look at the power consumption of your custom board compared to PocketBeagle? My suspicion is that something getting initialized during kernel boot is drawing too much power from IO may be because of a conflict with the pin definition with Pocketbeagle.

Can you probe the levels of CLK/CMD and DATA when kernel is booting to see what IO levels they are?

Best,

Neeraj

[Neeraj Dantu]

Ryan,

Please contact sales(at)octavosystems.com for additional information on this.

Best,

Neeraj

[Neeraj Dantu]

Ryan,

The eMMC inside OSD335x C-SiP implements wear-leveling. Specifically, we ensure that the eMMC is compliant to eMMC JEDEC v4.3 or higher.

Best,

Neeraj

[Neeraj Dantu]

Thomas,

The data lines need to be pulled up to 3.3V on the MMC interface like in the Pocketbeagle for the interface to work. Do you have the pull-ups? It looks like the Pocketbeagle device tree enables the internal pull-ups on these pins: https://openbeagle.org/beagleboard/BeagleBoard-DeviceTrees/-/blob/v5.10.x-ti-unified/src/arm/am335x-pocketbeagle.dts#L238.

Can you also check voltage for VDDSHVx(SYS_VDD3_3P3V)?

Best,

Neeraj

[Neeraj Dantu]

Thomas,

Looking at the boot log:

[    1.818009] omap_gpio 44e07000.gpio: Could not set line 6 debounce to 200000 microseconds (-22)

[    1.826827] omap_hsmmc 48060000.mmc: Got CD GPIO

[    1.832087] omap_hsmmc 48060000.mmc: Linked as a consumer to regulator.1

 

It looks like the driver is running into an error setting up the card detect GPIO. Here is the GPIO bank corresponding to the driver error: https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/am33xx.dtsi#L155. You can deduce from the datasheet(https://www.ti.com/lit/ds/symlink/am3356.pdf) that SPI0_CS1 is GPIO0_6.

You mentioned that the voltage on card detect pin is not 3.3V. Is there any other circuit on this pin that could effect it?

If you have more than 1 board, please try other boards in case this is a 1 off error.

Best,

Neeraj

[Neeraj Dantu]

Thomas,

Can you check the polarity and connection for MMC0_CD(card detect pin) of the SD card interface on your custom board? I suspect the SD card detect signal is either not hooked up the same as Pocketbeagle or the polarity is reversed. See https://github.com/beagleboard/pocketbeagle/blob/master/PocketBeagle_sch.pdf for the configuration of MMC0_CD in Pocketbeagle.

Check the pin and polarity of card detect pin(‘cd-gpios’) defined in the device tree here: https://openbeagle.org/beagleboard/BeagleBoard-DeviceTrees/-/blob/v5.10.x-ti-unified/src/arm/am335x-pocketbeagle.dts#L799.

Best,

Neeraj

[Neeraj Dantu]

Eric,

Does this happen at random or all the time?

Is there additional circuitry connected to the BRK that is consuming current from the PMIC rails?

What is the environment temperature? Are you using an enclosure?

What is the current consumption of the board?

Best,

Neeraj

[Neeraj Dantu]

asd,

It seems like you found a hardware bug on the RED board. I was able to figure out the root cause after a chat with ST’s Engineer:

“TF-A is accurate when reporting the boot reason.”

This meant that NRST was being pulled LOW by another component. eMMC is the only device that has it’s RESET pin tied to NRST and it is powered by BUCK4. This is probably why if you have BUCK4 ON, you are not seeing the faulty behavior.

Once I disconnected eMMC’s RESET from NRST by cutting the trace, I was able to get the RED board into STANDBY without issue.

I was seeing variability in behavior before because I was using SD card interface to boot instead of eMMC. I suggest you use the SD card boot to work with low power modes that turn off BUCK4. I will add an issue to the design team to fix the hardware issue in the next revision.

Best,

Neeraj

[Neeraj Dantu]

asd,

Verified this behavior on RED v1.2. I will put in an issue with the software team. I suspect that it is a RED specific Debian service(weston?) that is preventing a proper enter into low power state. Please use the OpenSTLinux version to implement the deep sleep state for now. Will update here once I get an update.

Best,

Neeraj

[Neeraj Dantu]

Bow-Nan Cheng,

Internal Oscillator for PS_REF_CLK can be disabled by pulling down OSC_OE pin. PS_REF_CLK is available as package pin B26. Please see https://octavosystems.com/docs/osdzu3-ref-schematics/ for more information.

Best,

Neeraj

[Neeraj Dantu]

Simon,

The first thing to check would be if there is a back current on VDDSHV/SYS_VDD3_3P3V. This can happen if the IO of the processor are being driven/pulled-up by an external device that is still being powered after the PMIC power rails have come down. Please take a look at the power down sequencing of the PMIC in relation to the power down sequencing of the rest of the board.

Best,

Neeraj

[Neeraj Dantu]

Simon,

Appreciate the update. Thanks!

Best,

Neeraj

[Author]

Posts