This stinks. I really want to safely test out your 2014.01 u-boot. I hope heychris pokes in soon and can respond. I'm very curious what he did. It could be a difference in the bootRom version. It seem like your kernel should boot with the stock u-boot. I was going to attempt to boot my Stora's boot stick on the NSA as a test to determine if the issue is with the initrd or not.by kraqh3d - uBoot
Been there; done that. I've stopped and restarted kwboot *many* times while the stora was stuck in this frozen state. I originally broke into the NSA320 using kwboot to load another uboot. It only took a few tries. I spent three hours yesterday. I really don't think uart boot is possible on this platform given its got the older boortom like the dockstar. I even tried that crazy poby kraqh3d - uBoot
Yeah I'm actually going to give that a go but it should not matter as kwboot is kwboot regardless of what arch its compiled for. The Stora doesn't seem to accept the magic code and all information seems to point toward the problem being due to boot rom 1.11 versus 1.21. When the Stora powers up while kwboot is sending the handshake, it just stalls out. No lights flash or anything. Iby kraqh3d - uBoot
I'm trying but I'm having no luck kwboot'ing the new 2014.01 uboot image. I compiled kwboot for i686 from the official u-boot sources. I checked the Stora and its got boot rom version 1.11. Is this even supposed to work? Heychris, how did you get it to work?by kraqh3d - uBoot
@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 kernby kraqh3d - Debian
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 froby kraqh3d - Debian
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 simplby kraqh3d - Debian
That's not your uboot. It's your kernel and it looks like a squeeze kernel since a 2.6 version, not shyd's 3.1.10. The uboot is the hardware boot loader. If the script says you have the latest uboot, then you have the latest uboot. It checks by copying it off nand and doing an md5sum. Based off your md5sum, you have this uboot which is the latest for the Dockstar. It's wby kraqh3d - uBoot
@bodhi I do not have flash-kernel installed. I removed that long ago because I didn't want a deb install to ever overwrite anything without me being aware. 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. @nekitip No. I've got an ext3 root. Tby kraqh3d - Debian
Bodhi, I'm running into an issue with tld5 on my NSA320. I really thought it was already running your kernel but it wasn't. I installed the debs and generated the uImage and uInitrd files but I never swapped them to boot. l keep more than set around. I was still booting davygravy's 3.3.3 kernel. I have a lot of video sitting on those hard drives and I can't "test&by kraqh3d - Debian
Oh! I didn't know it would boot off the original uboot. That certainly makes it easier.by kraqh3d - Debian
Nope. Nothing at all wrong with the environment variables. I dd'ed wacked the first 512 bytes of the same stick to effectively blank the partition table. I ran back thru fdisk and mkfs again. Untar'ed your rootfs to it. And it boots with no other changes at all. The ALARM uboot doesn't complain about it and its properly reporting partition type 83 as it should. It's runby kraqh3d - uBoot
I need some ideas. It's very late. I'm probably missing something trivial and its driving me crazy. I got this Pogo just a little while ago so it's my newest toy. Over the weekend I got it booting Debian off USB using the Arch ALARM uboot. I had ran a revert to play around with using my.pogoplug.com to backup over the Internet. For giggles. I was curious about throughput.by kraqh3d - uBoot
Sorry you confuse me. You need to be clearer. I thought you said its not booting the standard pogo firmware (which implies its booting another linux) and you have no idea what the password is for ssh access. Now you're saying you don't have the usb stick with that alternate linux environment? If that's all true, then I can only guess that the previous owner loaded that alternaby kraqh3d - Debian
So its booting into this "squeezeplug" distro from USB? Why do you care about it? Looking at the instructions, I bet you could just boot a brand new stick built from bohdi's 3.12.0-kirkwood-tld3 rootfs. If not, I would suggest that you first and foremost open the box and setup serial access. It's the safest way to recover any of these devices.by kraqh3d - Debian
It's there. The sources are really installed to: /usr/src/linux-headers-3.12.0-kirkwood-tld-5 And symlinked from here: /lib/modules/3.12.0-kirkwood-tld-5/build/ But I see that header file via both paths: root@debian:~# ls -l /usr/src/linux-headers-3.12.0-kirkwood-tld-5/include/linux/netdevice.h -rw-r--r-- 1 root root 97369 Nov 3 15:41 /usr/src/linux-headers-3.12.0-kirkwood-tld-by kraqh3d - Debian
Just check for a file or directory on a USB drive as the trigger to boot into NetBSD. Something like this will see if the directory /netbsd exists on first usb device, and boot NetBSD from nand if it does. boot_nand=if fatls usb 0:1 /netbsd; then nand read.e 0x800000 0x800000 0x800000; bootm 0x800000; fi I find using fatls to check for a directory cleaner than using fatload to load a fiby kraqh3d - uBoot
You can. The updated uboot can load the original uboot which in turn loads the original firmware. This defines your boot order: bootcmd=usb start; run force_rescue_bootcmd; run ubifs_bootcmd; run usb_bootcmd; usb stop; run rescue_bootcmd; run pogo_bootcmd; reset At the very end, this is executed which tries to load a backup image of the original uboot from a jffs2 partition. pogo_boby kraqh3d - uBoot
I just checked and the ftdi_sio.ko module is present in 3.12.0-kirkwood-tld-5. You shouldn't need to anything more than dpkg install the debs which will put in the module somewhere in /lib/modules/3.12.0-kirkwood-tld-5/. You just have to modprobe or insmod load it. I don't have an NSA310 but comparing with my NSA320, it looks like you're writing the uImage in the "kernel_by kraqh3d - Debian
The vmlinuz file is not a uImage. It's a standard compressed kernel. I do not believe uBoot will process that correctly as-is. You need to create a proper uImage from it with mkimage. At least that's what I've done to use this kernel on three devices so far -- a Dockstar, a Pogo V4, and an NSA320, all of which boot from USB sticks. Just so it's clear. I dpkg'eby kraqh3d - Debian
bohdi, This is my current startup mount script. I still use pmount but you see its expanded since my original those years ago. It cleans up all stale mount points left over from an ugly shutdown before mounting the connected devices. And I found a few bugs with the original related to disk labels with spaces which required additional quoting and changing IFS to \n as I still make use of bashby kraqh3d - Debian
Hey Bodhi, I thought you would find this interesting... I was more than happy with the performance with the sync option so I never looked at async mode. Until very recently, I'd only had USB attached discs. This time I was using a flash media (ie conforming to the USB Mass Storage spec) and they are apparently very different from USB attached hard drives. They have absolutely dreadful peby kraqh3d - Debian
You likely have a bad block within the first four blocks of /dev/mtd0. See this for thread for some instructions on how to do manually install uboot to /dev/mtd0, working around the bad block. I'm going to warn you now that it's a bit hairy. You have to first find the bad block by erasing mtd0. After you do that you can't power it off until you load uboot back again. http:/by kraqh3d - Debian
I have but all my drives are Fantom USB2 to SATA 2TB drives. I have three different models but they all were about the same, near full 100 mbps ethernet doing read and write tests, using Samba no less. Testing was done individually. I never tried to run simultaneous tests against all three at once gauge the impact of concurrency. And thanks for that tip on smartmon. I just assumed it didntby kraqh3d - Debian
Nice. I actually have a system that I've dist-upgraded from Etch to Lenny to Squeeze in turn. (Yes it's still running.) The upgrade to Squeeze was not pretty. I had to correct a lot things by manually removing conflicting packages. You can run a mixed environment based off Squeeze but intentionally pulling some packages from Wheezy. Put both squeeze and wheezy in /etc/apt/sourby kraqh3d - Debian
I don't use Webmin. I don't know why it's showing that but it is sort of correct. It is NTFS-3G which uses FUSE (either internally or externally.) I suppose Webmin is building it's table by combining /etc/fstab (which needs type ntfs-3g) with the actual mounts from the mount command (which will report the type as fuseblk). What do you mean by mirror? You *could* mirrorby kraqh3d - Debian
After re-reading, it sounds like you have the cold boot problem and tried changing your kernel to see if it overcomes it. If you build a serial cable, I'm pretty sure you'll see errors that Uboot cant see your stick after a power cycle. (Please build a serial cable. You will not regret it. It's invaluable. At the very least please set up netconsole.) There is a work around.by kraqh3d - uBoot
You'll have to run the resultant kernel and initrd through mkimage to make a uboot compliant image.by kraqh3d - Debian
Assuming you have backups of the original mtd1 and mtd2 partitions, and can boot into an alternate linux environment (with the correct mtdparts parameter of course), I would expect you should be able to just write the backup copies back to those partitions. It should be nothing more than this: flash_eraseall /dev/mtd1 nandwrite /dev/mtd1 mtd1.dd.bkup flash_eraseall /dev/mtd2 nandwrite /devby kraqh3d - Rescue System