Jump to content

Orange Pi PC+ Vanilla Kernel Image


Pieter

Recommended Posts

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.

Link to comment
Share on other sites

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?

 

 

 

Link to comment
Share on other sites

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 :-)
Link to comment
Share on other sites

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'
        ;;

Link to comment
Share on other sites

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 ...

Link to comment
Share on other sites

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 :-)

Link to comment
Share on other sites

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. 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

 

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

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines