kiryl, Don't connect 3.3V, should connect only TX, RX, and GND.by bodhi - uBoot
Earl, apt-get update is successful, then the sources are OK. Did it happen after you upgraded the kernel? if yes then I would backup the rootfs first, and then do apt-get upgrade. Try install again after that.by bodhi - Debian
Kernel 3.13.1-kirkwood-tld-1 package was uploaded. Please see first post for download link.by bodhi - Debian
@milhouse31, I've ran the same dd test on the GoFlex Net USB thumb drive root@HomeMBP:/localdisk# dd if=/dev/zero of=./test count=50000 50000+0 records in 50000+0 records out 25600000 bytes (26 MB) copied, 1.51012 s, 17.0 MB/s No disk write slow down problem in 3.12.x or 3.13.1.by bodhi - Debian
Heychris, > Personally I've attempted many times, but am just > not quite finding the problem. I've also uart > restored dozens of times. So UART booting does work on the Netgear Stora? That would make upgrading uBoot much easier. What was the problem you've seen while booting your new uBoot? and what uBoot version did you build?by bodhi - uBoot
Atesz, See first post of this thread for how to download the latest rootfs (3.12.0-kirkwood-tld-3, updated 14 Dec 2013), and installation to a USB pen drive.by bodhi - Debian
Atesz Wrote: ------------------------------------------------------- > 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? May be. Which plug do you have? are you running stock FW and OS?by bodhi - Debian
nekitip, QuoteI 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 wheby bodhi - Debian
kiryl Wrote: ------------------------------------------------------- > Hi, > > I know there are patches available for compiling > version 1.1.5 => > u-boot-marvell-ms2110 <= but the > final compiled u-boot.kwb file seems to be too > small, something about 150KiB, while the original > is much bigger (or maybe it is just a mtd0 > backup), something aboutby bodhi - uBoot
Earl, 1. To turn the status LED to green for normal operation, put these statement in your /etc/rc.local (before the exit 0): # turn on LED if [ -d /sys/class/leds/status:green:health ]; then echo default-on > /sys/class/leds/status:green:health/trigger if [ -d /sys/class/leds/status:orange:fault ]; then echo none > /sys/class/leds/status:orange:fault/trigger fi fby bodhi - uBoot
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_CAMERAby bodhi - Debian
@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 lacby bodhi - Debian
johnklos Wrote: ------------------------------------------------------- > The IP was actually in the u-boot environment > before I changed anything (I kept a copy of the > original output): > ipaddr=192.168.58.233 > serverip=192.168.58.188 These are not relevant if you're not running tftp, nfs, or netconsole (these values are not default, but most likely were set byby bodhi - uBoot
Earl, The reason is that you are running GoFlex Net uBoot by davygravy (installed by Jeff's script). This works because the GoFlex Home is a closed cousin of the GF Net. The LEDs must be set in Debian using Goflex Net settings, you can find the trigger in /sys/class/leds. If you're not sure, post the output of ls -lR /sys/class/leds Rescue system is another story, since you haby bodhi - uBoot
The Stora stock uBoot is quite old. Running newer uBoot in memory will not work. I'll take a peek in uBoot source to see if anything is similar to this box. You can also Google it to see if anybody has created uBoot patch.by bodhi - uBoot
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 uby bodhi - Debian
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.by bodhi - Debian
Your rescue system arcNumber must be something other than the GoFlex Home (3338). Looks like it's a Dockstar. Check it with: fw_printenv arcNumber But before setting this arcNumber, make sure you can boot it with a kernel that supports it (I don't know if your rescue system supports it) . But first, make sure you can boot with the rootfs above (it works for most Kirwood plugs). Iby bodhi - uBoot
earl, If it's a GoFlex Home then try UART booting: http://forum.doozan.com/read.php?3,7852,7852 And you can use uBoot image from this thread for UART booting: http://forum.doozan.com/read.php?3,12381 After verifying that it booted, put this rootfs on a USB thumb drive: http://forum.doozan.com/read.php?2,12096 If everything boots OK into Debian, then while in Debian, flash thisby bodhi - uBoot
Yes, setup tftp on another Linux or OSX box and flash the current uBoot image. In the example below, 192.168.0.100 is the ip address of the other Linux box 192.168.0.200 is the ip address of this Dockstar (assuming it is the Dockstar) uboot.kwb is the uBoot image that is retrieved by Jeff script (http://projects.doozan.com/uboot/install_uboot_mtd0.sh) for the Dockstar. and all commanby bodhi - uBoot
ingmar_k Wrote: ------------------------------------------------------- > Great to hear that my little theory worked out > like expected. Nice solution!by bodhi - uBoot
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. Rby bodhi - Debian
@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 haveby bodhi - Debian
davidedg, > But how can I do with bootargs? I may end up > running from NAND, but using USB bootargs. > > Or am I missing something? > Ty! No, you did not miss any thing. It's a limitation of stock uBoot where you can't use "if else" syntax (contrary to the newer uBoot that I've built recently for other plugs). With stock uBoot, the envs forby bodhi - uBoot
The reason is the bootm was executed at the end of this command: setenv boot_from_usb 'usb reset; run usb_load_uImage; run usb_load_uInitramfs; run usb_setbootargs; bootm ${uImageAddr} ${uInitramfsAddr}' So take out the bootm and commonize it, something like this: setenv bootm_cmd 'bootm ${uImageAddr} ${uInitramfsAddr}' setenv bootcmd 'run boot_from_usb; run bootby bodhi - uBoot
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?by bodhi - Debian
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 satisfaby bodhi - Debian
johnklos, > Are all PogoPlugs configured from factory to the > same 192.168.58.x network? I noticed that the > netmask is 255.255.0.0, but I don't think people > should create an alias with such a large netmask > because some people will already be using another > 192.168 network. > No. 192.168.58.x is the local network IP subnet determined by your router. Iby bodhi - uBoot
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.by bodhi - Debian
The original Pogoplug uBoot envs is at 0xa0000. The new uBoot uses 0xc0000. Also, for the Pogo Mobile original uBoot, blparam must be used, not fw_setenv and fw_printenv. You can find blparam in the Pogo OS rootfs (iirc, it's under /usr/local/cloudengines/bin). The syntax is slightly different, and blparam calculates a different checksum for the envs, so dont use fw_setenv. Here is anby bodhi - uBoot