Linux Kernel 6.10.11 Kirkwood package and Debian rootfs

nekitip,

> the reason i had to do this is because bodhi's
> configuration couldn't access file sistem and
> thus, not been able to boot the system, so i had
> to include ext4, and also, in my case, i had to
> have ftdi_sio.ko. I have included them all in
> uImage.

The kernel has ext2, ext3, and ext4 supports loaded as modules.

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

Quote

@kragh3d, isn't intrid just for booting from NAND?

No. An initrd presents the kernel with small memory resident temporary rootfs that's used to load dynamic kernel modules and run some simple scripts that may be necessary to find and load the true rootfs. The use of it really depends on what has been compiled directly into the kernel, and where the rootfs resides. As a simple example, you need initrd to resolve the rootfs true path when passing a root=LABEL=foo parameter. My suggestion for using the uInitrd earlier was a safety as I didn't inspect the config file to see what was compiled into it.

And yes, I understood that you needed to write it into NAND for your boot sequence, but you do that last after you validate your uImage and/or uInitrd actually works by manually loading them into memory and then manually booting from memory. This is essentially the same thing your boot sequence is doing. It's loading the uImage and/or uInitrd into memory from NAND and then booting from those memory locations. If you don't test it first, you have no assurance that it'll work and you can be left with a system that doesn't boot. And after that, the NAND is entirely out of the equation.

So now you've found that the uImage can load and boot directly from hdd but not from the NAND? Did you write this latest one to NAND? The location of the uImage shouldn't matter other than the uBoot has to be able to load it into memory from there. Once its in memory and it's booted with bootm, it doesn't matter anymore.



Edited 5 time(s). Last edit at 01/25/2014 05:25PM by kraqh3d.

Quote
kraqh3d
The location of the uImage shouldn't matter other than the uBoot has to be able to load it into memory from there. Once its in memory and it's booted with bootm, it doesn't matter anymore.

that puzzles me also, because, there is no reason that i can fatload image, and then bootm with no problem, but also not being able to boot from that same image (copied from memory to NAND).
I suspect the problem might be in (you said it earlier), range of NAND mem that is first erased, and then written to.
But, I will leave that behind because I can live with it. The way I understand it is that the system will never be able to shut down disk (hdparm) because it has root on it, so to be able to boot from memory is not really a bonus. System still needs large root on disk. I also cant use USB because bootloader (i suspect) doesn't bring power early. So, i gave up on that.
If i'm wrong, please point me in some direction.

Quote
kraqh3d
An initrd presents the kernel with small memory resident temporary rootfs that's used to load dynamic kernel modules and run some simple scripts that may be necessary to find and load the true rootfs.

that seems logical, but where it?

setenv bootargs 'console=ttyS0,115200 root=/dev/sda4'
setenv bootcmd 'ide reset; fatload ide 0 0x800000 /uimage-3.12; bootm 0x800000'

This is all I've got, and it boots. (root is on sda4 from before).

Quote
bodhi
The kernel has ext2, ext3, and ext4 supports loaded as modules.

my opinion, based on my new experience, is that filesystem access should always be included in kernel.
your patch is good, but leds are not working, as I can see it, altough it can be caused by my overmessing with adding some drivers to kernel

nekitip,

The kernel was never intended for flashing in NAND. Hence, the patch was provided so you can compile your own kernel for that purpose. If you had installed Arch, then everything should be in the kernel (they don't use initrd). In any case, what you should do is following kraqh3d 's advice to boot the kernel first from memory or USB, make sure everything works to your satisfaction before thinking about NAND. As they say, you got to walk before you can run! that way you will not brick your box unecessarily.

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



Edited 1 time(s). Last edit at 01/25/2014 01:29PM by bodhi.

I noticed something. I don't think it matters, but it is worth investigating.

Your non-working nand boot was loading and booting the uImage from address 0x2000000.
Your working hdd boot is loading and booting the uImage from address 0x800000.

Let's see if that location is the culprit. From the uboot prompt, try to fatload and boot from address 0x2000000 like you were doing from nand. I'm hoping it doesn't boot. Then try the reverse with your nand read.e and bootm from address 0x800000.

---the way that works--

1) install
fatload ide 0 0x800000 uimage-3.12
2) work
setenv bootcmd 'ide reset; fatload ide 0 0x800000 /uimage-3.12; bootm 0x800000'

