[fedora-arm] Cubieboard 2 compatible kernel package

Andy Green andy at warmcat.com
Thu Aug 14 14:03:29 UTC 2014



On 14 August 2014 20:45:07 GMT+08:00, Robert Moskowitz <rgm at htt-consult.com> wrote:
>For a change I can help!
>
>Been here, done a few things...
>
>On 08/14/2014 07:26 AM, Andy Green wrote:
>> Hi -
>>
>> I have a headless cubieboard 2 running a 3.4 kernel that came with
>the 
>> board, but a Fedora rootfs already.
>
>You are using:
>
>https://fedorapeople.org/~lkundrak/a10-images/
>
>stuff?  It works well on my CB2.  Well as well as can be expected with 
>the Allwinner 3.4 kernel, and part of the reason why there is now a 
>community effort to build an open uboot.  Hans posted a note about this
>
>back aways.

No I used a generic Fedora rootfs tarball from somewhere that worked out of the box with the 3.4 kernel that came with the board, plus or minus the odd iptables-related module.  At least it's the first cheapo board I used that has been perfectly stable doing serving tasks for months, and I tried a several boards.

But now it needs not only the rootfs normalizing but also the kernel, which should improve a few things at once if I survive the ordeal.

>> It's been pretty workable, but now I need to compile an OOT kernel 
>> module, and that's a big mess with the magic 3.4 kernel. The
>defconfig 
>> it was built with has gone 404, although a tarball of the sources 
>> (with different defconfigs) exists.
>>
>> So after reading the megathreads here about cubieboard 2 support 
>> working, I went to look for a rawhide kernel package and give it a
>try.
>
>I am using the F21 builds, rather than the rawhide.  They are all there
>
>together.
>
>http://koji.fedoraproject.org/koji/tasks?state=all&view=tree&method=appliance&order=-id
>
>with instructions at:
>
>https://fedoraproject.org/wiki/Architectures/ARM/Rawhide/Installation
>

I think it's the same direction, I will discard the rootfs part and continue to use what I have.

I don't even mind having to do things by hand with kernel package upgrades until it's turnkey I'm just grateful it'll be supported at all.

>> However after looking at Wikis that are out of date compared to the 
>> mailing list, and an "Arm Koji" that only has 64-bit arm binaries in 
>> the kernel package, I have no idea where to go to get the latest
>armhf 
>> kernel package, U-Boot pieces etc.
>
>Above is the 32 bit stuff.  uboot is another issue, but I will give you
>
>what Hans posted here and works for me:
>
>On your development machine (mine is my F20 x86 notebook):
>
>Cubieboard2 uboot:
>
>yum install gcc-arm-linux-gnu gcc
>git clone https://github.com/jwrdegoede/u-boot-sunxi.git
>cd u-boot-sunxi
>git checkout -B next origin/next
>make -j4 CROSS_COMPILE=arm-linux-gnu- Cubieboard2_defconfig
>make -j4 CROSS_COMPILE=arm-linux-gnu-

I tried meddling the U-Boot over serial, I must be missing a trick somewhere because mmc rescan etc do not find the uSD card even.

So thanks for the above I'll give it try.

>Everytime I make a new SDcard for a test F21 using:
>
>fedora-arm-image-installer.sh 
>--image=Fedora-Xfce-armhfp-21-20140803-sda.raw.xz --target=Cubietruck 
>--media=/dev/sdb --norootpass

Yes this is OK by just xzcat and dd directly too.  I'm OK meddling with that kind of stuff by hand.

>I run:
>
>dd if=u-boot-sunxi-with-spl.bin of=/dev/sdb bs=1024 seek=8; sync
>
>To overlay the Cubietruck uboot with the Cubieboard2 uboot.  Works just
>
>fine.

Ah.  I see.  It's not very friendly.

>> I think this respin concept is not a good idea, I see rotting one-off
>
>> "respins" including one from Feb for Cubieboard. But all I want is to
>
>> upgrade the 3.4 kernel to use a Fedora one with latest upstream 
>> pieces. My fedora rootfs is already in good shape.
>>
>> What steps should someone in this situation take to align themselves 
>> with latest armv7 hf kernel and boot-related pieces that will work on
>
>> Cubieboard 2?
>
>Note that F21 is locked into the uboot 3.16:
>
>http://linux-sunxi.org/Linux_mainlining_effort
>
>Perhaps rawhide will keep rolling in the latest uboot, but Hans has not
>
>updated the uboot build I pointed out above for a while.  He will have 
>to comment on what updates may be in the works before it is merged into
>
>the Fedora uboot base.

The nice thing about being on uSD is if an upgrade for the kernel didn't work out I can just pop the card and revert it by main force.  So I think that's the least of the worries, U-Boot is the biggest sticking point it seems.

-Andy

>Hope this helps.



More information about the arm mailing list