Linux Kernel 6.7.5 Kirkwood package and Debian rootfs

Hi Chessplayer,

It was removed from the mainline kernel in version 3.12:
https://github.com/torvalds/linux/commit/9fc2105aeaaf56b0cf75296a84702d0f9e64437b

I guess you will have to get this info from dmesg, i.e.

dmesg | grep -i bogomips | cut -c41-58
 1191.11 BogoMIPS

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

Hi bodhi,

thanks for looking into it. And I actually do not do anything to get the info: it is the program called linuxlogo which is installed via the package by the same name, as I already pointed out in my original post on the subject.
So I guess the developer should be informed, which is what I just did. Whether there is going to be an update, however, I do not know, since the software was last updated in November 2010.

Cheers,

chessplayer

---
Standart ist der Standardfehler

Hi chessplayer,

Understood. If the developer is no longer active, I could look to see if we could patch their code and rebuild the package. Depending how it was implemented, if it's easy enough then it would be no problem.

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

Hi chessplayer,

Here is the patched linux_logo.
md5:
7ae1817502a0246e49616d07e6df4e8c

Run this on your boxes and let me know what you see :) if you see no problem with it, you can replace this binary where it is installed (e.g. usr/local or where you've defined it).

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

Hi bodhi,

thanks. I am at work right now, so will test later today.

P.S.: Don't you have anything better to do than giving other people their broken toys back? ;-))

---
Standart ist der Standardfehler

I'm going to bed now :)) you won't hear from me for another 10 hours :)

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

bodhi Wrote:
-------------------------------------------------------
> Hi chessplayer,
>
> Here is the patched
> linux_logo.
> md5:
> 7ae1817502a0246e49616d07e6df4e8c
>
> Run this on your boxes and let me know what you
> see :) if you see no problem with it, you can
> replace this binary where it is installed (e.g.
> usr/local or where you've defined it).

Hi bodhi,

good morning, hope you slept long and well ...

Please see for yourself what I am getting. This is really funny, since with the 3.8.11 kernel I suddenly have twice the number of precessors as well as twice the speed (see output on the bottom of attached screenshot) ;-). Also, note that your program seems to be looking for the debian
logo in the wrong place (or whatever might be happening), since it reverts to the dfault logo (which also looks nice, I'd say). It must find that somewhere, however ...

Cheers,

chessplayer

---
Standart ist der Standardfehler

Hi chessplayer,

Ah! it's explainable. I compiled the program, but did not install it. I ran the binary in the build directory, and also tried both the binary and Debian logo on the Pogo Pro (2 CPUs).

./linux_logo -D ./logos/distributions/debian.logo

I think when you run it like I did, you have specify where the logo image is. Hopefully, when you put it in your standard installation directory it will pick up your default location for the logo.

The double count in 3.8.11 also makes sense. I added code to extract the number of processor and bogomips from dmesg. But in 3.8.11 these information are still in /proc/cpuinfo! so the counters were increment twice. I'll have to account for when the linux_logo is run on an older kernel then!

Update:

BTW, the Bogomips on the PogoPro is all messed up! looks like the calibration was not working on OXNAS.

[    0.000194] Calibrating delay loop... 319.48 BogoMIPS (lpj=1597440)

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



Edited 2 time(s). Last edit at 04/29/2014 03:41PM by bodhi.

I've uploaded the latest version for linux_logo:

Download at dropbox:
linux_logo
md5:
fbbf949b21fbf6829a8f28edd24637ab

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

More serious matters

Hi bodhi,

I am currently in the process of testing the latest VDR on my plugs. Most of the things work fine, but the web interface never uses the German language as it does on my "production systems", but rather defaults to English. The production systems are still running your 3.8.11-tld-3 kernel and Wheezy 7.1.

So, I had a look in the syslog and found the following entries pertaining to the matter:

On the new 3.14.0-tld-2 kernel with Wheezy 7.5:

...
May  2 01:07:32 3.14.0-VDR user.info vdr: [3552] VDR version 2.1.6 started
May  2 01:07:32 3.14.0-VDR user.info vdr: [3552] switched to user 'vdr'
May  2 01:07:32 3.14.0-VDR user.info vdr: [3552] codeset is 'ANSI_X3.4-1968' - unknown
May  2 01:07:32 3.14.0-VDR user.debug vdr: [3552] found 0 locales in /usr/share/locale
...

Thus, I took a fresh 3.8.11 stick with just the rootfs and installed the same self compiled VDR-packages on that one as on the one which produced the output above. Then syslog says:

...
May  2 01:00:40 3.8.11-VDR user.info vdr: [2997] VDR version 2.1.6 started
May  2 01:00:40 3.8.11-VDR user.info vdr: [2997] switched to user 'vdr'
May  2 01:00:40 3.8.11-VDR user.info vdr: [2997] codeset is 'UTF-8' - known
May  2 01:00:40 3.8.11-VDR user.debug vdr: [2997] found 1 locales in /usr/share/locale
...

and the web interface is in German. I did some googling on the ANSI_X3.4-1968 codeset in connection with VDR, but it seems to me to have something to do with the base system. I wonder whether you might know what is going wrong here.

Cheers,

chessplayer

---
Standart ist der Standardfehler

Hi chessplayer,

It seems you don't have any locale in your new 3.14.0-tld-2 rootfs (kernel does not have any locale specific stuff). If locales was not installed, or has not been generated (I don't know if you had done this, so stating here for reference):

