[fedora-arm] Compiled kernel problem

[Andy Green]

On 17 August 2014 11:55:40 GMT+08:00, "Iván Chavero" <ichavero at 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 at 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.4/cubietruck_defconfig
>>>
>>> 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

>>
>>
>https://fedoraproject.org/wiki/Architectures/ARM/F20/Remixes#Allwinner_A10_.2F_A13_.2F_A20
>
>
>-- 
>Iván Chavero
>Hacker
>
>_______________________________________________
>arm mailing list
>arm at lists.fedoraproject.org
>https://admin.fedoraproject.org/mailman/listinfo/arm