[kd]

yes, it is shorted in layout. And i wont be able to remove it. Do you think default configuration will work ? i am aiming for  processor, ddr, and sd card to work properly. i am able to get to the uboot console.

[kd]

HI,

Recently  we tried resetting board several times with image which contains eeprom bypass check. And 1 in 5 try we were able to get into uboot console. at the end we realize we can not write eeprom because on our custom board i2c0’s SCL line is shorted to V3.3B. There is no way to remove that short.

other peripheral seems to be getting proper voltages without any pcb design fault. Do you think if we can properly bypass eeprom check in uboot we will be able to use our board as intended . We are not using i2c0 except on pmic/eeprom (by default). We haven’t tried booting a kernel yet.  Do you think that is it possible if we properly work on uboot we can overcome this hardware fault?

[kd]

@EshtaarthaAs i mentioned before i have blank EEPROM on my board so i tried following method to bypass the check.

@Neeraj First we tried this post #4733 

It is part of this thread . in this process we face no difficulty while applying the patch and building the source. But when i boot image through sd card my board didn’t responded on uart debug terminal.  We haven’t received anything on the uart console.

@EricT So second we tried this post #4582

We made a change in latest version of uboot available on github.

u-boot/board/ti/am335x/board.h

static inline int board_is_bone_lt(void)
{
        printf("called it\n");
        return 1;
}

 

And i dump this image on sd card and boot my custom board. it started throwing messages on serial uart as follows.

U-Boot SPL 2018.03-00001-g3751650-dirty (Mar 14 2018 - 19:32:44 +0530)
Trying to boot from MMC1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Failed (-5)
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt


U-Boot 2018.03-00001-g3751650-dirty (Mar 14 2018 - 19:32:44 +0530)

CPU  : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM:  512 MiB
Error binding driver 'gpio_omap': -22
Error binding driver 'gpio_omap': -22
Error binding driver 'gpio_omap': -22
Some drivers failed to bind
Error binding driver 'generic_simple_bus': -22
Some drivers failed to bind
initcall sequence 9ffac608 failed at call 8080e757 (err=-22)
### ERROR ### Please RESET the board ###

it continuously reset the board with these two errors repeatedly.

U-Boot SPL 2018.03-00001-g3751650-dirty (Mar 14 2018 - 19:32:44 +0530)
Trying to boot from MMC1
Loading Environment from FAT... *** Warning - bad CRC, using default environment

Failed (-5)
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt
Called lt


U-Boot 2018.03-00001-g3751650-dirty (Mar 14 2018 - 19:32:44 +0530)

CPU  : AM335X-GP rev 2.1
Model: TI AM335x BeagleBone Black
DRAM:  512 MiB
No serial driver found
Device tree error at node ''
Device tree error at node ''
Device tree error at node ''
resetting ...
Device tree error at node ''
Device tree error at node ''
?evice tree error at node ''

What do you think? is it a hardware problem? or uboot problem? i tested this image on real BBB which works fine.

My main objective here is to reach at the uboot console somehow.  I dont know where exactly problem is happening!!!

 

 

 

 

[kd]

Hi, I just tested your suggested image and it is working as expected.  It is throwing error message on uart which means sd card interface is working.

Thank you so much for your constant support.

[kd]

Okay, I will test it right away and update you with the result.

[kd]

Yes my team mate is currently working on that patch. Mine and my team mate’s understanding is EEPROM check happens in uboot spl stage. Before that MLO  and uboot spl (starting ) log should be printed by UART console. But i am getting none when in SD card boot mode!!!

I am booting this image through SD Card  :

bone-debian-9.3-lxqt-armhf-<wbr style=”color: #222222; font-family: arial, sans-serif; font-size: small;” />2018-01-28-4gb.img.xz

What i am expecting is something like this..

U-Boot SPL 2018.01-00002-g9aa111a004 (Jan 20 2018 - 12:45:29)
Trying to boot from MMC1


U-Boot 2018.01-00002-g9aa111a004 (Jan 20 2018 - 12:45:29 -0600), Build: jenkins-github_Bootloader-Builder-32

