Linux Kernel 6.7.5 Kirkwood package and Debian rootfs

Val,

Thank for reporting this error! This has helped me think I'll need to take a look at the rest of the Kirkood DTS to verify the correct timing before the next release. Most of the DTS I am using are from mainline tree, so I was counting on them to be correct, but it does not seem to be the case.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I think I tried to fix this myself in june, but as far as I remember for some reason I did not succeed in compiling the dts (I'm kind of a noob in this). And I did not get the time to test/document and report here.

The change that had to be done was 'chip-delay = <35>;' change to 'chip-delay = <40>;', right?

[EDIT]: nevermind, I just answered my own question, dtc can also decompile. :-))
chip-delay = <0x28>;

Cheers, Val.



Edited 1 time(s). Last edit at 09/20/2015 05:39PM by vcheche.

I just installed Debian on my NSA325v2 and I have to say that it works quite nicely so far. Thank you very much for all the hard work which surely went into this project.

Now I have some questions – I read quite a few threads but I have to admit I didn't read all 40 pages of this top for example.

1. Is there an overview which modifications the root fs tarball contains (over a pristine Debian)? I noticed that the "halt" init script was modified for example.

2. I started out with a 3.14 rootfs and did a manual upgrade to Debian Jessie. Are there any known caveats in doing so (as opposed to using a 3.18 rootfs package)?

3. So far I did not update uboot because it seems risky (even though I have a uart cable attached). Is there any downside in not upgrading the boot loader? I store my rootfs on a USB stick and I'm only using this one device. As far as I know with the old uboot I can not use step "4a. Boot with DTB file (standard way to boot FDT kernel). Recommended." Why is booting with a DTB file recommended? I see the immediate benefits for developers but for regular users?

4. The kernel contains a few patches. Is there any tracking in place to get these upstream? Did you try to get them upstream at all?

5. Can I use the netconsole with an old uboot? (1.1.4)

6. In my Debian system when I use "fw_printenv" I says that there are CRC errors so it uses default values. That doesn't seem healthy. Known bug?

Hello Muchatet,

Most of your questions are indeed answered in the thread. ;-)
1. I personally did not find modifications over a basic install other then the ones mentioned in the changelog (first post).
I quote:

3.18: - The init system used in this rootfs is sysvinit (same as in the previous wheezy rootfs). To boot with systemd, see note 4 below.
	- Installed packages: nano, avahi, ntp, busybox-syslogd (log to RAM), htop, isc-dhcp-client, dialog, bzip2, nfs server/client, iperf, ethtool, sysvinit-core, sysvinit, and sysvinit-utils.
	- see LED controls in /etc/rc.local, and /etc/init.d/halt
	- see some useful aliases in /root/.profile
	
3.17: - Installed packages: nano, avahi, ntp, busybox-syslogd (log to RAM), htop, isc-dhcp-client, dialog, bzip2, nfs server/client, iperf, and ethtool.
    - see LED controls in /etc/rc.local, and /etc/rc0.d/K07halt (updated in this version to include all Kirkwood boxes LED controls). Note: for LED controls, look in /sys/class/leds after the system is booted (I might have some old settings in this rootfs rc.local that need to be adjusted to the correct trigger names).
    - see some useful aliases in /root/.profile 
    
3.16: - Installed packages: nano, avahi, ntp, busybox-syslogd (log to RAM), htop, isc-dhcp-client, dialog, bzip2, nfs server/client, iperf, and ethtool.
    - see LED controls in /etc/rc.local, and /etc/rc0.d/K07halt (for NSAxxx LEDs control, see pbg4, and buttzy)
    - see some useful aliases in /root/.profile 
    etc.

2. Don't think so, except for any of the LED and script hacks mentioned above(which should migrate just fine in a dist-upgrade, I believe).

3. Try UART booting your box with kwboot and a working uboot image.
If this works, then there is no significant risk in reflashing uboot. You can always restore your flash this way if something goes wrong. See here about kwboot on NSA325v2 (afaik NSA325 is trickier then other NSA boxes):
http://forum.doozan.com/read.php?2,14351,22885#msg-22885
As I see it, there are no direct benefits for a user that just sets the box and forgets about it to use one method or another. Both work just fine.
However, these are the reasons why NOT appending dtb to uImage is recommended:
- this is the new Linux kernel direction. Better adapt to it sooner then later.
(not sure if appending the dtb is a transition workaround for the time being and will go away or is here to stay.)
- it gives an easyer way to upgrade just kernel or just dtb, keeps the installation modular.
- one less command when building uImage.
- generally, loading dtb from uboot is a more modular, "Linux-ish", approach.
- advantages for a regular updater/power user/dev are obvious from above. ;-)

