[Eshtaartha Basu]

Nolebrain,

I think we need to take a look at your complete schematics to help you further. If you’re uncomfortable about sharing the schematics on the forum, please fill out the Contact Form (https://octavosystems.com/contact/) so that we can setup a secure channel for communication and do a full review on the design.

Meanwhile, I’ll answer your previous questions and give you few more tips that may help you resolve the issue.

1. Yes, PMIC_PGOOD should be connected to PWRONRSTN. It should also be connected to WARMRSTN through a buffer. The purpose of PMIC_PGOOD signal (Power-good signal) is to bring the processor out of reset once all the power rails of the PMIC are stable. You don’t have to do anything manually to achieve this. You can refer the PMIC datasheet (http://www.ti.com/lit/ds/symlink/tps65217.pdf) to understand this (PMIC_PGOOD signal is called PGOOD on the datasheet).

2. WARMRSTN should be pulled up to 3.3V (not 1.8V). Good that you took care of that. I don’t think the rise time of the capacitor on the WARMRSTN pin is causing any issues at this stage.

3. “CCCC … ” is printed on UART0 by the ROM code on the AM335x processor when the processor is in search of boot device (assuming your SYSBOOT pins are configured properly to include UART0 in boot sequence). An OS or any external software is not necessary to achieve this.

4. Different ways to program the EEPROM outside U-Boot are given in Programming the Board ID Outside of U-Boot section of EEPROM app note which I shared with you in the previous post.

I would suggest doing few preliminary voltage checks suggested in Tests after power-up section of Bare Minimum Board Boot Process article (https://octavosystems.com/app_notes/osd335x-design-tutorial/bare-minimum-boot/boot-process/). Also go through the Boot Configuration section of Peripheral Circuitry article (https://octavosystems.com/app_notes/osd335x-design-tutorial/bare-minimum-boot/peripheral-circuitry/). Since you’re using both eMMC and SD card in your design, make sure your boot sequence includes UART0, SD card and eMMC.

[Eshtaartha Basu]

Oh! Good to know that you resolved the issue. Please let us know if you have any other questions.

[Eshtaartha Basu]

Hello StephenHopkins,

From your serial log, it looks like your U-Boot is not able to write to the EEPROM because we can see that the contents of your EEPROM is all “ff”. What is happening now is that your U-Boot is detecting a blank EEPROM, it is trying to write to it but is not able to. So whenever it resets, it again detects a blank EEPROM and tries to do the same thing over and over again.

Did you ground the Write Protect pin (EEPROM_WP) while running the patch? Also, make sure you have a valid board ID in “.eeprom.txt” file.

We have a good app note on this (https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/). The app note should help you understand the process better.

[Eshtaartha Basu]

Hello Dion,

Good question. On all our reference designs, we have used a 1K resistor between the output of supervisor circuit and nRESETIN_OUT. As a result, this resistor will act as either pull up or pull down of nRESETIN_OUT depending on the output state of supervisor circuit.

When low, nRESETIN_OUT buffer can sink up to 4mA whereas the supervisor circuit can only source up to 3.3mA through 1K resistor (at 3.3V). As a result, the supervisor circuit will not be able to override the state of nRESETIN_OUT if AM335x were to assert nRESETIN_OUT due to an internally generated warm reset.

Hope this answers your question. Please let us know if you have any other concerns.

[Eshtaartha Basu]

Hello Nolebrain,

I don’t see any problems in your schematic. I think you’re not able to boot up because of blank EEPROM. Have you programmed the EEPROM inside OSD335x-SM?

The U-Boot of BeagleBoard images and the RED image look for appropriate Board ID in the EEPROM during boot up. If no suitable Board ID is found, U-Boot will halt and you won’t see any messages on UART0.

Our app note on EEPROM (https://octavosystems.com/app_notes/osd335x-eeprom-during-boot/) should help you add the Board ID to the EEPROM and boot the board.

 

[Eshtaartha Basu]

Hello samy03,

The following application notes should help you with modifying Device Trees and creating/modifying Device Tree Overlays :

1. App note on Device Tree: https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree/

2. App note on Device Tree Overlay: https://octavosystems.com/app_notes/osd335x-design-tutorial/osd335x-lesson-2-minimal-linux-boot/linux-device-tree-overlay/

Please let us know if you have any other concerns.

• This reply was modified 6 years, 5 months ago by Eshtaartha Basu.

[Eshtaartha Basu]

Apart from changing the status property, you’ll have to set other properties as well as shown here to enable the MMC1 interface. In the link given, make sure you reference “mmc2” instead of “mmc1” by changing node name to “&mmc2” from “&mmc1”. Also make suitable name changes to pinctrl-0 property. Retain cd-gpios property if you plan to use chip detect pin. Else, remove it.

Next, setup proper pin muxing for your MMC1 interface as shown here (This is a reference to BB Black’s MMC1 pin muxing for eMMC). You should modify the pin muxing shown in the given link to 4 wire interface instead of 8 wire since SD card uses a 4 wire interface. If you’re using chip detect pin, setup pin mux for it too as shown here (Don’t forget to make suitable changes to node name).

The above two steps will help you bring up the MMC1 interface.

 

 

[Eshtaartha Basu]

@JAbella

You’re not able to boot from MMC1 interface because in the PocketBeagle device tree MMC1 interface is NOT enabled at all by default (This is because SD card is connected to MMC0 interface and MMC1 interface is not used on PocketBeagle). U-Boot will be able to see and read the MMC1 interface but the kernel will not be able to run from MMC1 if the interface is not enabled in the kernel’s device tree. This is why you get the error:

ALERT!  /dev/mmcblk1p1 does not exist.

To successfully boot your board, you will have to modify the PocketBeagle Device Tree to exactly match your custom board hardware. This will involve enabling the MMC1 interface and also doing the required pin muxing in the device tree. If any of the other peripherals on your custom board is different from PocketBeagle, you will have to make suitable modifications to capture those differences as well.

Please note that MMC0 device tree node is labeled “mmc1” and MMC1 device tree node is labeled “mmc2” in Beagleboard/PocketBeagle device trees. This can lead to some confusion if you’re new to device trees. Keep this in mind while modifying device tree.

• This reply was modified 6 years, 6 months ago by Eshtaartha Basu.
• This reply was modified 6 years, 6 months ago by Eshtaartha Basu.
• This reply was modified 6 years, 6 months ago by Eshtaartha Basu.

[Eshtaartha Basu]

@JAbella

Looks like your attachment was not uploaded successfully due to security reasons. Please ZIP the file and resend it.

[Eshtaartha Basu]

Hello JAbella,

From your boot log, it looks like the board is having difficulty booting from MMC0 interface (MMC0 is typically connected to SD card slot on BB Black) as indicated by the lines:

Card did not respond to voltage select!

mmc_init: –95, time 13

** Bad device mmc 0 **

You can see that the board is trying to boot from MMC1 once booting from MMC0 fails. At line 48, it says:

mmc1 is current device

 

I’ll need a little more information before we proceed further.

1. What interface is SD card connected to in your design (MMC0 or MMC1)?

2. Does your design have both eMMC and SD card?

3. If yes to previous question, have you flashed both eMMC and SD card with the same image?

• This reply was modified 6 years, 6 months ago by Eshtaartha Basu.
• This reply was modified 6 years, 6 months ago by Eshtaartha Basu.

[Eshtaartha Basu]

I was about to respond to your previous question. I’m glad that you were able to figure it out yourself using one of our previous forum posts. Please let us know if you need any other information.

[Eshtaartha Basu]

Since you’re board is powering up and you’re able to reach U-Boot console, PMIC seems to be functioning properly. The default configuration of PMIC is sufficient for most applications (You can go through TPS65217C datasheet for more information). Yes, PMIC should be able to support all peripherals on BeagleBone Black in its default configuration (Processor, DDR3 and SD Card in your case).

[Eshtaartha Basu]

@kd

Yes. You should be able to use the board as intended if you bypass EEPROM properly. Keep in mind that PMIC will always function in its default configuration and you won’t be able to configure it (changing input current limits etc) without I2C0.

Since I don’t have access to your actual schematic file, it is difficult to track all signals with just a picture of your schematic. From what I see, it looks like I2C0_SCL is not shorted in schematic. Is it shorted in layout?

[Eshtaartha Basu]

@kd

Based on the errors you’re getting, it looks like this is a device tree issue. I believe your hardware is behaving different from that of BeagleBone Black and hence Device Tree is having trouble loading drivers and initializing your hardware. It would be best if you modify the Device Trees of both your U-Boot and Kernel. You can use a Device Tree Rebuilder for this.

You can just use a minimal device tree for verification.

[Eshtaartha Basu]

@kd

I will look into this issue and get back to you by the beginning of next week.

[Author]

Posts