[fedora-arm] F18 on mirabox

Thu Apr 4 19:27:12 UTC 2013

Making some progress on this, slowly...

After moving the USB driver from module to built-in, I was able to make 
it find
the rootfs on the USB stick. First issue I see is this:

<28>systemd[1]: No control group support available, not creating root group.

even though it's definitely enabled in the kernel:

[root at localhost ~]# zcat /proc/config.gz | grep CGROUP
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_NS=y
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_DEVICE=y
# CONFIG_CGROUP_CPUACCT is not set
CONFIG_CGROUP_SCHED=y
# CONFIG_BLK_CGROUP is not set

then there were a couple of systemd services failing:
<27>systemd[855]: Failed at step OOM_ADJUST spawning 
/usr/lib/systemd/systemd-readahead: No such file or directory
<29>systemd[1]: systemd-udevd.service: main process exited, code=exited, 
status=206/OOM_ADJUST

I managed to work around both of those by commenting out the OOMScoreAdjust
parameter in their respective systemd config files.

Next thing was that I forgot to adapt fstab to point to the right UUID 
for root.

And now I'm running into this:
<28>systemd[1]: dbus.service start request repeated too quickly, 
refusing to start.

repeated a couple dozen times, then it seems to hang. Don't even get the
emergency shell prompt I got through some of the failure above.

I'll try some more tinkering tonight, but if anyone had any ideas I'll 
be happy
to hear them.

J.

On 4/1/2013 12:36, Jochen De Smet wrote:
> On 3/29/2013 5:45, Peter Robinson wrote:
>> Hi Jochen,
>>
>> What is the release architecture of Debian Squeeze? I believe squeeze
>> is only built for ARMv4 which might be part of the chroot issue. I
>> suspect it might be easier to use the kernel from debian to boot
>> Fedora directly.
>>
>> In theory the 3.8.3+ kernels in Fedora might work with it but I don't
>> think it will because I don't believe everything needed for the device
>> landed in the 3.8 kernel. I'm hoping the 3.9 kernel will have enough
>> to support the marvell mvebu devices and hence we'll be able to
>> support them out of the box for F-19. As the 3.9 kernel comes together
>> you'll see more details on the list on how to test them on F-18.
>>
>> Peter
> I actually started off trying with a 3.8.2 stock kernel, but didn't 
> get very far; then I switched
> to the kernel at 
> https://github.com/MISL-EBU-System-SW/mainline-public.git, which I think
> got me a kernel that booted but wasn't able to get to the NAND device.
>
> I just tried copying the fedora rootfs to a USB stick and booting with 
> a root= argument, but it
> seems to be unable to find the device at boot time even though it does 
> get automounted, so
> I'm guessing some driver isn't built-in.
>
> I've also tried grabbing the sources for their default kernel and 
> simply rebuilding, then booting
> the kernel over the network, but again ended up with something that 
> couldn't read the NAND.
>
> I'll play around some more with a recompiled kernel + USB root, both 
> their default one and the
> mainline-public variety.
>
> file /bin/ls on the squeeze binary shows:
> /bin/ls: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically 
> linked (uses shared libs), for GNU/Linux 2.6.18, stripped
>
> not sure if that's enough to tell you the architecture version.
>
> J.
>
>
>> On Wed, Mar 27, 2013 at 12:48 AM, Jochen De Smet 
>> <jochen.arm at leahnim.org> wrote:
>>> I'm trying to get F18 running on the globalscale mirabox.
>>>
>>> It comes preloaded with Debian Squeeze.  As a first step I've tried
>>> downloading the generic
>>> rootfs from the 
>>> https://fedoraproject.org/wiki/Architectures/ARM/F18/Remixes
>>> page; I've
>>> tried both the arm and armhfp versions, and even tried an armv5 
>>> kirkwood
>>> rootfs.
>>>
>>> All of them behave the same. I unpack the rootfs into /mnt/f18, and 
>>> then try
>>> to chroot into
>>> it.  The first two or three times I try it, it comes back with either
>>> "Illegal instruction" or
>>> "Segmentation fault", but after a few times I successfully get into the
>>> chroot.  Then for pretty
>>> much every command inside it's the same thing.  First few times it 
>>> runs it
>>> fails with one of
>>> the two errors above, then it starts working and appears to keep 
>>> working for
>>> an indeterminate
>>> amount of time.
>>>
>>> I've tried to start rebuilding rpms from source in the chroot but 
>>> things
>>> never work long enough
>>> to get anything built.
>>>
>>> I've also (and this part is probably off-topic) tried building rpms 
>>> from the
>>> debian environment,
>>> and that's failing because gcc gives an error when explicitly 
>>> compiling for
>>> armv7:
>>>
>>> $ gcc -c ui.c -march=armv7
>>> ui.c:1: error: target CPU does not support ARM mode
>>>
>>> Additionally, I've tried building gcc 4.8.0 from source, and that 
>>> errors out
>>> with:
>>>
>>> ../.././gcc/config/arm/neon.md: In function 'const char*
>>> output_1551(rtx_def**, rtx)':
>>> ../.././gcc/config/arm/neon.md:3953:1: internal compiler error: Illegal
>>> instruction
>>>     [(set_attr "neon_type" "neon_shift_2")]
>>>   ^
>>>
>>> ../.././gcc/config/arm/neon.md:3953:1: internal compiler error: 
>>> Segmentation
>>> fault
>>>
>>>
>>>   cpuinfo below:
>>>
>>> # cat /proc/cpuinfo
>>> Processor       : Marvell PJ4Bv7 Processor?? rev 1 (v7l)
>>> BogoMIPS        : 1199.30
>>> Features        : swp half thumb fastmult vfp edsp vfpv3 vfpv3d16
>>> CPU implementer : 0x56
>>> CPU architecture: 7
>>> CPU variant     : 0x1
>>> CPU part        : 0x581
>>> CPU revision    : 1
>>>
>>> Hardware        : Marvell Armada-370
>>> Revision        : 0000
>>> Serial          : 0000000000000000
>>>
>>>
>>> Looking for any help on how to debug or how to proceed.
>>>
>>> J.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> arm mailing list
>>> arm at lists.fedoraproject.org
>>> https://admin.fedoraproject.org/mailman/listinfo/arm
>
> _______________________________________________
> arm mailing list
> arm at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/arm