Actually you can have Wheezy system which runs great with WarheadSE's standard 2.6.31 kernel (the one from Arch Linux) using libaccept4 as outlined in this thread, so why not first install such a system before experimenting with different kernels? Mine is running now for more than three months without any particular issues so far.

Simple: Using the external libaccept4 solution is kind of a half-assed solution. You still have to edit some udev files and there isn't even a official debian package providing libaccept4. Besides, the accept4 support was in the kernel since 2.6.28 or something like that, but simply was not enabled, because there was no need for that until udev started requiring it.
So, the kernel IMHO is the right solution.
The problem is that most people don't know what they are doing and wildly try any commands and/or files they find on the net, without realizing that they can easily cripple their systems that way. And sadly enough, often even without reading the instructions correctly.

ingmar_k Wrote:
-------------------------------------------------------
> I'm sorry to write the following, but if you had
> truly read the instructions, you would have
> realized that a serial connection to the device is
> nearly indispensable. Especially when changing
> something kernel related.
> And from what you wrote I guess you don't have a
> serial connection set up, yet. Right?
> Besides that the device can still be booted via
> SATA.
>
> Oh and BTW, let me guess: You tried to use the
> kernel images with a root drive that uses a EXT3
> filesystem? This can't work and has been explained
> before.
>
> Edit:
> What I also don't understand: I explicitly write
> in my instructions to first flash the
> second/backup kernel location and test that uImage
> BEFORE flashing the main kernel location. But so
> far, there don't seem to be too many people who
> really followed those instructions. I don't get
> it.


Probably because setting up a serial connection is a pain?
I do appreciate the work you've done. But I kinda asked for help, not a lecture. I wouldn't consider myself a total n00b, but I'm definitely not as good at all this as a lot of you guys. Amy help you can give would be appreciated.



Edited 1 time(s). Last edit at 11/10/2013 07:45PM by SCrid2000.

@SCrid2000:

I don't like full quotes. If possible please regard my hints in the following post: Link.

Setting up serial connection is not that painful as you think. You could look for CP2102 module in ebay. With this adapter you don't need any soldering. For the connector on the PCB I can recommend an old PC audio cable for connection between CD/DVD drive and sound card (see attached picture).

Let's assume that you have ingmar_k's kernel on your device and kernel and device fit each other. Than you could try to put my roots onto an ext4 partition with partition name rootfs. You must put the modules which fit to ingmar_k's kernel into /lib/modules. Afterwards you should pray that everything is right and the device is accessible through the network.

- shv



Edited 1 time(s). Last edit at 11/11/2013 01:34AM by shv.

@SCrid2000:
You might not like a lecture, but from what you continue to write, you definitely need(ed) one.
The kernels that I provided were and still are strictly for testing purposes. If you do not understand that hint and its implications, then don't use stuff like that. Simple as that.

Howto resolve your situation:
I already gave you the hint, but I will describe it again, more detailed.
The way that shv just described might not work, because your bootloader most likely still has the "rootfstype" set to 'EXT3'. That means that the system will still try to mount the rootfs as EXT3, while the kernel itself has no (compiled in!) support for that. EXT3 is there as a module, but that doesn't help while booting, in this case. To solve this you probably would need a EXT4 rootfs, PLUS you would have to change the uboot bootargs to indicate a 'rootfstype' setting of 'ext4'. Then you could boot a EXT4 rootfs with the newer kernel.

Now here is a solution to bypass that problem altogether, temporarily:
Direct SATA booting uses its own uboot bootloader, so it doesn't care about what is set in the uboot environment in NAND. Use my Debian/Emdebian scripts, or WarheadsSE's scripts to create a bootable SATA drive and boot from that. When the system is up and running you can make all necessary changes to get it booting from NAND again, too.

Thank you. I will try using that rootfs on an ext4 drive and order that serial connector if it doesn't work :)
I knew there was a chance this would soft brick my plug, but figured it wouldn't because other people reported it working. I take full responsibility for the soft brick, just trying to get some help moving forward.



Edited 2 time(s). Last edit at 11/11/2013 04:02PM by SCrid2000.

Good luck! I hope you get it to work soon.
I know those embedded device topics and their specifics are not very easy to understand at first. But I guess you will learn a lot if you read up on it. The trick is not to give up too easy. The good thing is that it is virtually impossible to really brick the Pogoplug V3. Even if you completely erase the NAND, you can always still boot from SATA.