---the way it is working with 3.5.1, not with 3.12

1) install
fatload ide 0 0x800000 uimage-3.5.1

nand erase 0x4640000 0x300000
nand write.e 0x800000 0x4640000 0x300000
2) work
setenv bootcmd 'nand read.e 0x2000000 0x04640000 0x400000; bootm 0x2000000'

---your way?

1) install
fatload ide 0 0x800000 uimage-3.12

nand erase 0x4640000 0x300000
nand write.e 0x800000 0x4640000 0x300000
2) work
setenv bootcmd 'nand read.e 0x800000 0x04640000 0x400000; bootm 0x800000'

I feel that it has to do with the number of bytes read, erased, written, and then read by nand read.e. Bootloader reports this, but I have failed to preserve that info. If that is the case, then without that we are just guessing.

But kragh3d, to be honest, I will wait for the new 3.13 patch from bodhi to become available, and then unscrew open device to upload newly compiled kernel.

kraqh3d,

> I'll regen the uInitrd tonight and give that a
> shot and report back tomorrow. Come to think of
> it, I should've done that last night. It was late
> and I wasn't thinking.

> ** edit **
>
> Generating a new initrd worked.

Did you mean the rootfs mounted with new initrd?

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

@bodhi

I have never before had any expirience with patching, so with the danger of sounding pompous, and concerning not working LED-s on my nsa310 with yours patch, I notice that you have changed Peeters patch in the part where he defines leds.
The problem i'm seeing with your patch (and again, it may be that it's my fault) is that the leds are not working. Looking at your patch, could it be that it is a trigger issue, or, precisely, not using consitently "sata-disk" or "ide-disk" or "ide-disk1" or "ide-disk2"?
If that is indeed the case, then, when you find the time to look into that, please, consider Pietr/Slawomirs patch. It uses for different color for read or write to both usb and sata.

@nekitip,

It's very possible that I've missed part of the NSA310 patch. It was extracted from Arch Linux ARM patch. Don't worry about pointing out problems! I don't have any of the NSA3xx series boxes and have no way of testing the patch, so other users have been testing these boxes and reported problems in this thread. Especially the NSA310, only you and another user have posted feedbacks. In the first post, the NSA310 is still shown as untested. I'll take a look at Arch patch and Peeters' patch to reconcile them.

