[fedora-arm] Cubieboard 2 compatible kernel package

[Robert Moskowitz]

On 08/14/2014 10:03 AM, Andy Green wrote:
>
> 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 seems that firstboot for the F20 build I used, and many others, mess 
up the nand boot to android.  There are a couple messages on the 
cubieforum about this.  Look at:

ARGH!  I lost the link.  I am going to have to dig for it.  Problem is 
that some of the directions are  screen captures in Chinese.

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

I believe Hans DeGoede is doing the uboot integration for Allwinner 
boards into Fedora, so his uboot I point to below is what will 
eventually be mainline.

>
>>> 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 reread the old post and you need to do this on an x86 system.

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

And for me, it only goes to external!  If I do not have a card in system 
stops with a SUnxi prompt on serial console.  I am getting some more 
Cubieboards probably monday, so I am going to pop one of the cards in 
and see how it boots if I had not run a first boot.

>
>> 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 have followed the manual steps provided for the CubieTruck, but just 
prefer the installer packaging.  And at somepoint it will go beyond the 
~6 allowed boards.

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

Hey, this is early alpha F21!  I am thankful for each improvement they 
deliver.

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

I have a dozen 16 and 8 GB SDcards with different boots on the.  I have 
made up a card holder (that needs an improvement, maybe I can patent 
it!) for organizing all these cards.  Leaving them on my desk result in 
them getting mixed up.

When the additional systems come, I will be working on HD booting of the 
sata.