So I got myself a second mirabox and figured I'd try to get F19 on there.
I got myself a microSD card as well, and wrote the image on there. When plugged into the mirabox, I can see the SD card from linux and mount the partitions etc.
But after that I seem to be stuck. The instructions on https://fedoraproject.org/wiki/Architectures/ARM/F19/Installation seem to stop after the "write the image" step and don't have any information on actually booting from the SD card.
I figured I'd just try to manually load kernel/initramfs from the card, but I seem to have issues accessing it from U-boot:
Marvell>> mmcinfo Card did not respond to voltage select! Device: MRVL_MMC Manufacturer ID: ff OEM: ffff Name: ▒▒▒▒▒ Tran Speed: -1 Rd Block Len: -1 SD version 15.15 High Capacity: Yes Capacity: -1 Bus Width: 1-bit
I'm also not sure which kernel version to point to. From the config file it seems like the supplied kernels do have CONFIG_ARM_APPENDED_DTB set to y; can I just cat together uImage-3.9.5-301.fc19.armv7hl and the DTB, or do I need to add the DTB to vmlinuz and then convert to uImage?
U-boot version on the mirabox is U-Boot 2009.08 (Sep 16 2012 - 22:50:06)Marvell version: 1.1.2 NQ
If I can find some time later today I might try putting the image on a USB stick and booting from that instead of the SD card, but that's not something I'd want to keep as a permanent solution.
Idea anyone ?
J.
Here are my notes on MiraBox. (These are adapted from Jon Masters)
[jon@shambhala ~]$ cat mira-notes.txt #version=3.9.5-301.fc19 version=3.10.0-1.fc20
# change to the boot directory on the rootfs # all paths are relative to the boot partition.
cat vmlinuz-${version}.armv7hl \ dtb-${version}.armv7hl/armada-370-mirabox.dtb > \ vmlinuz-${version}.armv7hl.mirabox-adtb
mkimage -A arm -O linux -T kernel -C none \ -a 0x00008000 -e 0x00008000 \ -n "${version}.armv7hl.mirabox-adtb" \ -d vmlinuz-${version}.armv7hl.mirabox-adtb \ uImage-${version}.armv7hl.mirabox-adtb
/bin/cp -f uImage-${version}.armv7hl.mirabox-adtb uImage /bin/cp -f uInitrd-${version}.armv7hl uInitrd
# bellow are the u-boot commands
setenv bootcmd 'usb start; ext2load usb 1:1 0x02000000 uImage; ext2load usb 1:1 0x02800000 uInitrd; bootm 0x02000000 0x02800000' setenv bootargs 'ro rootwait earlyprintk debug root=/dev/sdb3 console=ttyS0,115200' run bootcmd
#THE END
On Fri, Jul 19, 2013 at 1:30 PM, Jochen De Smet jochen.arm@leahnim.org wrote:
So I got myself a second mirabox and figured I'd try to get F19 on there.
I got myself a microSD card as well, and wrote the image on there. When plugged into the mirabox, I can see the SD card from linux and mount the partitions etc.
But after that I seem to be stuck. The instructions on https://fedoraproject.org/wiki/Architectures/ARM/F19/Installation seem to stop after the "write the image" step and don't have any information on actually booting from the SD card.
I figured I'd just try to manually load kernel/initramfs from the card, but I seem to have issues accessing it from U-boot:
Marvell>> mmcinfo Card did not respond to voltage select! Device: MRVL_MMC Manufacturer ID: ff OEM: ffff Name: ▒▒▒▒▒ Tran Speed: -1 Rd Block Len: -1 SD version 15.15 High Capacity: Yes Capacity: -1 Bus Width: 1-bit
I'm also not sure which kernel version to point to. From the config file it seems like the supplied kernels do have CONFIG_ARM_APPENDED_DTB set to y; can I just cat together uImage-3.9.5-301.fc19.armv7hl and the DTB, or do I need to add the DTB to vmlinuz and then convert to uImage?
U-boot version on the mirabox is U-Boot 2009.08 (Sep 16 2012 - 22:50:06)Marvell version: 1.1.2 NQ
If I can find some time later today I might try putting the image on a USB stick and booting from that instead of the SD card, but that's not something I'd want to keep as a permanent solution.
Idea anyone ?
J.
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 7/19/2013 16:03, Jon wrote:
Here are my notes on MiraBox. (These are adapted from Jon Masters)
Thanks!
Indeed, the SD reader is behind a usb bus so usb needs to be started in u-boot to get to the card.
Using those instructions the kernel at least starts booting, makes it to the initrd but then appears to hang at this point:
[ OK ] Mounted Configuration File System. Starting LVM2 metadata daemon... [ OK ] Started Apply Kernel Variables. [ OK ] Started Create static device nodes in /dev. Starting udev Kernel Device Manager... [ OK ] Started LVM2 metadata daemon. systemd-fsck[239]: _/: clean, 44920/397488 files, 338291/1586914 blocks [ OK ] Started File System Check on Root Device. Starting Remount Root and Kernel File Systems... [ OK ] Started udev Kernel Device Manager. [ 214.643245] systemd-udevd[250]: starting version 204 [ 214.662018] EXT4-fs (sdb3): re-mounted. Opts: (null) [ OK ] Started udev Coldplug all Devices. Starting udev Wait for Complete Device Initialization... [ OK ] Started Remount Root and Kernel File Systems. [ OK ] Reached target Local File Systems (Pre). Starting Configure read-only root support... [ OK ] Started Monitoring of LVM2 mirrors, snapshots etc. u...ogress polling. [ OK ] Started Configure read-only root support. Starting Load Random Seed... [ OK ] Started Load Random Seed. [ OK ] Found device /dev/ttyS0. [ 215.468098] mvneta d0070000.ethernet eth0: mac: 06:a4:a7:49:fe:24 [ 215.522508] libphy: orion_mdio_bus: probed
I'll leave it alone for a while to see if it eventually makes it through. Should I expect some installer to start running at some point? Or is the root partition inside the image .xz really just the equivalent of the old FC18 root fs images with no more changes to it needed?
J.
Some progress.
Still can't get it to work with the fedora kernel, but I did manage to get it booted using the same kernel I use for F18 ; had to explicitly tell dracut to include the usb driver to be able to find the root partition.
Also had to enable the serial getty. Is there any particular reason why this isn't enabled by default on arm ?
So now I'm booted, but network-wise things are looking rather grim. I can see both interfaces, NetworkManager recognizes them, and ethtool confirms link at the expected speed. However that's as far as things get.
On eth0, running tcpdump shows me all my outgoing packets (DHCP/ARP) and even RIP packets from the router it's attached to, but nothing else. No DHCP reply from the router. Putting on a static IP doesn't help either.
On eth1, things are slightly worse. All the same problems as eth0, but in addition I'm seeing these when running tcpdump: mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=129 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=125 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=151 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=157 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=158
J.
On 7/19/2013 16:23, Jochen De Smet wrote:
On 7/19/2013 16:03, Jon wrote:
Here are my notes on MiraBox. (These are adapted from Jon Masters)
Thanks!
Indeed, the SD reader is behind a usb bus so usb needs to be started in u-boot to get to the card.
Using those instructions the kernel at least starts booting, makes it to the initrd but then appears to hang at this point:
[ OK ] Mounted Configuration File System. Starting LVM2 metadata daemon... [ OK ] Started Apply Kernel Variables. [ OK ] Started Create static device nodes in /dev. Starting udev Kernel Device Manager... [ OK ] Started LVM2 metadata daemon. systemd-fsck[239]: _/: clean, 44920/397488 files, 338291/1586914 blocks [ OK ] Started File System Check on Root Device. Starting Remount Root and Kernel File Systems... [ OK ] Started udev Kernel Device Manager. [ 214.643245] systemd-udevd[250]: starting version 204 [ 214.662018] EXT4-fs (sdb3): re-mounted. Opts: (null) [ OK ] Started udev Coldplug all Devices. Starting udev Wait for Complete Device Initialization... [ OK ] Started Remount Root and Kernel File Systems. [ OK ] Reached target Local File Systems (Pre). Starting Configure read-only root support... [ OK ] Started Monitoring of LVM2 mirrors, snapshots etc. u...ogress polling. [ OK ] Started Configure read-only root support. Starting Load Random Seed... [ OK ] Started Load Random Seed. [ OK ] Found device /dev/ttyS0. [ 215.468098] mvneta d0070000.ethernet eth0: mac: 06:a4:a7:49:fe:24 [ 215.522508] libphy: orion_mdio_bus: probed
I'll leave it alone for a while to see if it eventually makes it through. Should I expect some installer to start running at some point? Or is the root partition inside the image .xz really just the equivalent of the old FC18 root fs images with no more changes to it needed?
J.
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
And some more progress.
The network functions fine if and only if I use the network in U-boot, i.e. a simple "dhcp ; setenv ethact egiga1 ; dhcp" before booting from the sd makes everything work, at least temporarily. Bringing the interface up and down a few times appear to break things again, but as long as I just let it stay up it functions without any apparent issues.
So I guess this means there might be some initialization missing in the kernel driver for the 370 NICs ?
On a bright note, that means I now have both interfaces working on my F18 box as well; the reason eth0 didn't work there but eth1 did, was because eth1 is used there to network load the kernel/initrd.
I did still have to add a file /etc/udev/rules.d/40-network.rules with contents like this:
KERNELS=="d0070000.ethernet", RUN += "/sbin/ip link set dev eth0 address F0:AD:4E:01:E1:D2" KERNELS=="d0074000.ethernet", RUN += "/sbin/ip link set dev eth1 address F0:AD:4E:01:E1:D3"
to make NetworkManager happy (replace those MACs with the ones on the mirabox label if you're doing this), since otherwise I still ended up with a new random MAC on every boot.
I also re-learned that you do indeed have to copy your preferred kernel to uImage; you can't symlink it. Otherwise a kernel update through yum will happily overwrite your kernel. That also taught me that the updated F19 kernel (3.9.9-302) does not boot on the mirabox; it's worse than the 3.9.5-301 in the xz; no kernel output whatsoever.
One last note is on the microSD performance, which appears to be very slow from u-boot. Loading the 10MB initrd takes over 45 seconds, as compared to maybe 2 or 3 when loading from the network. Under linux, a copy of the same file also takes just a few seconds.
J.
On 7/20/2013 2:49, Jochen De Smet wrote:
Some progress.
Still can't get it to work with the fedora kernel, but I did manage to get it booted using the same kernel I use for F18 ; had to explicitly tell dracut to include the usb driver to be able to find the root partition.
Also had to enable the serial getty. Is there any particular reason why this isn't enabled by default on arm ?
So now I'm booted, but network-wise things are looking rather grim. I can see both interfaces, NetworkManager recognizes them, and ethtool confirms link at the expected speed. However that's as far as things get.
On eth0, running tcpdump shows me all my outgoing packets (DHCP/ARP) and even RIP packets from the router it's attached to, but nothing else. No DHCP reply from the router. Putting on a static IP doesn't help either.
On eth1, things are slightly worse. All the same problems as eth0, but in addition I'm seeing these when running tcpdump: mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=129 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=125 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=151 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=157 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=158
J.
On 7/19/2013 16:23, Jochen De Smet wrote:
On 7/19/2013 16:03, Jon wrote:
Here are my notes on MiraBox. (These are adapted from Jon Masters)
Thanks!
Indeed, the SD reader is behind a usb bus so usb needs to be started in u-boot to get to the card.
Using those instructions the kernel at least starts booting, makes it to the initrd but then appears to hang at this point:
[ OK ] Mounted Configuration File System. Starting LVM2 metadata daemon... [ OK ] Started Apply Kernel Variables. [ OK ] Started Create static device nodes in /dev. Starting udev Kernel Device Manager... [ OK ] Started LVM2 metadata daemon. systemd-fsck[239]: _/: clean, 44920/397488 files, 338291/1586914 blocks [ OK ] Started File System Check on Root Device. Starting Remount Root and Kernel File Systems... [ OK ] Started udev Kernel Device Manager. [ 214.643245] systemd-udevd[250]: starting version 204 [ 214.662018] EXT4-fs (sdb3): re-mounted. Opts: (null) [ OK ] Started udev Coldplug all Devices. Starting udev Wait for Complete Device Initialization... [ OK ] Started Remount Root and Kernel File Systems. [ OK ] Reached target Local File Systems (Pre). Starting Configure read-only root support... [ OK ] Started Monitoring of LVM2 mirrors, snapshots etc. u...ogress polling. [ OK ] Started Configure read-only root support. Starting Load Random Seed... [ OK ] Started Load Random Seed. [ OK ] Found device /dev/ttyS0. [ 215.468098] mvneta d0070000.ethernet eth0: mac: 06:a4:a7:49:fe:24 [ 215.522508] libphy: orion_mdio_bus: probed
I'll leave it alone for a while to see if it eventually makes it through. Should I expect some installer to start running at some point? Or is the root partition inside the image .xz really just the equivalent of the old FC18 root fs images with no more changes to it needed?
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
And more information, with some kernel woes.
When I compile the 3.10 kernel with my config on F18, the first compilation aborts with:
CC [M] fs/ubifs/budget.o CC [M] fs/ubifs/find.o fs/ubifs/find.c: In function ‘ubifs_save_dirty_idx_lnums’: fs/ubifs/find.c:771:18: internal compiler error: Bus error Please submit a full bug report, with preprocessed source if appropriate. See http://bugzilla.redhat.com/bugzilla for instructions. The bug is not reproducible, so it is likely a hardware or OS problem. make[2]: *** [fs/ubifs/find.o] Error 1 make[1]: *** [fs/ubifs] Error 2 make: *** [fs] Error 2
Just re-running "make" after that successfully produces a kernel, and the result appears to work fine.
Compiling the same kernel and config on F19 does not give any errors and produces a kernel, but it doesn't quite work. It appears to boot fine, but soon oopses with something like the below (don't think it's the same every boot):
Unable to handle kernel NULL pointer dereference at virtual address 0000001c pgd = ee0b8000 [0000001c] *pgd=2e2c2831, *pte=00000000, *ppte=00000000 Internal error: Oops: 17 [#1] ARM Modules linked in: ipt_MASQUERADE iscsi_tcp libiscsi_tcp libiscsi iptable_nat nf_nat_ipv4 nf_nat drbd lru_cache scsi_transport_iscsi iptable_mangle ipt_REJECT xt_conntrack iptable_filter ip_tables ext3 jbd autofs4 ext4 jbd2 mbcache sd_mod usb_storage mmc_block mvsdio mmc_core ehci_orion CPU: 0 PID: -1073560872 Comm: bash Not tainted 3.10.0-stock1 #23 task: ee1df440 ti: ee154000 task.ti: ee154000 PC is at __task_pid_nr_ns+0x40/0xa4 LR is at schedule_tail+0x44/0x64 pc : [<c0037c4c>] lr : [<c00439e0>] psr: 60000013 sp : ee155f88 ip : ee155f88 fp : ee155f94 r10: 00000000 r9 : 00000000 r8 : 00000000 r7 : 00000000 r6 : 00000000 r5 : bf000000 r4 : ee154000 r3 : ef181efc r2 : 00000000 r1 : 00000000 r0 : ee1df440 Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 2e0b8019 DAC: 00000015 Process bash (pid: -1073560872, stack limit = 0xee154230) Stack: (0xee155f88 to 0xee156000) 5f80: ee155fac ee155f98 c00439e0 c0037c18 00000000 00000000 5fa0: 00000000 ee155fb0 c000df48 c00439a8 00000000 00000000 00000000 00000000 5fc0: b6fc3068 bed65f08 48a50000 00000078 000d6d64 b6fc3000 000d63cc bed65f34 5fe0: b6fc34c0 bed65f08 00000a18 489aa0cc 60000010 01200011 00000000 00000000 Backtrace: [<c0037c0c>] (__task_pid_nr_ns+0x0/0xa4) from [<c00439e0>] (schedule_tail+0x44/0x64) [<c004399c>] (schedule_tail+0x0/0x64) from [<c000df48>] (ret_from_fork+0x4/0x3c) r5:00000000 r4:00000000 Code: e0831101 e5913120 e3530000 0a00000c (e592101c) ---[ end trace 20369176bc42626e ]--- Unable to handle kernel paging request at virtual address 2e6f2e7a pgd = c0004000 [2e6f2e7a] *pgd=00000000 Internal error: Oops: 15 [#2] ARM Modules linked in: ipt_MASQUERADE iscsi_tcp libiscsi_tcp libiscsi iptable_nat nf_nat_ipv4 nf_nat drbd lru_cache scsi_transport_iscsi iptable_mangle ipt_REJECT xt_conntrack iptable_filter ip_tables ext3 jbd autofs4 ext4 jbd2 mbcache sd_mod usb_storage mmc_block mvsdio mmc_core ehci_orion CPU: 0 PID: -1073560872 Comm: bash Tainted: G D 3.10.0-stock1 #23 task: ee1df440 ti: ee154000 task.ti: ee154000 PC is at acct_process+0x34/0x88 LR is at acct_process+0x20/0x88 pc : [<c005bb78>] lr : [<c005bb64>] psr: 20000013 sp : ee155d48 ip : ee155d48 fp : ee155d5c r10: ef238080 r9 : ee1df440 r8 : 00000017 r7 : ee154000 r6 : c034afb0 r5 : e5911018 r4 : ee154020 r3 : 00000000 r2 : ee155d48 r1 : ef238080 r0 : 2e6f2e72 Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 2f35c019 DAC: 00000015 Process bash (pid: -1073560872, stack limit = 0xee154230) Stack: (0xee155d48 to 0xee156000) 5d40: ee154020 00000000 ee155d94 ee155d60 c0022070 c005bb50 5d60: c03c45f0 00000001 ef2380b8 00000017 ee1df440 c03e0ac0 ee155d94 ee155d88 5d80: c001decc ee154000 ee155dd4 ee155d98 c0011afc c00219f4 ee154230 0000000b 5da0: 60000113 ee154000 c0356054 0000001c 00000017 ef238080 ee155f40 ef238080 5dc0: ee1df440 00000028 ee155dec ee155dd8 c02bd6dc c0011984 ee155f40 0000001c 5de0: ee155e8c ee155df0 c02c3794 c02bd67c ee155e14 ee155e00 c004374c c00435a4 5e00: ee7b1b80 00000000 00010000 00000000 ef2380b8 00000000 c03c9ea0 00000001 5e20: ee155e64 ee155e30 c00465a0 c03c9ed8 ee1dfb78 00000400 ee155e5c ee155e48 5e40: ffffffff 00000000 ee155e7c ee155e58 c02c3a88 c0009038 ffffffff ef18001c 5e60: ee1df440 00000017 c02c35b0 c03c5064 0000001c ee155f40 00000000 00000000 5e80: ee155f3c ee155e90 c0008428 c02c35bc c02c22b4 c02c3af8 ee155f44 ee155ea8 5ea0: c002dab0 c0022f58 00000011 c02c128c c03f6ab0 c03c00d0 c03e07c6 ee154018 5ec0: 00000000 00000000 ee155ef4 ee155ed8 c0042cbc c00465c4 00000000 ee1df440 5ee0: 00000001 ee1df440 ee155f14 ee155ef8 c0044cf8 c0042c98 00000000 ee1df440 5f00: 00000004 ee0bcb80 c03cb00c ee154000 00000000 ee1df534 ee1df438 c0037c4c 5f20: 60000013 ffffffff ee155f74 00000000 ee155f94 ee155f40 c02c1f18 c00083f4 5f40: ee1df440 00000000 00000000 ef181efc ee154000 bf000000 00000000 00000000 5f60: 00000000 00000000 00000000 ee155f94 ee155f88 ee155f88 c00439e0 c0037c4c 5f80: 60000013 ffffffff ee155fac ee155f98 c00439e0 c0037c18 00000000 00000000 5fa0: 00000000 ee155fb0 c000df48 c00439a8 00000000 00000000 00000000 00000000 5fc0: b6fc3068 bed65f08 48a50000 00000078 000d6d64 b6fc3000 000d63cc bed65f34 5fe0: b6fc34c0 bed65f08 00000a18 489aa0cc 60000010 01200011 00000000 00000000 Backtrace: [<c005bb44>] (acct_process+0x0/0x88) from [<c0022070>] (do_exit+0x688/0x87c) r5:00000000 r4:ee154020 [<c00219e8>] (do_exit+0x0/0x87c) from [<c0011afc>] (die+0x184/0x238) r7:ee154000 [<c0011978>] (die+0x0/0x238) from [<c02bd6dc>] (__do_kernel_fault.part.9+0x6c/0x7c) [<c02bd670>] (__do_kernel_fault.part.9+0x0/0x7c) from [<c02c3794>] (do_page_fault+0x1e4/0x3e4) r7:0000001c r3:ee155f40 [<c02c35b0>] (do_page_fault+0x0/0x3e4) from [<c0008428>] (do_DataAbort+0x40/0xa0) [<c00083e8>] (do_DataAbort+0x0/0xa0) from [<c02c1f18>] (__dabt_svc+0x38/0x60) Exception stack(0xee155f40 to 0xee155f88) 5f40: ee1df440 00000000 00000000 ef181efc ee154000 bf000000 00000000 00000000 5f60: 00000000 00000000 00000000 ee155f94 ee155f88 ee155f88 c00439e0 c0037c4c 5f80: 60000013 ffffffff r8:00000000 r7:ee155f74 r6:ffffffff r5:60000013 r4:c0037c4c [<c0037c0c>] (__task_pid_nr_ns+0x0/0xa4) from [<c00439e0>] (schedule_tail+0x44/0x64) [<c004399c>] (schedule_tail+0x0/0x64) from [<c000df48>] (ret_from_fork+0x4/0x3c) r5:00000000 r4:00000000 Code: 089da830 e595002c e3500000 0a00000f (e5903008) ---[ end trace 20369176bc42626f ]---
J.
On 7/21/2013 2:13, Jochen De Smet wrote:
And some more progress.
The network functions fine if and only if I use the network in U-boot, i.e. a simple "dhcp ; setenv ethact egiga1 ; dhcp" before booting from the sd makes everything work, at least temporarily. Bringing the interface up and down a few times appear to break things again, but as long as I just let it stay up it functions without any apparent issues.
So I guess this means there might be some initialization missing in the kernel driver for the 370 NICs ?
On a bright note, that means I now have both interfaces working on my F18 box as well; the reason eth0 didn't work there but eth1 did, was because eth1 is used there to network load the kernel/initrd.
I did still have to add a file /etc/udev/rules.d/40-network.rules with contents like this:
KERNELS=="d0070000.ethernet", RUN += "/sbin/ip link set dev eth0 address F0:AD:4E:01:E1:D2" KERNELS=="d0074000.ethernet", RUN += "/sbin/ip link set dev eth1 address F0:AD:4E:01:E1:D3"
to make NetworkManager happy (replace those MACs with the ones on the mirabox label if you're doing this), since otherwise I still ended up with a new random MAC on every boot.
I also re-learned that you do indeed have to copy your preferred kernel to uImage; you can't symlink it. Otherwise a kernel update through yum will happily overwrite your kernel. That also taught me that the updated F19 kernel (3.9.9-302) does not boot on the mirabox; it's worse than the 3.9.5-301 in the xz; no kernel output whatsoever.
One last note is on the microSD performance, which appears to be very slow from u-boot. Loading the 10MB initrd takes over 45 seconds, as compared to maybe 2 or 3 when loading from the network. Under linux, a copy of the same file also takes just a few seconds.
J.
On 7/20/2013 2:49, Jochen De Smet wrote:
Some progress.
Still can't get it to work with the fedora kernel, but I did manage to get it booted using the same kernel I use for F18 ; had to explicitly tell dracut to include the usb driver to be able to find the root partition.
Also had to enable the serial getty. Is there any particular reason why this isn't enabled by default on arm ?
So now I'm booted, but network-wise things are looking rather grim. I can see both interfaces, NetworkManager recognizes them, and ethtool confirms link at the expected speed. However that's as far as things get.
On eth0, running tcpdump shows me all my outgoing packets (DHCP/ARP) and even RIP packets from the router it's attached to, but nothing else. No DHCP reply from the router. Putting on a static IP doesn't help either.
On eth1, things are slightly worse. All the same problems as eth0, but in addition I'm seeing these when running tcpdump: mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=129 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=125 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=151 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=157 mvneta d0074000.ethernet eth1: bad rx status 0cc10000 (crc error), size=158
J.
On 7/19/2013 16:23, Jochen De Smet wrote:
On 7/19/2013 16:03, Jon wrote:
Here are my notes on MiraBox. (These are adapted from Jon Masters)
Thanks!
Indeed, the SD reader is behind a usb bus so usb needs to be started in u-boot to get to the card.
Using those instructions the kernel at least starts booting, makes it to the initrd but then appears to hang at this point:
[ OK ] Mounted Configuration File System. Starting LVM2 metadata daemon... [ OK ] Started Apply Kernel Variables. [ OK ] Started Create static device nodes in /dev. Starting udev Kernel Device Manager... [ OK ] Started LVM2 metadata daemon. systemd-fsck[239]: _/: clean, 44920/397488 files, 338291/1586914 blocks [ OK ] Started File System Check on Root Device. Starting Remount Root and Kernel File Systems... [ OK ] Started udev Kernel Device Manager. [ 214.643245] systemd-udevd[250]: starting version 204 [ 214.662018] EXT4-fs (sdb3): re-mounted. Opts: (null) [ OK ] Started udev Coldplug all Devices. Starting udev Wait for Complete Device Initialization... [ OK ] Started Remount Root and Kernel File Systems. [ OK ] Reached target Local File Systems (Pre). Starting Configure read-only root support... [ OK ] Started Monitoring of LVM2 mirrors, snapshots etc. u...ogress polling. [ OK ] Started Configure read-only root support. Starting Load Random Seed... [ OK ] Started Load Random Seed. [ OK ] Found device /dev/ttyS0. [ 215.468098] mvneta d0070000.ethernet eth0: mac: 06:a4:a7:49:fe:24 [ 215.522508] libphy: orion_mdio_bus: probed
I'll leave it alone for a while to see if it eventually makes it through. Should I expect some installer to start running at some point? Or is the root partition inside the image .xz really just the equivalent of the old FC18 root fs images with no more changes to it needed?
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
On 7/21/2013 2:13, Jochen De Smet wrote:
I did still have to add a file /etc/udev/rules.d/40-network.rules with contents like this:
KERNELS=="d0070000.ethernet", RUN += "/sbin/ip link set dev eth0 address F0:AD:4E:01:E1:D2" KERNELS=="d0074000.ethernet", RUN += "/sbin/ip link set dev eth1 address F0:AD:4E:01:E1:D3"
to make NetworkManager happy (replace those MACs with the ones on the mirabox label if you're doing this), since otherwise I still ended up with a new random MAC on every boot.
In case anyone interested, it appears kernel v3.11-rc1 and up contain a fix for the above, so the workaround should not be needed when using a kernel newer than that. Haven't tried it yet myself.
J.
On Wed, Jul 24, 2013 at 1:10 PM, Jochen De Smet jochen.arm@leahnim.orgwrote:
In case anyone interested, it appears kernel v3.11-rc1 and up contain a fix for the above, so the workaround should not be needed when using a kernel newer than that. Haven't tried it yet myself.
I tried the 3.11.0-0.rc2.git3.1.fc20.armv7hl kernel from Koji on my Mirabox this afternoon, and it completely hangs with no output. :-(
-- Jared Smith
On 7/26/2013 22:40, Jared K. Smith wrote:
On Wed, Jul 24, 2013 at 1:10 PM, Jochen De Smet <jochen.arm@leahnim.org mailto:jochen.arm@leahnim.org> wrote:
In case anyone interested, it appears kernel v3.11-rc1 and up contain a fix for the above, so the workaround should not be needed when using a kernel newer than that. Haven't tried it yet myself.I tried the 3.11.0-0.rc2.git3.1.fc20.armv7hl kernel from Koji on my Mirabox this afternoon, and it completely hangs with no output. :-(
Just in case you want to try it, I've put the kernel, initrd and modules I'm currently using here: http://www.leahnim.org:8080/~jochen/mira/
I haven't found a working pre-built Fedora kernel yet, and I still haven't had time to try and build a 3.11-rc2 since both my Miraboxes are now running F19 on which I haven't been able to build a good kernel yet.
J.
-- Jared Smith
Another update, and the news is mixed as usual.
A stock 3.11-rc3 kernel compiled on a F18 root fs appears to be working great, and not only does it solve the MAC address issue, it now also supports the USB ports on the mirabox.
On the downside, the exact same kernel compiled on F19 comes up but soon after startup hits these:
[ 330.307636] Unable to handle kernel paging request at virtual address bf370a58 [ 330.314988] pgd = ee12c000 [ 330.316393] [bf370a58] *pgd=2dd00811, *pte=00000000, *ppte=00000000 [ 330.321402] Internal error: Oops: 7 [#1] ARM [ 330.324371] Modules linked in: tun gfs2 sha1_generic drbd lru_cache dlm sctp configfs ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT xt_conntrack ebtable_filter ebtables iptable_filter ip_tables ext3 jbd autofs4 ext4 jbd2 mbcache sd_mod usb_storage mmc_block xhci_hcd mvsdio mmc_core ehci_orion [ 330.351619] CPU: 0 PID: 1774 Comm: lrmd Not tainted 3.11.0-rc3-stock1 #26 [ 330.357111] task: ee098540 ti: ee102000 task.ti: ee102000 [ 330.361220] PC is at copy_process.part.65+0x9ac/0xdd0 [ 330.364980] LR is at recalc_sigpending+0x20/0x70 [ 330.368299] pc : [<c001e1c0>] lr : [<c002cd48>] psr: 20000093 sp : ee103f00 ip : ee103efc fp : ee103f4c [ 330.377183] r10: b6fde068 r9 : ed126b40 r8 : c03ffbf8 [ 330.381111] r7 : ed126c7c r6 : c0417f40 r5 : ee102000 r4 : 01200011 [ 330.386342] r3 : bf370a3c r2 : eea65a40 r1 : ee098540 r0 : 00000000 [ 330.391575] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 330.397503] Control: 10c5387d Table: 2e12c019 DAC: 00000015 [ 330.401951] Process lrmd (pid: 1774, stack limit = 0xee102230) [ 330.406487] Stack: (0xee103f00 to 0xee104000) [ 330.409549] 3f00: ed126cb4 00000000 ed126c3c 00000000 00000000 00000000 ee103f78 fffffff4 [ 330.416436] 3f20: ee102000 01200011 00020200 00000000 00000000 00000000 ee102000 00000000 [ 330.423323] 3f40: ee103f8c ee103f50 c001e734 c001d820 ee103efc 00000000 00000000 c0157bb4 [ 330.430211] 3f60: ee103f94 ee103f70 c00ba6b8 b6fde068 bee38828 48a50000 00000078 c000e6a8 [ 330.437098] 3f80: ee103fa4 ee103f90 c001ea18 c001e6a4 b6fde068 c00ba614 00000000 ee103fa8 [ 330.443986] 3fa0: c000e500 c001ea00 b6fde068 bee38828 01200011 00000000 00000000 00000000 [ 330.450874] 3fc0: b6fde068 bee38828 48a50000 00000078 46ba4000 b6fde000 0003c138 bee38864 [ 330.457761] 3fe0: b6fde4c0 bee38828 000006ee 489aa0cc 60000010 01200011 3ec52a3e 3ec53a3e [ 330.464643] Backtrace: [ 330.465805] [<c001d814>] (copy_process.part.65+0x0/0xdd0) from [<c001e734>] (do_fork+0x9c/0x2c4) [ 330.473303] [<c001e698>] (do_fork+0x0/0x2c4) from [<c001ea18>] (SyS_clone+0x24/0x2c) [ 330.479750] r8:c000e6a8 r7:00000078 r6:48a50000 r5:bee38828 r4:b6fde068 [ 330.485218] [<c001e9f4>] (SyS_clone+0x0/0x2c) from [<c000e500>] (ret_fast_syscall+0x0/0x30) [ 330.492279] Code: e5933138 e5893138 e59c3004 e08c3203 (e593201c) [ 330.497077] ---[ end trace 836c3039ee5ba43a ]--- [ 333.601499] ------------[ cut here ]------------ [ 333.605836] Kernel BUG at c00c4f18 [verbose debug info unavailable] [ 333.610809] Internal error: Oops - BUG: 0 [#2] ARM [ 333.614300] Modules linked in: tun gfs2 sha1_generic drbd lru_cache dlm sctp configfs ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT xt_conntrack ebtable_filter ebtables iptable_filter ip_tables ext3 jbd autofs4 ext4 jbd2 mbcache sd_mod usb_storage mmc_block xhci_hcd mvsdio mmc_core ehci_orion [ 333.641540] CPU: 0 PID: 3498 Comm: httpd Tainted: G D 3.11.0-rc3-stock1 #26 [ 333.648077] task: ed17f480 ti: ed228000 task.ti: ed228000 [ 333.652188] PC is at dput+0x150/0x154 [ 333.654552] LR is at __fput+0x108/0x1f4 [ 333.657090] pc : [<c00c4f18>] lr : [<c00b3a78>] psr: 60000013 sp : ed229f10 ip : ed229f28 fp : ed229f24 [ 333.665974] r10: ee359b08 r9 : 00000000 r8 : 40000010 [ 333.669901] r7 : ed8fe080 r6 : ee7fb810 r5 : ed903778 r4 : ed903778 [ 333.675132] r3 : 00000000 r2 : 20000013 r1 : c04020c8 r0 : ed903778 [ 333.680364] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 333.686204] Control: 10c5387d Table: 2d1c4019 DAC: 00000015 [ 333.690653] Process httpd (pid: 3498, stack limit = 0xed228230) [ 333.695276] Stack: (0xed229f10 to 0xed22a000) [ 333.698336] 9f00: ee359b00 ed903778 ed229f5c ed229f28 [ 333.705224] 9f20: c00b3a78 c00c4dd4 00000000 00000000 c00b3efc ed17f738 ed17f480 c041e694 [ 333.712111] 9f40: 00000000 c000e6a8 ed228000 00000000 ed229f6c ed229f60 c00b3bbc c00b397c [ 333.718999] 9f60: ed229f8c ed229f70 c00398a4 c00b3bb8 ed228010 ed228000 c000e6a8 ed229fb0 [ 333.725887] 9f80: ed229fac ed229f90 c00118b0 c0039810 00000004 b705d790 b7023a68 00000006 [ 333.732774] 9fa0: 00000000 ed229fb0 c000e540 c0011830 00000000 00000000 00000001 00000001 [ 333.739662] 9fc0: 00000004 b705d790 b7023a68 00000006 b705d8d8 b705d770 b6fcb0a8 bedac5e8 [ 333.746549] 9fe0: 00000000 bedabf00 b6bad2b8 b6b76294 60000010 00000004 00000000 00000000 [ 333.753431] Backtrace: [ 333.754592] [<c00c4dc8>] (dput+0x0/0x154) from [<c00b3a78>] (__fput+0x108/0x1f4) [ 333.760692] r5:ed903778 r4:ee359b00 [ 333.762991] [<c00b3970>] (__fput+0x0/0x1f4) from [<c00b3bbc>] (____fput+0x10/0x14) [ 333.769277] [<c00b3bac>] (____fput+0x0/0x14) from [<c00398a4>] (task_work_run+0xa0/0xb4) [ 333.776086] [<c0039804>] (task_work_run+0x0/0xb4) from [<c00118b0>] (do_work_pending+0x8c/0xac) [ 333.783490] r7:ed229fb0 r6:c000e6a8 r5:ed228000 r4:ed228010 [ 333.787902] [<c0011824>] (do_work_pending+0x0/0xac) from [<c000e540>] (work_pending+0xc/0x20) [ 333.795131] r7:00000006 r6:b7023a68 r5:b705d790 r4:00000004 [ 333.799540] Code: e5820004 e2812001 e583207c eaffffe4 (e7f001f2) [ 333.804339] ---[ end trace 836c3039ee5ba43b ]---
Unfortunately I have no idea how to debug this. Should I file a bug against this? Since it's a stock kernel I don't know if it would be accepted on the fedora bugzilla. Of course the fedora kernels aren't working at all on mirabox, so maybe a bug should be filed for that as well? Unfortunately there's even less information I can supply about what the issue is there.
J.
On 7/27/2013 15:57, Jochen De Smet wrote:
On 7/26/2013 22:40, Jared K. Smith wrote:
On Wed, Jul 24, 2013 at 1:10 PM, Jochen De Smet <jochen.arm@leahnim.org mailto:jochen.arm@leahnim.org> wrote:
In case anyone interested, it appears kernel v3.11-rc1 and up contain a fix for the above, so the workaround should not be needed when using a kernel newer than that. Haven't tried it yet myself.I tried the 3.11.0-0.rc2.git3.1.fc20.armv7hl kernel from Koji on my Mirabox this afternoon, and it completely hangs with no output. :-(
Just in case you want to try it, I've put the kernel, initrd and modules I'm currently using here: http://www.leahnim.org:8080/~jochen/mira/
I haven't found a working pre-built Fedora kernel yet, and I still haven't had time to try and build a 3.11-rc2 since both my Miraboxes are now running F19 on which I haven't been able to build a good kernel yet.
J.
-- Jared Smith
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
Maybe gcc is the problem?
Perhaps install gcc from f19 into the f18 builder, see if that also fails. On Jul 31, 2013 9:30 AM, "Jochen De Smet" jochen.arm@leahnim.org wrote:
Another update, and the news is mixed as usual.
A stock 3.11-rc3 kernel compiled on a F18 root fs appears to be working great, and not only does it solve the MAC address issue, it now also supports the USB ports on the mirabox.
On the downside, the exact same kernel compiled on F19 comes up but soon after startup hits these:
[ 330.307636] Unable to handle kernel paging request at virtual address bf370a58 [ 330.314988] pgd = ee12c000 [ 330.316393] [bf370a58] *pgd=2dd00811, *pte=00000000, *ppte=00000000 [ 330.321402] Internal error: Oops: 7 [#1] ARM [ 330.324371] Modules linked in: tun gfs2 sha1_generic drbd lru_cache dlm sctp configfs ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT xt_conntrack ebtable_filter ebtables iptable_filter ip_tables ext3 jbd autofs4 ext4 jbd2 mbcache sd_mod usb_storage mmc_block xhci_hcd mvsdio mmc_core ehci_orion [ 330.351619] CPU: 0 PID: 1774 Comm: lrmd Not tainted 3.11.0-rc3-stock1 #26 [ 330.357111] task: ee098540 ti: ee102000 task.ti: ee102000 [ 330.361220] PC is at copy_process.part.65+0x9ac/0xdd0 [ 330.364980] LR is at recalc_sigpending+0x20/0x70 [ 330.368299] pc : [<c001e1c0>] lr : [<c002cd48>] psr: 20000093 sp : ee103f00 ip : ee103efc fp : ee103f4c [ 330.377183] r10: b6fde068 r9 : ed126b40 r8 : c03ffbf8 [ 330.381111] r7 : ed126c7c r6 : c0417f40 r5 : ee102000 r4 : 01200011 [ 330.386342] r3 : bf370a3c r2 : eea65a40 r1 : ee098540 r0 : 00000000 [ 330.391575] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 330.397503] Control: 10c5387d Table: 2e12c019 DAC: 00000015 [ 330.401951] Process lrmd (pid: 1774, stack limit = 0xee102230) [ 330.406487] Stack: (0xee103f00 to 0xee104000) [ 330.409549] 3f00: ed126cb4 00000000 ed126c3c 00000000 00000000 00000000 ee103f78 fffffff4 [ 330.416436] 3f20: ee102000 01200011 00020200 00000000 00000000 00000000 ee102000 00000000 [ 330.423323] 3f40: ee103f8c ee103f50 c001e734 c001d820 ee103efc 00000000 00000000 c0157bb4 [ 330.430211] 3f60: ee103f94 ee103f70 c00ba6b8 b6fde068 bee38828 48a50000 00000078 c000e6a8 [ 330.437098] 3f80: ee103fa4 ee103f90 c001ea18 c001e6a4 b6fde068 c00ba614 00000000 ee103fa8 [ 330.443986] 3fa0: c000e500 c001ea00 b6fde068 bee38828 01200011 00000000 00000000 00000000 [ 330.450874] 3fc0: b6fde068 bee38828 48a50000 00000078 46ba4000 b6fde000 0003c138 bee38864 [ 330.457761] 3fe0: b6fde4c0 bee38828 000006ee 489aa0cc 60000010 01200011 3ec52a3e 3ec53a3e [ 330.464643] Backtrace: [ 330.465805] [<c001d814>] (copy_process.part.65+0x0/0xdd0) from [<c001e734>] (do_fork+0x9c/0x2c4) [ 330.473303] [<c001e698>] (do_fork+0x0/0x2c4) from [<c001ea18>] (SyS_clone+0x24/0x2c) [ 330.479750] r8:c000e6a8 r7:00000078 r6:48a50000 r5:bee38828 r4:b6fde068 [ 330.485218] [<c001e9f4>] (SyS_clone+0x0/0x2c) from [<c000e500>] (ret_fast_syscall+0x0/0x30) [ 330.492279] Code: e5933138 e5893138 e59c3004 e08c3203 (e593201c) [ 330.497077] ---[ end trace 836c3039ee5ba43a ]--- [ 333.601499] ------------[ cut here ]------------ [ 333.605836] Kernel BUG at c00c4f18 [verbose debug info unavailable] [ 333.610809] Internal error: Oops - BUG: 0 [#2] ARM [ 333.614300] Modules linked in: tun gfs2 sha1_generic drbd lru_cache dlm sctp configfs ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT xt_conntrack ebtable_filter ebtables iptable_filter ip_tables ext3 jbd autofs4 ext4 jbd2 mbcache sd_mod usb_storage mmc_block xhci_hcd mvsdio mmc_core ehci_orion [ 333.641540] CPU: 0 PID: 3498 Comm: httpd Tainted: G D 3.11.0-rc3-stock1 #26 [ 333.648077] task: ed17f480 ti: ed228000 task.ti: ed228000 [ 333.652188] PC is at dput+0x150/0x154 [ 333.654552] LR is at __fput+0x108/0x1f4 [ 333.657090] pc : [<c00c4f18>] lr : [<c00b3a78>] psr: 60000013 sp : ed229f10 ip : ed229f28 fp : ed229f24 [ 333.665974] r10: ee359b08 r9 : 00000000 r8 : 40000010 [ 333.669901] r7 : ed8fe080 r6 : ee7fb810 r5 : ed903778 r4 : ed903778 [ 333.675132] r3 : 00000000 r2 : 20000013 r1 : c04020c8 r0 : ed903778 [ 333.680364] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 333.686204] Control: 10c5387d Table: 2d1c4019 DAC: 00000015 [ 333.690653] Process httpd (pid: 3498, stack limit = 0xed228230) [ 333.695276] Stack: (0xed229f10 to 0xed22a000) [ 333.698336] 9f00: ee359b00 ed903778 ed229f5c ed229f28 [ 333.705224] 9f20: c00b3a78 c00c4dd4 00000000 00000000 c00b3efc ed17f738 ed17f480 c041e694 [ 333.712111] 9f40: 00000000 c000e6a8 ed228000 00000000 ed229f6c ed229f60 c00b3bbc c00b397c [ 333.718999] 9f60: ed229f8c ed229f70 c00398a4 c00b3bb8 ed228010 ed228000 c000e6a8 ed229fb0 [ 333.725887] 9f80: ed229fac ed229f90 c00118b0 c0039810 00000004 b705d790 b7023a68 00000006 [ 333.732774] 9fa0: 00000000 ed229fb0 c000e540 c0011830 00000000 00000000 00000001 00000001 [ 333.739662] 9fc0: 00000004 b705d790 b7023a68 00000006 b705d8d8 b705d770 b6fcb0a8 bedac5e8 [ 333.746549] 9fe0: 00000000 bedabf00 b6bad2b8 b6b76294 60000010 00000004 00000000 00000000 [ 333.753431] Backtrace: [ 333.754592] [<c00c4dc8>] (dput+0x0/0x154) from [<c00b3a78>] (__fput+0x108/0x1f4) [ 333.760692] r5:ed903778 r4:ee359b00 [ 333.762991] [<c00b3970>] (__fput+0x0/0x1f4) from [<c00b3bbc>] (____fput+0x10/0x14) [ 333.769277] [<c00b3bac>] (____fput+0x0/0x14) from [<c00398a4>] (task_work_run+0xa0/0xb4) [ 333.776086] [<c0039804>] (task_work_run+0x0/0xb4) from [<c00118b0>] (do_work_pending+0x8c/0xac) [ 333.783490] r7:ed229fb0 r6:c000e6a8 r5:ed228000 r4:ed228010 [ 333.787902] [<c0011824>] (do_work_pending+0x0/0xac) from [<c000e540>] (work_pending+0xc/0x20) [ 333.795131] r7:00000006 r6:b7023a68 r5:b705d790 r4:00000004 [ 333.799540] Code: e5820004 e2812001 e583207c eaffffe4 (e7f001f2) [ 333.804339] ---[ end trace 836c3039ee5ba43b ]---
Unfortunately I have no idea how to debug this. Should I file a bug against this? Since it's a stock kernel I don't know if it would be accepted on the fedora bugzilla. Of course the fedora kernels aren't working at all on mirabox, so maybe a bug should be filed for that as well? Unfortunately there's even less information I can supply about what the issue is there.
J.
On 7/27/2013 15:57, Jochen De Smet wrote:
On 7/26/2013 22:40, Jared K. Smith wrote:
On Wed, Jul 24, 2013 at 1:10 PM, Jochen De Smet jochen.arm@leahnim.orgwrote:
In case anyone interested, it appears kernel v3.11-rc1 and up contain a fix for the above, so the workaround should not be needed when using a kernel newer than that. Haven't tried it yet myself.
I tried the 3.11.0-0.rc2.git3.1.fc20.armv7hl kernel from Koji on my Mirabox this afternoon, and it completely hangs with no output. :-(
Just in case you want to try it, I've put the kernel, initrd and modules I'm currently using here: http://www.leahnim.org:8080/~jochen/mira/
I haven't found a working pre-built Fedora kernel yet, and I still haven't had time to try and build a 3.11-rc2 since both my Miraboxes are now running F19 on which I haven't been able to build a good kernel yet.
J.
-- Jared Smith
arm mailing listarm@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/arm
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On 7/31/2013 14:15, Jon wrote:
Maybe gcc is the problem?
Perhaps install gcc from f19 into the f18 builder, see if that also fails.
This appears to be somewhat less than trivial. Can't install the f19 rpm directly, since the dependency chain appears rather long and includes glibc.
I tried just rebuilding the f19 gcc rpm on f18, but that ends up bombing out with:
+ ../../isl-0.11.1/configure --disable-shared CC=/usr/bin/gcc CXX=/usr/bin/g++ 'CFLAGS=-O2 -g -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -fpic' --prefix=/dir/rpm/BUILD/gcc-4.8.1-20130603/obj-armv7hl-redhat-linux/isl-install checking for a BSD-compatible install... /bin/install -c checking whether build environment is sane... yes <<<cut>>> checking whether to build shared libraries... no checking whether to build static libraries... yes checking how to run the C++ preprocessor... /lib/cpp configure: error: in `/dungeon/jochen/rpm/BUILD/gcc-4.8.1-20130603/obj-armv7hl-redhat-linux/isl-build': configure: error: C++ preprocessor "/lib/cpp" fails sanity check See `config.log' for more details error: Bad exit status from /var/tmp/rpm-tmp.p79HhW (%build)
I'll probable try the reverse next, i.e. install f18's gcc in my f19 environment.
J.
On Jul 31, 2013 9:30 AM, "Jochen De Smet" <jochen.arm@leahnim.org mailto:jochen.arm@leahnim.org> wrote:
Another update, and the news is mixed as usual. A stock 3.11-rc3 kernel compiled on a F18 root fs appears to be working great, and not only does it solve the MAC address issue, it now also supports the USB ports on the mirabox. On the downside, the exact same kernel compiled on F19 comes up but soon after startup hits these: [ 330.307636] Unable to handle kernel paging request at virtual address bf370a58 [ 330.314988] pgd = ee12c000 [ 330.316393] [bf370a58] *pgd=2dd00811, *pte=00000000, *ppte=00000000 [ 330.321402] Internal error: Oops: 7 [#1] ARM [ 330.324371] Modules linked in: tun gfs2 sha1_generic drbd lru_cache dlm sctp configfs ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT xt_conntrack ebtable_filter ebtables iptable_filter ip_tables ext3 jbd autofs4 ext4 jbd2 mbcache sd_mod usb_storage mmc_block xhci_hcd mvsdio mmc_core ehci_orion [ 330.351619] CPU: 0 PID: 1774 Comm: lrmd Not tainted 3.11.0-rc3-stock1 #26 [ 330.357111] task: ee098540 ti: ee102000 task.ti: ee102000 [ 330.361220] PC is at copy_process.part.65+0x9ac/0xdd0 [ 330.364980] LR is at recalc_sigpending+0x20/0x70 [ 330.368299] pc : [<c001e1c0>] lr : [<c002cd48>] psr: 20000093 sp : ee103f00 ip : ee103efc fp : ee103f4c [ 330.377183] r10: b6fde068 r9 : ed126b40 r8 : c03ffbf8 [ 330.381111] r7 : ed126c7c r6 : c0417f40 r5 : ee102000 r4 : 01200011 [ 330.386342] r3 : bf370a3c r2 : eea65a40 r1 : ee098540 r0 : 00000000 [ 330.391575] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user [ 330.397503] Control: 10c5387d Table: 2e12c019 DAC: 00000015 [ 330.401951] Process lrmd (pid: 1774, stack limit = 0xee102230) [ 330.406487] Stack: (0xee103f00 to 0xee104000) [ 330.409549] 3f00: ed126cb4 00000000 ed126c3c 00000000 00000000 00000000 ee103f78 fffffff4 [ 330.416436] 3f20: ee102000 01200011 00020200 00000000 00000000 00000000 ee102000 00000000 [ 330.423323] 3f40: ee103f8c ee103f50 c001e734 c001d820 ee103efc 00000000 00000000 c0157bb4 [ 330.430211] 3f60: ee103f94 ee103f70 c00ba6b8 b6fde068 bee38828 48a50000 00000078 c000e6a8 [ 330.437098] 3f80: ee103fa4 ee103f90 c001ea18 c001e6a4 b6fde068 c00ba614 00000000 ee103fa8 [ 330.443986] 3fa0: c000e500 c001ea00 b6fde068 bee38828 01200011 00000000 00000000 00000000 [ 330.450874] 3fc0: b6fde068 bee38828 48a50000 00000078 46ba4000 b6fde000 0003c138 bee38864 [ 330.457761] 3fe0: b6fde4c0 bee38828 000006ee 489aa0cc 60000010 01200011 3ec52a3e 3ec53a3e [ 330.464643] Backtrace: [ 330.465805] [<c001d814>] (copy_process.part.65+0x0/0xdd0) from [<c001e734>] (do_fork+0x9c/0x2c4) [ 330.473303] [<c001e698>] (do_fork+0x0/0x2c4) from [<c001ea18>] (SyS_clone+0x24/0x2c) [ 330.479750] r8:c000e6a8 r7:00000078 r6:48a50000 r5:bee38828 r4:b6fde068 [ 330.485218] [<c001e9f4>] (SyS_clone+0x0/0x2c) from [<c000e500>] (ret_fast_syscall+0x0/0x30) [ 330.492279] Code: e5933138 e5893138 e59c3004 e08c3203 (e593201c) [ 330.497077] ---[ end trace 836c3039ee5ba43a ]--- [ 333.601499] ------------[ cut here ]------------ [ 333.605836] Kernel BUG at c00c4f18 [verbose debug info unavailable] [ 333.610809] Internal error: Oops - BUG: 0 [#2] ARM [ 333.614300] Modules linked in: tun gfs2 sha1_generic drbd lru_cache dlm sctp configfs ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat iptable_mangle ipt_REJECT xt_conntrack ebtable_filter ebtables iptable_filter ip_tables ext3 jbd autofs4 ext4 jbd2 mbcache sd_mod usb_storage mmc_block xhci_hcd mvsdio mmc_core ehci_orion [ 333.641540] CPU: 0 PID: 3498 Comm: httpd Tainted: G D 3.11.0-rc3-stock1 #26 [ 333.648077] task: ed17f480 ti: ed228000 task.ti: ed228000 [ 333.652188] PC is at dput+0x150/0x154 [ 333.654552] LR is at __fput+0x108/0x1f4 [ 333.657090] pc : [<c00c4f18>] lr : [<c00b3a78>] psr: 60000013 sp : ed229f10 ip : ed229f28 fp : ed229f24 [ 333.665974] r10: ee359b08 r9 : 00000000 r8 : 40000010 [ 333.669901] r7 : ed8fe080 r6 : ee7fb810 r5 : ed903778 r4 : ed903778 [ 333.675132] r3 : 00000000 r2 : 20000013 r1 : c04020c8 r0 : ed903778 [ 333.680364] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 333.686204] Control: 10c5387d Table: 2d1c4019 DAC: 00000015 [ 333.690653] Process httpd (pid: 3498, stack limit = 0xed228230) [ 333.695276] Stack: (0xed229f10 to 0xed22a000) [ 333.698336] 9f00: ee359b00 ed903778 ed229f5c ed229f28 [ 333.705224] 9f20: c00b3a78 c00c4dd4 00000000 00000000 c00b3efc ed17f738 ed17f480 c041e694 [ 333.712111] 9f40: 00000000 c000e6a8 ed228000 00000000 ed229f6c ed229f60 c00b3bbc c00b397c [ 333.718999] 9f60: ed229f8c ed229f70 c00398a4 c00b3bb8 ed228010 ed228000 c000e6a8 ed229fb0 [ 333.725887] 9f80: ed229fac ed229f90 c00118b0 c0039810 00000004 b705d790 b7023a68 00000006 [ 333.732774] 9fa0: 00000000 ed229fb0 c000e540 c0011830 00000000 00000000 00000001 00000001 [ 333.739662] 9fc0: 00000004 b705d790 b7023a68 00000006 b705d8d8 b705d770 b6fcb0a8 bedac5e8 [ 333.746549] 9fe0: 00000000 bedabf00 b6bad2b8 b6b76294 60000010 00000004 00000000 00000000 [ 333.753431] Backtrace: [ 333.754592] [<c00c4dc8>] (dput+0x0/0x154) from [<c00b3a78>] (__fput+0x108/0x1f4) [ 333.760692] r5:ed903778 r4:ee359b00 [ 333.762991] [<c00b3970>] (__fput+0x0/0x1f4) from [<c00b3bbc>] (____fput+0x10/0x14) [ 333.769277] [<c00b3bac>] (____fput+0x0/0x14) from [<c00398a4>] (task_work_run+0xa0/0xb4) [ 333.776086] [<c0039804>] (task_work_run+0x0/0xb4) from [<c00118b0>] (do_work_pending+0x8c/0xac) [ 333.783490] r7:ed229fb0 r6:c000e6a8 r5:ed228000 r4:ed228010 [ 333.787902] [<c0011824>] (do_work_pending+0x0/0xac) from [<c000e540>] (work_pending+0xc/0x20) [ 333.795131] r7:00000006 r6:b7023a68 r5:b705d790 r4:00000004 [ 333.799540] Code: e5820004 e2812001 e583207c eaffffe4 (e7f001f2) [ 333.804339] ---[ end trace 836c3039ee5ba43b ]--- Unfortunately I have no idea how to debug this. Should I file a bug against this? Since it's a stock kernel I don't know if it would be accepted on the fedora bugzilla. Of course the fedora kernels aren't working at all on mirabox, so maybe a bug should be filed for that as well? Unfortunately there's even less information I can supply about what the issue is there. J. On 7/27/2013 15:57, Jochen De Smet wrote:On 7/26/2013 22:40, Jared K. Smith wrote:On Wed, Jul 24, 2013 at 1:10 PM, Jochen De Smet <jochen.arm@leahnim.org <mailto:jochen.arm@leahnim.org>> wrote: In case anyone interested, it appears kernel v3.11-rc1 and up contain a fix for the above, so the workaround should not be needed when using a kernel newer than that. Haven't tried it yet myself. I tried the 3.11.0-0.rc2.git3.1.fc20.armv7hl kernel from Koji on my Mirabox this afternoon, and it completely hangs with no output. :-(Just in case you want to try it, I've put the kernel, initrd and modules I'm currently using here: http://www.leahnim.org:8080/~jochen/mira/ <http://www.leahnim.org:8080/%7Ejochen/mira/> I haven't found a working pre-built Fedora kernel yet, and I still haven't had time to try and build a 3.11-rc2 since both my Miraboxes are now running F19 on which I haven't been able to build a good kernel yet. J.-- Jared Smith_______________________________________________ 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
On Fri, Jul 19, 2013 at 1:03 PM, Jon jdisnard@gmail.com wrote:
Here are my notes on MiraBox. (These are adapted from Jon Masters)
Thanks for posting these! I'm still not able to get them to work -- maybe someone on the list can tell me what I'm doing wrong. I started by downloading Fedora-Minimal-armhfp-19-1-sda.raw.xz, finding that the micro-sd card was showing up as /dev/sdb on my system, and then doing (as root):
xzcat Fedora-Minimal-armhfp-19-1-sda.raw.xz > /dev/sdb
After the light on the SD card reader stopped blinking, I ran "sync" a couple of times to ensure that the data had all been written. I then examine the SD card -- it had three partitions: a boot partition, a swap partition, and a root partition. Everything looked in order so far.
[jon@shambhala ~]$ cat mira-notes.txt #version=3.9.5-301.fc19 version=3.10.0-1.fc20
# change to the boot directory on the rootfs # all paths are relative to the boot partition.
cat vmlinuz-${version}.armv7hl \ dtb-${version}.armv7hl/armada-370-mirabox.dtb > \ vmlinuz-${version}.armv7hl.mirabox-adtb
mkimage -A arm -O linux -T kernel -C none \ -a 0x00008000 -e 0x00008000 \ -n "${version}.armv7hl.mirabox-adtb" \ -d vmlinuz-${version}.armv7hl.mirabox-adtb \ uImage-${version}.armv7hl.mirabox-adtb
/bin/cp -f uImage-${version}.armv7hl.mirabox-adtb uImage /bin/cp -f uInitrd-${version}.armv7hl uInitrd
I followed all of these commands, and created the new uImage with the appended dtb. So far so good.
# bellow are the u-boot commands
setenv bootcmd 'usb start; ext2load usb 1:1 0x02000000 uImage; ext2load usb 1:1 0x02800000 uInitrd; bootm 0x02000000 0x02800000' setenv bootargs 'ro rootwait earlyprintk debug root=/dev/sdb3 console=ttyS0,115200' run bootcmd
This is where I ran into problems. When I run the "ext2load usb 1:1" command, I get an error message:
Marvell>> ext2load usb 1:1 0x02000000 uImage ** Bad partition 1 **
Any idea why I'd be getting a "bad partition" message? Here's the output of parted on the SD card:
[root@hockey ISO]# parted /dev/sdb print Model: USB Mass Storage Device (scsi) Disk /dev/sdb: 15.7GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 1 1000kB 513MB 512MB primary ext3 boot 2 513MB 1025MB 512MB primary linux-swap(v1) 3 1025MB 15.7GB 14.7GB primary ext4
I'll continue to fiddle with this again today.
-- Jared Smith
On 7/21/2013 11:17, Jared K. Smith wrote:
# bellow are the u-boot commands setenv bootcmd 'usb start; ext2load usb 1:1 0x02000000 uImage; ext2load usb 1:1 0x02800000 uInitrd; bootm 0x02000000 0x02800000' setenv bootargs 'ro rootwait earlyprintk debug root=/dev/sdb3 console=ttyS0,115200' run bootcmdThis is where I ran into problems. When I run the "ext2load usb 1:1" command, I get an error message:
Marvell>> ext2load usb 1:1 0x02000000 uImage ** Bad partition 1 **
What's the output you get from "usb start" ? Should be someting like
Marvell>> usb start (Re)start USB... USB: Active port: invalid port number 2, switching to port 0 Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 4 USB Device(s) found Waiting for storage device(s) to settle before scanning... scanning bus for storage devices... Device NOT ready Request Sense returned 02 3A 00 2 Storage Device(s) found Marvell>>
Does it see your sd card as device 1? i.e.
Marvell>> usb storage Device 0: Vendor: Generic Rev: 9451 Prod: STORAGE DEVICE Type: Removable Hard Disk Capacity: not available Device 1: Vendor: Generic Rev: 9451 Prod: STORAGE DEVICE Type: Removable Hard Disk Capacity: 15407.0 MB = 15.0 GB (31553536 x 512)
And does u-boot see the partitions?
Marvell>> usb part 1 print_part of 1
Partition Map for USB device 1 -- Partition Type: DOS
Partition Start Sector Num Sectors Type 1 1953 1000001 83 2 1001954 1000000 83 3 2001954 12695312 83
J.
Any idea why I'd be getting a "bad partition" message? Here's the output of parted on the SD card:
[root@hockey ISO]# parted /dev/sdb print Model: USB Mass Storage Device (scsi) Disk /dev/sdb: 15.7GB Sector size (logical/physical): 512B/512B Partition Table: msdos Disk Flags:
Number Start End Size Type File system Flags 1 1000kB 513MB 512MB primary ext3 boot 2 513MB 1025MB 512MB primary linux-swap(v1) 3 1025MB 15.7GB 14.7GB primary ext4
I'll continue to fiddle with this again today.
-- Jared Smith
arm mailing list arm@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/arm
On Sun, Jul 21, 2013 at 9:01 AM, Jochen De Smet jochen.arm@leahnim.orgwrote:
What's the output you get from "usb start" ? Should be someting like
Marvell>> usb start (Re)start USB... USB: Active port: invalid port number 2, switching to port 0 Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 4 USB Device(s) found Waiting for storage device(s) to settle before scanning... scanning bus for storage devices... Device NOT ready Request Sense returned 02 3A 00 2 Storage Device(s) found Marvell>>
That's exactly what I was getting.
Does it see your sd card as device 1? i.e.
Marvell>> usb storage Device 0: Vendor: Generic Rev: 9451 Prod: STORAGE DEVICE Type: Removable Hard Disk Capacity: not available Device 1: Vendor: Generic Rev: 9451 Prod: STORAGE DEVICE Type: Removable Hard Disk Capacity: 15407.0 MB = 15.0 GB (31553536 x 512)
No, the Mirabox wasn't seeing the card for some reason. I've tried again with another SD card, and it's seeing this one, so I'm able to get a bit further. I can now get the kernel to boot, but it hangs almost immediately after the line that says "[ OK ] Found device /dev/ttyS0." For what it's worth, this is the same place my OpenBlocks AX3 is hanging as well -- so I'm wondering if this is a problem across all the Armada-XP systems.
Anybody have any other ideas on how to work around this problem?
-- Jared Smith
On Sun, Jul 21, 2013 at 9:07 AM, Jared K. Smith jsmith@fedoraproject.orgwrote:
No, the Mirabox wasn't seeing the card for some reason. I've tried again with another SD card, and it's seeing this one, so I'm able to get a bit further. I can now get the kernel to boot, but it hangs almost immediately after the line that says "[ OK ] Found device /dev/ttyS0." For what it's worth, this is the same place my OpenBlocks AX3 is hanging as well -- so I'm wondering if this is a problem across all the Armada-XP systems.
I meant to paste a link to the output, in case someone can read through it and spot anything that looks fishy:
http://paste.fedoraproject.org/26857/
-- Jared Smith
On 7/21/2013 12:07, Jared K. Smith wrote:
On Sun, Jul 21, 2013 at 9:01 AM, Jochen De Smet <jochen.arm@leahnim.org mailto:jochen.arm@leahnim.org> wrote:
What's the output you get from "usb start" ? Should be someting like Marvell>> usb start (Re)start USB... USB: Active port: invalid port number 2, switching to port 0 Register 10011 NbrPorts 1 USB EHCI 1.00 scanning bus for devices... 4 USB Device(s) found Waiting for storage device(s) to settle before scanning... scanning bus for storage devices... Device NOT ready Request Sense returned 02 3A 00 2 Storage Device(s) found Marvell>>That's exactly what I was getting.
Does it see your sd card as device 1? i.e. Marvell>> usb storage Device 0: Vendor: Generic Rev: 9451 Prod: STORAGE DEVICE Type: Removable Hard Disk Capacity: not available Device 1: Vendor: Generic Rev: 9451 Prod: STORAGE DEVICE Type: Removable Hard Disk Capacity: 15407.0 MB = 15.0 GB (31553536 x 512)No, the Mirabox wasn't seeing the card for some reason. I've tried again with another SD card, and it's seeing this one, so I'm able to get a bit further. I can now get the kernel to boot, but it hangs almost immediately after the line that says "[ OK ] Found device /dev/ttyS0." For what it's worth, this is the same place my OpenBlocks AX3 is hanging as well -- so I'm wondering if this is a problem across all the Armada-XP systems.
Mirabox is Armada-370, not Armada-XP.
Which kernel are you using? What you get matches what I see with the F19 kernel inside the xz archive.
It works fine for me when I compile a stock 3.10 kernel, using this config: http://pastebin.com/Qcj8vTs7
You should probably also enable the serial getty if you want to be able to log in after the system comes up:
[root@stock ~]# ll /etc/systemd/system/getty.target.wants/ total 0 lrwxrwxrwx. 1 root root 38 Jun 27 15:23 getty@tty1.service -> /usr/lib/systemd/system/getty@.service lrwxrwxrwx 1 root root 45 Jul 20 01:21 serial-getty@ttyS0.service -> /usr/lib/systemd/system/serial-getty@.service [root@stock ~]#
J.
Anybody have any other ideas on how to work around this problem?
-- Jared Smith
-
Jared K. Smith -
Jochen De Smet -
Jon