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.
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
On Wed, Mar 27, 2013 at 12:48 AM, Jochen De Smet jochen.arm@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
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@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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
check for
CONFIG_AUDITSYSCALL=y
On Thu, Apr 4, 2013 at 2:27 PM, Jochen De Smet jochen.arm@leahnim.orgwrote:
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@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.githttps://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@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/ **Remixeshttps://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@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/armhttps://admin.fedoraproject.org/mailman/listinfo/arm
______________________________**_________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/armhttps://admin.fedoraproject.org/mailman/listinfo/arm
______________________________**_________________ arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/armhttps://admin.fedoraproject.org/mailman/listinfo/arm
On 4/4/2013 16:03, Jon wrote:
check for
CONFIG_AUDITSYSCALL=y
Auditing was disabled completely. Enabled it and will retest.
Can't enable CONFIG_AUDITSYSCALL though, since:
config AUDITSYSCALL bool "Enable system-call auditing support" depends on AUDIT && (X86 || PPC || S390 || IA64 || UML || SPARC64 || SUPERH)
it won't enable on ARM in this (linux-2.6.35.9-armada370-1.0.2_gw) kernel version.
J.
On Thu, Apr 4, 2013 at 2:27 PM, Jochen De Smet <jochen.arm@leahnim.org mailto:jochen.arm@leahnim.org> wrote:
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@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@leahnim.org <mailto:jochen.arm@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 <http://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@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/arm _______________________________________________ arm mailing list arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/arm _______________________________________________ arm mailing list arm@lists.fedoraproject.org <mailto:arm@lists.fedoraproject.org> https://admin.fedoraproject.org/mailman/listinfo/arm--
-Jon
Having AUDIT enabled will improve your experience.
Would be worth while to make a list of kernel config option that SystemD needs to be happy.
In the long run you will want to run the unified 3.9 kernel once that is available.
On Thu, Apr 4, 2013 at 3:18 PM, Jochen De Smet jochen.arm@leahnim.orgwrote:
On 4/4/2013 16:03, Jon wrote:
check for
CONFIG_AUDITSYSCALL=y
Auditing was disabled completely. Enabled it and will retest.
Can't enable CONFIG_AUDITSYSCALL though, since:
config AUDITSYSCALL bool "Enable system-call auditing support" depends on AUDIT && (X86 || PPC || S390 || IA64 || UML || SPARC64 || SUPERH)
it won't enable on ARM in this (linux-2.6.35.9-armada370-1.0.2_gw) kernel version.
J.
On Thu, Apr 4, 2013 at 2:27 PM, Jochen De Smet jochen.arm@leahnim.orgwrote:
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@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@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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
--
-Jon
On Thu, Apr 4, 2013 at 8:27 PM, Jochen De Smet jochen.arm@leahnim.org wrote:
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@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.
systemd really needs at least 2.3.36 as there's a couple of features in that which are used actively.
Peter
-
Jochen De Smet -
Jon -
Peter Robinson