Thanks guys. All sorted. I couldn't do it on my current install - despite showing as installed the binaries weren't there. No idea what had happened, but it's been used a lot to get a feel for the system again so I probably broke it somewhere. But I took a clean rootfs and it compiled (almost) first time. Adding some swap sorted it, took around an hour to compile. Thanksby Biohead - Debian
Mijzelf Wrote: ------------------------------------------------------- > Biohead Wrote: > ------------------------------------------------------- > > it > > seems a downgrade to GCC isn't as > straightforward > > as I'd hoped, > What do you mean? On my system (Buster) > > apt list | grep gcc > > shows (among others) gcc-7-baseby Biohead - Debian
Thanks for the pointer bodhi. I've had a look at what may be needed, and it seems a downgrade to GCC isn't as straightforward as I'd hoped, certainly not below GCC-9 anyway (which gives the same error when trying to compile this driver). Could anyone offer any further advice, or should I look for a more compatible WiFi adapter? (A genuine question: would there been any benefby Biohead - Debian
I figured it's quite relevant here.... I'm having a very similar issue. I've installed the 5.15 headers. This is the error I'm getting when using the make command (not using DKMS): root@pogoplug:~/88x2bu-20210702# make make ARCH=arm CROSS_COMPILE= -C /lib/modules/5.15.5-kirkwood-tld-1/build M=/root/88x2bu-20210702 modules make[1]: Entering directory '/usr/src/linby Biohead - Debian
Thank you for tracing that Bodhi, I confirm rollback was successful and USB3 works fine.by Biohead - Debian
Here is the full output from boot to login: There is a USB3 drive connected throughout. Once boot was completed, it was removed and reinserted. Boot from SD card. U-Boot 2017.07-tld-1 (Sep 05 2017 - 00:34:01 -0700) Pogoplug V4 SoC: Kirkwood 88F6192_A1 DRAM: 128 MiB WARNING: Caches not enabled NAND: 128 MiB MMC: MVEBU_MMC: 0 In: serial Out: serial Err: serial Net:by Biohead - Debian
Hi Bodhi, Absolutely nothing showing in dmesg, nothing on the serial output when I plug something in to those ports. The USB2.0 port is fine and works as expected (and you can see the output in dmesg) - but absolutely nothing on the 3.0 ports. root@debian:~# dmesg | tail -20 [ 19.467988] netpoll: netconsole: interface 'eth0' [ 19.473378] netpoll: netconsole: remote portby Biohead - Debian
I've tried searching, but not really seen anything... I'm using the latest Debian rootfs, topped upto the latest kernel. This is a Pogo V4. The USB3 ports are completely dead when booted into Debian. Nothing shows using lspci, no power to the ports either. Nothing also picked up by uBoot (2017). I thought it was a hardware failure, but I restored my stock bootloader and booted Pogby Biohead - Debian
Whilst I remember (and unrelated to the initial question) - these are the commands I followed to reset the SSH password I'd set all those years ago and then completely forgot what it was. Saved me having to dig out a serial cable (and possibly soldering required). I've just followed these instructions on a spare GoFlex Net still running Pogo OS. I used a variant on my V4 where I dby Biohead - uBoot
Unfortunately I have no stock bootlog to go through, the only info I have is from this in the stock OS: # cat /proc/mtd dev: size erasesize name mtd0: 00200000 00020000 "u-boot" mtd1: 00300000 00020000 "uImage" mtd2: 00300000 00020000 "uImage2" mtd3: 00800000 00020000 "failsafe" mtd4: 07000000 00020000 "root" I guess using that inby Biohead - uBoot
Wow, it's been some time since I have frequented here. It also looks to have changed an awful lot since the days I really got involved! I have dug out a Pogo V4. It looks to be in stock form, with the exception of it running optware. I'd previously enabled SSH, but couldn't remember the password - some playing around in the url command interface got me back in using passwd and dby Biohead - uBoot
Things really have moved on from when I was last active in this area! Although this might just get put on hold now... I've got a Buffalo Cloudstation Pro on it's way to me (with the 1.6GHz Kirkwood) which is much more appealing to play with as there's very little info around for that!by Biohead - uBoot
Hi all, It's been a while since I've been here! And my Goflex Net is still chugging along nicely (although it runs stock Pogo OS with optware and nothing exotic). No hardware mods, although it is powered through PoE via an adaptor - no worrying about power sockets for it! I've just recently dug out my old V4 and thought it's time to start playing again. As mentioned with myby Biohead - uBoot
Sorry it's a bit late, but I have these on my cloud: http://ppl.ug/KH4OtdkSclI/ I believe it's as close to out the factory as possible - it boots a ramdisk image which then copies the necessary files over to nand.by Biohead - Off-Topic
Just in terms of reliability, I've had my E02 and my Goflex Net being in use from about 2012 - the GFN almost continuously. Unlike the main goal of this forum, I stuck with the stock system and used optware to add the tools I needed - I have probably stressed the hardware less than other people but they're still both in perfect order. The only issue I have is that the GFN seems to cby Biohead - Off-Topic
Right - managed to get that done. I ended up booting to a USB install of Debian by uploading a different boot loader through UART. Thanks to that method, the new device has never actually been booted using its own nand so these dumps are factory fresh. The result is completely virgin dumps of mtd1 and 2. Restoring these back to my other goflex net worked fine (all showing up in pogoplug.com) aby Biohead - uBoot
Hi guys, I've got a goflex net which I've recently had to recover and whilst I had some dumps, I've no idea of their origin as my original ones proved corrupt. I've also got a 2nd goflex net which is sat in the box, still sealed and unused. As this firmware hasn't even been booted, I'm trying to think of a way of dumping the firmware in it's current state,by Biohead - uBoot
http://ppl.ug/9-29lbY1JWE/ Sorry for the late response, but I've just had to flash mine back to stock - so had to refresh my mind how it's done and saw this post.by Biohead - Debian
Many many many thanks for your help Davy. I have got it running, and could access it through my.pogo. I guess this is also useful for anyone who has completely hosed their GFN like I did ;) What I also noticed was in your MTD2 dump, is the original uboot that was backed up when you ran Jeff's script (Don't worry, it doesn't have any of your env stuff in it - i've checked).by Biohead - Debian
Nice to know it should work at least Davy. I did briefly try it last night (it's the only place I can get an hour or so free) and it didn't go quite so well. I'm working from memory now, but I'll post in more detail later. I'd restored each bit of the NAND and then let it reboot. Flashed the uboot one from 0x0, size 0x80000. Watched it as it booted through serialby Biohead - Debian
The restore files provided for V2 pogo plugs (nothing is available for GFN) are in the form of a ramdisk image. Upon first boot, the ramdisk is opened, and then it starts writing to flash what is needed, you can't actually get into the OS until this has run, and been replaced with the OS. Assuming it's a similar setup on the unused GFN, I want to try and preserve this bit so the installby Biohead - Debian
Right I'm pretty resigned to the fact that the backups are duds. I didn't use Jeff's script to backup, but just issued commands manually. It seems that you have to specify an option specifically or you will get problems relating to error correction and what not which means they backups aren't really usable. So I'm looking at trying to make a new set of backups from myby Biohead - Debian
I don't have any output saved, but I can't remember any errors being shown when I did it. I believe the command I used was: nanddump -nf mtd0 /dev/mtd0 Looking at the idea of creating backups from the unused gfn, but I'm unsure how I'd get the files off there without booting it past uboot? Can you also send through tftp?by Biohead - Debian
There's something not quite right with my mtd backups, heres the output from my attempt at restoring mtd1, but they all have the same error: root@debian-kirkwood-wide:~# ./flash_erase /dev/mtd1 0 4 Erase Total 4 Units Performing Flash Erase of length 131072 at offset 0x60000 done root@debian-kirkwood-wide:~# ./nandwrite /dev/mtd1 mtd1 Image 4325376 bytes, NAND page 2048 bytes, OOB aby Biohead - Debian
Yes I used the uart uboot from Scott's site as I've even looked at compiling uboot yet. Thank you for providing one - it detects my NAND fine and also my RAM. What I have tried doing now is erase each mtd block in the nand, so I know i'm on a clean slate. Then I've copied my mtd0 backup into ram at address 0x800000, and written it into mtd0 using nand write.e 0x800000 0xby Biohead - Debian
mtd0 is the contents of uboot partition, correct. I was just trying to get it to load from memory when doing the booth commands, although it didn't do any of them. When trying to load the ce_kernel, it was purely a kernel, no initrd - just to see if it would at least start the booting process, which it did. Am I right in thinking that the problem lies with this uboot not detecting theby Biohead - Debian
Had another quick try tonight, and got the same error with the flash - it's as though it's not seeing it at all. Is this because the uboot.uart won't function on the GFN? Or am I not uploading something else before hand? This bit isn't in the log I've provided: When I try to upload my mtd0 backup (which is 1024kb in size, not 512kb like the uboot.uart) via picocom, iby Biohead - Debian
If someone tells me how to backup the entire flash through the uboot prompt I'll gladly open the box. I figure it would have to be done through uboot so that the flash remains completely fresh (I think it does a few changes on first boot). Anyway, as for fixing my dead one, I got a quick uart boot running - but either it could not find or not initialise the flash - too many bad bloby Biohead - Debian
Once I get UART working, I have a completely unused (as in sealed box still) 2nd GFN. Do you know of a way where this flash could be dumped at the uboot prompt, then flashed to the kaput'd GFN? I suppose once the MAC address, and Pogo ID etc are all changed (if required), it would be just like a new GFN out the box - could possibly upload these dumps should other people need them in future.by Biohead - Debian
Managed to wipe out uboot from the flash by accident, so going to need to start looking into the UART booting.by Biohead - Debian