Linux Kernel 6.7.5 Kirkwood package and Debian rootfs

absintos Wrote:
-------------------------------------------------------

> same with 3.14. The main culprit that i suspect is samba4. although, the lack of proper jumbo frames
> support might also be affecting this (worked great with stock). when jumbo frames are enabled (9k,
> 4k, whatever), speed drops to about 1-2 MBps....

When first replaced stock fw with my first debian build, I had same problems (if not worse).
That belonged to debian default configuration.
Speaking about NSA325 here, eventually I got a decent config:
https://github.com/davidedg/NAS-mod-config/tree/master/samba

The real speed-changer parameter seemed to be socket options and use sendfile

So I suggest you first try with samba3 with my params (or a subset of them) and see if it's a samba config issue, rather than a kernel/driver issue.

For reference, with NSA325 I can get around 60MB/sec with gigabit network and no jumbo frames.

Bye!

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

Hello,

my goal ist to get a debian wheezy system on my NSA325v1.

So I created a new debian on a USB stick with Debian-3.14.0-kirkwood-tld-1-rootfs-bodhi.tar.bz2 (15 April 2014).
I modified environment like in attached setenv.txt .
Then I rebooted from the original firmware and the nsa325 booted from the stick and everything worked fine !
Unfortunately after repowering the device now it is constantly rebooting.

It loads the kernelimage and initrd and comes that far:
[ 26.100085] alg: hash: Test 1 failed for mv-hmac-sha1
[ 26.105163] 00000000: 0c aa 9f d5 37 c3 79 3a 91 d9 21 5f 42 2b 2c 24
[ 26.119668] 00000010: b7 c3 16 0c
[ 26.127328] nsa3xx-hwmon nsa3xx-hwmon: initialized
[ 26.151730] orion_wdt: Initial timeout 21 sec
done.

At this point the nsa325 reboots.

When reverting back to original firmware and rebooting again into the debian on the stick, the system is stable. Until repowering ;)


Unfortunately i cannot test the behaviour with linux-image-3.15.3 (following the installation for the update on 03 July) because then the system only loads the kernel image and then it does nothing:
.........................
.........................
.........................
.........................
.........................
.....

6362802 bytes read
## Booting image at 02000000 ...
Image Name: Linux-3.15.3-kirkwood-tld-1
Created: 1970-01-01 0:08:38 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 7191588 Bytes = 6.9 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK

At this point it sits there not loading the ramdisk.

Then it reboots again.


Seems like the old watchdog is back again ?

Greetings,
Peter

@Peter,

See this thread for discussion about watchdog:
http://forum.doozan.com/read.php?2,14351

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

Wow, so it was the stick. I already wondered, sometimes the image loading failed with bad crc, sometimes it didnt find the stick, most of the time it booted.

With the new stick everything changed: no crc errors at all, the stick is found at every boot, no watchdog issues anymore.

I dont understand the issue completely: when a stick boots, the disabling of the watchdog should be done early enough to ensure even slow sticks can be used. But I just cannot believe it has something to do with the speed of the stick (the new one i am using is not significantly faster than the first one). Or what is the issue ?

Regards,
Peter

@Peter,

The bad stick is slow and the kernel has not gotten executed far enough to shut it off. As WarheadsSE explained here:
http://forum.doozan.com/read.php?2,14484,14487#msg-14487

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

Hi,

i think i finally tracked down the speed issue: i "think" it was due to the uboot i was using, which apparently was disabling the L2 cache. using stock uboot, things are moving along the lines of 37 MBps (stock is somewhere around 38-39 so close enough).

"small" issue though: using kernel from Debian-3.14.0-kirkwood-tld-1-rootfs-bodhi.tar.bz2, system boots up fine. using latest kernel though, system freezes at:

## Booting image at 00800000 ...
Image Name: Linux-3.15.3-kirkwood-tld-1
Created: 2014-07-23 18:37:36 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 7191588 Bytes = 6.9 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK

(does not execute kernel)

anyone hava any clue ? I've noticed that the latest kernel image is far larger then the one in the rootfs (both being uncompressed). May it be due to the fact that it exceeds a size limitation or something ?

using

ext2load ide 0:1 0x00800000 /uImage; ext2load ide 0:1 0x01100000 /uInitrd

to boot (address issues ?)

U-Boot 1.1.4 (Nov 9 2012 - 14:55:24) Marvell version: 3.4.19

U-Boot code: 00600000 -> 0067FFF0 BSS: -> 006CFB00