Regarding the ide-disk1 and ide-disk2 (it's my own patch), it should work for NSA310 using ide-disk1. And the color of the LEDs should be what you choose to set, not the kernel.

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



Edited 1 time(s). Last edit at 01/27/2014 04:13AM by bodhi.

Thank you for your hard work! Please keep it up! Works fine on NSA325v2.

Are there any plans about submitting it to the Debian Project?

Quote
bodhi
And the color of the LEDs should be what you choose to set, not the kernel.

no, using that patch, the kernel will choose color by testing write/read state of sata-disk.
sata-disk LED is green/red, and Pietr/Slawomir patch will make it green when it is in read state, or red in write state. Similar for USB, but i dont know if usb has two leds.
Please, take a look at that patch and see what it does. I haven't tested it, but looking at the code i have idea of what it should do.

nekitip,

See this post by pbg4 for setting NSA3xx LEDs.
http://forum.doozan.com/read.php?2,12096,13642#msg-13642

It is the normal way to control the LEDs in all these Linux ARM boxes. The color for each LED is whatever you want it to be. Setting them in the kernel is unecessary. The necessary part is to specify the addresses in the code so that the /sys/class/leds triggers are available. Read/write states are really overkilled, IMO. However, if they are available as /sys/class/leds triggers then it's OK to include them (but not if they are hardcoded).

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

from the command line, works, for example:
echo heartbeat > /sys/class/leds/nsa310:red:SATA1/trigger
and default-on, timer...

but not the
echo ide-disk > /sys/class/leds/nsa310:red:SATA1/trigger
nor the:
ide-disk1, ide-disk2, sata-disk, SATA1...

I have a spare DLink DNS-323 that im not doing anything with at the moment. Would I be able to setup this debian rootfs and kernel on the dns323 like I did with my xyzel nsa325? I know there is FFP and a native debian installer to install debian on the hard drives but I was thinking of installing debian on usb flash drive and booting it and creating a raid1 with the 2 drives which is exactly how my nsa325 is setup at the moment and running great.

~SOL

Hi,

@SOL

may be I am wrong, but isn't your DNS323 an ORION type of SOC with a 500 MHz Marvell 88f5182-a2 core??,...
so provided you have a uboot which is able to boot from usb and a newer kernel which is able to interact with
bodhi's wheezy rootfs, this should in principle be possible,.. but would need some efforts from your side definitely,..

@nekitip

if you review the patches from the nas-central nsa310 kernel thread it should be obvious, that Pjotr's v5.2 patch
related heavily -with regard to the LEDs functionality- on the original led ide-disk trigger routine introduced in mainline kernel land by rpurdie some while ago,...

since Pjotr's patches never got upstream and we are discussing here in a kirkwood non device-tree!! thread, it was - at least to my judgement - a very clever idea of bodhi to keep the amount of code lines as minimal as possible by simply patching the original ide-disk trigger routine, and on the nsa320 this works perfectly,.. so if we stick to the idea in the future to have a non device-tree enabled kernel on our devices the amount of work to keep this going is also minimised,..

best wishes pbg4

@bohdi,
Sorry I was away. I couldn't boot this kernel on my NSA320 with the default generated initrd. Strangely, I couldn't even boot it without an initrd using a direct /dev/sda root. I manually made a new initrd using "dpkg-reconfigure linux-*" and then all was good.

@nekitip
Did loading from nand to address 0x800000 and booting from there work for the 3.12 kernel? If so, that will probably be the same way you boot 3.13 when its available. I don't know why your other kernel was booting from 0x2000000. All four of my kirkwood devices load and boot from 0x80000.

I'm attempting to download an install this kernel. I am at the root of my debian USB stick, made a backup of my boot folder, ran:

wget --no-check-cert https://dl.dropboxusercontent.com/s/2429qd7cckhi3z8/linux-3.12.0-kirkwood-tld-5-bodhi.tar.bz2

as you can see, it's present in the root directory:

-rwxrwxrwx  1 root root 30057333 Jan 30 16:17 linux-3.12.0-kirkwood-tld-5-bodhi.tar.bz2

MD5 checks out

root@debian:/# md5sum linux-3.12.0-kirkwood-tld-5-bodhi.tar.bz2
d0fbe64dbe5e4fdbb4842205de77e6a9  linux-3.12.0-kirkwood-tld-5-bodhi.tar.bz2

everything looking good right? well...

root@debian:/# tar -xjf linux-3.12.0-kirkwood-tld-5-bodhi.tar.bz2
tar (child): bzip2: Cannot exec: No such file or directory
tar (child): Error is not recoverable: exiting now
tar: Child returned status 2
tar: Error is not recoverable: exiting now
root@debian:/#

How can that be? I've looked over the file name a dozen times, I'm probably missing something really simple or stupid...



Edited 1 time(s). Last edit at 01/30/2014 10:56AM by ubermacin.

@ubermacin
do you even have bzip2?
try maybe bzip2 -dc linux-3.12.0-kirkwood-tld-5-bodhi.tar.bz2 | tar -xf -

@krakqh3d, I tried with kernel 3.13.1, same thing. Runs loaded from HDD, not from rom (bad CRC at the end).
I vaughly remember that i saw somewhere in config "execute from rom" option... will try that in a day or two.

also, I must admit that i dont fully understand the thing about not include some patch in non dt kernel. I googled that and for all that i understand is that - that means nothing in reality.
that being said, for the curious one, here is how you can compile kernel with minimal effort and it works
download kernel from kernel.org (on your ubuntu/linux mint machine) and unpack it in lets say /home/build/linux-3.13.1

cd linux-3.13.1
make mrproper
make kirkwood_defconfig ARCH=arm
(make menuconfig ARCH=arm) if you need drivers like FTDI, prolific...
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs modules -j3
(-j3 is just a switch for a number of cores on CPU)
ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- make dtbs modules modules_install -j3
cat arch/arm/boot/zImage arch/arm/boot/dts/kirkwood-nsa310.dtb \
    > /tmp/zImage-dtb-kirwood
mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 \
    -n Linux-kikrwood-nsa310.dtb -d /tmp/zImage-dtb-kirwood \
    /home/build/uImage-3.13.1

and there you go. It will work.
If you are lucky, it wil also blink leds. On nsa310 it does not.
cat /sys/class/leds/nsa310:green:hdd/trigger shows
none nand-disk timer oneshot heartbeat gpio default-on
but no sata-disk, or at least ide-disk

...oh, and yes, in config, you must put * next to, or edit .config manualy to set:
CONFIG_ARM_APPENDED_DTB=y
it was described here, but he has compiled it on device itself.

w00t! thanks nekitp! That was the problem! Unbelieveable, I spent at least an hour googling that issue and never seen anyone ask about that. For future fellow n00bs:

apt-get install bzip2

This is a great board!

The newest 3.12.0-kirwood-tld-5 worked like a champ (once I got my bzip2 errors figured out LOL) on my E02. Here is how it played out (dunno if the errors are benign):

root@debian:/tmp# apt-get remove flash-kernel
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following packages will be REMOVED:
  flash-kernel
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
After this operation, 129 kB disk space will be freed.
Do you want to continue [Y/n]? y
(Reading database ... 21752 files and directories currently installed.)
Removing flash-kernel ...
root@debian:/tmp# dpkg -i linux-image-3.12.0-kirkwood-tld-5_5.0_armel.deb
Selecting previously unselected package linux-image-3.12.0-kirkwood-tld-5.
(Reading database ... 21737 files and directories currently installed.)
Unpacking linux-image-3.12.0-kirkwood-tld-5 (from linux-image-3.12.0-kirkwood-tld-5_5.0_armel.deb) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
debconf: falling back to frontend: Readline
Done.
Setting up linux-image-3.12.0-kirkwood-tld-5 (5.0) ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line 76.)
debconf: falling back to frontend: Readline

 Hmm. There is a symbolic link /lib/modules/3.12.0-kirkwood-tld-5/build
 However, I can not read it: No such file or directory
 Therefore, I am deleting /lib/modules/3.12.0-kirkwood-tld-5/build


 Hmm. The package shipped with a symbolic link /lib/modules/3.12.0-kirkwood-tld-5/source
 However, I can not read the target: No such file or directory
 Therefore, I am deleting /lib/modules/3.12.0-kirkwood-tld-5/source

Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.12.0-kirkwood-tld-5 /boot/vmlinuz-3.12.0-kirkwood-tld-5
update-initramfs: Generating /boot/initrd.img-3.12.0-kirkwood-tld-5
run-parts: executing /etc/kernel/postinst.d/zz-flash-kernel 3.12.0-kirkwood-tld-5 /boot/vmlinuz-3.12.0-kirkwood-tld-5
root@debian:/tmp# mkimage -A arm -O linux -T kernel -C none -a 0x00008000 -e 0x00008000 -n Linux-3.12.0-kirkwood-tld-5 -d /boot/vmlinuz-3.12.0-kirkwood-tld-5 /boot/uImage
Image Name:   Linux-3.12.0-kirkwood-tld-5
Created:      Fri Jan 31 02:05:31 2014
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:    2342512 Bytes = 2287.61 kB = 2.23 MB
Load Address: 00008000
Entry Point:  00008000
root@debian:/tmp# mkimage -A arm -O linux -T ramdisk -C gzip -a 0x00000000 -e 0x00000000 -n initramfs-3.12.0-kirkwood-tld-5 -d /boot/initrd.img-3.12.0-kirkwood-tld-5 /boot/uInitrd
Image Name:   initramfs-3.12.0-kirkwood-tld-5
Created:      Fri Jan 31 02:05:42 2014
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:    5982187 Bytes = 5841.98 kB = 5.71 MB
Load Address: 00000000
Entry Point:  00000000
root@debian:/tmp# sync
root@debian:/tmp# shutdown -r now

