A new kernel for oxnas

[Mijzelf]

Any idea how hard it will be to get this also running on the Ox810?

[WarheadsSE]

Considering the cores are quite a bit different, a bit.

[celemine1gig]

Interesting and strange at the same time:
From the stock U-Boot 1.1.2 on one of my Pogoplug V3 B04 devices, I just can't erase nand. Instead I get an immediate device reset, when trying to do so.
Next try will be from within Linux, following navym's instruction. Hope it will boot from a working new u-boot then. Fingers crossed.
BTW, all the Pogo V3 devices seem to have that behaviour, when it comes to NAND and stock U-Boot.
Anyone noticed before?
Edit:
BIG THANKS! New U-Boot is running fine, as it seems. Now moving on to more tests on the kernel, tomorrow, probably.
Erasing and flashing the NAND worked like a charm from within Linux.
Edit 2:
Unfortunately, for example the USB functionality of navym's U-Boot version seems very buggy. Issueing a "usb start" command leads to a following device hang. Some other functions seem to have the same effect.

Edit 3: Forget my previous comment!
The USB problems were merely caused by me using a (seemingly unstable) external 5V power supply to power my test Pogoplug V3 B04. After switching back to the default power supply, the USB functionality is working like it should. Sorry!

[celemine1gig]

OK, so I could finally successfully boot the kernel version 3.12 on my Pogoplug V3 B04 Classic.

Key to a successful boot was the bootarg "rootwait" (without a specified time!). It does seem that this kernel needs a lot of time to fully bring up the usb interface. So without the "rootwait" option, I always got a vfs oops telling me that root could not be mounted from /dev/sda1.
Could work better with root on SATA or NAND. Didn't try that yet.

Now I will experiment with kernel configurations and do some performance testing of my own.
So far I am also using the newest U-Boot from navym and I have to say that booting completely from USB (kernel + rootfs) is quite convenient for testing.
The new parts look very promising!

[crckmc]

Hey all,

I'm compiling the new kernel right now and want to create a bootable sata hdd. I did this several times using WarheadSE's disk_create script and the default uBoot but now I wonder how to get the new uBoot and stage1 to work with the script.
So my question: What do I have to do to create the stage1.wrapped and uboot.wrapped files?

Thanks in advance

crckmc

[navym]

you dont have to use the new u-boot to try the kernel, just build a uImage with builtin device tree blob:
ARCH=arm make ox820_defconfig
ARCH=arm make menuconfig
Boot options --->
[*] Use appended device tree blob to zImage (EXPERIMENTAL)
[*] Supplement the appended DTB with traditional ATAG informati
you may also want to disable PCI support if you device does not have one
ARCH=arm make -j8 zImage ox820.dtb
cat arch/arm/boot/zImage arch/arm/boot/dts/ox820.dtb > arch/arm/boot/zImage.fdt
/bin/sh scripts/mkuboot.sh -A arm -O linux -C none -T kernel -a 0x60008000 -e 0x60008000 -n 'Linux-3.11.1+' -d arch/arm/boot/zImage.fdt arch/arm/boot/uImage

[celemine1gig]

The problems I initially had with the kernel 3.12, which then made me try the newer UBoot version, simply were configuration issues on my part. As navym said, it should work with the stock UBoot version, too.

There are some settings that for example work for a Kirkwood device and the 3.12 kernel, but don't for the sources that navym published. If I am not mistaking, the main difference is the handling of UART for dbugging. There seem to be some "odd" dependencies in the sources ATM. I am no expert on the matter, though. I just think hat it should be possible to get UART printk messages without having kernel low level debugging enabled. And at the moment it seems that exactly these two are a MUST to get a valid output over the serial console.

But don't get me wrong, I really and honestly highly appreciate the work that is done on these new sources! Just something I noticed when testing, that seemed strange at first.

[crckmc]

thanks navym it boots now but I can't get it to acquire an ip. When I look at the logs I see dhcpcd timing out 38 seconds after boot but when I look with wireshark no traffic is coming from the plug. Anything I forgot to set? I tried setting a static ip in /etc/rc.conf but it had no effect

[celemine1gig]

MAC-Address problems maybe?
The ethernet driver in this kernel generates a fresh MAC on every boot. If you do not specify a static MAC address via the "hwaddress ether" setting in Debian's /etc/network/interfaces.

[navym]

What config options from kirkwood? I know nothing about that SOC, so I would say good luck.
About $this->bbcode_second_pass_quote('', '&')quot;odd" dependencies in the sources ATM