Soc: 88F6281 A1 (DDR2)
CPU running @ 1200Mhz L2 running @ 400Mhz
SysClock = 400Mhz , TClock = 200Mhz

with custom uboot (uboot.NAND-NSA320-IDEfixedv4-scripted.kwb) kernel loaded fine before...

The disabling of the L2 cache in modern uBoots was purposefully done -- I think it started with U-Boot 2011.12 (Feb 20 2012) with Wheezy -- because, for some reason I can't explain, it allowed the 3.2-and-beyond kernels to be successfully uncompressed and dispatched to. With L2 cache enabled, I think these kernels could not be used, as they employed a different compression method which would not work correctly. (I think an alternative was to build them differently, but the L2 work-around allowed the uBoot to work with standard kernels.)

When this was done, I asked how the L2 cache was re-enabled, and was told the kernel took care of this. So, you're saying L2 is *not* re-enabled, at least in some kernels? Is there some way to tell this for sure, rather than relying on speed tests? It would of course be a huge problem if it is generally the case.

Inquiring minds...

FWIW, a couple datapoints: I just compared my Pogoplug E02 running Wheezy to a SheevaPlug running Ubuntu 9.04 booted from a very old uBoot -- certainly one that predates the L2-disable trick. These two boxes have the same processors and the reported BogoMIPS are virtually identical: 1192. Furthermore, a difficult factoring problem was handled in roughly the same amount of time on each, leading me to believe that L2 has indeed been enabled under Wheezy (or is disabled on both boxes).

Hi restamp,

The L2 cache is re-enabled by the kernel during boot, we can see this in dmesg:

root@tldDebian:~# dmesg | grep -i l2
[   16.769392] Feroceon L2: Enabling L2
[   16.769431] Feroceon L2: Cache support initialised.

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

absintos,

The new kernel has more modules compiled in so it's quite a bit larger than before.

> ext2load ide 0:1 0x00800000 /uImage; ext2load ide
> 0:1 0x01100000 /uInitrd

This should boot fine with uncompressed 6.9MB kernel (0x01100000 = 17MB, 0x00800000 = 8MB).

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

bodhi Wrote:
-------------------------------------------------------
> The L2 cache is re-enabled by the kernel during
> boot, we can see this in dmesg:
>

> root@tldDebian:~# dmesg | grep -i l2
> [   16.769392] Feroceon L2: Enabling L2
> [   16.769431] Feroceon L2: Cache support
> initialised.
>

So it is. Thanks, bodhi!

bodhi Wrote:
-------------------------------------------------------
> absintos,
>
> The new kernel has more modules compiled in so
> it's quite a bit larger than before.
>

> > ext2load ide 0:1 0x00800000 /uImage; ext2load
> ide
> > 0:1 0x01100000 /uInitrd
>

> This should boot fine with uncompressed 6.9MB
> kernel (0x01100000 = 17MB, 0x00800000 = 8MB).

well, it's not working... :(

restamp Wrote:
-------------------------------------------------------
> bodhi Wrote:
> --------------------------------------------------
> -----
> > The L2 cache is re-enabled by the kernel during
> > boot, we can see this in dmesg:
> >

> > root@tldDebian:~# dmesg | grep -i l2
> > [   16.769392] Feroceon L2: Enabling L2
> > [   16.769431] Feroceon L2: Cache support
> > initialised.
> >

> So it is. Thanks, bodhi!

i checked and indeed L2 gets enabled by the kernel at boot for both uboots (stock & custom),

don't know why the 3.15 kernel doesn't boot with stock though..bodhi, could you possibly make one image using the same conf file as used for 3.14 ? (without all the extra modules)

:)

absintos,

You can add earlyprintk to kernel bootargs (depending what your bootargs looks like, just add it to the end). For example:

usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts earlyprintk=serial

And look at dmesg in serial console ouput. Perhaps stock U-Boot has different memory allocation, it's quite old!

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

bodhi Wrote:
-------------------------------------------------------
> absintos,
>
> You can add earlyprintk to kernel bootargs
> (depending what your bootargs looks like, just add
> it to the end). For example:
>

> usb_set_bootargs=setenv bootargs console=$console
> root=$usb_root rootdelay=$usb_rootdelay
> rootfstype=$usb_rootfstype $mtdparts
> earlyprintk=serial
>

>
> And look at dmesg in serial console ouput. Perhaps
> stock U-Boot has different memory allocation, it's
> quite old!

it doesn't get that far...it hangs at the phase where uboot checks the image just before executing the kernel (basically, uboot hangs, not the kernel). so the only thing that crosses my mind is that it does a buffer overflow or smth due to the size of the new kernel (speculation, as i don't really have any clue about the process of checking and starting a kernel - i just imagine it to be a crc check and a memory adress execution (the kernel entry point))