Broadcast message from root@debian (pts/0) (Fri Jan 31 02:05:54 2014):

The system is going down for reboot NOW!

To get the LEDs to work right, I did have to add the machid

fw_setenv machid dd6

For future readers, tread carefully here, it broke my previous wheezy install. To fix it, I booted back into U-Boot and ran:

fw_setenv machid

That let me boot back into wheezy where i then proceeded to do the kernel upgrade.

Also, as a side note, I found this tutorial helpful for adding some nice things to the LED functionality:

http://midnight-coder.blogspot.com/2013_12_01_archive.html

I did have to install iptables to get the LED on net traffic



Edited 1 time(s). Last edit at 01/30/2014 08:32PM by ubermacin.

nekitp Wrote:

> If you are lucky, it wil also blink leds. On
> nsa310 it does not.
> cat /sys/class/leds/nsa310:green:hdd/trigger
> shows
> none nand-disk timer oneshot heartbeat gpio
> default-on
> but no sata-disk, or at least ide-disk

Did you compile with the patch? if not then that was the reason.

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

ubermacin Wrote:
-------------------------------------------------------

>
> debconf: unable to initialize frontend: Dialog
> debconf: (No usable dialog-like program is
> installed, so the dialog based frontend cannot be
> used. at
> /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line
> 76.)
> debconf: falling back to frontend: Readline
> Done.
> Setting up linux-image-3.12.0-kirkwood-tld-5 (5.0)
> ...
> debconf: unable to initialize frontend: Dialog
> debconf: (No usable dialog-like program is
> installed, so the dialog based frontend cannot be
> used. at
> /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line
> 76.)
> debconf: falling back to frontend: Readline
>
> Hmm. There is a symbolic link
> /lib/modules/3.12.0-kirkwood-tld-5/build
> However, I can not read it: No such file or
> directory
> Therefore, I am deleting
> /lib/modules/3.12.0-kirkwood-tld-5/build
>
>
> Hmm. The package shipped with a symbolic link
> /lib/modules/3.12.0-kirkwood-tld-5/source
> However, I can not read the target: No such file
> or directory
> Therefore, I am deleting
> /lib/modules/3.12.0-kirkwood-tld-5/source
>

