The complete sources, including patches, are available here, now: https://github.com/ingmar-k/2.6.31.14_OXNAS_kernelby ingmar_k - uBoot
OK, so I just deleted the 2.6.32.61 github repo, because this seemed to be a dead end. BUT, I have this kernel here for a Pogoplug V3 Classic: http://www.hs-augsburg.de/~ingmar_k/Pogoplug_V3/kernels/2.6.32-00-OXNAS-wheezy-fake-1.0.tar.bz2 It is based on the most recent Medion/Zyxel kernel sources, plus some patches for devtmpfs and accept4. And guess what, it seems to work with wheezy justby ingmar_k - uBoot
OK, I gave it a new try. The sources are available here: https://github.com/ingmar-k/OXNAS_Kernel_2.6.32.61.git They are fully untested at the moment however. And I'll need people testing and/or contributing to make it work. ;-) Edit: Still working on it. Doing some compile tests at the moment. Edit_2: With the newly included defconfig for the Pogoplug V3 Classic I could compile aby ingmar_k - uBoot
http://www.aliexpress.com/item/1-PCS-PL-2303HX-PL2303HX-USB-To-TTL-Converter-Adapter-Module-cable-00024440/697742228.html Just an example. ;-) And these are tested to be working perfectly. You can get comparable adapters virtually anywhere. I'll leave it at that, because I don't think any further discussion would make much sense. If you feel the need to build you own adapter, thby ingmar_k - uBoot
I didn't say you shouldn't share. I think it's very nice that you did. Don't get me wrong. ;-) I solder something nearly every day and layouted my own usb to serial converter pcb and so on. The point is the following: Why reinvent the wheel, if there are working solutions readily available? You don't even have to order the part from asia. That was just an example becby ingmar_k - uBoot
No offence, but why do you bother him with schematics for serial converter boards and soldering this and that, when you can get a decent usb to serial converter board (PL2303) from Asia for about 3,-USD shipped? It takes some time to get to your location, that's for sure, but the quality is good and it works perfectly.by ingmar_k - uBoot
Already wrote 2 mails to the Shuttle support. They ignored the request and I am pretty sure the support employees didn't even understand what it was about and didn't talk to someone who did. I am honestly considering firing off a mail to gpl-violations. How else do they learn? Edit: And license violation reported to gpl-violations.org. Let's see if Shuttle will comply once theby ingmar_k - uBoot
For those interested, I just created the full patch (complete difference in one patch file), representing the difference between the vanilla kernel 2.6.31-14 and the sources provided by Medion/Zyxel in December 2012. Here it is: http://www.hs-augsburg.de/~ingmar_k/Pogoplug_V3/medion_oxnas_december_2012_full.patch Oh and by the way, something that has been bothering me for some time now: Hby ingmar_k - uBoot
I honestly don't really care where the patches come from, as long as they work. But yes, I realized that one was based mostly on Silverstone patches. The silverstone patches seem to take a different approach concerning SATA and USB. Let's see how that turns out. Maybe I'll compile compile some 2.6.31-14 kernels with that patchset first. I don't know when, though. Will be quitby ingmar_k - uBoot
I will stick to my plan. BTW, it is quite easy to generate patches from certain commits in github. @kuleszdl: It won't be a problem to get the patches, as I plan to commit each patch on its own. So, one commit should equal one specific patch. And people can get ready to compile kernel sources without first using "patch -p1 < ..." etc. . And if you need the patches alone, youby ingmar_k - uBoot
Not yet. At the moment it's just the vanilla kernel, without any patches. The plan was to only push the patched version, if it was at least booting. Edit: I will start over in a few days, applying each patch, step-by-step. And updating the git after each of the patches is applied. That should be a better approach than what I did now.by ingmar_k - uBoot
Well, well. First try and the compiled 2.6.32.61 kernel didn't even boot. :( Would've been too easy, though. Will have to investigate the next few days, if I find the time.by ingmar_k - uBoot
Maybe I'll start a git repo with the patched kernel sources. So other people with more experience could contribute and/or correct my faults. As I said, I am a total noob to kernel porting. What I am doing is mearly a little tinkering without much knowledge what is behind each patch. Doesn't look too bad at the moment, though, I venture to say. :-\by ingmar_k - uBoot
Of the 26 patches that were orignally published by telzey for 2.6.31-14, 12 could be directly used for kernel 2.6.32.61, while 14 of them will need extra care. Will see what I can do. I guess that about one third of these 14 patches are obsolete for 2.6.32.61 anyway. Should leave about 10 patches that need work. Hope it is possible. Will keep you up-to-date.by ingmar_k - uBoot
If I am not mistaking, the udev problem could be solved by porting OXNAS support to kernel version 2.6.32, right? If that is correct, I might try to do that. With the emphasis on "try", because I never did something comparable before. But, as 2.6.31-14 to 2.6.32-61 doesn't necessarily seem like a HUGE step, it might be possible. What's your opinion? I just think that itby ingmar_k - uBoot
Hi guys, just a quick question. It seems that Allwinner stayed with the r3p0 mali kernel drivers for a long time now already. No change there for months, while arm already published r3p2-01rel2. Now, for some experimenting I wanted to upgrade the drivers, but can't get them to compile. I did not try native compiling on the hackberry, my A10 device, yet. But I can say that my crosby ingmar_k - Allwinner A10
I'm not using any of the older kernels anymore, because of the NAND limitations. And quite frankly I lack the time to do much at all with my Pogos, at the moment.. So I can't give you any feedback concerning kernel 2.6.31.14. My tip for kernel testing: Setup a tftp and nfs server and have your kernel loaded via tftp and the filesystem via nfs. This way, experimenting with newly compby ingmar_k - uBoot
This particular problem should be limited to WD only. I am not aware of another HDD manufacturer with such a aggressive firmware based idle timer. As bodhi said, drives from other manufacturers should be compatible with the standard tools concerning power management.by ingmar_k - Debian
It is a special WesternDigital "feature"! :-) Their 2.5" and Green 3.5" drives tend to park their heads after a few seconds of idle time (I think the default on my 2.5" scorpio blue drives was 8 seconds). It's only logical that this behaviour eventually will kill the mechanics in the drive. But, this way they can propagate energy savings, while having you going outby ingmar_k - Debian
You can get the normal, vanilla kernel sources from kernel.org and the patchset from telzey, here: http://archlinuxarm.org/forum/viewtopic.php?f=29&t=2472&start=10 I don't remember which patches I did apply. It's a bit of tinkering, but it should work.by ingmar_k - uBoot
I tested high memory and CPU load recently, with the help of stress. It ran without any problems for hours on full CPU+Memory load. So I guess the real problems could start with high disk IO load. Didn't test that yet! That's why I said that I'd like to hear some feedback. And thanks again to WarheadsSE and the ARCH team for their work! BTW, I just needed the 3.1 kernel for tby ingmar_k - uBoot
With debian you will get a much bigger image, which probably won't fit into NAND. And emdebian only builds reliably with squeeze/stable ATM.by ingmar_k - Debian
Does "fdisk -l", run with root rights, list your disk. If yes the kernel already knows it's there. If it's in the list, you have to mount it, to use it. ;-) If it's not in the list, the kernel probably doesn't have support for sata, or you need to load the coresponding module first. Once I think I read that setting the right arcNumber fixed some problems. No guby ingmar_k - Debian
It is kind of hard to find detailed info on the flash type that certain USB drives use. After some searching however, I found, what seems to be a safe bet: http://www.mx-technology.com/en/product/flash2.php?sid=38 Those are guaranteed to use SLC NAND. And from the looks of it they aren't even as expensive as I had feared. However, I have no info on the reliability.by ingmar_k - Debian
You can find the kernel source here: https://github.com/WarheadsSE/OX820-3.1-Linux I already compiled some kernels for testing. If you want to give them a try, they are available here: http://www.hs-augsburg.de/~ingmar_k/Pogoplug_V3/kernels/ If you should try my kernels, please give some feedback as to whether they run stable on your system, or not.by ingmar_k - uBoot
Just prepared my Pogo V3 PRO for a little experiment. Ordered a PM362 (Jmicron JMB362 based mini PCIe half height SATA Controller with 2 ports) online and will try some Port Multiplier, Raid5, LVM2 action when it's here. :-D Just finished a little reconfiguration of my 3.1 kernel build (thanks again to the Arch Linux Team). I'm now at Version 1.6, with full raid and SATA support. Addeby ingmar_k - uBoot
Good question. Most manufacturers will mention it somehow in the product description, though. SLC-NAND is faster, more robust and thus much more expensive than MLC. So it's a feature! Besides that it's not really easy to tell, without closer inspection.by ingmar_k - Debian
There are two options that I know of: 1.) Use ZRAM/CompCache, which must be compiled into the kernel. This can come in very handy with devices with a low amount of RAM. 2.) Get a small(-ish) flash drive based on SLC, rather than MLC Flash chips. It will last far longer and is more robust and even faster.by ingmar_k - Debian
Very interesting device! BTW, for those interested in Emdebian in NAND, have a look at my project for the Pogoplug V3 Versions. https://github.com/ingmar-k/Pogoplug_V3_Emdebian With a few small modifications you should be able to get an Emdebian image for NAND without too much work. If I have read this correctly, the Zyxel also has 128MB NAND, just like the Pogoplug V3. So, all you wouldby ingmar_k - Debian
@shv: As long as the kernel has SATA-support compiled into it, booting the kernel from NAND, with rootfs on SATA should work, like with any other SCSI storage device. But, I didn't try it yet personally. So, just a theory of mine, before anyone asks.by ingmar_k - uBoot