so basically it hangs here:

Verifying Checksum ... OK
OK <---- doesn't appear (so it confirms the checksum but hangs at the OK step (whatever that is))

absintos Wrote:
-------------------------------------------------------
> bodhi Wrote:
> --------------------------------------------------
> -----
> > absintos,
> >
> > You can add earlyprintk to kernel bootargs
> > (depending what your bootargs looks like, just
> add
> > it to the end). For example:
> >

> > usb_set_bootargs=setenv bootargs
> console=$console
> > root=$usb_root rootdelay=$usb_rootdelay
> > rootfstype=$usb_rootfstype $mtdparts
> > earlyprintk=serial
> >

> >
> > And look at dmesg in serial console ouput.
> Perhaps
> > stock U-Boot has different memory allocation,
> it's
> > quite old!
>
> it doesn't get that far...it hangs at the phase
> where uboot checks the image just before executing
> the kernel (basically, uboot hangs, not the
> kernel). so the only thing that crosses my mind is
> that it does a buffer overflow or smth due to the
> size of the new kernel (speculation, as i don't
> really have any clue about the process of checking
> and starting a kernel - i just imagine it to be a
> crc check and a memory adress execution (the
> kernel entry point))
>
> so basically it hangs here:
>
> Verifying Checksum ... OK
> OK <---- doesn't appear (so it confirms the
> checksum but hangs at the OK step (whatever that
> is))

zyxel nas320 btw....only 1 custom uboot available for it (short of compiling it myself) which unfortunately doesn't boot the stock kernel (hangs the same way as this situation - go figure) and i like to go back to it from time to time to check if anything new appeared (and i don't want to go through flashing every time).

absintos,

> zyxel nas320 btw….

Then try UART booting with the new u-boot test build I've justed uploaded:
http://forum.doozan.com/read.php?3,12381,16787#msg-16787

I have high hope that it will boot the latest kernel.

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

Hello,

I have the same problem like absintos but with nsa325.
After updating the kernel from 3.14.0 to 3.15.3 following bodhi's guide (from "Updated 03 July 2014"), this is how the boot process looks like on the console:
.
.
7191652 bytes read

6445893 bytes read
## Booting image at 02000000 ...
Image Name: Linux-3.15.3-kirkwood-tld-1
Created: 1970-01-01 0:15:16 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 7191588 Bytes = 6.9 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK



Nothing else happens. The system is idle.

Now, if I replace the file /boot/uImage with Version 3.14.0 uImage, then the system boots fine (of course it does not come far, since the kernel version mismatch).

So the whole problem is to find in the uImage file.

Cheers,
Peter

absintos & Peter,

You are running stock U-Boot so the memory location might be different. Please post the output of fw_printenv (or printenv in serial console) here.

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



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

Also, if you have serial console and earlyprintk as parameter to the kernel, error might/might not shows up as load error. As it shown, we can't be sure know how far into the kernel booting before it freezes.

Regarding load address, for all other Kirkwood boxes, the common location for the uImage load address is 0x800000, and uInitrd is 0x1100000.

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

I attached the output from the printenv command from the console.

I was experimenting on the console with direct command (without variables).

mw.l f1010100 0020c000; ide reset; ext2load ide 0:1 0x800000 /uImage; ext2load ide 0:1 0x01100000 /uInitrd ; bootm 0x800000 0x1100000;

mw.l f1010100 0020c000; ide reset; ext2load ide 0:1 0x800000 /uImage; ext2load ide 0:1 0x01100000 /uInitrd ; bootm 0x800000 0x2000000;

Both command lines lead to the described effect of freezing.

How can it be that uImage (3.14.0) boots normally and uImage (3.15.3) doesn't if the parameters for the memory location are the same ? Shouldn't both versions of uImage have the same memory locations ?

Anyway: I hope to be able to use the RTC again like in stock image. Do You think the problem with RTC is fixed in this kernel ? If not, I don't have o bother with new kernel (although it would be nice to know what the problem is).

Regards,
Peter

Hi Peter,

I have not looked at the kernel source about the "RTC not ticking" problem (its status is unchanged in 3.15.3). I will start looking into this problem in a couple days, since I've just got this new toy today :).

The booting problem, I think, might have to do with the large size of the kernel due to a lot more modules got compiled in and initrd uncompressed size might have also increased in a non-trivial way. My thinking is perhaps not the uImage. I'll experiment with earlyprintk to see if I can find out if that was the case (whether anything will be printed out).

