There are newer kernel sources and with Debian I don't think there are the same problems as with Arch. I am running my Pogos with Kernel 3.1. and Emdebian Stable. I can't say anything about longterm stabilty of Kernel 3.1., though.. So far I didn't run into any problems, however.by ingmar_k - uBoot
Yes, like that. But, as I said, this probably requires some handicraft work, which is not necessarily anyone's preference.by ingmar_k - uBoot
You are probably right. I forgot that the V3 is using some "crippled" U-Boot version which only supports the absolutely necessary. And yes, I think your idea about using SATA as boot drive might work fine. The only problem might be that it needs some tinkering to find a way to connect a drive to SATA directly without making it look too wild, if you know what I mean. :-)by ingmar_k - uBoot
There should be way of scripting it. Like the kernel loading procedure from NAND, where it starts loading from the backup address, if loading the standard kernel Image failed. ;) Would need a bit of testing, though. And btw, we are talking about multiple drives, BUT all connected via USB? Bodhi's post just confused me a bit. If it really is one USB and one SATA (directly!), then the situaby ingmar_k - uBoot
You have to keep in mind that hard drives as well as usb thumb drives both get the /dev/sd* IDs, because both are SCSI to the kernel. So,if the drive you try to boot from is the only USB or SATA drive, it always will be /dev/sda. If you have more than one drive connected, it will be a matter of timing (or maybe of udev rules). In the latter case, you will have to try. Edit: Scratch the udev rby ingmar_k - uBoot
As the Pogoplug V3 versions were recently sold for very good prices (classic and pro), I used my previous work to create some scripts to make switching from Arch Linux to Emdebian much easier. So, if anyone here is interested, have a look here: https://github.com/ingmar-k/Pogoplug_V3_Emdebian If you use the right settings in the main file for those, namely "general_settings.sh", youby ingmar_k - uBoot
Oh and BTW, murpf, your script includes the same error in the conditional logic that Dario's original script used to include. You may want to have a look at the use of "-o" in the if clauses. ;-) Those all need to be replaced by ANDs (&&).by ingmar_k - Debian
The original script was nice to test and play a bit. On the basis of Dario's script, I made my own version, which is "slightly" different. :-D I hope Dario is fine with it. After all I helped him a bit with bug squashing today and to be honest there is not much left from the original version. But you'll realize that quite fast when trying out my version. See the attachmentby ingmar_k - Debian
Yep, for testing purposes just a "quick" setenv is the way to go. Sorry to hear that your plan didn't quite work out the way you had hoped, though. I don't know anything about the fsprotect stuff, so I can't really comment on that.by ingmar_k - uBoot
@ivan: 1.) Ubifs uses compression if not explicitly specified otherwise. --> That 232M filesystem won't use 232M on ubifs. 2.) If there really that little flash space, or is it just partitioned strange? I mean the Dockstar has 256MB of NAND flash and one can use more than 200M for the root file system. Don't know about the pogo, though.by ingmar_k - Debian
You add the "fsprotect=20M" part to the "bootargs". You can set and save those parameters from within Debian using the "fw_setenv" command, or by halting the boot process and using the "setenv" command on the u-boot prompt. For the latter to be permanently set, you need to issue a "saveenv" after you have modified the bootargs on the u-boot prompby ingmar_k - uBoot
Doesn't look like a updated version. My wild guess would be that the hdd took too long to answer the uboot request, so it was skipped, but later seen by the kernel, thus the reversed order. As I said, only a guess. Could be that next time you reboot it won't boot, like it did this time. You could try.by ingmar_k - Debian
Strange but good for you. I don't know, maybe Jeff already made the newer usb_init script the default in the meantime. Could you perhaps run fw_printenv and post the "usb_init" part?by ingmar_k - Debian
"It doesn't work" isn't really a good error description for troubleshooting. I happen to have that exact wlan stick and already tested it with kernel 2.6.39-2. Seemed to work when I tried. Now one thing after the other: What kernel did you use when it didn't work? And what was the dmesg/syslog output telling you that it indeed didn't work? And finally what firmwby ingmar_k - Debian
kraqh3d Wrote: ------------------------------------------------------- > The usb_scan "function" runs through all the usb > ports in a fixed order (until it can e2load > /boot/uImage) and assigns that disk a device id > based on the it's port. This is then device is > passed to the kernel as the root parameter. The > problem is that when the kernel boots,by ingmar_k - Debian
Seems harder than it actually is. 1) Boot your dockstar into linux. 2) Paste the full command, from the linked posting, into the command line: fw_setenv usb_init 'usb start; if ext2load usb 0:1 0x800000 /boot/uImage; then setenv usb_device 0:1; setenv usb_root /dev/sda1; elif ext2load usb 1:1 0x800000 /boot/uImage; then setenv usb_device 1:1; setenv usb_root /dev/sdb1; elif ext2loadby ingmar_k - Debian
Have a look at this: http://forum.doozan.com/read.php?3,12 When using the unmodified uboot environment (boot command) the dockstar will try to boot from the first detected USB device. The usb port that is scanned first is the one on top. So you would be out of luck, as the dockstar would probably seize to boot with the harddisk in place. The solution is described in the link above. Withby ingmar_k - Debian
Just out of curiosity: Any progress on the matter?by ingmar_k - Debian
funtoy1001 Wrote: ------------------------------------------------------- > ingmar_k Wrote: > -------------------------------------------------- > ----- > > Just because a drive must be a few years old > > doesn't necessarily mean that it will fail > soon. > > It all depends. > > > True. Just because the drive is old doesn't not > meby ingmar_k - Debian
Just because a drive must be a few years old doesn't necessarily mean that it will fail soon. It all depends. And spindown is not a really big problem. What kills drives faster than usual are short sequencies of the drive spinning down just to be awakened from idle shortly after that. That's because the motor doesn't really like to be treated with the high current pulse needed tby ingmar_k - Debian
Besides access times, a hdd is usually faster than a USB stick. But both will be limited to the max. USB 2.0 transfer rates of around 25-30MB/s. Then again the file system on the hdd will matter. As long as you use a linux file system (preferrebly EXT2/3/4; EXT2 for /boot, IIRC, due to uboot), there should be no problem. Go ahead and try it. I'm sure other people did so already I don'tby ingmar_k - Debian
I don't think you can use it like that because the rescue system maybe uses another shell or something, but you should get the idea. Assumption is that you know your drive's uuid and that the script only runs at a point where the very drive is not mounted: #!/bin/bash #get the line containing the uuid and device name dev_name_line=`blkid |grep "your_drives_uuid_without_theby ingmar_k - Debian
You could always create a small script which you'd place inside the recovery partition and run it automatically by calling it through rc.local. Theoretically (I don't know the details on the recovery system, as I don't use it) this should work. The script should check for your usb drive first (maybe by uuid if possible, otherwise just look for /dev/sdxx). If the drive was presenby ingmar_k - Debian
Just a little heads up for those of you wanting to use a custom kernel + emdebian in NAND with ubifs: Don't check the kernel config option for NAND page write verification! It will render the ubifs unusable due to it being unable to write anything. Just found that issue and wanted to let you know. Don't know yet if it's a bug or lack of knowledge on my part. Both scenarios seeby ingmar_k - Debian
Well, you could try a new kernel anyway, but there sure is no guarantee that it'll get the device to work. Especially considering that we don't even know what options/modules to enable (besides the obvious Avermedia, if present). I googled some and chances are that the box uses a trident chipset. But, without you opening the device, there's no way of being sure about that, as Iby ingmar_k - Debian
Doesn't really help much. I should have told you before to run dmesg, too. That could get more info. As an alternative you can also just have a look into the syslog. Maybe that will reveal the information about the chipset.by ingmar_k - Debian
You probably won't find much on the specific Avermedia HD DVR. The key is to find out what chipset your Avermedia part uses. ;) When you know that it will certainly be easier to tell if it is supported by newer kernels, or not.by ingmar_k - Debian
varkey Wrote: ------------------------------------------------------- > I recently ordered this adapter (yet to be > delivered) -- > http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item > =350466560323 > > It says it works with both 5v and 3.3v target > devices, so it should work fine with the Dockstar > and GoFlex right? :) CP2102 works just fine with the dby ingmar_k - Debian
I guess you are still using the "old" 2.6.32-5-kirkwood kernel, right? If that is the case, then it could be possible that drivers for your Avermedia HD DVR are included in the new kernel(s). You should look into that. Normally you don't really need many standalone drivers in linux. Eventually nearly everything should be included in the kernel sources. To use it, you sometimesby ingmar_k - Debian
Thanks for the tip. The questions that still remain are: Is undervolting really worth it? How reliable is that stress test? I once read something about a port of the intel linpack stress test/benchmark for ARM. That's a test that I would personally trust. It's a benchmark suite called minibench, that I'll probably look into before doing any voltage modifications. Could bby ingmar_k - Debian