Linux Kernel 6.11.6 Kirkwood package and Debian rootfs

@davidedg,

thanks I will go thru it.

t.

Just installed ntpdate again and rebooted and guess what...

root@pogo01:~# ps ax|grep ntp
2053 pts/0    S+     0:00 grep ntp

And when you look at the bootlog...

Jan  1 01:00:41 pogo01 daemon.notice ntpd[1898]: ntpd 4.2.6p5@1.2349-o Sat Dec 20 18:42:15 UTC 2014 (1)
Jan  1 01:00:41 pogo01 daemon.notice ntpd[1899]: proto: precision = 2.130 usec
Jan  1 01:00:41 pogo01 daemon.err ntpd[1899]: unable to bind to wildcard address 0.0.0.0 - another process may be running - EXITING

Hello all.
I'm sure this is not the right place for this post, but I need to tell the world what I've done, and what they should not!
A year ago I've built myself a custom kernel for nsa310. First I experimented with bodhi kernels (at the time 3.12, 3.13), and it worked very well, but i needed some drivers and didn't want to bother bodhi so I've decided to build my own kernel (dts).
If anyone is interested, it's almost default kirkwood config, with a few .config modifications, and with LEDs fix and fancontrol.

To make a working leds, I modified sata_mv.c
At the beginning I added
#include <linux/leds.h>