Edited 1 time(s). Last edit at 11/12/2013 05:00AM by ingmar_k.

Hey ingmar_k

I'm really interested in your work!!
I installed now emdebian on my pogo plug pro. And now I'm trying to get Wifi working:
Can you give me some help. Is it integrated in your scripts really. As far as I see it, there is missing the module of the wifi card. So I don't have the wifi-interface with ifconfig.


Thank you very much for your work!!
benni

I probably did not include all wifi modules in my kernels. If that is the case for the one you need, then feel free to recompile the kernel with a configuration of you liking. I provide the sources via github ( www.github.com/ingmar-k ). If you need a newer kernel than version 2.6.31, you could have a look at kref's work ( www.github.com/kref ).

ingmar_k Wrote:
-------------------------------------------------------

> Edit 4:
> Some testers would be great.
> Kernel for Pogoplug V3 Classic:
> http://www.hs-augsburg.de/~ingmar_k/Pogoplug_ > V3/kernels/2.6.32-ppv3-classic-zram-1.1_ARMv6k.tar > .bz2
>
> Kernel for Pogoplug V3 Pro:
> http://www.hs-augsburg.de/~ingmar_k/Pogoplug_ > V3/kernels/2.6.32-ppv3-pro-zram-1.0_ARMv6k.tar.bz2 >
How do you identify a pogoplug V3 Classic?

I would love to test these out but my OXNAS versions are pogo-p25 and pogo-pro. Inside they look really really similar.

> Sources are available via github, as always. The
> kernels are explicitly compiled for ARMv6k, but
> they work (of course) with standard ARMv5
> distributions.
>
> Also quite interesting. Someone seems to be
> working on a 3.1.11 kernel for OXNAS-devices,
> again:
> https://github.com/kref/linux-oxnas

Doesn't kernel 3.1.x> have better support for wireless?



Edited 1 time(s). Last edit at 01/06/2014 12:54AM by gr0ck.

Pro has the PCIe bus connection soldered, anything else does not. Pretty much that simple.

bodhi Wrote:
-------------------------------------------------------

> [/code]
>
>
> 6. Here is the serial console output:
>
>

> U-Boot 1.1.2 (Jul 29 2010 - 19:36:07)
> 
> U-Boot code: 60D00000 -> 60D1C030  BSS: ->
> 60D21800
> RAM Configuration:
> 	Bank #0: 60000000 128 MB
> SRAM Configuration:
> 	64KB at 0x50000000
> NAND:128 MiB
> In:    serial
> Out:   serial
> Err:   serial
> Setting Linux mem= boot arg value
> Hit any key to stop autoboot:  2  1  0 
> 
> Loading from device 0: 128MiB 3,3V 8-bit (offset
> 0x500000)
>    -- Using 1bit ECC style encoding
>    Image Name:   Linux-2.6.31.6_SMP_820
>    Image Type:   ARM Linux Kernel Image
> (uncompressed)
>    Data Size:    2132260 Bytes =  2 MB
>    Load Address: 60008000
>    Entry Point:  60008000
> ## Booting image at 60500000 ...
>    Image Name:   Linux-2.6.31.6_SMP_820
>    Image Type:   ARM Linux Kernel Image
> (uncompressed)
>    Data Size:    2132260 Bytes =  2 MB
>    Load Address: 60008000
>    Entry Point:  60008000
>    Verifying Checksum ... OK
> OK
> 
> Starting kernel ...
> 
> Uncompressing
> Linux.............................................
> ..................................................
> .................................. done, booting
> the kernel.
> [    0.000000] Linux version 2.6.31.6_SMP_820
> (root@ProDev) (gcc version 4.6.0 20110429
> (prerelease) (GCC) ) #99 SMP Sun May 29 03:04:43
> EDT 2011
> [    0.000000] CPU: ARMv6-compatible processor
> [410fb025] revision 5 (ARMv7), cr=00c5387f
> [    0.000000] CPU: VIPT nonaliasing data cache,
> VIPT nonaliasing instruction cache
> [    0.000000] Machine: Oxsemi NAS
> 
> ..... (the rest are same as dmesg output)
>

bodhi,

I have a pogo-pro and pogo-p25 but I can't get serial output from them. I see the rx lightup on my usb to serial converter but no output.

I'm on ubuntu 13.10 using putty, gtkterm, cutecom, minicom, ..etc, but nothing is working for me on either device.

