Booting Debian on Pogoplug Pro

Found this here, which sounds interesting:
https://github.com/olderzeus/linux-oxnas/commit/709d9eeb626091c614c4e2042048702fb6921df1

Hey. i used the arch installer and the debian sqeeze rootfs, now I have kernel 2.6.31.6_SMP_820 working on my B04.
Now I have problems getting a USB soundcard to work. On arch linux forums it seems others had the same problem. Did somebody fix the problem - perhaps by upgrading to a higher kernel?
I'd be happy to compile the kernel myself, also can set up a tftp server for testing without risk, etc.
But I'm not sure what the latest state is... Can someone lead me a few steps?
Thanks.

It depends on you sound card. You could try if my kernel supports your sound card: http://pogoplug.square7.de/forum/viewtopic.php?f=5&t=98 (DL from 2nd post). Alternatively you could try a newer kernel: http://archlinuxarm.org/forum/viewtopic.php?f=55&t=6193. You could boot from SATA disk to try out different kernels without the risk of flashing the uImage into NAND.



Edited 6 time(s). Last edit at 03/11/2017 09:22AM by shv.

thanks for your kernel, installed it and did depmod, rebooted and now when snd_usb_audio gets loaded there's this error in dmesg:
[ 15.260000] snd_page_alloc: Unknown symbol pci_set_consistent_dma_mask
[ 15.260000] snd_page_alloc: Unknown symbol pci_dev_put
[ 15.270000] snd_page_alloc: Unknown symbol pci_get_device
[ 15.280000] snd_page_alloc: Unknown symbol pci_set_dma_mask

I guess I'll have to try a newer one... not sure which one would be suited...

so it seems like snd_page_alloc is compiled against some pci stuff that's missing in the non-pci kernel?
is there any kernel version including modules that work with non-pci? or where's the source or patches so I can compile it myself?
I've some cross-compiler setup anyway for my kirkwood devices, shouldn't be anything different about this, right?

If you tried my 2.6.31.14 Kernel you can find the necessary kernel sources and patches in the first post: http://pogoplug.square7.de/forum/viewtopic.php?f=5&t=98.



Edited 2 time(s). Last edit at 03/11/2017 09:23AM by shv.

Sorry, had too many tabs open and missed that. now in the meantime I've managed to brick my device with this kernel: http://www.hs-augsburg.de/~ingmar_k/Pogoplug_V3/kernels/2.6.32-ppv3-classic-zram-1.1_ARMv6k_incl_headers.tar.bz2

With this kernel in NAND I get blinking green light for a few seconds, then suddenly at the same time when the hard drive spins up the led goes steadily green. But I thought only userland would set the light and I don't think it had a chance to load the rootfs so fast.

Tried to make it boot from SATA, cause I don't have my USB-TTL with me. But there I don't even get a blinking led. hard drive doesn't seem to get accessed after spinning up.

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.



Edited 1 time(s). Last edit at 04/17/2014 08:27AM by ingmar_k.

i accept this award proudly, was a risk i was willing to take :P
i will get my usb-ttl adapter and everything will be fine.
also i had read that sata alternative should be rather failsafe: "unbrickable".

it's good it happens to me, i think i have a chance of testing this out without big loss (time, nerves).
at least that specific kernel is confirmed non-working on b04 now - or perhaps all armv6 "classic" devices without pci.

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 kernel myself before uploading it. And other people also tested it, successfully.
So please stop posting until you at least have SOME clue. Or simply stop making claims that are absolute nonsense.

If you can get SATA boot working you can correct everything even without a serial interface. The advantage of the serial interface is that you can see what is the problem with the current kernel in NAND.

I am not sure but I think that the kernel from ingmar_k you have used just supports Ext4 rootfs partitions during boot.



Edited 2 time(s). Last edit at 04/17/2014 09:59AM by shv.

thank you loads, it's true, with ext4 it works.
for anyone else stumbling about this, you might need to change your root partition from ext3 to ext4 by running:

tune2fs -O extents,uninit_bg,dir_index /dev/sdxroot

also have to change uboot bootargs so that
rootfstype=ext4

e.g. if you boot with serial adapter, press key, then type
setenv bootargs root=/dev/sda1 ubi.mtd=2,512 rootfstype=ext4 console=ttyS0,115200 elevator=cfq mac_adr=0x00,0x30,0xe0,0x00,0x00,0x01 rootwait mem=128M poweroutage=yes

and

to boot type:

run boot_custom

thanks, ingmar, for your directly usable 2.6.32 kernel sources. It was very straightforward to compile the sound modules.

If anybody wants working usb audio on classic they can use ingmar's 2.6.32-ppv3-classic-zram-1.1 kernel (careful because only ext4 root is supported, see above) with these modules:

http://[2a02:908:ee52:f300:1000::500]/modules-sound-2.6.32-ppv3-classic-zram-1.1.tbz

If someone would reupload this to a server with ipv4 that would be nice, or just tell me where to put it, haven't used any good filehosters recently...

