please choosego to mobile | Continue to access the PC version
Author: BryanFRitt

Directions for Heat Sink?

[Copy link]

0

threads

18

posts

230

credits

Intermediate member

Rank: 3Rank: 3

credits
230
Published in 2015-12-8 18:52:28 | Show all floors
bronco replied at 2015-12-8 18:07
Did you also gave lima-memtester a try? http://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit ...

Not yet. I had tried lima-memtester before, but there was a problem with mali driver or something like that.

Published in 2015-12-8 19:19:38 | Show all floors
Edited by bronco at 2015-12-8 19:22
dvl36 replied at 2015-12-8 18:52
Not yet. I had tried lima-memtester before, but there was a problem with mali driver or something  ...
Same here. Now I'm really concerned since the preliminary test results doesn't look that promising. And bit flips are really bad leading to all sorts of trouble, data corruption and crashes (we normally attribute to 'software' but it might be also wrong hardware initialisation).

This new approach https://github.com/ssvb/lima-mem ... ange-pi-pc-fel-test comes with everything already prepared. You just need a x86 box where you can connect your OPi to using FEL/USB (and sunxi-tools -- unfortunately all my 'physical' PCs run OS X and I'm still unable to 'make sunxi-fel' -- no time to dig deeper at the moment)

EDIT: Just forgot that I should be able to use any of the other SBCs lying around here and running linux to do the test...

BTW: Did you altered the dvfs table inside script.bin or tested with the defaults (only 1.3V and 1.5V)?
Published in 2015-12-8 19:42:43 | Show all floors
Edited by bronco at 2015-12-8 19:55

Got it running on a Banana Pi M3 after compiling the most recent version of sunxi-tools (the one included in most distro images is too old):

  1. root@bananapi:~/fel-boot-lima-memtester-on-orange-pi-pc# lsusb
  2. Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  3. Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  4. Bus 001 Device 005: ID 1f3a:efe8 Onda (unverified) V972 tablet in flashing mode
  5. Bus 001 Device 003: ID 05e3:0718 Genesys Logic, Inc. IDE/SATA Adapter
  6. Bus 001 Device 002: ID 1a40:0101 Terminus Technology Inc. Hub
  7. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

  8. root@bananapi:~/fel-boot-lima-memtester-on-orange-pi-pc# ./fel-boot-lima-memtester-on-orange-pi-pc 480
  9. Stack pointers: sp_irq=0x00002000, sp=0x00005E08
  10. MMU is not enabled by BROM
  11. Generating the new MMU translation table at 0x00044000
  12. => Executing the SPL... done.
  13. Setting write-combine mapping for DRAM.
  14. Setting cached mapping for BROM.
  15. Writing back the MMU translation table.
  16. Enabling I-cache, MMU and branch prediction... done.
  17. Writing image "U-Boot 2016.01-rc1-00441-g75507d", 321065 bytes @ 0x4A000000.
  18. 0.2 kB written in 0.0 sec (speed: 69.6 kB/s)
  19. Passing boot info via sunxi SPL: script address = 0x43100000
  20. 36.0 kB written in 0.0 sec (speed: 737.2 kB/s)
  21. 7048.2 kB written in 7.6 sec (speed: 922.7 kB/s)
  22. Starting U-Boot (0x4A000000).

  23. Now the Orange Pi PC board should boot and show a spinning cube on
  24. a HDMI monitor. If the cube stops spinning or does not show up in
  25. the first place, then the selected DRAM clock speed is unreliable.

  26. Also one of the LEDs should be blinking. If this LED stops blinking,
  27. then the test has failed. When the second LED lights up while the
  28. first one still keeps blinking, then enough time has passed already
  29. and we can consider the test a success. The LEDs allow to use this
  30. test even when no monitor is connected.

  31. You still can keep the test running for a longer period (for example
  32. overnight) for extra confidence. Also please consider to have some
  33. extra safety headroom. For example, if the test seems to run fine at
  34. 'X MHz', but fails at 'X + 24MHz', then it may be reasonable to use
  35. 'X - 24MHz' setup in the end. Good luck.
Copy code


First test with 672 MHz immediately crashed

600 MHz crashed after 2 minutes, now I let 552 MHz try... also crashed after 2 minutes. Woohoo

