Jump to content
  • 0

OPi1 stuck on DRAM:


psygnosis
 Share

Question

Hi, do you remember my issue with 2 opi1?

Well, today I burned again an armbian image with etcher and connect either of the two opi one, to a usb-ttl converter (an arduino).

ok, when I put the power on the result is what you see in the attach...

the two freeze on DRAM: always.

the power is a xiaomi power adapter 5v2a (double checked with a multimeter) and a handmade cable (checked with the multimeter too, 4.8v/4,9v always)

so...can I finally tell that my two board are faulty? or there is something I could do?

thank you in advance

 

ssdasd.JPG

Link to comment
Share on other sites

17 answers to this question

Recommended Posts

  • 0
1 hour ago, psygnosis said:

the power is a xiaomi power adapter 5v2a (double checked with a multimeter) and a handmade cable (checked with the multimeter too, 4.8v/4,9v always)

so...can I finally tell that my two board are faulty? or there is something I could do?

Do you got another power cable? I did buy cables for the power-socket which has USB on the other end and my 2 OPi One do work also on normal USB Port of my NAS or computer:

https://www.robotistan.com/orange-pi-plus-2-guc-kablosu

I dont think that booth could be defective - one maybe but two - I dont think so.

 

How about some pictures of your cable, Power adapter, Case?
You do power viathe power-socket and not via micro-usb?
Whats the TTL-Output with non armbian images?

 

OPi_One_USB_Cable.jpg

Link to comment
Share on other sites

Help Armbian team helping you!

  • 0

This is the cable I made,

And the power adapter I use.
I measure the V again now and point the negative on the bottom center of the barrel plug I have -4,96 pointing the red on the center i have 4,96 I think It's perfect for orange pi, am I correct?

 

I didn't try to see the log of another image but I try the same image with 2 different sd on the 2 opi and the two crash at dram:

IMG_20171127_150520.jpg

IMG_20171127_150539.jpg

IMG_20171127_163154.jpg

Link to comment
Share on other sites

  • 0
3 hours ago, psygnosis said:

This is the cable I made,

And the power adapter I use.
I measure the V again now and point the negative on the bottom center of the barrel plug I have -4,96 pointing the red on the center i have 4,96 I think It's perfect for orange pi, am I correct?

 

I didn't try to see the log of another image but I try the same image with 2 different sd on the 2 opi and the two crash at dram:

Hmm...cable seems to be thick enough and also the power should deliver enough Ampere - but it sounds for me more as a powersupply problem than a OPi problem.

 

Could you connect the powercable to a USB-Connector and run from another powersupply?

The OPi doenst need much Ampere - my OPi One is running from a normal USB-Port (from Synology NAS) as Pi-Hole

 

You could try to meassure the Ampere while the OPi is connected. Maybe the powersupply Ampere or Volt when connected.

 

Link to comment
Share on other sites

  • 0

on the screen, the fail in SDRAM init is seen, rather than power supply issues, or SD card issues. uboot when initializing SDRAM loops in several cycles waiting for HW registers to finally indicate what is expected. if after some number of tries it is not as expected, it calls hang() function, which is telling of itself. it is rather not very probable that you had such a luck to get 2 boards with the same hardware bug. Maybe try another u-boot version. older/newer armbian (if exists) or another linux+uboot bundle (from the vendor for example). If another bundle fails, try different SD card.

Link to comment
Share on other sites

  • 0

Ok here I am...
There Are all the tests I did today: with different Power Adaper (5v2A/5.1V2.1A/5V1,8A) same SD card all images burned with etcher.

As you can see the result are the same, with armbian it freeze on DRAM and the official images from the opi website, it goes a little far but it crash again.

at this point I don't know what to do, maybe I really get 2 Opi with DRAM issue?

 

H2testw

Quote

Warning: Only 7641 of 7642 MByte tested.
Test finished without errors.
You can now delete the test files *.h2w or verify them again.
Writing speed: 17.3 MByte/s
Reading speed: 19.0 MByte/s
H2testw v1.4

 

opi1_lu_5.2.JPG

opi2_arm325_5.1.2.1.JPG

opi2_arm335_5.2.JPG

opi2_deb_5.2.JPG

opi2_lu_5.1.2.1.JPG

opi2_lu_5.1.8.JPG

opi2_lu_5.2.JPG

Link to comment
Share on other sites

  • 0

it's only a speculation, but from the new screenshots it looks like the code couldn't rise voltage (axp probe error and following) for cpu but rose frequency, which caused instability. but why it couldn't do axp related stuff, I have no idea, hardly it's power issue with all 3 PSUs.

Link to comment
Share on other sites

  • 0
5 minutes ago, zador.blood.stained said:

Because there is no AXP PMIC on H3 boards :)

 

In any case this looks like a DRAM issue (most likely BGA soldering related) since the mainline u-boot can't autodetect DRAM size.

haha, didn't know that, don't have H3 boards.)

but why it fails in the middle of printing "READ ..." string, at "RE"? it's not like here it starts to read some DDRC register and this causes hang, it fails before that. looks like random instability from the CPU side.

 

How does uboot autodetect DRAM size? Is there SPD? On my board (CI20) uboot just uses hardcoded values for everything, following the vendor BSP.

Link to comment
Share on other sites

  • 0
4 minutes ago, valant said:

but why it fails in the middle of printing "READ ..." string, at "RE"?

Because it tries to use (i.e. store and execute the next stage bootloader) DRAM that doesn't work properly?

 

