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(a)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(a)lists.fedoraproject.org
>
https://admin.fedoraproject.org/mailman/listinfo/arm