TEN, > Jeff in http://forum.doozan.com/read.php?3,14 has > two more lines - not needed? 1. You do need all of these 5 lines for net console. Caution: the variable preboot_nc only exists afer you've flashed the default env image uboot.2014.07-tld-2.environment.img (see number 2 below) # fw_setenv preboot 'run preboot_nc' # fw_setenv ipaddr '192.168.2.94'by bodhi - uBoot
tufkal, > Is there a possibility in the architecture being > the problem? I did this exact process on a RPi > last night, but as you pointed out not only is > that ARM6, its armhf, whereas the kirkwood is > armel. If you can compile it with that script on the Pogo then it is an armel binary. So I don't think it is architeture.by bodhi - Debian
Joey, > Hey while we're at it, is there any merit in > making pretty much, just a boot manager out of the > stock flash drive? I was about to ask about a > minimal arch or something in the neighborhood of > the space it takes for router firmware. But then > again, since Pogo is headless then nothing is > there to tell me the boot choices. Ahh... lol Boot menuby bodhi - Rescue System
TEN, Yes, it is safe to flash 2014.07-tld-2 u-boot. I did look at this script before. It only erases and writes to mtd0. And the mtd definition left the rest of NAND intact, so chance is that stock Pogo OS will work out of NAND.by bodhi - uBoot
TEN, > So I understand it could be replaced with bodhi's > while booted into the working Arch (after fixing > /etc/fw_env.config at least, or better yet > reflecting all 4 mtds as they are to properly > nanddump and disable hbmgr.sh as well, in > http://archlinuxarm.org/forum/viewtopic.php?f=23&t > =8637)? Yes. > > Not supporting Debian by defaulby bodhi - uBoot
dirixmjm, > I've moved the UART connection to a different host > (normal desktop instead of the router) and now the > upload works. > Uploading of the new uboot (through tftboot) also > worked. Cool, good job figuring it out! I understood your previous problem now. It is very subtle, it explained a lot of cases where others failed to UART boot the box. > tftpboby bodhi - uBoot
LeggoMyEggo, > > So confirming, the scandisk check is performed > before the uenv import call/function? It could be before or after, depending on your need. This will scan the disks that were specified in devices to find uImage, regardless of what will be redefined in bootcmd_uenv. fw_setenv bootcmd 'run scan_disk; run bootcmd_uenv; run set_bootargs_xxx; run bootcmd_xby bodhi - uBoot
TEN, > Well, the mod is Arch's not mine in this case. ;) :)) > Stock OS of course has the benefit of "Just Being > There" already. Yes. You can use graymanforhire's instruction about how to boot back to stock Pogo OS from the new u-boot. > However this isn't what's actually found on the > NAND at that point (as even the Arch U-Boot >by bodhi - uBoot
grayman4hire, > There are a few minor bugs with the archlinuxarm > uboot, mainly netconsole not working as expected > (no preboot) and you will not be able to boot the > default Pogoplug OS because the uboot is missing > the fsload needed to chainload the original > uboot. > > Not supporting Debian by default is a new one for > me, so another reason not to uby bodhi - uBoot
@Don, > @bodhi, that makes sense. So basically fsck.f2fs > isn't in initramfs It is in actually. But the rootfs check was after it was mounted. FYI, with the new initramfs version, it is somewhat alleviated. The rootfs is now checked before it is mounted (no need for fstab). However, f2fs filesystem is still not up to date with other filesystem as far as feeding information tby bodhi - Debian
LeggoMyEggo, > So you are saying this scan disk > function which is part of the default boot > environment would scan all the connected devices, > whether usb or ide, and search for the one which > has the /boot directory and then boot off of that > one automaitcally?. If so that is what I > wanted. Yes. That's exactly the purpose. But it is not inside u-bootby bodhi - uBoot
@TEN, > Just wondering how to do > this from Arch with minimal risk It is minimized if the instruction is followed without any modification. Usually we get into trouble thinking something is equivalent and tweak the instruction just a bit :) with boot loader installation, it is best to do exactly (copy/paste) as the instruction states. And also, if you post the entire log of installaby bodhi - uBoot
@TE, > However none of the utilities needed (fw_printenv, > flash_erase, nandwrite) are in Arch by default. > Should I use those mountable from /usr/bin under > mount /dev/mtdblock2 /media/nand -t jffs2 -o > noatime, or rather > Quotepacman -S uboot-env mtd-utilsPackages (2) > mtd-utils-1.5.1-1 uboot-tools-2015.01-1 > ... i.e. is the process you describe for >by bodhi - uBoot
@Joey, No, it meant the the rescue system rootfs has a problem. So it must be fixed, or reinstalled. The best way to fix this is to connect serial console. And watch the boot process. Log in to the rescue system through serial console connection and then fix the problem. Or take the shortcut by reinstalling it. Btw, serial console is the indispensible tool for embedded Linux device :) getby bodhi - Rescue System
@LeggoMyEggo, > The diskscan can't > be called for out of uEnv.txt because u-boot has > to know which disk is the rootfs before it will > search for the uEnv.txt file in that rootfs' /boot > folder. Not really. The scan disk has nothing to do with rootfs yet. If you reread my post: http://forum.doozan.com/read.php?3,19093,19093#msg-19093 we are still in Sectiby bodhi - uBoot
@Yama, On the latest 3.18 I still get the cryptic symbols, which makes serial unusable, but network works and I can ssh to it. Which 3.18 version? And these weird chars might just be the box's serial baud rate/parity/... parameters are different than we expected.by bodhi - Debian
TEN, Quoteget the most versatile, reliable U-Boot (presumably http://forum.doozan.com/read.php?3,12381). Yes, and set up netconsole right away, especially with no serial console set up. Furthermore, with this new u-boot, you will have the LED flashing correctly in the boot sequence, so the quick visual indicator is available (most of the time, it is enough to tell that something went wrong bby bodhi - uBoot
Scan disk: http://forum.doozan.com/read.php?3,19093,20399#msg-20399by bodhi - uBoot
@Gravelrash, Thanks! corrected.by bodhi - Debian
tufkal, > As long as the kernel has the tun.ko driver > enabled or as a module, the binary takes care of > the rest. Based on what you mentioned above and everybody's suggestions: - On a fresh 3.18.5-kirkwood-tld-1 rootfs - Add tun module to /etc/initramfs-tools/modules so it will tell initrd to load during boot. echo tun >> /etc/initramfs-tools/modules - Regby bodhi - Debian
@Tomas, > Still I would like to try to build my own kernel. > So I need solve issue with "make: *** > Error 2". You have not applied the patch correctly if you see this error.by bodhi - Debian
@WarheadsSE, I've pushed out to u-boot-kirkwood GitHub all the changes I have for NSA325 and NSA320. Please make modification to anything that you see fit. commit bb8ac0e067f6f42d8832c11c9266707bcba419f9 branch 2014.07.c-kirkwood Also included in this commit, for all supported Kirkwood u-boots: uEnv.txt loading capability, better default envs, and miscellaneous editorial changes.by bodhi - uBoot
@tutkal, If you do what Almaz suggested, I am sure it will work. At the end of the day, once it is working, we all will learn something. That's I think the best contribution, because others will then know where to go for solution. After that, there is plenty of time to figure out the differences.by bodhi - Debian
@Joe, Thank you also. It's a very helpful description of the process.by bodhi - Debian
dirixmjm, The smallest one is attached in this post: http://forum.doozan.com/read.php?2,14351,17193#msg-17193 It does not depend on any host speed, since you are connecting with serial console to boot UART. QuoteUPDATE: My thought was incorrect. The loading is affected by the how noisy the network environment is. See post below this for how dirixmjm solved it. If it does not load complby bodhi - uBoot
dirixmjm Wrote: ------------------------------------------------------- > I think I did it. My NSA 325 is bricked. > > I followed these instructions, where I did the > MTD0 flash using the stock NSA 325 firmware, and I > also did rewrite the environment to 0xc0000. > > http://forum.doozan.com/read.php?3,12381,17420#msg > -17420 > > If I now boot I get nby bodhi - uBoot
I've updated the 1st post to include new scanning script. With the new script, we can scan all types of drives in a multi-drive configuration to find the boot partition. In the near future, I will post another set of default u-boot envs to simplify the booting envs substantially (generalize all device types in booting using the same approach in this script). Please see section A.2 forby bodhi - uBoot
@DavideDG, Thanks for the helpful description! > Still - it may very well be that CodeSourcery has > problems with CODA source code, I'm no expert in > this field. It might be the case. I'm compiling natively with distcc. > Another option is to first install the NAS without > MD, let it boot, then regenerate initrd by > installing mdadm. > Then sby bodhi - Debian
@Tomas, I don't know, never had problem with compiling CODA. The errors you've listed did not ring any bell for me. include/uapi/linux/coda.h:221:2: error: unknown type name 'u_quad_t' According to Davide said above, MD works in his initrd. Perhaps you should look at your log to see how you set it up in initrramfs? Also since Davide got it working, may be we should seeby bodhi - Debian
@Tomas, > Yes I tried it. My uImage and uInitrd are on small > /boot parition that is not RAID device. Also the > documentation explicitly says it won't work: It is not clearly say that it won't work even if you loaded the module early enough in initrd. In any case, I thought that's what davidedg meant to say above: QuoteI don't know if Bodhi's initby bodhi - Debian