apt-get install locales

Check to see if your locale is in the file (my locale is US). And then edit this file locale.gen to uncomment your locale

cat /etc/locale.gen | grep US

Generate locale

/etc/locale-gen

See if you have utf8 for your language

cat ~/.utf8

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

I'm using your rootfs with 3.12.0-kirkwood-tld-3 kernel for PogoPlug e02. It's only used for transmission, openvpn, samba, couchpotato and sickbeard. So far it's rock solid. Any advantages upgrading to your latest kernel or should I just leave it as is?

Almaz,

There is really no need to run the latest kernel, unless you want to try new features in 3.13 or 3.14. See LinuxChanges log for new features such as zram, zswap (relevant to memory constraint plug computers).

The most important upgrade is security related upgrade, where you just do

apt-get update
apt-get upgrade

to get the latest security patches

or do

apt-get upgrade openssl  (or openvpn)

And of course backup your rootfs before upgrading.

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

bodhi Wrote:
-------------------------------------------------------
[... snip ...]
>
> It seems you don't have any locale in your new
> 3.14.0-tld-2 rootfs (kernel does not have any
> locale specific stuff).
[... snip ...]

Hi bodhi,

sorry for not making this clear in my earlier post: I do have locales installed on both systems. I get the following from locale in both cases:

└──> locale
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Then, what do you mean by this line:

cat ~/.utf8

There is no file called .utf8 in /root (which means it is not there in your rootfs either; such a file does not exist on my Ubuntu system either). I just created one by touching it in the 3.14.0-tld-2 system to see whether that makes a difference. It did not. The system still thinks that the codeset is ANSI_X3.4-1968.

Anyway, to isolate the problem further, I took the stick where the locale is found (i.e., the one running the old 3.8.11 kernel with Debian 7.1) and only installed the new kernel as explained in your first post. So now it is running the 3.14.0 kernel and it still does find the UTF-8 codeset! Therefore, it definitely is not a kernel problem.

Then I looked at the files /etc/locale.gen on both systems. They are identical according to meld and contain two lines which are uncommented, namely

de_DE.UTF-8 UTF-8

and

en_US.UTF-8 UTF-8

The only other test left seems to be dist-upgrading to 7.5. Did that also and nothing changed, meaning codeset is till determined to be UTF-8, as it should be.

To summarize:

One system is such that I first installed the latest kernel together with my germanized version of bodhi's latest rootfs (with all upgrades, so I have the latest Wheezy 7.5) and then I installed the self-compiled VDR packages. This system thinks its codeset is ANSI_X3.4-1968 when VDR is started.

The other system is such that I installed the VDR packages on Wheezy 7.1 running kernel 3.8.11. I then upgraded the kernel and finally upgraded the system to Wheezy 7.5. This system thinks its codeset is UTF-8 when VDR is started.