528 MHz also broken, now trying 480 MHz...

5

threads

354

posts

2614

credits

Moderator

Rank: 7Rank: 7Rank: 7

credits
2614
Published in 2015-12-8 19:50:32 | Show all floors
mine passed with 600Mhz.
Boards:
orangepi plus, olinuxino A20, cubieboard A10, mele A2000 .....

0

threads

18

posts

230

credits

Intermediate member

Rank: 3Rank: 3

credits
230
Published in 2015-12-8 20:40:38 | Show all floors
Edited by dvl36 at 2015-12-8 20:57
bronco replied at 2015-12-8 19:19
Same here. Now I'm really concerned since the preliminary test results doesn't look that promising.  ...

Checked. At frequencies 504Mhz and above LED stop blinking. At 480Mhz heatsink temperature (at bottom) only 40-41C.
Previously I tested with four linpacks (4000) without any problems. (Two days running)
So it seems that something wrong with this test.

ADD: Default voltages of loborises Debian Wheezy image. Should be 1.5v.
Published in 2015-12-8 21:20:06 | Show all floors
dvl36 replied at 2015-12-8 20:40
Checked. At frequencies 504Mhz and above LED stop blinking. At 480Mhz heatsink temperature (at bott ...

I don't know whether heatsink temperature is relevant here at all. As far as I understand the lima-memtester is a tool that has to run under worst case conditions putting as much stress on the SoC as possible (therefore the spinning cube rendered with Mali) to get a clue when bitflips happen (might be related to undervoltage of DRAM -- this has nothing to with the Vcore voltage of the CPU cores). I don't know how that translates to real-world situations (or running only cpu intensive benchmarks as you did)

And obviously DRAM initialisation/settings differ between what we use now and what the most recent u-boot does:

https://github.com/loboris/Orang ... onfig.fex#L179-L203 vs.

https://u-boot.googlesource.com/ ... nxi/dram_sun8i_h3.h
https://u-boot.googlesource.com/ ... angepi_pc_defconfig

BTW: My 1st OPi PC didn't survive even 480 MHz. Currently testing 456 MHz
Published in 2015-12-8 21:49:38 | Show all floors
fritz replied at 2015-12-8 19:50
mine passed with 600Mhz.

Did you also tested with ssvb's new fel version using his kernel fork and recent u-boot or when running loboris' 3.4.39 kernel?

5

threads

354

posts

2614

credits

Moderator

Rank: 7Rank: 7Rank: 7

credits
2614
Published in 2015-12-8 22:39:20 | Show all floors
I don' t use the kernel by @loboris.
Test was done with u-boot binary and uImage provided by @ssvb on opi plus.
Restested with 600 Mhz and this time it failed at loop 1/8:
Bit Flip            : testing 111READ FAILURE: 0xffffdfff != 0xffffffff at offset 0x0054a294 (bitflip)

Boards:
orangepi plus, olinuxino A20, cubieboard A10, mele A2000 .....
Published in 2015-12-9 17:33:21 | Show all floors
fritz replied at 2015-12-8 22:39
I don' t use the kernel by @loboris.
Test was done with u-boot binary and uImage provided by @ssvb o ...

Seems to be related to DRAM initialisation in the early boot stage: https://groups.google.com/d/msg/ ... 4k8nIE/PKkl7cwUAQAJ

0

threads

18

posts

230

credits

Intermediate member

Rank: 3Rank: 3

credits
230
Published in 2015-12-9 18:19:25 from mobile | Show all floors
Edited by dvl36 at 2015-12-9 18:29
bronco replied at 2015-12-8 21:20
I don't know whether heatsink temperature is relevant here at all. As far as I understand the lima ...

@ssvb at linux-sunxi Google groups:
-----
Currently U-Boot v2016.01-rc2 fails the lima-memtester check unless
the DRAM clock speed is reduced to 456 MHz on my Orange Pi PC. But
if I use the boot0 bootloader to boot the same kernel image
(uImage-3.4-sun8i-h3-lima-memtester), then the test works fine.
This means that there must be still something wrong with the H3
DRAM init code in U-Boot, or maybe some clocks are wrong
------

How we can test it using boot0 bootloader?


You need to log in before you can reply login | Register

Points Rule

Quick reply Top Return list