BTW, I believe this is a typo, should be: ext2load ide 0:1 0x2000000

> mw.l f1010100 0020c000; ide reset; ext2load ide
> 0:1 0x800000 /uImage; ext2load ide 0:1 0x01100000
> /uInitrd ; bootm 0x800000 0x2000000;

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

bodhi Wrote:
-------------------------------------------------------
> Hi Peter,
>
> I have not looked at the kernel source about the
> "RTC not ticking" problem (its status is unchanged
> in 3.15.3). I will start looking into this problem
> in a couple days, since I've just got this new toy
> today :).
>
> The booting problem, I think, might have to do
> with the large size of the kernel due to a lot
> more modules got compiled in and initrd
> uncompressed size might have also increased in a
> non-trivial way. My thinking is perhaps not the
> uImage. I'll experiment with earlyprintk to see if
> I can find out if that was the case (whether
> anything will be printed out).
>
> BTW, I believe this is a typo, should be: ext2load
> ide 0:1 0x2000000
>

> > mw.l f1010100 0020c000; ide reset; ext2load ide
> > 0:1 0x800000 /uImage; ext2load ide 0:1
> 0x01100000
> > /uInitrd ; bootm 0x800000 0x2000000;
>

Bodhi,
Can you please help me a bit. I got Jeff's uBoot loaded on a factory certified goflex base, but then lost the connection before debian was loaded...so I prepared a rootfs on a USB drive and plugged that in, but the base boots with the green light blinking for a short time, then it goes off. The USB drive flashes like its being accessed/read but then after green light goes off, USB goes into idle mode (light glows a bit). No IP address is generated on my router so I cannot ssh in...can you offer something I could try?

Peter,

> Anyway: I hope to be able to use the RTC again
> like in stock image. Do You think the problem with
> RTC is fixed in this kernel ? If not, I don't have
> o bother with new kernel (although it would be
> nice to know what the problem is).

I've found that the NSA325 RTC driver was loaded as module. This was too late in the boot process. Will see if I can get it working and include it in either in kernel 3.15.3 or a special version of 3.14.0.

UPDATE:
The problem is a little different than I thought. I think we might need to change the patch slightly. I'll consult with WarheadsSE to see what he thinks.

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



Edited 4 time(s). Last edit at 08/02/2014 03:55PM by bodhi.

ptosch,

> mw.l f1010100 0020c000; ide reset; ext2load ide
> 0:1 0x800000 /uImage; ext2load ide 0:1 0x01100000
> /uInitrd ; bootm 0x800000 0x1100000;
>
> mw.l f1010100 0020c000; ide reset; ext2load ide
> 0:1 0x800000 /uImage; ext2load ide 0:1 0x01100000
> /uInitrd ; bootm 0x800000 0x2000000;
>
> Both command lines lead to the described effect of
> freezing.
>

I'm seeing the same freezing with kernel 3.15.8 with load address 0x2000000. And I've verified that kernel 3.15.3 when built with the config file for 3.14 showed the same freezing.

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

Regarding RTC on NSA325:

> I've found that the NSA325 RTC driver was loaded
> as module. This was too late in the boot process.
> Will see if I can get it working and include it in
> either in kernel 3.15.3 or a special version of
> 3.14.0.

This was the reason. Once the driver module for NSA325 was compiled in, it works. Apparently, the rtc-mv still is going to spit out the error because it can't find the Marvell Soc RTC. But not a real problem:

[   14.512070] rtc-mv rtc-mv: internal RTC not ticking
[   14.520852] rtc-pcf8563 0-0051: chip found, driver version 0.4.3
[   14.528172] rtc-pcf8563 0-0051: rtc core: registered rtc-pcf8563 as rtc0
[   14.572101] rtc-pcf8563 0-0051: setting system clock to 2014-08-04 22:57:46 UTC (1407193066)

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

Regarding the freezing problem with kernel 3.15.3 for NSA325. Prelimilary finding: there seems to be a limitation of 4M memory for uImage with stock U-Boot. Stock U-Boot code is difficult to read, so this needs to be confirmed later.

I'm wondering, anybody booting Arch with > 4M uImage? please post (I have not downloaded Arch rootfs to check).

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

Hmm, I've never had a resultant uImage that large.

I've checked. ALARM is just a little bit under 4M currently. There must have been something in 3.15.x kernel and my Debian config that has made the size increase by that much. But it's been running OK for all other Kirkwood boxes.

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

Is there any chance to get this problem for the NSA325 solved?