and later in function start_edma I added "ledtrig_ide_activity();"
static void mv_start_edma(struct ata_port *ap, void __iomem *port_mmio,
struct mv_port_priv *pp, u8 protocol)
{
int want_ncq = (protocol == ATA_PROT_NCQ);

ledtrig_ide_activity();

if (pp->pp_flags & MV_PP_FLAG_EDMA_EN) {
int using_ncq = ((pp->pp_flags & MV_PP_FLAG_NCQ_EN) != 0);
if (want_ncq != using_ncq)
mv_stop_edma(ap);
}

also, now that you have that, in leds trigger config I changed "depends on" to set to SATA_MV

config LEDS_TRIGGER_IDE_DISK
bool "LED IDE Disk Trigger"
depends on SATA_MV
depends on LEDS_TRIGGERS
help
This allows LEDs to be controlled by IDE disk activity.
If unsure, say Y.

to make fancontrol work, you just needed to know if you have 310a or 310 version since, the difference is LM85
if you have it, choose nsa310a (otherwise, you will end with adt7476 but something is then wrong, since looks like there is only 7475 in kernel

Or modify arch/arm/boot/dts/kirkwood-nsa310.dts
i2c@11000 {
status = "okay";

lm85: lm85@2e {
compatible = "lm85";
reg = <0x2e>;
};
};

All this was first done a year ago and I've forgotten almost everything by now, since that is how good it was. 24/7, little nsa310 with debian worked, served nginx, owncloud, openvpn, minidlna...

But this week I've had a great idea to try to install Jessie. Big mistake!
So every free hour of this week was lost and this is why I write this.
DO NOT TRY THIS YET! Jessie is not ready!
First, you may need a new kernel. I was stuck with 3.13, and it was sort of abandoned. So i tried 3.19-rcX, but i could not even boot! Then I tried 3.14.2x longterm and it worked like a charm. Nothing special.
So I changed wheezy to jessie in sources,
apt-get update
apt-get upgrade
and it started to ask for thingies... first is that it has UDEV and it needs some kernel features

> - inotify(2) (CONFIG_INOTIFY_USER)
> - signalfd(2) (CONFIG_SIGNALFD)
> - accept4(2)
> - open_by_handle_at(2) (CONFIG_FHANDLE)
> - timerfd_create(2) (CONFIG_TIMERFD)
> - epoll_create(2) (CONFIG_EPOLL)

You will find all of this in System Type/General setup (and FS)

then you continue.
then you find out that you need devtmpfs, so you enable devtmpfs config, then you find out there is one more devtmpfs, and you enable it to.
then you notice systemd is unable to mount some nonegisting sys folder... and an hour later, you came to understand you need to enable control groups support in kernel

that is it
check for http://wiki.gentoo.org/wiki/Systemd, since here is some more info

and then after upgrade, dist upgrade, you have your system.
but it's BRAKING APART!

I've read about systemd and the haters were loud, but I never listened.
So, not working samba (after hour or two, i have figure samba out), minidlna and who knows what is sort of expected, but look at your boot options in Webmin! It's a mess. Total mess... Now you dont't know anything anymore, since it's kind of combined scripts and systemd way of doing.
Then let's try to explain the problems you have on the one of the first things I tried to fix. First, minidlna is not in webmin, I can't see it. Removed, installed again, and not there. Ok, but go on, try to create a "unit" with systemctl enable minidlna.service. No good, first, minidlna is pointing at sbin (wheres I have it on bin), but even when you learn yourself that now you have to make a minidlna.service, and what the new sintax is, minidlna is crashing after about 2 minutes, and even if not - there is no way I can make it into webmins bootlist. Even with systemctl daemon-reload. Also, disk grinding journal ext4 is now on 5 seconds grind interval, (instead of blessed 20), RAM was at 85 mb (mysql, minidlna, nginx...) and now is 125... and so on...
To conclude, Jessie is not ready yet!
And if it is, it is not good for upgrade. It is good maybe if you start from scratch. This was a wasted week for me, and save yourself!

However, if anyone has mazo wishes and wants workable kernel config for jessie on kernel 3.14.2x, I can post it here...

Nekitip,

You must a done something wrong. Just a few days ago I made my own quick and dirty Jessie (not upgrade) roofs for the nsa325v2 and used Bodhi's 3.17 kernel and no issue's with Jessie except some systems logind error on the serial output. Updating in my experience from 1 Debian release to the next never turns out well the is changes too much between releases.

Buttzy10169 Wrote:
-------------------------------------------------------
> Updating in my experience from 1 Debian release to
> the next never turns out well the is changes too
> much between releases.

My point exactly. I've had a working "system" 24/7, and upgrading messed it. As I said, jessie is either not ready yet for upgrade, or will never be "upgradable" from wheezy. This is a shame. And systemd, I totally understand now why all the fuss...
Also, I hope this text I wrote will help someone in compiling kernel configs, since they will have the anwsers here on one place.
To help further, not sure if I've seen one here, but for kernel testing I use this envs:

setenv boot_usb 'usb reset; fatload usb 0 0x800000 /uImage; bootm 0x800000'
setenv boot_hdd 'ide reset; fatload ide 0 0x800000 /uImage; bootm 0x800000'
setenv bootcmd 'run boot_usb; run boot_hdd'

Having this saved, once you have a new kernel, just put it on usb and reset your nas.
Of course, old kernel is on disk, if you are not happy, remove and reset.
(In my case, it is sda4)

setenv bootargs 'console=ttyS0,115200 root=/dev/sda4'

nekitip,

> I'm sure this is not the right place for this
> post, but I need to tell the world what I've done,
> and what they should not!

You are right that this post should be a new thread. Perhaps tittle it: Debian Jessie and systemd problem ?

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

@bodhi
Well, post was written in one breath, still under the impression of a wasted week. I'm sure you know days like theese.
I can't seem to delete the post now, but you delete it you see fit.
Nevertheless, post still contains some config hints, for those who will try to compile custom (or modify your) kernel, to use it with Jessie.

nekitip,

> Well, post was written in one breath, still under
> the impression of a wasted week. I'm sure you know
> days like theese.

I surely do :)

Perhaps you will have better luck if starting with rootfs 3.17? You could try my basic rootfs 3.17 as an experiment to see how well the process will go. If that goes well, you can upgrade your own rootfs to 3.17 kernel before upgrading to jessie.

BTW, I only meant to suggest a repost to a different thread. It would be a good new topic to report systemd installation headaches!

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



Edited 1 time(s). Last edit at 01/18/2015 12:08PM by bodhi.

Quote
bodhi
You could try my basic rootfs 3.17 as an experiment...

In fact, I already have!
I played with it a bit today...
Btw, why do you have custom rootfs, and also initrd? Because, I have tried using my old uImage and just point to your rootfs (on usb) and it booted (initrd seemed unimportant). Am I lucky or I'm missing some idea here?
Eventually, bodhi, I like the idea to install system on USB (as opposite to HDD install i had until now), but I'm finding out that USB drives are veeery slow... so...

question: is it possible to install system on HDD (or some fast usb external disk), and then, when system is done - just copy system (select all the files on ext2) to standard, slow usb? (and change if needed /dev/sdx to /dev/sdy)

Anyway, some anwsers for whoever googles to here:
-not being able to load intrid with my custom kernel (kirkwood): Check if you have in your config
BLK_DEV_INITRD set, and also BLK_DEV_RAM.
-not being able to boot SDB1 USB from uboot: it is in fact SDA if there is no HDD
-not being able to boot from ext2 usb from marvell uboot: on my uboot, only FAT (first) was willing to perform, so system was put on usb 0:2 and boot files to 0:1
-initrd did not start netinstall: if you use netinstall debian (either created by yourself from official debian, or downloaded from net like here, where nsa310 is covered, check if you have set setenv bootargs 'console=ttyS0,115200 root=/dev/ram'
-usb drive can be loaded from uboot setup, but not any other times. use delay like setenv bootargs 'console=ttyS0,115200 root=/dev/sdb2 rootdelay=10'
remember to saveenv; reset

nekitip,

All your questions/problem are really not related to this kernel / rootfs. They are rather general issues you would encounter in booting u-boot and kernel. I think the topic should be in a new thread.

Quote

question: is it possible to install system on HDD (or some fast usb external disk), and then, when system is done - just copy system (select all the files on ext2) to standard, slow usb? (and change if needed /dev/sdx to /dev/sdy)

Yes.

Quote

-not being able to boot SDB1 USB from uboot: it is in fact SDA if there is no HDD
-not being able to boot from ext2 usb from marvell uboot: on my uboot, only FAT (first) was willing to perform, so system was put on usb 0:2 and boot files to 0:1

These are solvable with u-boot envs scripting.

Quote

Btw, why do you have custom rootfs, and also initrd? Because, I have tried using my old uImage and just point to your rootfs (on usb) and it booted (initrd seemed unimportant). Am I lucky or I'm missing some idea here?

You don't need uInitrd in certain configuration.

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



Edited 1 time(s). Last edit at 01/18/2015 11:30PM by bodhi.

Hey,
i just bought NSA325v2 and I'm new here.

Please correct me if I'm wrong.

To install Debian on my device I should:
1) upgrade u-boot - not necessarily, but have to if i want FDT?
2) install kernel 3.17 from this post even if i didn't upgrade u-boot?
3) install rootfs 3.17 from this post even if i didn't upgrade u-boot?