I'm using the orginal uboot or oxnas from archarm back in 2012. My goal now is to get wheezy on these devices but before that I want to try and get serial output setup 1st as many posts suggest this.

Any idea what is wrong.

my 203 is identified as Prolific Technology, Inc. PL2303 Serial Port and wired rx on pl2303 to tx on the pogo, ground to ground, and tx on pl2303 to rx on pogo.

pl2203 pogo
gd > gd
rx > tx
tx > rx

although I tried it both ways no output at all.

Do you have it configured for the right voltage?

WarheadsSE Wrote:
-------------------------------------------------------
> Do you have it configured for the right voltage?

Yes. I did not plug in voltages and the device showed it was receiving data from the pogo. I unplugged the pl2303, plugged it back in, then power cycled the pogo, then all the output came out. Looks like I have uboot 1.1.2.

I'm so happy about seeing this output because of all it took to get a good pl2303. One I ordered was not what was shown in the order form so I had to order a new one and it took awhile to get to me. :(

Stage-1 Bootloader XCE_STAGE1: 1.1: Tue Feb  8 01:40:26 PST 2011
Attempting to set PLLA to 700MHz ...
  plla_ctrl0 : 0x0000000A
  plla_ctrl1 : 0x000E0000
  plla_ctrl2 : 0x001C01A0
  plla_ctrl3 : 0x00000016
PLLA Set

Setup memory, testing
Reading NAND, Image 0
  Hdr len: 0x0001C030
  Hdr CRC: 0x39F6D832
 OK


U-Boot 1.1.2 (Jul 29 2010 - 19:36:07)

U-Boot code: 60D00000 -> 60D1C030  BSS: -> 60D21800
RAM Configuration:
        Bank #0: 60000000 128 MB
SRAM Configuration:
        64KB at 0x50000000
NAND:128 MiB
In:    serial
Out:   serial
Err:   serial
Setting Linux mem= boot arg value
Hit any key to stop autoboot:  0 

Loading from device 0: 128MiB 3,3V 8-bit (offset 0x500000)
   -- Using 1bit ECC style encoding
   Image Name:   Linux-2.6.31.6_SMP_820
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2159884 Bytes =  2.1 MB
   Load Address: 60008000
   Entry Point:  60008000
## Booting image at 60500000 ...
   Image Name:   Linux-2.6.31.6_SMP_820
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    2159884 Bytes =  2.1 MB
   Load Address: 60008000
   Entry Point:  60008000
   Verifying Checksum ... OK
OK

Starting kernel ...

