[fedora-arm] Cubieboard 2 compatible kernel package

[Andy Green]

On 14 August 2014 22:03:29 GMT+08:00, Andy Green <andy at warmcat.com> 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'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.

heh... it seems workable, network came up, have to test it and see about stability.  Great.

There are some more instructions needed to get it to come up with serial console if you're doing it by hand.

Currently there are many competing boot management methods down /boot, some huge u-boot scripts, grub and other mysteries.

The one that the U-Boot you described how to get and build listens to is

 extlinux/extlinux.conf

For Cubieboard 2, this has to be edited to change the "append" line for the kernel to add

console=ttyS0,115200 

to get the serial console, otherwise nothing is coming.


Thanks a lot for the help, looking forward to more fedora goodness.

-Andy

>>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.
>
>_______________________________________________
>arm mailing list
>arm at lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/arm