Will attempt to reproduce these results on Mirabox tonight.
Thanks for doing the preliminary board bring-up

Appending the DTB to kernel is considered yucky, but it might be nice to support this as a feature.

Something along the lines of installing the kernel rpm produces a normal zimage, uImage, and uImage+dtb (appended).
Then A-B-C could be taught to load the appended kernel for the boards lacking a modern u-boot, or whatever DTB challenges.
It would always be considered a last ugly option.

That said, politely harassing the upstream maintainers of this u-boot is the best solution.

Something to consider.

Thanks Jon & Jochen

-Jon Disnard
fas:parasense
irc: masta


On Fri, Jul 5, 2013 at 10:27 AM, Jochen De Smet <jochen.arm@leahnim.org> wrote:

fwiw, with the stock 3.10 kernel the Mirabox now works fine for me with F18. Pretty much
using the same commands as you:

cat arch/arm/boot/zImage arch/arm/boot/dts/armada-370-mirabox.dtb >arch/arm/boot/zImagedtb
./scripts/mkuboot.sh -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n 'Linux-marvell' -d arch/arm/boot/zImagedtb arch/arm/boot/uImage

I'm using an md root on top of iscsi instead of local storage though.

The only issues I see so far are:
1) the MAC addresses of the network interfaces seem to change on every boot
2) eth0 isn't quite working right (but this may be a local issue)
3) there's still something not quite right with the shutdown order for the iscsi root

but none of those are a showstopper for me right now.

J.



On 7/5/2013 11:24, Jon Masters wrote:
Hey folks,

I've not had as much time as I wanted to play with the Mirabox. I'm
taking this one over to the UK to give to Peter in a few hours, and I've
ordered myself another one so that I can help get it working. It's not a
high priority, but I agree that this is a nice device for F20.

In the absence of dtb support in the U-Boot, and given the ugly way the
storage is setup via USB, I'm just hacking together a test environment
that isn't using a-b-c. I use the Minimal VFAT image with a microSD card
inside an SD Card adapter (for my laptop), delete the first two
partitions, then re-create them of even size (about 256M each). Then I
format the first partition using ext2 as the filesystem.

I prep a suitable mvebu kernel by appending the dtb (using the non-lpae
kernel as that is still in prep upstream):

sudo sh -c "cat vmlinuz-$version.fc19.armv7hl
dtb-$version.fc19.armv7hl/armada-370-mirabox.dtb
vmlinuz-$version.fc19.armv7hl.mirabox"
sudo mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e
0x00008000 -n $version.fc19.armv7hl.mirabox -d
vmlinuz-$version.fc19.armv7hl.mirabox uImage-$version.fc19.armv7hl.mirabox

Then I copy this (renamed to uImage), and the uInitrd onto the first
ext2 partition. Inserting into the Mirabox, I set the following U-Boot
environmental parameters to boot the result:

setenv bootcmd 'usb start; ext2load usb 1:1 0x02000000 uImage; ext2load
usb 1:1 0x02800000 uInitrd; bootm 0x02000000 0x02800000'
setenv bootargs 'ro rootwait root=/dev/sdb3 console=ttyS0,115200'

These are just rough notes. Ultimately, we'd want dtb support in the
U-Boot, and we'd want to have a-b-c learn about this particular
armada-370 variant. I've poked at a-b-c a couple of times but honestly
didn't go too far down that path as it's not going to be supportable
yet. You'd certainly want to change the 370 load addresses at least.

Jon.
_______________________________________________
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