Both systems have identical locale.gen files. They both "speak German", e.g. when I run apt-get update.

????????????????????????????????????

Sorry, couldn't help that. I really do not have a clue what is going on here.

Will try to investigate further and see what I can find out, although I do not really have another idea right now.

Cheers,

chessplayer

---
Standart ist der Standardfehler



Edited 4 time(s). Last edit at 05/02/2014 10:35AM by chessplayer.

Hello!

I just bought a pair of NSA325v2 and am going to mod them (as soon as they're delivered), trying to preserve both original nand and stock u-boot.

I've already read:
http://forum.doozan.com/read.php?2,14351
http://forum.doozan.com/read.php?3,12381
and this thread (this one not completely)

What is still unclear to me is:
- If I want to compile my own 3.14.2 kernel, should I apply bodhi's patch to vanilla sources as a starting point?
- Since there is still no .dts file in mainline kernel, does it mean that no FDT Kernel can actually be built ?
- Why bodhi's patches do not get applied to mainline kernel? Is it because the trend is to migrate all devices to FDT ?

Also, I build my rootfs with multistrap and have my custom-made initramfs.
I looked into initrd.img-3.14.0-kirkwood-tld-1 - how has it been built (what program) ?

Thank you, and ofc kudos to all the fantastic people that keep this forum so amazing!!

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

chessplayer,

The clue here is

May  2 01:07:32 3.14.0-VDR user.debug vdr: [3552] found 0 locales in /usr/share/locale

It seems to indicate that the locale on that 3.14.0-tld-2 system was not properly installed somehow. Because if you follow the standard procedure during installation then /usr/share/locale should have locales.

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

@davidedg,

> - If I want to compile my own 3.14.2 kernel, should I apply bodhi's patch to vanilla sources as a starting point?
Yes.

> - Since there is still no .dts file in mainline kernel, does it mean that no FDT Kernel can actually be built ?
True. You'll have to find the NSA325 dts or create one.

> - Why bodhi's patches do not get applied to mainline kernel? Is it because the trend is to migrate all devices to FDT ?
Yes. Kernel mainline no longer accept patches for machine type since 3.5.xx, only FDT patches. That's the whole purpose of this thread, i.e. to provide non-FDT kernel updates.

> Also, I build my rootfs with multistrap and have my custom-made initramfs. I looked into initrd.img-3.14.0-kirkwood-tld-1 how has it been built (what program) ?
The initrd.img-xxx is automatically built when the kernel is compiled. So you can run update-initramfs -u after install this kernel to update your initramfs.

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



Edited 1 time(s). Last edit at 05/02/2014 07:03PM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> chessplayer,
>
> The clue here is
>

> May  2 01:07:32 3.14.0-VDR user.debug vdr: [3552]
> found 0 locales in /usr/share/locale
>

>
> It seems to indicate that the locale on that
> 3.14.0-tld-2 system was not properly installed
> somehow. Because if you follow the standard
> procedure during installation then
> /usr/share/locale should have locales.


Hi bodhi,

as I said, the system does "speak German" and the locales are there:

┌─[root@wheezy-VDR-dvbapi]─[~]
└──> ls /usr/share/locale/
.   ast       bn_IN  cs_CZ  de_AT  en_AU        en@quot  et_EE  fr     he     hu_HU  ja  ku            lt_LT  ml  nl     pa     pt_PT  ru_RU  sl        sr_RS  te     uk     zh_TW
..  be        bs     cy     de_DE  en@boldquot  eo       eu     fr_FR  hi     id     kk  ky            lv     mr  nl_NL  pl     rm     rw     sl_SI     sv     th     uk_UA  zu
af  be@latin  ca     da     dz     en_CA        es       fi     ga     hr     is     km  lg            mg     ms  nn     pl_PL  ro     si     sq        sv_SE  tl     vi
ar  bg        ca_ES  da_DK  el     en_GB        es_ES    fi_FI  gl     hr_HR  it     kn  locale.alias  mk     nb  nn_NO  pt     ro_RO  sk     sr        sw     tr     wa
as  bn        cs     de     el_GR  en_NZ        et       fo     gu     hu     it_IT  ko  lt            mk_MK  ne  or     pt_BR  ru     sk_SK  sr@latin  ta     tr_TR  zh_CN
┌─[root@wheezy-VDR-dvbapi]─[~]
└──> ls /usr/share/locale/de_DE
.  ..  LC_MESSAGES
┌─[root@wheezy-VDR-dvbapi]─[~]
└──> ls /usr/share/locale/de_DE/LC_MESSAGES/
.  ..  vdr-dvbapi.mo  vdr-epgsearch.mo  vdr-live.mo  vdr.mo  vdr-streamdev-server.mo  vdr-svdrpservice.mo  vdr-xvdr.mo

The problem must be the codeset. For this ANSI_X3.4-1968, there really are no locales to be found, that's true. But meanwhile I believe that it must be a VDR-specific issue and will try to find out how VDR determines the codeset in the first place. So, don't worry about this any more. For completeness, I am going to post here when I have found a solution. But it is not something too many people will actually have to worry about.

Thanks anyway for your efforts again.

chessplayer

---
Standart ist der Standardfehler

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

Quote
bodhi
> > - Since there is still no .dts file in mainline
> kernel, does it mean that no FDT Kernel can
> actually be built ?
> True. You'll have to find the NSA325 dts or create
> one.

Maybe the question is naive - is it that difficult to actually build one? Maybe we can request more info at Zyxel?

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

My apologies ...

to anyone who read and thought about the ANSI_X3.4-1968 problem. The solution was so easy and damn obvious, that I feel more than just a little embarrassed. It turns out that the locales package was installed, but not configured correctly in that the default language was not set. So

dpkg-reconfigure locales

with setting German as the default language did the trick ...

chessplayer

---
Standart ist der Standardfehler

davidedg,

Regarding FDT kernel, the kernel DTS is not difficult to build. However, it's a non-trivial task. Take time to code and test. I actually built one for GoFlex Home as an exercise, but have not tested it because the time I estimated it would take to spend on the whole process (and then have forgotten all about it :-). I used Kurlon example and tutorial. Kurlon did an excellent job of describing how it should be done.

The good thing is that the NSA325 technical info is already done by WarheadsSE, now it only needs to be converted to DTS format. So that counted toward a big part of the effort already.

Also note that you don't need a FDT-able U-Boot to run FDT kernel, you use a compatible mode where the DTB is appended to the kernel zImage. So that saves some of the effort. OTOH, if you have U-Boot that support FDT then the testing is little easier.

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

bodhi,

I've used your kernel patches to derive a minimal compiling config.
It gave me some problems about kirkwood_pm_init(void) symbol not present, had to forcefully disable CONFIG_PM_RUNTIME, I'd expect #ifdefs should have take care of it.
I hope it will boot, nas should arrive tommorrow or so :D

Regarding FDT, I've read Kurlon post and it does not seem rocket science, provided that those info are already available (thx to WarHeadsSE ?).
Is there a project (here or somewhere else) to bring it to life?
Once I have 1 of the the boxes running for my friend, I'm willing to help in building DTS, if help is needed, with my other box.

Thx!

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

davidedg Wrote:
-------------------------------------------------------
> bodhi,
>
> I've used your kernel patches to derive a minimal
> compiling config.
> It gave me some problems about
> kirkwood_pm_init(void) symbol not present, had to
> forcefully disable CONFIG_PM_RUNTIME, I'd expect
> #ifdefs should have take care of it.
> I hope it will boot, nas should arrive tommorrow
> or so :D

Kernel boots almost fine, but it gives strange errors during my initramfs init (during busybox findfs).

__nand_correct_data: uncorrectable ECC error
__nand_correct_data: uncorrectable ECC errorend_request: I/O error, dev mtdblock5, sector 0
Buffer I/O error on device mtdblock5, logical block 0
__nand_correct_data: uncorrectable ECC error
__nand_correct_data: uncorrectable ECC errorend_request: I/O error, dev mtdblock5, sector 8
Buffer I/O error on device mtdblock5, logical block 1

I tried your kernel with my initramfs and it works like a charm, so it is definitely related to *my* kernel, maybe I missed some options for NAND.
You got any clues? Otherwise I'll try to split the differences in sections and try to catch the culprit.


Thx!

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

DavideDG,

It does not ring a bell! it is strange that your initramfs would look for the kernel in NAND. I think that's where the stock kernel resides? if it looks for mtdblock6 then it would not be that weird.

[   14.004579] 0x000000000000-0x000000100000 : "uboot"
[   14.009710] 0x000000100000-0x000000180000 : "uboot_env"
[   14.015215] 0x000000180000-0x000000200000 : "key_store"
[   14.020693] 0x000000200000-0x000000280000 : "info"
[   14.025696] 0x000000280000-0x000000c80000 : "etc"
[   14.030676] 0x000000c80000-0x000001680000 : "kernel_1"
[   14.036047] 0x000001680000-0x000004640000 : "rootfs1"
[   14.041378] 0x000004640000-0x000005040000 : "kernel_2"
[   14.046757] 0x000005040000-0x000008000000 : "rootfs2"

I think it's best to rebuild it with your specific options, if any, using my kernel's initrd. if you intent to keep the kernel.

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



Edited 1 time(s). Last edit at 05/10/2014 09:44PM by bodhi.

bodhi Wrote:
-------------------------------------------------------
> It does not ring a bell! it is strange that your initramfs would look for the kernel in NAND. I think that's where the stock kernel resides? if it looks for mtdblock6 then it would not be that weird.

Actually, my initramfs is a very simple one, based upon busybox. The operation that triggers the error is "findfs", which basically looks in all /proc/partitions (so including mtd*) for a block device whose label is a particular one.
The boot actually works and I can get a stable system, but everytime I call findfs (even once booted up), I get those errors.

I tend to think that some nand functionality is missing in my kernel; since it's a cloudy sunday here, I got some spare time... I'll try catch it, even for just an excercise...

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

Found the error, I had

CONFIG_MTD_BLOCK=y

Confirmed also by this: if I use your kernel, initrd and rootfs and I modprobe mtdblock, it gives same errors.


Now I have another problem, always using 3.14.0-kirkwood-tld-2 and your rootfs, I cannot seem to have sensors working:

root@debian:~# cat /sys/class/hwmon/hwmon0/device/temp1_input
[  396.131910] nsa3xx-hwmon nsa3xx-hwmon: Failed to read MCU data
0
root@debian:~# cat /sys/class/hwmon/hwmon0/device/fan1_input
[  401.391909] nsa3xx-hwmon nsa3xx-hwmon: Failed to read MCU data
0

Should they actually work?
Ty!

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

DavideDG,

Others have not reported seeing the error with sensor in their NSA325. I think it is best to post in this thread:
http://forum.doozan.com/read.php?2,14351

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

bodhi Wrote:
-------------------------------------------------------
> Almaz,
>
> There is really no need to run the latest kernel,
> unless you want to try new features in 3.13 or
> 3.14. See

...

I've long wondered about this, with regard to both my Go Flex as well as other embedded devices. Upstream is constantly upgrading the various kernel releases - e.g., on my laptop, I've been using 3.10.x longterm for a while, and I'm currently preparing to upgrade from 3.10.39 -> 3.10.40. Each of these releases is followed by an announcement that "all users of the x.y branch must upgrade". Doesn't this mean that running the same kernel for a while without upgrading will possibly leave one exposed to all sorts of newly discovered problems?

Hi,
ist your Kernel compatible with the Pogoplug V1 (currently @ Linux 3.3.2-kirkwood-dg #1 Mon Apr 23 17:09:27 CDT 2012 armv5tel GNU/Linux)?
Last time I tried one of your kernels (about 1 year ago) I couldn't get it working.

theliquid,

It should work for the Pogo V1. But you should back up your rootfs before trying it. The archNumber should be set to 2097 to boot it. And as always, make sure you have serial console or netconsole connected before changing arcNumber.

If you want to be extra careful, then list the V1 dmesg output and/or U-Boot boot log here so we can verify.

EDIT:
I believe arcNumber 2998 should also work. So check your current one if it's either 2097 or 2998 then keep it the same.

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



Edited 1 time(s). Last edit at 05/23/2014 03:59PM by bodhi.