[fedora-arm] Cubieboard 2 compatible kernel package

[Andy Green]

On 14 August 2014 22:38:15 GMT+08:00, Robert Moskowitz <rgm at htt-consult.com> wrote:
>
>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.

Well, I don't mind these will only be used on Fedora.

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

No I mean that SoC's method of putting the bootloader in magic sectors instead of a file or in other NV is not friendly.

Even Panda's ROM knew how to parse the filesystem to find the bootloader and that's getting long in the tooth now.

-Andy

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