• Content Count

  • Joined

  • Last visited

About wtarreau

  • Rank
    Advanced Member

Recent Profile Visitors

1183 profile views
  1. It would have been nice at least to keep the mention that the device Balbes was talking about was the X96 Max, that's not specific to any store and it's just a board with a supported SoC (S905X3), otherwise his post becomes confusing or misleading since it's a different hardware from the one posted above.
  2. Please note, my build farm is used for cross-compiling only. I used to do native builds 20 years ago, and after having been hit several times by accidental dependencies on the build host, I stopped and am always cross-compiling nowadays, even when doing x86 on x86. That's why I can use whatever host is available for the build farm. My build farm at home is heterogeneous, it's made of the armv8 boards above, one armv7 board (odroid xu4) and sometimes some x86 hosts when the devices are up. So yes, I'm a huge proponent of cross-compiling.
  3. I understood as well that HK got their hands on the blob part and were able to figure the highest stable frequency they could use. I don't know how this blob is used but definitely without it you won't go above 1.5 GHz.
  4. Use sales@, I've used it several times and it works. Oh and put a link to the discussion in this forum so that they know you're not just doing random stuff but are actually using their boards fine. I wouldn't be surprised if they're used to receive an occasional complaint from people who just accidently erase their micro-SD and cry for help.
  5. OK, good luck! Note, you may want to contact FriendlyElec before putting the board into the oven to let them know that one of your boards seems to be dead and let them know what you've tried and that you're planning on trying the oven. Maybe they'll simply want to send you a replacement one and will ask for this one to be sent back there for inspection. They've already sent me some replacement hardware for early defects, they're really nice.
  6. You should try to connect a serial adapter to its console port to see if it emits anything at boot. If it doesn't, it's probably dead. If it emits random errors which differ upon every boot, it could be the RAM which became defective. This happened to me on a few boards in the past, and on one of the MIQIs on my build farm. It is also possible that a solder joint has gone bad under a BGA chip. That's the most common failure cause in modern hardware (especially smartphones). It's even worse with RoHS and lead-free because lead-free tin is less elastic and breaks more easily. I've repaired a few
  7. I never had such an issue, but I never plugged HDMI into it either, so it's hard to say if anything is related. If it fails to boot, I'd suggest it's not related to the software/distro so you'd better ask FriendlyElec directly in case they'd be aware of any stability issue or a workaround for what you're seeing. Note, be careful about the power supply, especially if it's shared between all boards. It could be possible that when they're all rebooting, the PSU doesn't cope nicely with the sudden current rush and provides too low a voltage to the boards.
  8. Hi, So I finally found some time to pick the file form the board, sorry for the delay, was busy on other stuff. I verified the temperature thresholds. First alert is at 113, second at 115 and critical is at 120. The file includes one extra DVFS entry for 1600 MHz at 1.25V. I didn't find any other difference compared to the factory dtb. For those landing here from a search engine without preliminary context, this works for my board and is very likely to fry yours, so don't randomly try this file at all, or don't complain! s5p6818-nanopi3-rev05.1g6-1v25-113deg.dtb
  9. Hehe, that doesn't change my opinion of this standard which is only useful to build development boards and nothing looking even remotely like a usable prototype. The small form factor only exposes useless stuff and the large one requires access to both sides, thus imposing an enclosure size. But for development I'm totally fine with the EE form factor as it provides a rich set of connectors and standards in a reasonable size.
  10. Confirmed, from memory I just added a line with "1600000 1250000". Mine is ultra-stable even with 8 cores at full speed. It happens to throttle a little bit from time to time because the heat cannot escape easily from the cardboard enclosure, but that's all. From what I remember from the datasheet, the chip is designed to run at 1.6 GHz, that's why I picked this frequency. I also modified the thermal triple points because I don't want the machine to throttle quickly, I seeked the limits on mine and set the points slightly below. I can upload the file later if some want it. It's just that
  11. I thought they were two different names for the same upcoming board, with various intermediary designs. But you're right, the NEO4 is even smaller than the M4! So yes that makes sense, it's a single channel RAM. Then I think I'm more interested in the M4. However if they made a complete aluminum enclosure like they recently did with the NEO/NEO2 with the buttons and OLED, it could be very tempting to get one as well for about everything you can do with a machine lying in your computer bag!
  12. I just checked the Wiki and it's clearly written dual-channel for the RAM regardless of the size, so we have 64 bits.
  13. @tkaiser I totally agree with you. I'm checking every morning on their site while drinking my first coffee if it's available or not! While I'm not *that* much impressed by RK3399, it's still a pretty good SoC, and this combined with FE's documentation and thermal design should bring something really nice. I'm just wary of the 32-bit memory, we'll have to see once it's available. I can understand their choice given the small size of the board though.
  14. What you can do is increase the 2nd argument, it's the number of loops you want to run. At 1000 you can miss some precision. I tend to use 100000 on medium-power boards like nanopis. On the clearfog at 2 GHz, "mhz 3 100000" takes 150ms. This can be much for your use case. It reports 1999 MHz. With 1000 it has a slightly larger variation (1996 to 2000). Well, it's probably OK at 10000. I took bad habits on x86 with intel_pstate taking a while to start. Maybe you should always take a small and a large count in your tests. This would more easily show if there's some automatic frequenc
  15. Please note that the operating points is usually fed via the DT while the operating frequency is defined by the jumpers on the board. It's very possible that the DT doesn't reference the correct frequencies here. From what I've apparently seen till now, the Armada 38x has limited ability to do frequency scaling, something like full speed or half speed possibly. When I was running mine at 1.6 GHz, I remember seeing only 1600 or 800 being effectively used. I didn't check since I upgraded to 2 GHz (well 1.992 to be precise) but I suspect I'm now doing either 2000 or 1000 and nothing else. Thus if