It is sort of a combination. You have to copy some files and then apply the main patch. You git clone the repo and find the patch itself under "/target/linux/oxnas/patches-3.14". Under "/target/linux/oxnas/files" you find the missing files or rather the directory structure that you need to copy directly into your kernel source tree. And if I remember correctly that shby ingmar_k - Debian
Great news! Unfortunately, I was too busy to actually test my build, yet. Hope to finally find the time to do some OXNAS testing the next few days.by ingmar_k - Debian
OK, I just did a quick test build with Debian 3.15 kernel sources, patched for OXNAS support, with the help of the openwrt repo. Then I took the kirkwood_defconfig and adapted it for OX820. It built just fine, but I still need to test it. Probably tomorrow. Will let you all know how it turns out.by ingmar_k - Debian
Maybe we should create a dedicated howto thread for "cross compiling your own kernel on Ubuntu and/or Debian". As for the kernel config, it could make sense to start with a Debian defconfig (such as the kirkwood_defconfig) and then "just" change the machine specific parts to make it work for OXNAS. That way, nearly all the interesting modules should be included. It is uby ingmar_k - Debian
I didn't even see before that kref seems to have merged his changes to Linux 3.13-5. But as the openwrt repo is based on kref's work, it should be nearly identical, at least. If you like to know exactly, check out both and compare. The thing is that the openwrt branch is a little more recent. They seem to maintain their repo constantly.by ingmar_k - Debian
Get the Debian kernel sources, here: http://ftp.debian.org/debian/pool/main/l/linux/ Then get the current kernel patches and missing files for the OXNAS support, from Openwrt, here: https://gitorious.org/openwrt-oxnas Extract the Debian kernel sources and copy the missing files to the source directory, from the openwrt git directory. Finally apply the patches, configure the kernel andby ingmar_k - Debian
VERY NICE work my friend! Thank you for sharing. I will be sure to test both your new U-Boot and kernel, once I find the time. Keep up the good work.. ;-)by ingmar_k - Debian
The openwrt guys seem to have brought it to 3.14, already. Have a look here: https://gitorious.org/openwrt-oxnas/openwrt-oxnas/commit/6f090b045b00f1739b292d14c1bbf5f84eaa345bby ingmar_k - Debian
@bodhi: Did you have time to try the openwrt kernel patches for the 3.13 kernel sources? I know that they are there and I actually compiled a 3.13 kernel once, but I never found the the time to test the uImage on one of my Pogoplugs..by ingmar_k - Debian
My problem was actually a little different, I think. I had the problem that I got no console output at all, if low level debug was not enabled. Normally there should be output on serial console either way. So, unfortunately I can't really comment on your problem.by ingmar_k - uBoot
I was working on a new environment just before I ran out of time on this project. As is, I would say the U-Boot version that kref provides is pretty solid. Both the NAND and the SATA part. Had no problems with it, whatsoever. If we can "polish" it and its functionality a bit further and include a fully working and extensive default environment, this could be perfect. Add the newby ingmar_k - uBoot
You really don't get it. Device tree file (.dts), SATA definition. Now compare the current defintion and see where you could add one for the second SATA port. Either that or you wait until someone else does the work. Edit: Hehe, bodhi to the rescue. :-Dby ingmar_k - uBoot
You need that line for your device tree: "#define SATA_1_REGS_BASE 0x45910000" In most device tree files, only SATA0 gets explicitly set up with its address of 0x45900000, just like defined one line above the one I just quoted. "#define SATA_0_REGS_BASE 0x45900000"by ingmar_k - uBoot
Source code my friend. This is not the kind of information that is usually available once the software is running.by ingmar_k - uBoot
Marvell Armada, maybe. If those specs are right. ;-) But the bootlogs indeed seem to indicate Kirkwood. Hmm...by ingmar_k - Debian
Actually I don't have much time for either testing, or code reading on the subject of OX820. I was just curious and had, and still have, the notification function of the forums enabled. :-D So, I am in no hurry, concerning the OX820. I need to work on other systems at the moment. It still is interesting, though.by ingmar_k - uBoot
Ah, as I said, I wasn't sure. Thanks for clarifying! ;-) But that also would mean that there is nearly nothing there in RAM, which in turn would mean that loading the kernel at a much lower address shiould not be a problem at all.by ingmar_k - uBoot
Normally there should be nothing there, other than U-Boot. And that shouldn't be any bigger than 1M or maybe 2M. So my guess would be that loading the kernel at 2M should work, too.by ingmar_k - uBoot
To clarify this a bit further: I was wondering if 5MB isn't a bit high. My thought was that it should be possible to load the kernel at a lower address, which could lead to a few more MB of useable RAM, when the system is up and running. I am not too sure about that last part, though. Just a thought at the moment.by ingmar_k - uBoot
I think you minsunderstood me. What I meant was: Why do we load the kernel at exactly 5MB in RAM, and not at a lower address? ;-)by ingmar_k - uBoot
No, until now, I never used initrd on any of my embedded devices. I always compiled kernels with anything mandatory compiled in. So I can't really tell you. However, you can guess and/or compute a appropriate loaction. 0x60000000 seems to be the RAM base address. The kernel get's loaded at '0x60500000', which then equals a location of 5MB in RAM. Now the kernel image shouby ingmar_k - uBoot
clge Wrote: ------------------------------------------------------- ... > at least that specific kernel is confirmed > non-working on b04 now - or perhaps all armv6 > "classic" devices without pci. And you conclude that on what basis? Sorry, but in all honesty, that is utter nonsense. The kernel works perfectly fine, if you know what you are doing. I tested that kernelby ingmar_k - uBoot
So once again, someone who flashed a kernel to the main NAND location without testing it thoroughly, prior to the flashing? Congratulations! Sometimes I really ask myself why I write documentation on howto use it, if noone reads it.by ingmar_k - uBoot
@WarheadsSE: Thanks for the hint. I will have a look at that. @bodhi, I had seen that the installed U-Boot had nand functions and just guessed that there could be another product model with NAND, i.e. NAND should work. I already had some NAND chips here, that I had desoldered with a hot air soldering station (from old USB flash drives, old IDE DOMs etc.). And I just picked a Samsung SLC 1by ingmar_k - Debian
Exactly! I found that there seem to be other implementations that define a gpio switch like that, as a "regulator". At least I saw some dts files where it was done like that.by ingmar_k - Debian
You are very welcome! I hope the information will help some people. About the soldering: Well, it actually could have been better. Partly at least. I didn't do any soldering for a long time before that. I was a bit out of practice, but it all worked. So it's fine. Looks like it could finally start to pay out to be a computer engineer and soon to be master of computer science. :-Dby ingmar_k - Debian
And before I forget: With my NAND Device (Samsung K9F1G08U0x), I had to solder a wire from the NANDs WP/-Pin to VCC, in order to completely disable WriteProtection. Otherwise the NAND writes would fail sporadically. Strange, but now it works.by ingmar_k - Debian
Hi guys and gals, I recently got ahold of two Buffalo Linkstation Live V3 devices. These are based on Marvell Kirkwood 88F6192 SOCs, have 64MB DDR2 RAM, a Gigabit Ethernet port and one single SATA connector. No additional USB, or other nice things. :-) Just the amount of hardware to make data available on one's network, and nothing more. After having tinkered with these little Gizmosby ingmar_k - Debian
Found this here, which sounds interesting: https://github.com/olderzeus/linux-oxnas/commit/709d9eeb626091c614c4e2042048702fb6921df1by ingmar_k - uBoot
Great to hear that my little theory worked out like expected.by ingmar_k - uBoot