CPU  : AM335X-GP rev 2.1
I2C:   ready
DRAM:  512 MiB
No match for driver 'omap_hsmmc'
No match for driver 'omap_hsmmc'
Some drivers were not found
Reset Source: Power-on reset has occurred.
MMC:   OMAP SD/MMC: 0, OMAP SD/MMC: 1
Using default environment

Board: BeagleBone Black
 not set. Validating first E-fuse MAC
BeagleBone Black:
BeagleBone: cape eeprom: i2c_probe: 0x54:
BeagleBone: cape eeprom: i2c_probe: 0x55:
BeagleBone: cape eeprom: i2c_probe: 0x56:
BeagleBone: cape eeprom: i2c_probe: 0x57:
Net:   eth0: MII MODE
cpsw, usb_ether
Press SPACE to abort autoboot in 2 seconds

 

Please note i am not receiving anything on the UART console. At least some log should be printed like “eeprom error….” !!

 

 

• This reply was modified 7 years ago by kd.
• This reply was modified 7 years ago by kd.

[kd]

Actual connector is on left-top corner of the schematic.  You will notice that , those pins have UART0_TX  labeled, in the updated and final schematic i removed those extra small pins and routed only main big connector. So in the end B_UART0_TX got replaced with UART0_TX.  You will find routing error in attached file.

I have one query left which is as follows

Right now i do not have EEPROM programmed and so when i boot readymade BBB images through SD card will it throw anything on serial debug? like MLO found and reading boot image etc… We haven’t provided bypass for the check of the eeprom in uboot. My intention here is to check sd card interface working properly or not!

 

Attachments:

1. 

   bufferic.png
   

[kd]

I just found out the problem. i assumed that processor is working fine and focused on just uart signaling part and found out that i made a mistake in schematic.

If you follow my schematic properly you will find that due to my wrong labels of signals input/output of uart buffer ic  got shorted out. I removed the UART buffer ic and now i am able to see “CCCC”on serial monitor.

Right now i am attaching FTDI cable directly to processor’s debugger without buffer ic. And its working fine. should i keep buffer ic between them?

 

 

[kd]

Hi,

Thank you for coming to my aid,First of all I like to mention one thing which I forgot last time is, between poweronreset(cold reset) and nreset(warm reset) there is a buffer. We haven’t populated that buffer  on Pcb due to unavailability of that ic on our end. But I don’t think that can cause any problems.

1) at the input of buffer U8 , it is 0.60 voltage. Same reflects on its output pin.

2)I am using pqcom in windows which perfectly works with original BBB. At 115200 baud rate. I tried to connect it but it didn’t show anything.

3) we have eeprom that Is not programmed so we have to bypass that check in uboot,my colleague is working on that as soon as he is done I will test to see if I get any status led working.

But I doubt that wont work until we solve this problem. It is something in hardware but I am unable to pinpoint it exactly.

What do you think,what should I do next?

Thank you,

Keval desai

[kd]

Hello Mr. Neeraj,

I have developed my custom board based on OSD3358 beaglebone black wireless version. I am attaching my circuit design png below.

Changes in my board:

different wireless module and instead of HDMI i am using LCD interface directly. All remaining things are exact of the octavo’s BBB.

Now current status of board is as follows :

EMMC is empty and i am not inserting sd card in slot.My intention is to go in UART boot mode and see “CCCC” coming on the serial monitor.

Power led,PMIC_LED_GOOD ,reset_signal all power voltage rails are working fine. currently I am unable to check crystals because of  CRO unavailability.

Question : I am getting 0.60 volt on UART0_Tx debug header instead of 3.3 volts.   I have checked buffer ic and all traces on pcb they all checked out. And resistance of trace is 4.5 OHM so that should be not an issue for fast signal like this. I am thinking it is because at power on boot lines aren’t getting latched!  what are your thoughts on this?

Note : On pcb i have kept 47pF capacitors pads open(They are connected to BOOT lines/LCD lines). They are not populated, should i populate them??

Thank you,

Keval Desai

Attachments:

1. 

   schematic.png
   

[Author]

Posts