Uncompressing Linux................................................................................................................................... done, booting the kernel.
[    0.000000] Linux version 2.6.31.6_SMP_820 (root@ProDev) (gcc version 4.6.0 20110429 (prerelease) (GCC) ) #100 SMP Sun May 29 04:53:45 EDT 2011
[    0.000000] CPU: ARMv6-compatible processor [410fb025] revision 5 (ARMv7), cr=00c5387f
[    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache
[    0.000000] Machine: Oxsemi NAS

Next task try to update uboot.

code info from the most recent downloadable archarm boot loader for pogo-p25:

		echo "# Coping key CE binaries..."
		cp -ar /usr/local/cloudengines usr/local/
		cp /usr/sbin/nandwrite usr/local/cloudengines/bin/
                cp /usr/sbin/flash_erase usr/local/cloudengines/bin/
		cp /usr/sbin/nanddump usr/local/cloudengines/bin/
		echo "# Done copying."
		echo "#############################"	
		echo "## FLASHING NAND & UBOOT VARS"
		echo "# backing up mtd1"
		/usr/sbin/nanddump -o -f mtd1.dump /dev/mtd1
		echo "# Erasing mtd1 @ 0x500000 for 17 erase blocks (kernel location)"
		/usr/sbin/flash_erase /dev/mtd1 0x500000 17
                echo "# Erasing mtd1 @ 0xB00000 for 17 erase blocks (2nd kernel location)"
		/usr/sbin/flash_erase /dev/mtd1 0xB00000 17
 
		########
		## flash kernel
		########
		echo "# Flashing Kernel..."
		if [ $PCI = 1 ]
		then
			echo "# - @ 0x500000"
			/usr/sbin/nandwrite -p -s 0x500000 /dev/mtd1 /tmp/usb/boot/uImage.pci
			echo "# - @ 0xB00000"
                        /usr/sbin/nandwrite -p -s 0xB00000 /dev/mtd1 /tmp/usb/boot/uImage.pci
		else
			echo "# - @ 0x500000"
			/usr/sbin/nandwrite -p -s 0x500000 /dev/mtd1 /tmp/usb/boot/uImage.nopci
			echo "# - @ 0xB00000"
			/usr/sbin/nandwrite -p -s 0xB00000 /dev/mtd1 /tmp/usb/boot/uImage.nopci
		fi

		echo "# Done Flashing Kernel"
		echo ""
		#######
		## flash boot arguments
		#######
		cd /tmp
		echo $BOOTARGS > bootarg.txt
		NEWARGS=`cat bootarg.txt | sed 's/ubi0:rootfs/\/dev\/sda1/' | sed "s/ubifs/$FMT/"`
		NEWARGS="$NEWARGS rootwait"
		NLNAND="nboot 60500000 0 500000"
	
		echo "# NEW uBoot Parameters"
		echo "# = bootargs_usb : $NEWARGS"
		echo "# = load_custom_nand : $NLNAND"
		echo "# = rootfs : /dev/sda1"
		echo "# = root fs type : $FMT"
	
		echo "# "
		echo "# Setting up uboot parameters"
		/usr/local/cloudengines/bin/blparam bootargs_stock="$BOOTARGS" > /dev/null
		/usr/local/cloudengines/bin/blparam load_custom_nand="$NLNAND" > /dev/null
		/usr/local/cloudengines/bin/blparam load_custom_nand2="nboot 60500000 0 B00000" > /dev/null
		/usr/local/cloudengines/bin/blparam boot_custom="run load_custom_nand boot || run load_custom_nand2 boot" > /dev/null
		/usr/local/cloudengines/bin/blparam bootargs="$NEWARGS" > /dev/null
		/usr/local/cloudengines/bin/blparam bootcmd="run boot_custom"  > /dev/null
		echo "#" .......

is the original boot loader still on the device?

Looks like there is a backup boot loader ..

Why is the boot loader there and the kernel in a different spot?

Wouldn't it be good to tell the boot loader to look to the usb or sata device?



Edited 1 time(s). Last edit at 01/06/2014 08:19PM by gr0ck.

The boot loader on the device does not support that.

If the Pogo P25 is OXNAS based, which I don't know ATM, then there is a new Uboot version provided by kref that supports USB boot etc.

I flashed it to one of my B04 Pogo V3s a few weeks back. Seems to run just fine. Only the power consumption numbers seem a bit higher. But considering that the device only stays at the Uboot prompt if you explicitly stop it there, that is NOT a problem at all. Once the kernel is loaded everything is fully back to normal. We are not talking about a dramatic increase anyway. Just noticable.
Nothing to worry about, anyway!

I am following these developments, and it would be nice to have the oxnas family back under full support @ Arch Linux ARM, but I can't devote time to the device at this point.

I would love to support these devices, I own them, and I think they are good systems, but I have no idea how to cross compile or code a kernel.

Any idea who is working on coding the kernels?

But I plan to learn how to at least cross compile a kernel, and update the uboot. I feel its a security risk if I don't update my system.


The strange thing for me is my OXNAS system is running with a kirkwood kernel.

gr0ck Wrote:
-------------------------------------------------------
>
> Any idea who is working on coding the kernels?
>
There are people working on compiling new kernel. See first post.

>
> The strange thing for me is my OXNAS system is
> running with a kirkwood kernel.

If you follow instruction in the first post. Your kernel is Arch Linux smp for OXNAS. Your rootfs is Kirkwood Debian.

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

bodhi Wrote:
-------------------------------------------------------
> If you follow instruction in the first post. Your
> kernel is Arch Linux smp for OXNAS. Your rootfs is
> Kirkwood Debian.

This is one of my confusing issues. Over a year ago I used varkey's image for debian. bodhi's post I used long time ago. This is why I have the kirkwood kernel. :) I think WarheadsSE was trying to tell me I messed up a long time ago.

At the time I didn't know what Oxnas was at all.

No you did not mess up! that's how you run Debian rootfs (current method is hybrid, Arch kernel Debian rootfs). If you run Arch then instruction at Arch site is all you'd need.

There are users working on getting Debian or Arch running fully with later kernel (no hybrid).

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

bodhi Wrote:
-------------------------------------------------------
> No you did not mess up! that's how you run Debian
> rootfs (current method is hybrid, Arch kernel
> Debian rootfs).