5 minutes ago, valant said:

How does uboot autodetect DRAM size?

You can try clicking on dram_*.c files here and find something like this, if it explains anything :)

 

9 minutes ago, valant said:

Is there SPD?

No, DRAM init code and its configuration has to be provided by bootloader/SPL. SPD is just an additional EEPROM on removable memory modules and it doesn't make much sense to use this for something that is soldered on the same board as the CPU/SoC.

Link to comment
Share on other sites

  • 0
1 hour ago, zador.blood.stained said:

Because it tries to use (i.e. store and execute the next stage bootloader) DRAM that doesn't work properly?

I meant that the printing itself fails, it doesn't involve DRAM accesses, it runs from SRAM, the strings are there as well, it writes in UART and fails in the middle of the "READ" substring. It's not a multithreaded environment where one thread prints a string and another (on a different) CPU accesses faulty DRAM causing the board to hang.

 

1 hour ago, zador.blood.stained said:

 

You can try clicking on dram_*.c files here and find something like this, if it explains anything :)

Thanks, interesting trickery showing me how much I skimmed over with SDRAM initialization.) and totally different from the same uboot but with CI20, where it just copies hardcoded values into the appropriate register.

 

1 hour ago, zador.blood.stained said:

No, DRAM init code and its configuration has to be provided by bootloader/SPL. SPD is just an additional EEPROM on removable memory modules and it doesn't make much sense to use this for something that is soldered on the same board as the CPU/SoC.

But see, if column/row width is DRAM chips dependant, as it seems with the examples of autodetect above, then it's not as a bad idea to have such for a board vendor and flush there info provided by DDR chip vendor.

Link to comment
Share on other sites

  • 0
9 hours ago, valant said:

I meant that the printing itself fails, it doesn't involve DRAM accesses, it runs from SRAM, the strings are there as well, it writes in UART and fails in the middle of the "READ" substring. It's not a multithreaded environment where one thread prints a string and another (on a different) CPU accesses faulty DRAM causing the board to hang.

Yes, where only boot0 was started it should live in SRAM, but since there are no boot0 sources it is impossible to say where and why it fails without disassembling it

 

9 hours ago, valant said:

But see, if column/row width is DRAM chips dependant, as it seems with the examples of autodetect above, then it's not as a bad idea to have such for a board vendor and flush there info provided by DDR chip vendor.

But why do you need to increase the total cost by programming and soldering an EEPROM and in addition rewriting vendor's BSP DRAM init to read such EEPROM (and hoping that it would fit in 32K SRAM after that) if you can just hardcode DDR type and frequency at compile time and rely on autodetect for columns/rows?

And AFAIK column/row stuff also depends on the number of chips connected to the SoC, i.e. there are H3 boards with 1, 2 and 4 chips.

Link to comment
Share on other sites

  • 0
11 hours ago, zador.blood.stained said:

Yes, where only boot0 was started it should live in SRAM, but since there are no boot0 sources it is impossible to say where and why it fails without disassembling it

You just can see at the above screenshots it fails randomly in the middle of printing. then knowing it's 1 core 1 thread process, get the idea there was no DRAM access at that point. or do you mean it's OoO speculative execution and data abort happens later when CPU does UART writing? On Cortex-A7? :D I honestly don't know that much about it yet, i am in mips now in my humble hobbyistic learning. :)

 

11 hours ago, zador.blood.stained said:

But why do you need to increase the total cost by programming and soldering an EEPROM and in addition rewriting vendor's BSP DRAM init to read such EEPROM (and hoping that it would fit in 32K SRAM after that) if you can just hardcode DDR type and frequency at compile time and rely on autodetect for columns/rows?

And AFAIK column/row stuff also depends on the number of chips connected to the SoC, i.e. there are H3 boards with 1, 2 and 4 chips.

this autodetect method is a little hacky, it guesses, - it relies on matching values from reads which shouldn't match, as a signal of out of range. Probably there are some caveats that might misdirect this method too far away. of course it would better to just have exact numbers from SoC/board vendors. if it worked that way.)

as of coulmn/row dependency on number of chips. well, the latter is also known for the board vendor. a third party FW vendor doesn't have such a knowledge. they product can't see what it is going to manage. again, if they don't wish toput that info in pdf, then, right, probably they won't put it into EEPROM. :D

Link to comment
Share on other sites

  • 0
7 hours ago, psygnosis said:

Sorry if I bother you. so can I trash those two Opi?

don't give up. i still can't believe there are two boards with the same hw flaw. I'd try other possibilities. Is there an android image for this? official, tested, known to work etc. then try it, just to be sure. with the fattiest PSU, try it yet.

Link to comment
Share on other sites

  • 0
13 hours ago, valant said:

don't give up. i still can't believe there are two boards with the same hw flaw. I'd try other possibilities. Is there an android image for this? official, tested, known to work etc. then try it, just to be sure. with the fattiest PSU, try it yet.

 =( I already tried an android img (official) and it doesn't start either but I will try again with UART to see the log.

for the psu what psu should I try?

Link to comment
Share on other sites

  • 0
11 hours ago, psygnosis said:

 =( I already tried an android img (official) and it doesn't start either but I will try again with UART to see the log.

that's crap. if you tried everything that could run and everything failed to run, trying different PSUs etc, then you got 2 broken boards. Probably you should contact your seller. Or at least "advertise" it in due course.

 

11 hours ago, psygnosis said:

for the psu what psu should I try?

They probably all are OK.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...