Is this correct list of steps?

bonk1990 Wrote:
-------------------------------------------------------
> Hey,
> i just bought NSA325v2 and I'm new here.
>
> Please correct me if I'm wrong.
>
> To install Debian on my device I should:
> 1) upgrade u-boot - not necessarily, but have to
> if i want FDT?

For NSA325, your best course is to install new u-boot. Even though it is not absolutely necessary to boot 3.17 FDT rootfts (with DTB embedded inside uImage).

> 2) install kernel 3.17 from this post even if i
> didn't upgrade u-boot?

No, since you have NSA325 which comes with the watchdog problem. You need to install 3.16.0-tld-2 rootfs or older.

So the incremental approach is:

1. Update to 3.16-tld-2 kernel, if you already have a Kirkwood rootfs. Or if you want to start fresh, install 3.16.0-tld-2 rootfs on USB thumb drive as new.
2. Boot with USB thumb drive (not with HDD). If everything goes well, u-boot does not need to be updated.
3. Finally, update u-boot to take advantage of the ability to boot with 3.17.0-tld-1 rootfs
4. Update to 3.17.0-tld-1 kernel.

I would do all these in the above order if you are very cautious. However, if your goal is to run 3.17 kernel, then the quicker steps:

1. Create 3.17.0-tld-1 rootfs
2. Update u-boot while inside whatever rootfs you are running.
3. Boot with the new 3.17.0-tld1 rootfs.

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

I need your help because I'm not sure what i should do.

I'm trying install Debian-3.16.0-kirkwood-tld-2-rootfs-bodhi.tar.bz2 on nsa325v2.

I have created usb rootfs by root and kept entry /dev/root ext3.

Whats should I do next?
My guess I should set some variables in u-boot's env. Is that right?

Could you tell me what should I set step-by-step?

I found this but I'm not sure this is right for bodhi's rootfs:

setenv arcNumber 4495
setenv mainlineLinux yes
setenv bootargs 'console=ttyS0,115200 root=/dev/sda1 rootdelay=5'
setenv bootcmd 'usb start;ext3load usb 0:1 0x800000 /uImage; bootm 0x800000'
saveenv
reset

Please help me:)

bonk1990,

Sounds like you are trying to run the new rootfs with stock u-boot? Pls post in this NSA325 thread:
http://forum.doozan.com/read.php?2,14351

It's best that someone who runs the NSA325 with stock u-boot and new rootfs would post a listing of their envs, and you can follow that.

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



Edited 1 time(s). Last edit at 01/24/2015 11:32AM by bodhi.

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

> Perhaps you will have better luck if starting with
> rootfs 3.17? You could try my basic rootfs 3.17 as
> an experiment to see how well the process will go.
> If that goes well, you can upgrade your own rootfs
> to 3.17 kernel before upgrading to jessie.
>
> BTW, I only meant to suggest a repost to a
> different thread. It would be a good new topic to
> report systemd installation headaches!


