On 17 August 2014 11:55:40 GMT+08:00, "Iván Chavero"
<ichavero(a)chavero.com.mx> wrote:
On 14/08/14 03:14, Peter Robinson wrote:
> On Thu, Aug 14, 2014 at 4:23 AM, Iván Chavero
<ichavero(a)chavero.com.mx> wrote:
>> Hello,
>>
>> I've compiled a kernel from:
>>
https://github.com/jwrdegoede/linux-sunxi
>> I attached the .config to the mail in case is needed.
>>
>> this config file i got it from:
>>
https://github.com/cubieboard/cubie_configs/blob/master/kernel-configs/3....
>>
>> This are the commands i used to compile the kernel in my laptop:
>>
>> make ARCH=arm menuconfig
>>
>> make ARCH=arm CROSS_COMPILE=arm-none-eabi- -j5 uImage modules
>>
>> put the modules in a local directory:
>> make ARCH=arm INSTALL_MOD_PATH=../modules/fedora modules_install
>>
>> cd ../modules/fedora
>> tar -zc lib > modules_3.15.tar.gz
>>
>> copied the uImage and the modules to a running cubietruck, added the
kernel
>> to
>> the extlinux.conf
>>
>> and booted usign a serial cable but this was all i got:
>>
>> Retrieving file: /uImage-3.15
>> 4631624 bytes read in 512 ms (8.6 MiB/s)
>> no console=
>> append: enforcing=0 ro
root=UUID=b487fc2a-226b-4b85-a435-a259656fb9e7
>> console=ttyS0,115200
>> Retrieving file:
>> /dtb-3.16.0-0.rc7.git1.1.fc22.armv7hl/sun7i-a20-cubietruck.dtb
>> 21639 bytes read in 2139 ms (9.8 KiB/s)
>> Bad Linux ARM zImage magic!
>> ## Booting kernel from Legacy Image at 42000000 ...
>> Image Name: Linux-3.15.0+
>> Image Type: ARM Linux Kernel Image (uncompressed)
>> Data Size: 4631560 Bytes = 4.4 MiB
>> Load Address: 40008000
>> Entry Point: 40008000
>> Verifying Checksum ... OK
>> ## Flattened Device Tree blob at 50000000
>> Booting using the fdt blob at 0x50000000
>> Loading Kernel Image ... OK
>> Loading Device Tree to 4fff7000, end 4ffff486 ... OK
>>
>> Starting kernel ...
>>
>> and it hanged.
>>
>> can somebody give me a hint on what i'm doing wrong?
> Did you build device trees and specify the right one on the command
> line? TBH 3.4 is ancient and I've no idea how forked it is so it
could
> be anything. Did you look at the Fedora 20 Allwinner remix as I
> believe it uses that kernel.
i'm not sure about the device tree, how do you do that?
i can use any kernel version, i just need the proper instructions to
build it, i've tried a lot of stuff on the wiki and howtos and nothing
seems to work.
thanks for your help
There's no point building your own 3.4 kernel when Fedora already did it from upstream
sources.
Even if you want missing pieces like video, you can still get everything else up and prove
the flow using their image and then video is your only problem, instead of "nothing
works" being your problem.
There seem to be a few gotchas with the otherwise excellent Allwinner A20 stuff.
Download a Fedora xz SD Card image and xzcat it on to an sd Card, eg, /dev/sdv since the
image contains a partition table already.
This one worked for me (get the xz image link at the end)
http://koji.fedoraproject.org/koji/taskinfo?taskID=7272114
Now the quirks...
1) The Rom in the A20 expects the SD card to have a U-Boot binary stashed at +16 512-byte
sectors on the card.
Build the magic A20-specific U-Boot as mentioned by Robert a few days ago on this list and
dd it into place on your card.
https://lists.fedoraproject.org/pipermail/arm/2014-August/008150.html
2) The U-Boot binaries keep an environment stored elsewhere on the SD card... I dunno
where.
If you're re-using an existing SD card that already had an image on it, you'll
need to use the U-Boot commands to force the environment to be reset and then save it
before it will use the new default environment from the new U-Boot and act reasonably.
Otherwise your new, improved U-Boot will load the old craptastic environment and do
nothing useful.
(In fact this whole environment thing has always been an unmaintainable mess in U-Boot,
it's a step forward that this new method requires the default env to work properly...
just nuke the env and leave it at default).
Once you took care of that, the default env and the stuff placed into /boot by the xz
image are enough to figure out where the dtb is down the versioned dtb dir, so there is
nothing special you need to do about that, it will know the kernel version string from
what the Fedora image did and go to the right dir itself and stick it somewhere reasonable
in DDR at boot time.
So it's almost enough already....
3) Set up a serial console.
The new bootloader scripts default to looking in [/boot/]extlinux/extlinux.conf to find
out what to do
For Cubieboard 2, this has to be edited to change the "append" line for the
kernel to add
console=ttyS0,115200
then with a USB serial adapter on the 4-pin connector, you should boot and see a firstboot
script there.
Currently it's not very turnkey and you have to know the above quirks.
But I found the results are VERY good, Fedora + Cubieboard 2 is very solid 2 x A7 system
with decent DDR + SD rootfs, and worth the small effort needed currently to make it work.
-Andy