On 14 August 2014 22:38:15 GMT+08:00, Robert Moskowitz <rgm@xxxxxxxxxxxxxxx> wrote: > >On 08/14/2014 10:03 AM, Andy Green wrote: >> >> On 14 August 2014 20:45:07 GMT+08:00, Robert Moskowitz ><rgm@xxxxxxxxxxxxxxx> 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. _______________________________________________ arm mailing list arm@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/arm