- Update kernel 3.17 -> 3.18
- update webmin 1.720 -> 1.730
- add in sources wheezy-updates
- apt-get update , apt-get dist-upgrade
- add in sources jessie
- apt-get update , apt-get dist-upgrade
( if errors upgrade -> apt-get -f install -> apt-get dist-upgrade .... )

Start :

- SAMBA - OK
- minidlna - OK
- mediatomb - OK
- Transmission - OK
- webmin - OK
- apcupsd - OK
- synaptik - OK
- gparted - OK
- apache2 - OK

What else to check?

You're such a champion, bodhi. I've been using your stuff for ages and I just had to say it. Thank you for saving me hours of fun ;)

@megal0maniac,

Cool! my pleasure to be able to contribute to Linux device hacking community.

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

I've been wanting to setup my dockstar as a backup NAS using BTRFS and it's snapshots feature.
I just went through the process of installing the linux-3.17.0-kirkwood-tld-1-bodhi kernel and setup the system, only to discover that the 3.17.0 kernel corrupts the BTRFS snapshots.
http://www.reddit.com/r/LinuxActionShow/comments/2kbzjh/linux_317_filesystem_corruption/

From what I've read 3.16.0 also has various BTRFS related bugs. I'll have to do some more reading on the 3.14 and 3.15 kernels to see if there are any issues.

Is there any chance that a newer 3.17.x or 3.18.x kernel build might be released in the near future?

wtip Wrote:
-------------------------------------------------------
> I've been wanting to setup my dockstar as a backup
> NAS using BTRFS and it's snapshots feature.
> I just went through the process of installing the
> linux-3.17.0-kirkwood-tld-1-bodhi kernel and setup
> the system, only to discover that the 3.17.0
> kernel corrupts the BTRFS snapshots.
> http://www.reddit.com/r/LinuxActionShow/comments/2
> kbzjh/linux_317_filesystem_corruption/
>
> From what I've read 3.16.0 also has various BTRFS
> related bugs. I'll have to do some more reading on
> the 3.14 and 3.15 kernels to see if there are any
> issue
>
> Is there any chance that a newer 3.17.x or 3.18.x
> kernel build might be released in the near future?

I plan to release 3.18.x in a couple weeks.

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

Thanks for the status update and all of the hard work you've put into this project over the years!

I have 3.17 running on a PP E02 and the RAM shows up as 128MB but information from the Arch Linux site and others says the E02 is supposed to have 256MB of RAM. Is this a limitation in the kernel or is 'free -h' giving incorrect info?

LeggoMyEggo Wrote:
-------------------------------------------------------
> I have 3.17 running on a PP E02 and the RAM shows
> up as 128MB but information from the Arch Linux
> site and others says the E02 is supposed to have
> 256MB of RAM. Is this a limitation in the kernel
> or is 'free -h' giving incorrect info?

It means you are not running it as Pogo E02. My guess is you might have missed the uImage creation step as Adam did:
http://forum.doozan.com/read.php?2,19498,19510#msg-19510

Check with dmesg to see if it is true:

dmesg | grep -i machine

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

OK so I gotta make sure I get this sequence right with the E02 stick mounted to /media/sdb1 in another Plug running Debian...............

4. Create uImage with embbeded DTB (If this is not first time installation, please see Note 2 below).

I'm using the GoFlex Net booting with USB drive as an example here. Please replace its name (kirkwood-goflexnet.dtb) with the box you are installing on (for example, kirkwood-pogo_e02.dtb). Look inside /media/sdb1/boot/dts/ for the correct DTB file name for your box.

cd /media/sdb1/boot
cp -a zImage-3.17.0-kirkwood-tld-1  zImage.fdt
cat dts/kirkwood-goflexnet.dtb  >> zImage.fdt
mv uImage uImage.orig
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-3.17.0-kirkwood-tld-1 -d /media/sdb1/boot/zImage.fdt /media/sdb1/boot/uImage
sync

Hi,

My old debian installation for my Goflex Home is dieing because of to many bad blocks on the USB stick.

So I tried to Install a fresh image to a new USB stick like described in section "Updated 31 Oct 2014:"


But the system don't boot from the new stick.

I've watched on serial console while starting and the boot process stops at line:

Uncompressing Linux... done, booting the kernel.

I can't see any error message.


Has someone an idea what's going wrong?

@LeggoMyEggo,

Read the rest of the thread from the post I've posted above.

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

dharry Wrote:
-------------------------------------------------------
> Hi,
>
> My old debian installation for my Goflex Home is
> dieing because of to many bad blocks on the USB
> stick.
>
> So I tried to Install a fresh image to a new USB
> stick like described in section "Updated 31 Oct
> 2014:"
>
>
> But the system don't boot from the new stick.
>
> I've watched on serial console while starting and
> the boot process stops at line:
>

