Koen Wrote: ------------------------------------------------------- > It seems that I've reached a dead end for now. If > I have time I will try to read the spi chip using > a raspberry pi this weekend. If that works I can > write new kernel boot parameters to spi using the > spi-w command and use the raspberry pi to restore > the spi if it ends up locking me out ofby bodhi - Debian
Christopher, Thanks for letting me know. That shortened link is a little troublesome! I am using it because Dropbox does not give download statistics (bitly gives me the ability to see the download count so I pay more attention to kernels that have most users).by bodhi - Debian
Christopher, David has confirmed that the hashes are OK. It must be some mistake you've made. Download and try again.by bodhi - Debian
daviddyer Wrote: ------------------------------------------------------- > My downloading / md5sum / sha256sum is the same as > bodhi's David, thanks for confirming!by bodhi - Debian
Awesome! Thanks Martin.by bodhi - uBoot
Derek, > root@pogoplug:~# cat /etc/fw_env.config > # MTD device name Device offset Env. size Flash > sector size Number of sectors > /dev/mtd0 0xc0000 0x20000 0x20000 > root@pogoplug:~# cat /proc/mtd > dev: size erasesize name > mtd0: 00200000 00020000 "u-boot" > mtd1: 00300000 00020000 "uImage" > mtd2: 00300000 00020000 "uImaby bodhi - uBoot
Koen > Is there a way to get any additional info from > deconstructing the .img files I've extracted from > the device? Or is that not possible? There is no value in doing that. This kernel is too old, so nothing in there would be of interest. We already know the SoC, and the kernel DTB that will boot this SoC.by bodhi - Debian
rayknight Wrote: ------------------------------------------------------- > bodhi Wrote: > ------------------------------------------------------- > > > BTW, it is best if you can find GPL for this > Dell > > FW. They must provide it somewhere as legally > > required. When we see GPL, we'll know for sure > > what to do. > > > > Gby bodhi - Debian
Martin, > U-Boot SPL 2013.10-tld-4 (Sep 07 2014 - 14:10:12) > Boot device: NAND > Attempting to set PLLA to 850 MHz ... > plla_ctrl0 : 0000020a > plla_ctrl1 : 00330000 > plla_ctrl2 : 0065008b > plla_ctrl3 : 000000f1 > > PLLA Set > > > U-Boot 2015.10-tld-2 (Oct 21 2017 - 22:00:02 > -0700) > OXNAS OX820 > Cool! &gby bodhi - uBoot
linux-4.17.2-kirkwood-tld-1-bodhi.tar.bz2 md5: cba58ed6f52efe2ea3fffa7e397b725a sha256: d4a3558072982dd8663cc54cb863998e15708916ad04b874a584909a3cb376a6 md5sum or sha256sum should give you the hash correctly. I've just rerun it. md5sum linux-4.17.2-kirkwood-tld-1-bodhi.tar.bz2 cba58ed6f52efe2ea3fffa7e397b725a linux-4.17.2-kirkwood-tld-1-bodhi.tar.bz2 sha256sum linux-by bodhi - Debian
Koen, BTW, it is best if you can find GPL for this Dell FW. They must provide it somewhere as legally required. When we see GPL, we'll know for sure what to do. > OK I've created the rootfs USB and tried to boot > it but it doesn't work yet. It is difficult to > know what is happening without serial console > output. True. > There is a quick message oby bodhi - Debian
ExtremelyCassidy, There is not enough information to tell what went on in this rootfs! So the first thing you should do is getting info about your Debian installation on this this drive. - Plug in the USB rootfs to another Linux box. - If it is automounted then umount it and run check disk to fix errors (if the drive as assigned sdb1): e2fsck /dev/sdb1 - Mount it again and (assby bodhi - uBoot
Koen, Quote- look for why the bootargs is different from the boot_normal.scr and the actual bootargs. IOW, are the actual parameters hard coded in the kernel or somehow was changed on top of the boot script. So we know where the bootargs was taken from. Now we need to see the boot sequence to make sure we know how to boot the Debian USB. Information you posted so far seems to point to theby bodhi - Debian
The next step: - look for why the bootargs is different from the boot_normal.scr and the actual bootargs. IOW, are the actual parameters hard coded in the kernel or somehow was changed on top of the boot script. - Change boot script to make it slightly different cat boot-normal.txt fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet rby bodhi - Debian
QuoteThe standard operating system doesn't have the fw_printenv command. However it does contain the command fconfig which seems to be related to redboot. Could it be that the system uses the redboot bootloader instead of uboot? It could be. But not likely.by bodhi - Debian
> I'm not sure if this is useful but this is the > output when the system is booted normally from the > internal memory. > > > root@LWT008064aa7d6c:~# cat /proc/mtd > dev: size erasesize name > root@LWT008064aa7d6c:~# cat /etc/fw_env.config > # MTD device offset size erase_size > /dev/mtd0 0xc0000 0x10000 0x10000 > It means u-boot is onby bodhi - Debian
Ok. It is very promising. However, boot-normal.scr is not what used when the kernel was actually booted. root@LWT008064aa7d6c:/mnt/temp1# cat boot-normal.scr fatload ide 0:1 0x200000 /uImage setenv bootargs pm_disable root=/dev/sda3 vmalloc=384M mimas quiet bootm 0x200000 Kernel command line: root=/dev/sda3 pm_disable usb0Mode=host usb1Mode=host video=dovefb:lcd0:1024x768-32@60,lcdby bodhi - Debian
Koen, There are quite a bit of info to digest! I'm busy right now, will take a look at your posts and fill in my observation in this post. - This is an ARM box so there should be no BIOS. - Apparently serial console is working. I need to recall what key sequence that might work when the secure boot is implemented.by bodhi - Debian
Martin, > no i didn't flash anything. Then blparam is the correct command to use. > /tmp # blparam > current_envs.txt > -sh: blparam: not found > /tmp # ./fw_printenv > current_envs.txt > Cannot read bad block mark: Invalid argument > /tmp # ./fw_printenv > Cannot read bad block mark: Invalid argument > The above erorrs aby bodhi - uBoot
Looks like it is Armada 510. Same as HP Thin Client T5335z. QuoteDove family (application processor) ----------------------------------- Flavors: 88AP510 a.k.a Armada 510 Product Brief : http://www.marvell.com/application-processors/armada-500/assets/Marvell_Armada510_SoC.pdf Hardware Spec : http://www.marvell.com/application-processors/arby bodhi - Debian
shayan123, > Thank you for all the support. I can now > successfully boot Debian on my GoFlex Home! Cool! > If so, how would this be done on the GoFlex Home > via serial console? Yes it is a given, that you can run stock. But I would not spend time to make it work. If you want a rescue system then look at the Rescue System subforum and pick one that you like to instalby bodhi - uBoot
Koen, It is not at all similar to the T5325 which has Kirkwood SoC (ARMV5). It seems this box has Marvell Dove SoC, which is ARMV7. Similar to other ARMV7 boxes that I supported: https://forum.doozan.com/read.php?2,32146 It is possible to run Debian on this box, with some more works. The Dove is already mainlined, so it would not be difficult. I don't think it is locked down, givby bodhi - Debian
Martin, QuoteSorry to keep bothering , but when i run : /tmp # ./fw_printenv > current_envs.txt Cannot read bad block mark: Invalid argument i must be doing something wrong , but i have no idea. any clues? best regards Martin Did you flash u-boot image and u-boot envs image? If you did, please post the log of the session (copy/paste whats in your terminal) from the beggby bodhi - uBoot
Martin Etcheverry, > /tmp # cat /proc/mtd > dev: size erasesize name > mtd0: 08000000 00020000 "NAND 128MiB 3,3V 8-bit" > mtd1: 00e00000 00020000 "boot" > mtd2: 07200000 00020000 "rootfs" > > appears mtd0,mtd1 and mtd2 , i only expected two > mtd's . > is this normal? It is normal, since stocks defines mtd0 is theby bodhi - uBoot
Last post moved here: https://forum.doozan.com/read.php?3,63514by bodhi - uBoot
shayan123, > The guide mentions to set mtdparts in the envs > after flashing. If they aren't listed by > fw_printenv do I leave it blank mtdparts can be set after flashing the envs image. In the normal case, you see it in your current envs, but yours were corrupted! It can be found in the envs text file from the tarball. Quoteuboot.2016.05-tld-1.environment (the contenby bodhi - uBoot
shayan123, > Yes! Debian boots perfectly from rootfs with > kwboot! Now I assume I need to flash the > uboot.2017.07 for GoFlexHome as described by this > post? > https://forum.doozan.com/read.php?3,12381 > Correct. > Would this be the part I’m supposed to be > focusing on? : > A. Flashing Instruction: Yes. This instruction was written to covby bodhi - uBoot
raven66, > http://zyxel.nas-central.org/w/index.php?title=Debian_on_325 > http://forum.nas-central.org/viewtopic.php?f=249&t=15633 > But my question is, is these tutorials still > valid? I mean, they are pretty old and they are > referring to Debian 3.14 and OMV 0.x (and probably > Debian is currently @ 4.xx and OMV is 4.1.3 - > http://www.openmediavault.org/doby bodhi - Debian
shayan123, > My bad. Alright, I'm able to send the boot image > now, but the new boot image is expecting a > uEnvs.txt which I don't have. That's the default behavior. It does not mean that uEnv.txt is required. > (The whole point of > this thread is that I don't have envs.) kwboot will help you booting into Debian rootfs on USB. After that you cby bodhi - uBoot
veriqster Wrote: ------------------------------------------------------- > most definitely a hardware problem, it boots even > with autoboot just fine as long as I leave it > alone or about 30 min. If I try and reboot or shut > down and restart immediately it acts up randomly, > the more I use it (like the dist-upgrade I did) > the more more it acts up. Yes. It soundsby bodhi - uBoot