4. I think lots of changes are already upstreamed. Afaik, including the dts files. Not sure where this is tracked, bodhi can answer this.

5. I think the answer to this one lies somewhere in here:
http://forum.doozan.com/read.php?3,12381
Sorry, also a long thread. :-))

6. Yep, known bug. This is the last discussion with bodhi in this thread (posts before yours). The FLASH chip timing is bad in the current dtb. (35, instead of 40)
Use the patched DTB in this post, should fix the problem: http://forum.doozan.com/read.php?2,12096,23906#msg-23906

I know it will hurt (I did it..), but better read/skim the entire thread. Lots of useful info. For me those were 30 minutes well invested.

Cheers.

Muchatet,

It is a long list, so I'll answer eventually. Pls post follow up questions if they are not clear.

> 1. Is there an overview which modifications the
> root fs tarball contains (over a pristine Debian)?
> I noticed that the "halt" init script was modified
> for example.

Yes, see the rootfs description for exactly what were installed on top of a Debian debootstrap installtion from mainline. All mods was described in that post.

>
> 2. I started out with a 3.14 rootfs and did a
> manual upgrade to Debian Jessie. Are there any
> known caveats in doing so (as opposed to using a
> 3.18 rootfs package)?
>

It is fine.

> 3. So far I did not update uboot because it seems
> risky (even though I have a uart cable attached).
> Is there any downside in not upgrading the boot
> loader?

A lot of upside (see description in u-boot thread first post). One minor downside is further adjustment is needed if you want to boot stock OS from NAND.

> I store my rootfs on a USB stick and I'm
> only using this one device. As far as I know with
> the old uboot I can not use step "4a. Boot with
> DTB file (standard way to boot FDT kernel).
> Recommended." Why is booting with a DTB file
> recommended? I see the immediate benefits for
> developers but for regular users?

This is useful for many reasons. For regular users, firstly would be the case when you have more than one kind of Kirkwood boxes. Booting with the separate DTB allows you to use the exact same rootfs for all of them.

> 4. The kernel contains a few patches. Is there any
> tracking in place to get these upstream? Did you
> try to get them upstream at all?
>

No I have not. It is a time consuming process so never have time to do it!

> 5. Can I use the netconsole with an old uboot?
> (1.1.4)
>

No, it won't work.


> 6. In my Debian system when I use "fw_printenv" I
> says that there are CRC errors so it uses default
> values. That doesn't seem healthy. Known bug?

It means the rootfs needed to be adjusted to use the old u-boot envs location and size. It's in:

/etc/fw_env.config

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Quote
2. I started out with a 3.14 rootfs and did a manual upgrade to Debian Jessie. Are there any known caveats in doing so (as opposed to using a 3.18 rootfs package)?

I can you give only information on the above question.
When using rootfs 3.17 or smaller then this is Debian Wheezy, if you then upgrade to the kernel 3.18 or higher it doesn't turn into jessie. It stays Debian Wheezy linux.
Starting from rootfs 3.18 and higher is a true Debain Jessie linux, but not with the new "systemd", but with the old "sysvinit" init environment. If you want or need it, you can change this behaviour like explained in note 4 at rootfs 3.18

I for example wanted OMV (OpenMediaValt) on my NSA325v2 and had to install rootfs 3.17 and stay with sysvinit, because otherwise OMV wasn't installable and doesn't work. Before installing OMV I had upgrade to the new kernel 4.2

Hope this helps you a bit further in your search.

----
Friendly regards


Ziggy



Edited 1 time(s). Last edit at 10/04/2015 01:57PM by ziggy.

vcheche,

> 6. Yep, known bug. This is the last discussion
> with bodhi in this thread (posts before yours).
> The FLASH chip timing is bad in the current dtb.
> (35, instead of 40)

That was a real bug, this case is slightly different :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Hi,
there is a possibility to create .img file of my rootfs? (or other option to backup my usb stick)

This is how I created the rootfs tarball that was uploaded here.

Assuming you've taken the rootfs offline and mount it on another Linux box. It is mounted at /media/sdb1, and your main disk on that Linux box is mounted at /media/sda1.

cd to the rootfs top level directory and create a tarball, and name it my-rootfs, or whatever name is appropriate! It will take a long time, so run it as background task and measure the time. When it is done, you'll get the time statistics as an indication the task was completed and can see how long did it take as bonus:

Log in as root. Everything you'll do from this point has to be under root user account. Backing up by creating the rootfs tarball (my-rootfs.tar.bz2).

cd /media/sdb1
time tar -cjf /media/sda1/my-rootfs.tar.bz2  . &

To restore it later when needed, use the same command that I have in the instruction in the first post. For example:

cd /media/sdb1
tar -xjf  /media/sda1/my-rootfs.tar.bz2

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 4 time(s). Last edit at 07/15/2016 06:16AM by bodhi.

Thanks. You are awsome!

I'd like to say thank you to all the helpful comments replying patiently to my questions. As usual I find it much easier to understand all the previous comments once I understood how it should be done in the end. I was able to fix my CRC errors by setting the correct addresses in /etc/fw_env.config as bodhi suggested.

Bodhi, I have used your u-boot, kernel and rootfs for a while now and appreciate how much work you put into them.
I want to thank you very much for all that.
Now I had a little problem with a hard drive on one of my NSA320 and had to re-format the drive and re-install.
When I get to the part where I install the kernel (I tried the 4.2.0 tld1 version) and when I ran the command
dpkg -i linux-image-4.2.0-kirkwood-tld-1_1.0_armel.deb
dpkg: error processing archive linux-image-4.2.0-kirkwood-tld-1_1.0_armel.deb (--install):
package architecture (armel) does not match system (amd64)
Errors were encountered while processing:
linux-image-4.2.0-kirkwood-tld-1_1.0_armel.deb
I have used the same system (a Dell 1720 laptop) for this same task (for your 4.18.5 version) and never saw this.
Have you seen this before? What may have changed to cause this?

Herb

herbr,

> dpkg -i
> linux-image-4.2.0-kirkwood-tld-1_1.0_armel.deb
> dpkg: error processing archive
> linux-image-4.2.0-kirkwood-tld-1_1.0_armel.deb
> (--install):
> package architecture (armel) does not match
> system (amd64)
> Errors were encountered while processing:
> linux-image-4.2.0-kirkwood-tld-1_1.0_armel.deb

You can extract rootfs to a HDD using it. You can also generate uImage and uInitrd. But you can not install an ARM kernel using the Dell, even you're running Linux on it, because the Dell is a different architecture (x86). The only way it would work is using qemu, but there is no need for that.

Just boot the NSA320 with your current HDD rootfs and then install the new kernel in Debian after booting. dpkg must be run while you're inside the Debian, and at the command line.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Anyone tested the new CESA cryptoaccelerator driver in kernel 4.2?

Does it need custom programs to be used like the old one (I think it was a custom OpenSSL) or not?

bobafetthotmail Wrote:
-------------------------------------------------------
> Anyone tested the new CESA cryptoaccelerator
> driver in kernel 4.2?
>
> Does it need custom programs to be used like the
> old one (I think it was a custom OpenSSL) or not?

I did not but others might have. And yes, cryptodev, as before.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Thanks.

I was interested mostly in off-loading btrfs checksumming to the CESA, does cryptodev allow that?

bobafetthotmail Wrote:
-------------------------------------------------------
> Thanks.
>
> I was interested mostly in off-loading btrfs
> checksumming to the CESA, does cryptodev allow
> that?

I don't use btrfs, so not sure about that.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

bodhi Wrote:
-------------------------------------------------------

> I don't use btrfs, so not sure about that.
My 2c on btrfs: last time I tried it (Ubuntu 14.04 x64), I got extended corruption with filesystems with huge traffic (>500M files). I still have nightmares :P

But it's probable fine for daily use.

--
DavideDG
My NAS userspace configs
My Zyxel NSA325 mod
My D-Link DNS325 mod
My Lacie NS2MAX mod

bodhi Wrote:
-------------------------------------------------------
> bobafetthotmail Wrote:
> --------------------------------------------------
> -----
> > Thanks.
> >
> > I was interested mostly in off-loading btrfs
> > checksumming to the CESA, does cryptodev allow
> > that?
>
> I don't use btrfs, so not sure about that.

Answering myself: btrfs uses crc32c checksums, which are theoretically accelerated by the XOR accelerator in Kirkwood/Orion SoCs. An entirely different subsystem from CESA.

Will have to go ask devs if the driver of the XOR accelerator allows this.

Quote
davidedg
My 2c on btrfs: last time I tried it (Ubuntu 14.04 x64), I got extended corruption with filesystems with huge traffic (>500M files). I still have nightmares :P