Glad to know I didn't mess up.

It all seems to work on my pogo-p25 but .. if I try to upgrade thats when it all goes to hell and it will not boot up.
I have a lot of trouble getting a wifi adapter working as well, but that's not a show stopper of requirement for what I use it for.

I"m not sure if there is a performance hit because of the kernel I'm running because I haven't tried other build processes yet.

The image linux-2.6.31.6_SMP_820 I'm guessing is a platform/processor identifier. I use the PLXNAS7820.
In my boot directory I have the following. I assume these are for kirkwood devices.

total 6.8M
-rw-r--r-- 1 root root  83K Sep 24 17:29 config-2.6.32-5-kirkwood
-rw-r--r-- 1 root root 4.4M Dec 30 06:24 initrd.img-2.6.32-5-kirkwood
-rw-r--r-- 1 root root 983K Sep 24 17:29 System.map-2.6.32-5-kirkwood
-rw-r--r-- 1 root root 1.4M Sep 24 17:28 vmlinuz-2.6.32-5-kirkwood

To know which kernel you are running at the moment, please run the command "uname -a". ;-)
Just because there is a certain kernel image in the "right" directory, it doesn't necessarily mean that it is actually being used.

The kernel you are running right now gets loaded directly from NAND. There is no directory (by default) to browse that.

gr0ck,
I think that you are trying to upgrade from Squeeze to Wheezy. This is very difficult! If you have the 2.6.31.6 kernel from WarheadsSE in your NAND flash you could try my Wheezy rootfs (see http://forum.doozan.com/read.php?3,6336,13993#msg-13993). It must be extracted to an ext3 partition with rootfs as the partition name. If it doesn't work you might need an update to lastest 2.6.31.6 kernel from WarheadsSE.

Alternatively you could stay on Squeeze. In this case it might be necessary to adapt your modules.conf to prevent the upgrade to wheezy.

- shv



Edited 5 time(s). Last edit at 01/09/2014 05:53AM by shv.

ingmar_k Wrote:
-------------------------------------------------------
> To know which kernel you are running at the
> moment, please run the command "uname -a". ;-)

Linux (none) 2.6.31.6_SMP_820 #100 SMP Sun May 29 04:53:45 EDT 2011 armv6l GNU/Linux

shv Wrote:
-------------------------------------------------------
> gr0ck,
> I think that you are trying to upgrade from
> Squeeze to Wheezy.
True I am trying to get to wheezy.
Update my uboot
and put a newer kernel somewhere so I can use wheezy.

I didn't know that the kernel was actually in the nand.

Do you know where the kernel is and how to get it into nand?

I see in the archarm script for pogoplug v3 the nandwrite, nanddump, ..etc, they are using and the addresses they write the image too, but not knowing enough about uboot or the boot process with these devices, I'm scared to just write a kernel to nand. I don't want to brick my device.

I've been trying to find areas of nand free to write, or specifications that show if you write this code at this location it will behave as follows, I guess it would be a map.

> http://forum.doozan.com/read.php?3,6336,13993#msg-
> 13993). It must be extracted to an ext3 partition
> with rootfs as the partition name. If it doesn't
> work you might need an update to lastest 2.6.31.6
> kernel from WarheadsSE.

From my uname -a output looks like I'm good to go if I grab that image and perform the modification of the rc file.



Edited 1 time(s). Last edit at 01/09/2014 04:46PM by gr0ck.

For my Wheezy image you need the following kernel:

Linux debian 2.6.31.6_SMP_820 #7 SMP Thu Jun 14 20:31:06 CDT 2012 armv6l GNU/Linux

shv Wrote:
-------------------------------------------------------
> For my Wheezy image you need the following
> kernel:
>

> Linux debian 2.6.31.6_SMP_820 #7 SMP Thu Jun 14
> 20:31:06 CDT 2012 armv6l GNU/Linux
>

OK I'm going to attempt this Sunday and see if I can update the kernel. :)

The oxnas install script I wrote covers the location,and page-cleaning pretty clearly. If not there, then the kernel updater script does.



Edited 1 time(s). Last edit at 01/13/2014 08:39AM by WarheadsSE.

I saw somewhere a patch to shutdown GMAC completely if the device is shut down. Does anybody know where I can find it? I beleave it was here in this forum.

-shv



Edited 2 time(s). Last edit at 03/05/2014 10:05AM by shv.