These errors are indeed benign! you can safely ignore them. To remove future dialog error:

apt-get install dialog

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

@bodhi,
No, no patch has been used.
The idea is that in that way, the patch it is not needed. It works without, like i have described it earlier, by pairing zImage with devices dts/dtb, wich in my case, for NSA310, was kirkwood-nsa310.dtb.
As I have said, patching is not needed the way I have understod it. However, in my case, LEDS don't work because led-trigger is non egzistent for sata-disk.
So, in that case, patch will indeed be needed, but it is far more simple than before, and maybe only a few lines long.
I haven't tried to make one, since it would take me far too much time to learn to do that, and I guess there are new tools needed but looking at the code, source has changed alot and it is simplified.

Again, it may not be needed at all for some of kirkwood devices.

@nekitip

It's true that for a few kirkwood devices, no patch is needed. Because those dts were already in the mainline, as basic reference boards. In those cases, they can be installed directly. But they will not have correct LEDs, and/or other sensors supports. A majority of the Kirwood plugs don't have dts in mainline, yet. In some cases, the reference board can be used, but it lacks a lot of the functionality that makes the plug unique.

Also, for those devices already in the mainline, when you append dtb to uImage, it really has nothing to do with the patch! It is because the uBoot version on that box is old and does not have FDT support compiled in. This was the main reason why non-fdt patching kernel is really a better approach when we want to run it with many Kirkwood variants (i.e a "universal" Kirkwood kernel). See this post for instruction on how to run a fdt kernel with newer uBoot:
http://forum.doozan.com/read.php?3,12381,13540#msg-13540

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