@clge: Can you please provide your configuration file? You can establish IPv4 connection to your IPv6 server with http://cloudflare.com -> HowTo: http://forum.lowendspirit.com/viewtopic.php?id=441.

IPv4 Download: http://pogoplug.square7.de/modules-sound-2.6.32-ppv3-classic-zram-1.1.tbz



Edited 3 time(s). Last edit at 03/11/2017 09:24AM by shv.

I changed my config since then to add some usb wireless modules (which sadly didn't work, i guess the kernel is a bit too old). But here it is:
http://[2a02:908:ee52:f300:1000::500]/modules-sound-2.6.32-ppv3-classic-zram-1.1.config

Thanks for suggesting cloudflare, I just tried to set it up, but it seems you can't use it with just an ipv6 address and I don't have any domain. Also looked into using a subdomain from afraid.org, but there's no way to use it with cloudflare at the same time. It would work if cloudflare started some free subdomain service.

You can get a free domain from http://www.dot.tk/ or http://www.freenom.com/.

IPv4 config download: http://pogoplug.square7.de/modules-sound-2.6.32-ppv3-classic-zram-1.1.config

Alternatively you could try the source code which is provided by the manufacturer of the Wifi Sticks if available. I did this for the Wifi module of the Pogoplug Pro.



Edited 1 time(s). Last edit at 03/11/2017 09:24AM by shv.

wow, now i can recommend this to all other people that have ipv6 at home, it works fine if you know how to set it up (when you register a .tk domain you have to put some random working address in redirection, so that cloudflare won't complain about the address not being registered, and then later you can change settings in .tk settings to set cloudflare as dns server).

http://v4v6.tk/modules-sound-2.6.32-ppv3-classic-zram-1.1.config
http://v4v6.tk/modules-sound-2.6.32-ppv3-classic-zram-1.1.tbz

@ingmar_k,

I finally have some time to take my PogoPro off line and play with it :). I've read most of the posts in the "A new kernel for oxnas" thread at Arch site. Thanks navym/kref, ingmar_k and others for valuable information about the effort to get this to run the latest kernel.

Using kref GitHub source, I've built the kernel 3.12.13 oxnas and it works great with my current wheezy rootfs. However, since I have not updated U-Boot yet, I'm still testing it with tftp. I'm avoiding SATA for now, even though I already have installed SATA/eSATA cable and verified that it works. The stock U-Boot is a joke, no USB supports!!!

Do you run the Oxnas 3.12.13 kernel with initrd? if you do, which location that you load it into?

CE>> tftpboot 0x60500000 uImage.3.12.13-oxnas
CE>> tftpboot ??????????  uInitrd.3.12.13-oxnas
CE>> bootm 0x60500000 ??????????

And btw, could you post the correct links for your ARMv6 kernel and u-boot, and any other links to your builds for public consumption ? I'd like to include them in the 1st posts.

Thanks!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/23/2014 04:39PM by bodhi.

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 should have a size of about 2-3MB. That means that a safe location for the initrd should be 8MB or more. So a working location should be 0x60800000 or more.

I even wonder, why we are using a location of 5MB and nothing lower. Will have to test if I find the time. Could be a long time, though until I do so. I am highly busy with other stuff ATM.

I have not looked at the new U-Boot source yet, so not sure either. But am wondering where in RAM is U-Boot relocated to. Could that be the reason?

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

Perhaps the reason is in include/configs/ox820.h. But my calculation for some address did not match up!

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/24/2014 05:49AM by bodhi.

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? ;-)

Yes I did misunderstand your post :)

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

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.

I think 5MB is a bit high, too. There should be data in the first 5MB before where the kernel is loaded, but it would not be that big. However, I think this is one of those undocumented details. I'm guessing 5MB is just a convention to make it large enough so it would not run out of space for dynamic data like boot parameters (i.e. they don't know what the kernel users will include in booting the kernel). That's one thing I can think of, perhaps there are other type of data.

Update:
Looks like bi_boot_params is at 0x60000100

CE>> bdinfo
arch_number = 0x00000480
env_t       = 0x00000000
boot_params = 0x60000100
DRAM bank   = 0x00000000
-> start    = 0x60000000
-> size     = 0x08000000

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)



Edited 1 time(s). Last edit at 04/24/2014 05:57PM by bodhi.

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.



Edited 1 time(s). Last edit at 04/24/2014 06:36PM by ingmar_k.

I think you probably mixed up the 2 locations (NAND vs. RAM) U-Boot is at higher memory (see include/configs/ox820.h):

#define CONFIG_SYS_TEXT_BASE 0x64000000

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

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.

Of course, but I have not finished reading this part of the code either, never had to :-) so please take that with a bunch of grains of salt! On the surface, it seems so. Furthermore, the U-Boot location in RAM could also be calculated and placed at somewhere in higher or lower memory. If it's placed at lower memory then it must falls in where the 5MB is, then your guess is more correct. I think it's easy to test this, because I guess as soon as you load uImage at lower than 5MB, it will give out access violation if U-Boot is there. But my bet is in higher memory.

-bodhi
===========================
Forum Wiki
bodhi's corner (buy bodhi a beer)

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.