> Uncompressing Linux... done, booting the kernel.
>

>
> I can't see any error message.
>
>
> Has someone an idea what's going wrong?

Please post the entire serial console boot log.

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

bodhi Wrote:
-------------------------------------------------------
>
> Please post the entire serial console boot log.

I found my problem. I'm useing a GoflexNet of U-Boot

U-Boot 2010.09 (Oct 23 2010 - 11:53:10)
Marvell-GoflexNet by Jeff Doozan, Peter Carmichael

and working with arcNumber 3089 (golfexNet). But tried with the goflexhome image. after generating a Image with for goflexnet my goflexhome device boots correctly.

best regards,

harry

dharry,

This GoFlex Net u-boot would work fine for a GoFlex Home plug. However, some functionalities are different enough that you should consider installing a proper GF Home u-boot and use the GF Home rootfs. For example, the LED light controll is different, and GoFlex Net does not have RTC but the GF Home does.

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



Edited 1 time(s). Last edit at 01/31/2015 06:21AM by bodhi.

Kernel 3.18.5-kirkwood-tld-1 package has been uploaded. Please see 1st post for download link.

The following features were added:

1. USB LED trigger. For boxes that have LEDs for USB drive (e.g. NSA325 and iConnect), see the trigger files for new option to trigger the LED for each USB drive.

Example for NSA325 - Turn on LED when there is activity on USB drives:

echo usb-host > /sys/class/leds/nsa325\:green\:usb/trigger

As the result of the above command, the trigger file now has usb-host turned on:

cat /sys/class/leds/nsa325\:green\:usb/trigger 
   none nand-disk usb-gadget [usb-host] timer oneshot ide-disk1 ide-disk2 heartbeat gpio default-on

Example for iConnect - Turn on LED when there is activity on USB drive 1

echo usb-host > /sys/class/leds/usb1\:blue/trigger

As the result of the above command, the trigger file now has usb-host turned on:

cat /sys/class/leds/usb1\:blue/trigger 
   none nand-disk usb-gadget [usb-host] timer oneshot ide-disk1 ide-disk2 heartbeat gpio default-on rfkill0 phy0rx phy0tx phy0assoc phy0radio

2. Also new in the kernel are various kernel configuration that are newly available in 3.18, and also various kernel configuration per forum users requests.


Update1:

FYI, the iConnect USB LEDs trigger works but not correctly! if one USB is set to trigger, all the LEDs light for USBs will light up. This seems to be an oversight in the kernel module.

Update2:

Confirmed, it is a kernel module issue. Similar to the multiple SATA ports issue before, the USB LEDs trigger module only deal with a common usb-host and a common usb-gadget LED trigger.

I'll implement a patch (similar to the patch I did before for ide_trigger) and incorporate it in the next release.

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



Edited 5 time(s). Last edit at 02/09/2015 02:19PM by bodhi.

First i want to thank all contributing foristi, but especially bodhy very very much for your great phantastic help- and meaningful work!!

Since weeks i'm reading here and try to understand and learn, how to install Debian on my Zyxel NSA-320. I really like this little boxes with their big potential, that is wasted with the original OS. I want to use the box with Debian and Openmediavault (that perfectly runs on my productive-NAS based on a HP-Microserver) as a backupserver, that should be the rsync-target of my main-NAS. It should boot from the first HDD, and store the data on the second HDD.

After many hours of trial and error the NSA-320 now boots with kernel 3.18 (with integrated dtb-file) from an ext3-rootfs on sda1(only this partition on the drive). It still has stock U-Boot 1.1.4 (Mar 18 2010 - 23:12:09) Marvell version: 3.4.19. The U-Boot environment was set with a modified script, that is based on the Archlinuxinstall-usb-key-func-script by Jason Plum.

But there are some issues: leds and powerbutton don't work, and fw_-commands bring up the "Bad CRC, using default environment"-message. According to the latter, there are probably wrong settings in /etc/fw_env.config, as i read earlier in this thread. I followed your earlier suggestion, and searched for a solution (the right settings for the NSA-320) in the archlinux-forum, but i couldn't find anything there or anywhere else. That's why i ask for your help now: can anybody tell me the right settings in /etc/fw_env.config for a NSA-320, or how to find them?

If you need my NSAs environment-settings or a bootlog, please let me know.

Many thanks in advance.

Best regards
Jan



Edited 2 time(s). Last edit at 02/11/2015 12:32PM by JanN.