Pieter Posted October 27, 2016 Posted October 27, 2016 Hi, I seem to be unable to create a working image for my Orange Pi PC+ with a 4.x kernel (I want to use Docker). I had a working 4.7.3 install but a recent (this week) apt-get upgrade installed a 4.8.x kernel (and probably a u-boot) after which my Opi PC+ will not boot anymore (my home-router shows the opi for a short time but it disappears before I can do a ssh to the Opi PC+). None of the images I have or create with a 4.x kernel seem to want to work. Only the 3.4.112 images that I download will work. Since I fried my uart0 and I haven't been able to use uart1 I have not been able to debug this. So I was hoping someone has a working image with a 4.x kernel (preferably debian-jessie server) for a Opi PC+ that they would be willing to share.
Igor Posted October 27, 2016 Posted October 27, 2016 H3 kernel is not ready for daily usage, but if you still want to use it, try some of our older builds or build on your own by changing this to 4.7 https://github.com/igorpecovnik/lib/blob/master/config/sources/sun8i.conf#L21 4.8.4 is currently broken for H3. 1
Pieter Posted October 27, 2016 Author Posted October 27, 2016 Thanks, I'll try setting it back to 4.7. I know the H3 kernel is not production / daily usage ready yet, but I had great results with the 4.7.2 or 4.7.3 (forgot which one) I was running. None of the 4.x kernels that I did have lying around from previous compilations seem to want to work so I hope a new compilation will work (compiling right now). You hint at there being older builds around, where could I find those in case my own compilation doesn't work?
Pieter Posted October 27, 2016 Author Posted October 27, 2016 Thanks, I'll try setting it back to 4.7.That did not work, compile errors (recipe for A33 olinuxino.dtb failed). I'll look into that a bit further You hint at there being older builds around, where could I find those in case my own compilation doesn't work?Found 'm :-)
chocho Posted October 27, 2016 Posted October 27, 2016 Works OK on mainline 4.9 kernel with montjoie ethernet patches, at least on orange PI PC and Orange PI One.
Pieter Posted October 27, 2016 Author Posted October 27, 2016 chocho, Could you explain to this noob (me), how to create an image with mainline 4.9 and the montjoie ethernet patch?
zador.blood.stained Posted October 27, 2016 Posted October 27, 2016 Works OK on mainline 4.9 kernel with montjoie ethernet patches, at least on orange PI PC and Orange PI One. What kernel configuration did you use?
chocho Posted October 27, 2016 Posted October 27, 2016 Well I tried both mailine with ethernet patches and directly from https://github.com/montjoie/linux/commits/sun8i-emac-wip-v5 Didn't notice any difference
chocho Posted October 27, 2016 Posted October 27, 2016 chocho, Could you explain to this noob (me), how to create an image with mainline 4.9 and the montjoie ethernet patch? The fastest way is to change lib/config/sources/sun8i.conf from dev) KERNELSOURCE='https://github.com/megous/linux' KERNELBRANCH='branch:orange-pi-4.8' KERNELDIR='linux-sun8i-mainline' ;; to dev) KERNELSOURCE='https://github.com/montjoie/linux' KERNELBRANCH='branch:sun8i-emac-wip-v5' KERNELDIR='linux-sun8i-mainline' ;;
martinayotte Posted October 27, 2016 Posted October 27, 2016 Yes, since the 4.8.x is completely broken under H3 (I still not understand why), I've switched to sun8i-emac-wip-v5 branch too. Now, I'm struggling to make SPI work again, I've fixed the DT, but I get "SPI transfer failed" during tests. It was working fine in 4.7.6 ...
Pieter Posted October 28, 2016 Author Posted October 28, 2016 Thanks for all the information. I tried the 4.9 build but it would not boot from microsd. Luckily I found an older microsd with 4.7.3 (armbian 5.20) still on it, and it did boot. I used that to boot and installed it on my opi-pc+ and marking the kernels on hold so that they will not be upgraded again after I do a apt-get upgrade :-) Since my uart0 is not working correctly anymore, making debugging very frustrating, and 4.7.3 is working correctly I'll hold on to this configuration for a while :-)
tcmichals Posted October 28, 2016 Posted October 28, 2016 Yes, since the 4.8.x is completely broken under H3 (I still not understand why), I've switched to sun8i-emac-wip-v5 branch too. Now, I'm struggling to make SPI work again, I've fixed the DT, but I get "SPI transfer failed" during tests. It was working fine in 4.7.6 ... I'm using https://github.com/megous/linux/tree/orange-pi-4.9and applying the following patch https://lkml.org/lkml/2016/10/28/64 - Ethernet works - I2C works - Have not tested SPI, in progress. I've added spi static const struct of_device_id spidev_dt_ids[] = { { .compatible = "rohm,dh2228fv" }, { .compatible = "lineartechnology,ltc2488" }, { .compatible = "spidev" }, //TCM:FIX to spidev to get around creating a overlay. I'm still clueless why kernel developers have not made this modification.
martinayotte Posted October 28, 2016 Posted October 28, 2016 BTW, this "{ .compatible = "spidev" }, //TCM:FIX " is only a workaround to avoid the warning "buggy DT: spidev listed directly in DT" been display in dmesg. Not having this patch would still load the DT, since it is only a warning. There was a lot of discussion between kernel developpers about this message. The fix you proposed have been discussed as well, and it has been rejected months ago ... I presume this warning check will eventually be refactored : https://patchwork.kernel.org/patch/9201131/ For the patch, I doubt it will fix the issue I'm facing, since it is only handling FIFO size, but I will give it a try. EDIT : For SPI issue, I don't have it on OPiPlus2E neither than OPiPC, it is working properly. So, something probably went wrong with my OPiPCPlus, which I didn't found yet.
tcmichals Posted October 29, 2016 Posted October 29, 2016 EDIT : For SPI issue, I don't have it on OPiPlus2E neither than OPiPC, it is working properly. So, something probably went wrong with my OPiPCPlus, which I didn't found yet. Well, I'm having issues as well with SPI, the first byte sent is "glitched" it is similar to was was posted before. he first byte should be 0x71
martinayotte Posted October 29, 2016 Posted October 29, 2016 That is probably a completely different issue...
Recommended Posts