James Kingdon

  • Content count

  • Joined

  • Last visited

  1. quick review

    Hi @Igor I'm curious where the info/photos came from - did you get a pre-release board? I'd love to get my hands on one (or more!) of these for testing.
  2. I work on a compiler development team and I thought it would be fun to have my own system at home. We have a large suite of regression tests that take quite a while to run on ARM, so the farm will do distributed build and test.
  3. There is no "too far" FWIW, I keep looking at a pile of peltier coolers I bought for another project...
  4. It is, and so far the XU4 is the workhorse in my (little) farm, so I'd rate it as pretty good value. It's weakness is the heat it puts out. I have one of those large 40mm northbridge heatsink and fan units (https://www.aliexpress.com/item/1pcs-40mm-x-10mm-Cooling-Fan-Heatsink-DIY-Northbridge-Cooler-South-North-Bridge-Radiator-for-PC/32432181804.html) on mine, and I still can't quite stop it from throttling at full load. (Admittedly the fan I put on it isn't moving a whole lot of air, so there's room for improvement). The other issue with the XU4 is that the eMMC is extra (and worth it), and shipping to Canada isn't cheap, so the total cost is a bit higher than I'd want to spend for the rest of the compute nodes. If I can hit $50 CDN/node I'll be pretty happy, where as the XU4 came out to about $140 all in (with a 16G emmc (not 32G like I first said - lousy memory)).
  5. That's awesome, thank you! I've looked at the Ugoos units several times but they're normally well over $100 which puts them into competition with 8 core boxes like the Xu4 and geekbox. I've ordered an UT3S, it will be interesting to compare with the Q8. Where did you find out about the coupon?
  6. Many thanks for the additional info, that was enough to get me in the right place. With 1.54GHz enabled my workload runs in the low fifties centigrade without the fan fitted. I'd expect to take another 5 to 10C off that when the fan is in place. So far no signs of instability but if I run into any problems I'll back the changes off. I'd have to rate the board as very impressive for thermal management, certainly compared to the odroid XU4 which pays for the speed with a whole lot of heat.
  7. Thanks for the reply. Sorry if I didn't make my question clear enough, I read the thread and attempted to follow what I could see but was unsuccessful. Hence the question asking for further guidance. And yes, I plan on using active cooling and monitoring temperatures during runs. At the moment my particular workloads only raise the cpu temp to about 45C and I'm comfortable with running the board hotter than that. I checked that /boot/script.bin was linked to bin/orangepipcplus.bin and ran bin2fex on it, but the dvfs_table in there doesn't seem to match the frequencies listed by cpufreq-info, so I'm a bit confused as to how this works. It looks like the fex is being modified or over-ridden by the patch you referenced a few posts up. How does that work?
  8. Hi, I have a slightly unusual use case, building a compile and test farm with a variety of different socs so that I can easily check for regressions. All the boards will have heatsinks and active cooling so I have more thermal budget than may be typical, and I'd like to run at the higher clockspeeds to push the tests through more quickly. I've just added an Orange pi pc+ and installed Armbian_5.25_Orangepipcplus_Ubuntu_xenial_default_3.4.113 onto the emmc (which went very smoothly - many thanks as always for the great work you do). cpufreq-info shows steps upto 1.54 GHz, but hardware limits between 480 MHz and 1.30 GHz. analyzing CPU 0: driver: cpufreq-sunxi CPUs which run at the same hardware frequency: 0 1 2 3 CPUs which need to have their frequency coordinated by software: 0 1 2 3 maximum transition latency: 2.00 ms. hardware limits: 480 MHz - 1.30 GHz available frequency steps: 60.0 MHz, 120 MHz, 240 MHz, 312 MHz, 408 MHz, 480 MHz, 504 MHz, 528 MHz, 576 MHz, 600 MHz, 624 MHz, 648 MHz, 672 MHz, 720 MHz, 768 MHz, 816 MHz, 864 MHz, 912 MHz, 960 MHz, 1.01 GHz, 1.06 GHz, 1.10 GHz, 1.15 GHz, 1.20 GHz, 1.25 GHz, 1.30 GHz, 1.34 GHz, 1.44 GHz, 1.54 GHz available cpufreq governors: interactive, conservative, ondemand, powersave, userspace, performance current policy: frequency should be within 624 MHz and 1.30 GHz. The governor "interactive" may decide which speed to use within this range. current CPU frequency is 624 MHz. cpufreq stats: 60.0 MHz:0.00%, 120 MHz:0.00%, 240 MHz:0.00%, 312 MHz:0.00%, 408 MHz:0.00%, 480 MHz:0.00%, 504 MHz:0.00%, 528 MHz:0.00%, 576 MHz:0.00%, 600 MHz:0.00%, 624 MHz:50.79%, 648 MHz:0.00%, 672 MHz:0.04%, 720 MHz:0.00%, 768 MHz:0.00%, 816 MHz:0.00%, 864 MHz:0.00%, 912 MHz:0.00%, 960 MHz:0.00%, 1.01 GHz:44.60%, 1.06 GHz:0.21%, 1.10 GHz:0.21%, 1.15 GHz:1.77%, 1.20 GHz:0.42%, 1.25 GHz:0.38%, 1.30 GHz:1.58%, 1.34 GHz:0.00%, 1.44 GHz:0.00%, 1.54 GHz:0.00% (49) During runs the maximum freq used is 1.30 GHz. I tried editing /etc/default/cpufrequtils and increasing the MAX_SPEED value, but it does not appear to have had any affect even after reboot. How do I enable the higher frequency steps? Regards, James
  9. Yes, that's what I was expecting. I obviously messed up somewhere along the way.
  10. Yes, that's all I did. Can't remember how to process the .dtb into the resource.img off the top of my head though. Ah, just resource_tool q8-rk3288.dtb according to Tim's page.
  11. That's an interesting idea. I have some other ARM boards, so I could give that a try.
  12. Forgot to mention, I also tried installing the armbian build system and building the miqi image from scratch, but my Linux setup seems to be way too old and I ran into endless problems. I did get a kernel zImage out of it, but there were no signs of it booting when I put it into Ian's sd card setup in place of the Tim P' kernel. So many attempts, so little progress! I'm still reluctant to give up on this board, given that the SOC is high end and Q8s are half the price of anything else with that chip.
  13. Ok, bear in mind that there have been a lot of mis-steps along the way, and I wasn't keeping notes, so it's possible that the following may not be sufficient to reproduce the current state of my Q8. It's also the case that my Q8 isn't currently usable for anything. I don't think the following steps were the cause, but it's possible that trying this will also cause problems. The key steps are: get Ian Morrison's tools from Follow his instructions to flash the RK3288Loader_uboot_V2.17.02.bin into the Q8 (I'm still not convinced this worked, so it may be unnecessary. the version number doesn't match what comes up on the serial log). Get a rootfs from somewhere (Ian gives some suggestions, and there are others that can be found with google. I'm not sure if the kernel ever gets as far as mounting the rootfs). I recommend editing create-linux-sdcard to remove all the redirecting stdout and stderr to /dev/null, as that isn't exactly helpful. If your linux distro uses /dev/mmcblk style names for the sd card you need to edit the places where the script accesses partitions because it assumes /dev/sda0 /dev/sda1 naming where new kernels use /dev/mmcblk0 for the root and /dev/mmcblk0p0 /dev/mmcblk0p1 etc for partitions (i.e. you need to add the 'p' to the script) You can try running the script at this point with the kernel that Ian included. Make sure to unmount the sdcard in the file browser if it was automatically mounted when you inserted it. Keep an eye on the speed reported after writing each part to the SD card. If something goes wrong the data ends up on your hard disk and typically gets written much faster than when writing to the SD card, so if you see most of the writes at 2MB/s and one at 100MB/s you know something went wrong. The default kernel didn't get very far at all for me, and stopped producing output at different points each time, so... Go to Tim Potter's repo on bit bucket ( https://bitbucket.org/DengueTim/q8-rk3288-kernel/overview ) Clone it, compile the kernel to get a zImage, process the zImage with rkcrc -p zImage timp-kernel.img (I think, memory is a little fuzzy here), link or copy timp-kernel.img to kernel-linux.img in Ian's create-sdcard directory and run create-linux-sdcard to write it all out to the SD card. This is all done on a linux amd64 host, and there's been a lot of installing tool-chains and supporting tools, so doubtless there are gaps in the above description. At the moment, my best guess for a possible problem area is that I might have used the wrong cross compiler tool chain (I think I used arm-linux-gnueabihf-gcc-4.8 when compiling Tim's kernel).
  14. Still no luck getting the Q8 to boot linux, it seems all roads lead to frustration at the moment. The furthest I've got so far has been with the Tim Potter kernel from https://bitbucket.org/DengueTim/q8-rk3288-kernel/overview That kernel seems to get quite a long way into the boot sequence, bringing all four processors up and probing a lot of hardware. It even brings up the firefly splash screen on the monitor, but then it starts hitting kernel oops and eventually seems to lock up solid. I confirmed that shorting pins 7 & 8 on the flash chip can bring it into maskrom mode, but I haven't figured out what to do with it from there.
  15. A little more progress - I did some debugging on the create-linux-sdcard script from and found that the assumptions it was making about the device naming scheme for the sd card reader didn't match my build environment (it assumed a root device such as sda with partition sda1, where as I have a root device mmcblk0 and partition mmcblk0p1). After fixing that the resulting sd card gets further into the boot process and starts bringing up the kernel. Unfortunately the boot appears to hang with no network or screen. The serial log stops at what looks like random places on each attempt, I'm not sure if this reflects the boot crashing randomly or if it's just the non-flow-controlled serial connection overflowing. This all has the feeling of re-discovering what other people did two or three years ago, but at least it doesn't look like I've completely trashed the system yet.