Obligatory "you should have used <insert a serious linux distro> instead" remark. :D

But yeah, I'm just playing with it to see how "future proof" is this box.

I've been running with ext4 + snapraid for a while, that's my main setup.



Edited 1 time(s). Last edit at 10/28/2015 03:48AM by bobafetthotmail.

Hi

please can you help me ( or send a link )

I have NSA310 connected to terminal by ( USB -> TTL )

In device is this U-boot:
U-Boot 1.1.4 (Sep 13 2013 - 00:48:52) Marvell version: 3.4.19
I would like to instal debian but I mess up something
( when passed u-boot in nsa310 the system do not start but finish at Kernel panic )
so I can not create uImage and uInitrd directly on the device.

If someone can give me ( uImage, uInitrd) and procedure how to start instalation from ( USB in u-boot ) I would be very graceful

or how to create this files on PC ( linux: ubuntu )

thanks for any answer if someone was asking this before so sorry I was trying to find answer before I asked

duanis,

You need to create a Debian 3.16 rootfs like I recommended in this post:
http://forum.doozan.com/read.php?4,23425,23427#msg-23427

You can do this on Ubuntu. And remember to follow the instruction very closely.

Plug this USB to the NSA310, boot with serial console. See how it goes, and post the entire serial boot log here.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

SSgheuindj Wrote:
-------------------------------------------------------
>
> yeah, that's right.

Um, can you explain more? What is right?

bobafetthotmail Wrote:
-------------------------------------------------------
> SSgheuindj Wrote:
> --------------------------------------------------
> -----
> >
> > yeah, that's right.
>
> Um, can you explain more? What is right?

It was spam. I've deleted it.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I'm using kernel 4.3.0-rc7 now and later let's see what's going on with the final 4.3.0.

as seen with 4.3-rc1 I'm seeing this:

[   17.602771] MV-CESA:Could not register sha1 driver
[   17.620416] MV-CESA:Could not register hmac-sha1 driver

and the S-ATA settings were not used from previous config so has to be reset.



Edited 2 time(s). Last edit at 11/02/2015 07:10AM by pengu.

Hi guys,

I have a quick question concerning the relatively new "marvell_cesa" driver.
Is there anyone with a Seagate Goflex-Net, who has the driver running successfully?

I tried with the latest Debian kernel sources (upto 4.3-RC7), but could not get it up and running. Driver module always reported return code -22. My current guess is that the device tree file is not 100% correct. Already tried a few things (compatible, kirkwood-crypto, ...), but nothing so far worked.

Thanks in advance for any input.

Dear All (Bodhi :)

Please help.
I have Goflex Net with SATA (Kernel 3.16) and worked fine, but just upgraded to 4.2 Kernel.

SATA boot is failed but USB is successfully booted.

USB booted with Option 4a. (DTB not in kernel image)

Same files are on Sata /boot directory but not booted.

I assume the problem is SATA_BOOT parameters are not for dtb load.

My present printenv is:

root@debian:~# fw_printenv 
arcNumber=3089
baudrate=115200
bootcmd_mmc=run mmc_init; run set_bootargs_mmc; run mmc_boot
bootcmd_rescue=run set_bootargs_rescue; nand read.e 0x800000 0x4640000 0xa00000; bootm 0x800000
bootcmd_sata=run sata_init; run set_bootargs_sata; run sata_boot;
bootcmd_usb=run usb_init; run set_bootargs_usb; run usb_boot;
bootdelay=3
console=ttyS0,115200
ethact=egiga0
ethaddr=00:10:75:26:6D:EC
force_rescue=0
force_rescue_bootcmd=if test $force_rescue -eq 1 || ext2load usb 0:1 0x1700000 /rescueme 1 || fatload usb 0:1 0x1700000 /rescueme.txt 1; then run rescue_bootcmd; fi
led_error=orange blinking
led_exit=green off
led_init=green blinking
mainlineLinux=yes
mtdids=nand0=orion_nand
mtdparts=mtdparts=orion_nand:1M(u-boot),4M(uImage),32M(rootfs),-(data)
partition=nand0,2
pogo_bootcmd=if fsload uboot-original-mtd0.kwb; then go 0x800200; fi
rescue_bootcmd=if test $rescue_installed -eq 1; then run rescue_set_bootargs; nand read.e 0x800000 0x100000 0x400000; bootm 0x800000; else run pogo_bootcmd; fi
rescue_installed=1
rescue_set_bootargs=setenv bootargs console=$console ubi.mtd=2 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts $rescue_custom_params
sata_root=/dev/sda1
set_bootargs_rescue=setenv bootargs console=$console ubi.mtd=8 root=ubi0:rootfs ro rootfstype=ubifs $mtdparts
set_bootargs_sata=setenv bootargs console $console root $sata_root rootdelay $rootdelay rootfstype $rootfstype $mtdparts
set_bootargs_usb=setenv bootargs console=$console root=$usb_root rootdelay=$rootdelay rootfstype=$rootfstype $mtdparts
stderr=serial
stdin=serial
stdout=serial
ubifs_bootcmd=run ubifs_set_bootargs; if ubi part data && ubifsmount rootfs && ubifsload 0x800000 /boot/uImage && ubifsload 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; fi
ubifs_mtd=3
ubifs_set_bootargs=setenv bootargs console=$console ubi.mtd=$ubifs_mtd root=ubi0:rootfs rootfstype=ubifs $mtdparts $ubifs_custom_params
usb_bootcmd=run usb_init; run usb_set_bootargs; run usb_boot
usb_device=0:1
usb_load_uimage=ext2load usb $device 0x800000 /boot/uImage
usb_load_uinitrd=ext2load usb $device 0x1100000 /boot/uInitrd
usb_root=/dev/sda1
usb_rootdelay=10
usb_rootfstype=ext3
usb_scan=usb_scan_done=0;for scan in $usb_scan_list; do run usb_scan_$scan; if test $usb_scan_done -eq 0 && ext2load usb $usb 0x800000 /boot/uImage 1; then usb_scan_done=1; echo "Found bootable drive on usb $usb"; setenv usb_device $usb; setenv usb_root /dev/$dev; fi; done
usb_scan_1=usb=0:1 dev=sda1
usb_scan_2=usb=1:1 dev=sdb1
usb_scan_3=usb=2:1 dev=sdc1
usb_scan_4=usb=3:1 dev=sdd1
usb_scan_list=1 2 3 4
usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params
preboot_nc=run if_netconsole start_netconsole
sata_bootcmd=run usb_set_bootargs; run sata_boot
bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run sata_bootcmd; run rescue_bootcmd; run pogo_bootcmd; reset
sata_boot=ide reset; mw 0x800000 0 1; ext2load ide 0:1 0x800000 /boot/uImage; if ext2load ide 0:1 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi
usb_init=usb start
load_dtb=ext2load usb 0:1 0x1c00000 /boot/dts/kirkwood-goflexnet.dtb
load_initrd=ext2load usb 0:1 0x1100000 /boot/uInitrd
load_uimage=ext2load usb 0:1 0x800000 /boot/uImage
usb_boot=run load_dtb; run load_uimage; if run load_initrd; then bootm 0x800000 0x1100000 0x1c00000; else bootm 0x800000 - 0x1c00000; fi

Can someone send printenv for 1.SATA and 2.DTB load on 3. Goflex net?

Update As a dirty hack I made 4b. option (DTB file embedded in the kernel image) and sata booted.


Best Regards,
Robert



Edited 1 time(s). Last edit at 11/02/2015 03:37PM by robert1968@gmail.com.

@ingmar_k

could be that ther is something messed up in kernel 4.3.
The given message persists in stable kernel 4.3 but I found no solution yet.
I haven't testet this on my goflex net so far.

marvell_cesa           24913  0 
des_generic            16866  1 marvell_cesa
mv_cesa                11324  0

but it get's loaded

you can test this (now dtb files included)
but I think that there's something missing



Edited 5 time(s). Last edit at 11/03/2015 05:30AM by pengu.

@Robert,

Your SATA boot command needs to be like the USB boot command

sata_boot=ide reset; mw 0x800000 0 1; ext2load ide 0:1 0x1c00000 /boot/dts/kirkwood-goflexnet.dtb; ext2load ide 0:1 0x800000 /boot/uImage; if ext2load ide 0:1 0x1100000 /boot/uInitrd; then bootm 0x800000 0x1100000; else bootm 0x800000; fi

I've also released a new envs set here: http://forum.doozan.com/read.php?3,24212. However, if you just change the sataboot env like above, it would work. No need to update the envs.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

ingmar_k,

Good to see you're visiting the forum again :)

As I've learned, the module marvell_cesa worked in 4.2.0, However, I did not have time to play with it, so no idea.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

I needed that line! :) Thank You very much Bodhi!



Bodhi I would say Thanks in name of everyone for new Kernel and Rootfs and fast and serius support!!!!!

Have a good day. :)