so, after spending a night and part of a day, looking at the code of each patch, and trying to understand the work of Peeter's, Piotr/Slawomir, and finaly, bodhi. Here I present you results. I'm sure I've miss something, but i've never done this before.
-so, to be able to compile your own kernel, you can follow my directions from a few posts ago, however, to make your LEDS blink, you must edit two files in your downloaded source kernel code

first, remove line marked with "-", or change it to depend on SATA_MV, not IDE_GD_ATA.

config LEDS_TRIGGER_IDE_DISK
  bool "LED IDE Disk Trigger"
- depends on IDE_GD_ATA
  depends on LEDS_TRIGGERS
  help
  This allows LEDs to be controlled by IDE disk activity.

once you've done that, "cat nsa310:red:hdd/trigger" will show that now you do have ide-disk, and you are able to do

echo ide-disk > /sys/class/leds/nsa310:red:hdd/trigger

however, it will not blink.
in drivers/ata/sata_mv.c, add one line, so it will call trigger routine, and add one "include", for ref.
those two lines are marked with + sign. That sign is just marking for your orientation, delete it in file.

 #include <scsi/scsi_cmnd.h>
 #include <scsi/scsi_device.h>
 #include <linux/libata.h>
+#include <linux/leds.h>

 {
  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)

and now, compile kernel as described in my posts before.
I have done this for NSA310 (TDC)
it can be done for other devices as well. for instance, check this nice tutorial for LaCie

And now I must take a look if buttons work, but they probably do not and will need my attention also.

cat config-3.12.0-kirkwood-tld-5 | grep LEDS_TRIGGER

CONFIG_LEDS_TRIGGERS=y
CONFIG_LEDS_TRIGGER_TIMER=y
CONFIG_LEDS_TRIGGER_ONESHOT=y
CONFIG_LEDS_TRIGGER_IDE_DISK=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_BACKLIGHT=m
# CONFIG_LEDS_TRIGGER_CPU is not set
CONFIG_LEDS_TRIGGER_GPIO=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_LEDS_TRIGGER_TRANSIENT=m
# CONFIG_LEDS_TRIGGER_CAMERA is not set

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

@bodhi
that's the one, I hope you are making patch already with this new data.

Next, it might happen that you have different version of nsa310.
For instance, nsa310.dts and nsa310a.dts have different sensors.
Just in my case, i have nsa310 (it's actually a TDC box), and everything in .dts like it should, but sensor from nsa310a. To do that, you must open dts file, delete adt and put LM85 from nsa310. Why not use nsa310a.dts from the beging? Network wont work.

Now that you have that, compiled and running, you can change input-event-daemon and change OPTION key to RESET key, because it is the same key, but reporting RESET now. If not sure, try run input-event-daemon in --monitor mode and push buttons to check.

Ok, that is it.
Now all i'm curious abut is that buzzer thing, and i'm not sure if it is in dts file.
Also, not sure how to use it anyway.
Next, i'm curious, what is this for:

  MPP38_GPIO, // VID B0
  MPP45_GPIO, // VID B1

  MPP44_GPIO, // Buzzer
  MPP43_GPIO, // HTP

  MPP47_GPIO, // Power Resume Data
  MPP49_GPIO, // Power Resume Clock

i'm thinking, although this was all done do bodhi can make new patch that works with nsa310 and is compatibile with new kernels, I think im flooding this topic too much with this since no one else seems interested, so if there is a better place... then point me to it.

Hi.

Can I try this debian linux without install? So only run from USB pendrive? I will not touch original firmware and data in HDD. Can you help for me?

nekitip,

Quote

I hope you are making patch already with this new data.

No :) I meant to say the config file indicated that the IDE LED triggers are already in place. I've done all I can there. The tld-3 patch version works for NSA320 and NSA325. So for NSA310, I don't know why it did not work for you! because I don't have the NSA310 so I can't really say with certainty whether what you've experienced was because of what you did wrong or not either.

Perhaps you should start a new thread for NSA310 like Buttzy did for NSA325. It seems there are only two NSA310 users on this board.

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



Edited 1 time(s). Last edit at 02/02/2014 05:29AM by bodhi.