@feas & davidyder, Thank you both for the info so far! It's very helpful. One thing I'm eagerly looking for is the bootlog that show how the kernel started. But so far everybody has posted only partial log, because the yaffs errors rolled it off to /dev/null. When I have time to have a handons look on my box, willl see if it has the same error.by bodhi - Off-Topic
All, here is the kernel uImage for 4.14.24-cns3xxx-tld-1.2 that you can use to boot the box. After this test kernel I will temporarily pause my activity in this subject for a while! In this version, I removed the ability to process ATAG data from the kernel. So the kernel bootargs is all info being passed from u-boot. This with the DTS will be what define the box. Thus, if you have 4-bay box,by bodhi - Debian
Tommy, I would try to ignore ATAG data completely and only rely on the DTS. That way we don't need to deal with what this stock u-boot does regarding it. u-boot is too old. We would not know how much is needed to ported until we can run with this initial DTS. I meant if kernel 4.4.88 is working for you guys, then perhaps that's OK. We only do this FDT build for an experiment, butby bodhi - Debian
Hi tommy, This is a very good observation! > > I think the problem why the kernel is not booting > might be memory map/offsets. > > In your dts you declare RAM starting at > 0x00000000 (and its size 256MB) > > + memory { > + /* 256MB at address 0 */ > + reg = <0x00000000 0x10000000>; > + }; > while in Seagate's sources it stby bodhi - Debian
habibie, Thanks for suggestion. I will close this subject for now. Until another time.by bodhi - Off-Topic
blackdevil, > I tryed and the same result :-( > > Whitney # setenv bootcmd_scsi 'scsi init; ext2load > scsi 0 0x8000000 /boot/uImage; bootm 0x8000000' This address is apparently hardcoded in stock u-boot. Try setenv bootcmd_scsi 'scsi init; ext2load scsi 0 0x02000000 /boot/uImage; bootm 0x02000000'by bodhi - Debian
blackdevil, Try booting with only the uImage setenv bootcmd_scsi 'scsi init; ext2load scsi 1 0x8000000 /uImage; bootm 0x8000000' See how far you got with it. You should get to the same point as Mark did, or further.by bodhi - Debian
All, here is the kernel files that you can use to boot the box.This stock u-boot does have the memory limitation that old u-boots had. So I had to scrap the idea booting with 1 image (as previously posted). Instead of repackaging the whole kernel tarball for each testing version, I thought it is simpler to do this until the test kernel has booted OK (or we want to take a pause and let everybodby bodhi - Debian
rynax Wrote: ------------------------------------------------------- > Does this instrstruction work with Pogo V3 > Classic/Pro? > > pogoplug-v3-squashfs-sysupgrade.tar > pogoplug-v3-squashfs-ubinized.bin > pogoplug-v3-u-boot-initramfs.bin > pogoplug-v3-uImage > pogoplug-v3-ubifs-sysupgrade.tar > pogoplug-v3-ubifs-ubinized.bin > > > Use the pogoplby bodhi - Rescue System
habibie, > The former requires > additional work to split the spam post and then > delete or move it somewhere. For 1 or 2 such spam > posts, I believe it is OK. However, for spam posts > like we had here every-now-and-then, you can ask > Bodhi how painful it is to split and remove those > spam posts. Normally, I delete a handful of spam threads a day, and that isby bodhi - Off-Topic
Gravelrash, > Linux kernel version 2.6.18 or higher > glibc2 version 2.5 or higher > gtk version 2.10.4 or higher > Pentium-compatible PC (Pentium III, Athlon or > more-recent system recommended) > 256Mb RAM (512Mb RAM recommended) OK so the HP T5325 or the Dreamplug is good enough for this task.by bodhi - Off-Topic
blackdevil, Thanks for trying. > It stops loading at > "Loading Multi-File Image ..." Damn! this stock u-boot is not cooperating :) I'll come back in a few hours.by bodhi - Debian
All, here is the single kernel file that you can use to boot the box. I hope this stock u-boot does not have the memory limitation that old u-boots had. Instead of repackaging the whole kernel tarball for each testing version, I thought it is simpler to do this until the test kernel has booted OK (or we want to take a pause and let everybody build their own kernel, if wishes to do so) then I&by bodhi - Debian
I am uploading a new kernel for testing. This time we will use a different booting method that hopefully will make it a lot easier.by bodhi - Debian
Kuzma, A couple things. > Write uboot: > > kwboot -t -B 115200 /dev/ttyUSB0 -b > uboot.2017.07-tld-1.goflexhome.mtd0.kwb -p > setenv ipaddr 192.168.0.109 > setenv serverip 192.168.0.101 > tftpboot 0x800000 > uboot.2017.07-tld-1.goflexhome.mtd0.kwb > nand erase 0x0 0x80000 > nand write.e 0x800000 0x0 0x80000 > reset > When you did this, onlby bodhi - Debian
butaford, Thanks for reporting! I've found it also. But it is a non-problem when the default envs image is flashed. IOW, we are not supposed to install u-boot without installing the default envs image :) Nevertheless, it will be corrected in the next release.by bodhi - Debian
MarkTurner Wrote: ------------------------------------------------------- > bodhi Wrote: > ------------------------------------------------------- > > > But you should append the DTB to zImage and make > a > > new uImage in your rootfs. Use this Kirkwood > > example (assuming the rootfs was mounted at > sdb1 > > on another Linux box): > >by bodhi - Debian
MarkTurner Wrote: ------------------------------------------------------- > bodhi Wrote: > ------------------------------------------------------- > > @Mark, > > > > Which BlackArmor box do you have, could you > post > > the model number? I thought all Seagate > BlackArmor > > have Marvel SoC, not Cavium SoC. Apparently you > > have oneby bodhi - Debian
So basically we have to append DTB to uImage to boot properly (regardless whether there is uInitrd used in booting or not)by bodhi - Debian
blackdevil, Your box's u-boot must be a different version from Mark's box. It looks like yours does not have FDT support. So keep these addresses load_initrd_addr=0x1100000 load_uimage_addr=0x800000 But you should append the DTB to zImage and make a new uImage in your rootfs. Use this Kirkwood example (assuming the rootfs was mounted at sdb1 on another Linux box): Becomby bodhi - Debian
blackdevil, Try using the addresses that we use for Kirkwood. load_dtb_addr=0x1c00000 load_initrd_addr=0x1100000 load_uimage_addr=0x800000 If this does not work. I need to look more closely at the the envs above and the previous serial bootlog that you had for 3.18.5 (to see if this stock u-boot is picky about these load addresses).by bodhi - Debian
blackdevil, > Maybe we have to change the dts file at this > position: No need to. That one in DTS is not used when you specified it in bootargs.by bodhi - Debian
blackdevil, That's strange. Because this apparently modifiable. The bootcmd: bootcmd=setenv bootargs $(bootargs_console) $(bootargs_root); run bootcmd_scsi Try setenv bootcmd 'setenv bootargs $(bootargs_console) $(bootargs_root) earlyprintk=serial; run bootcmd_scsi'by bodhi - Debian
dexter is correct. The bootargs need to be reset in the bootcmd_lede. setenv bootargs_lede setenv bootargs $console $mtdpartsby bodhi - Rescue System
Gravelrash, > has anyone tried this on there plug? I have been > looking around to see if I can find the minimum > spec to run it and either my google-fu or aged > eyes havent allowed me to find it. I'm not aware of that min spec, either. > Im interested in attempting to run this on my last > remaining kirkwood device. just for fun i would > like to createby bodhi - Off-Topic
@Mark, Which BlackArmor box do you have, could you post the model number? I thought all Seagate BlackArmor have Marvel SoC, not Cavium SoC. Apparently you have one with Cavium!by bodhi - Debian
blackdevil, > Maybe I should not boot from a 2.5" disk in the > USM port? That's OK. The kernel has loaded and run so the disk can be used. You need to specify earlyprink=serial in bootargs to see more why it seems to hang. At serial console, list the envs printenv and post output here in code tag.by bodhi - Debian
All, Quote> The modprobe/kernel paging issue still exists: It's the same kernel as before! so it is expected. Quote4.14.24-cns3xxx-tld-1.with-native-rootfs.boot.log (13.1 KB) This log is interesting! we got a lot further, even with stock rootfs. Quote4.14.24-cns3xxx-tld-1.with-bodhi-sda1.boot.log (11.7 KB) This log also showed basically the same thing, but with same knownby bodhi - Debian
I've uploaded the rootfs Debian-4.14.24-cns3xxxx-tld-1-rootfs-bodhi.tar.bz2. Please see 1st post for download link.by bodhi - Debian
doblecero, > I understand steps will be, being in u-boot > command line: > > > flash_erase /dev/mtd0 0 4 > nandwrite /dev/mtd0 mtd0_backup_uboot > > > mtd0_backup_uboot -> contains the back taken with > > nanddump --noecc --omitoob -l 0x80000 -f mtd0 > /dev/mtd0 > > will the above also restore environment as it > previously was?by bodhi - uBoot