Good works, Tommy :)by bodhi - Debian
Ben, Yes, the rootfs is most like the reason. But the DTB file name is wrong, too. Here is what you need to do. 1. Recreate the rootfs, and make sure you follow the instruction closely. 2. Attach the rootfs to the box, power up. 3. Interrupt serial console at count down, and execute setenv devices mmc setenv dtb_file ‘/boot/dts/kirkwood-pogoplug_v4.dtb’ printenv boot Andby bodhi - Debian
raffe, > 6. Boot with DTB file embedded in the kernel > image > > cd /boot > mv uImage uImage.orig > cp -a zImage-4.15.2-kirkwood-tld-1 zImage.fdt > cat dts/kirkwood-goflexnet.dtb >> zImage.fdt The DTB file name is wrong. Should be n1t1. The rest looks OK.by bodhi - Debian
Ben, ------------------------------------------------------- > Hi bodhi, > > I can't believe I missed that typo! After fixing > that, I could get uboot updated using your > release. HOWEVER, my device couldn't boot after I > followed your instructions to upgrade the kernel > (this post, > https://forum.doozan.com/read.php?2,12096). > > I cby bodhi - Debian
rayknight Wrote: ------------------------------------------------------- > bodhi Wrote: > > > rootfs. Ext4 has been troublesome lately (it > does > > not play well with older u-boot Ext4 driver). > > > > When formatting use mkfs.ext4dev instead of > mkfs.ext4 to avoid the issues with older u-boot. Thanks Ray. Is that becasue mkfs.ext4dev defaultby bodhi - uBoot
doblecero, Cool! glad you got everything working. I've looked at the stock OS booting briefly. I was not able to boot the stock kernel with new u-boot (not yet). Perhaps it is time wasting to do this, because we already have a LEDE rescue system built for this box: https://forum.doozan.com/read.php?4,29966by bodhi - uBoot
Mark, > I can't get tld-1.2 to boot at all. So the trying to help 2-bay, I broke the 4-bay :) All, I will rebuild and upload tld-3 kernel package. Hopefully, it will help everybody to build the FDT kernel.by bodhi - Debian
Ben, You did not say which version of u-boot that you have installed on this box. But by the look of the envs, it looks like an older version of my released u-boot here. This env is wrong: mtdparts=mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112(root) There is a typo mtdparts=mtdparts=orion_nand:2M(u-boot),3M(uImage),3M(uImage2),8M(failsafe),112M(root) Pleby bodhi - Debian
@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