Yes, certified repair means stock, so you will need to register online to get access to SSH.by bodhi - Debian
Here is what I did: http://forum.doozan.com/read.php?2,13702,13704#msg-13704by bodhi - Debian
fw_setenv will save it immediately. To verify if netconsole setup correctly, post the output of fw_printenv here (no automatic way to check).by bodhi - uBoot
You can interrupt netconsole, and execute printenv post the out put here, and we'll take a look if anything missing!by bodhi - uBoot
When you see this: OK Starting kernel ... and then it stuck there, most likely the problem is with either the bootargs or the rootfs on the USB stick.by bodhi - Debian
Lallo, It booted in to Pogo OS in NAND. Looks like your Debian USB rootfs is bad (not the drive, the rootf itself): Loading file "/boot/uImage" from usb device 0:1 (usbda1) ** File not found /boot/uImage ** Block device usb 1 not supported ** Block device usb 2 not supported ** Block device usb 3 not supported Loading file "/boot/uImage" from usb device 0:1 (usbdaby bodhi - Debian
schumischumi, Your U-Boot envs look OK. Have you tried checking your USB rootfs for error ? (using a different Linux box and fsck it).by bodhi - Debian
JohnXX, If you have not changed any of U-Boot envs (you have only played with rootfs), then it does not hurt to try these first: - On a different Linux box, fsck your rootfs to see if there is any error. Cold boot after the check. If this did not boot then, - Make a basic fresh rootfs on a different USB stick, and try to boot with that. The LED should be green after the U-Boot has loadeby bodhi - Debian
This needs to be fixed: fw_setenv=serverip 192.168.1.204 This is OK: usb_set_bootargs=setenv bootargs console=$console root=UUID=$usb_root_uuid rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params usb_root_uuid=846f98f1-d318-436f-b860-78f77d80f635 But a better approach is using rootfs label: http://forum.doozan.com/read.php?3,8044,8152#msg-8152by bodhi - Debian
WarheadsSE, Sure. I was hoping to get confirmation from YodaJM, or somebody before doing that. But it should not impact any thing to include it.by bodhi - uBoot
YodaJM, See this post: http://forum.doozan.com/read.php?3,12381,15608#msg-15608by bodhi - uBoot
I've uploaded 2014.01 U-Boot image for Pogo E02: uboot.2014.01-tld-1.pogo_e02.bodhi.tar md5: 8288a63432cb4fb0168d2baac8530333 This version incorporated a patch to provide a way to increase the USB ready retry period. This hopefully will help those who use large USB HDDs such as a 4TB WesternDigital or Seagate Desk, also possibly help with booting-problem USB thumb drives. To enableby bodhi - uBoot
Here is the working USB stick thread. Pretty long list of what usually work and what to avoid. http://forum.doozan.com/read.php?2,1915 IMO, it's partly in the U-Boot version that you're running. Usually it handles typical USB thumb drives very well. But some thumb drives are of low quality (e.g. Patriot), and it will fail to boot.by bodhi - Debian
Thanks Termo.by bodhi - Debian
Cool! glad it works the way you want it.by bodhi - Debian
toomyzoom, Yes, it is my build, and it is a basic rootfs so it might lack certain settings to make that happen. Asian file names have been working for me on all my existing rootfs, though. Did you copy your samba config file from your x86 debian wheezy server over to this rootfs? I will take a look if in fact you've done that and it did not work.by bodhi - Debian
Puhvogel, Your orginal uBoot envs are still intact, but the new U-Boot use a different location (0xC0000). That's why it seemsto be gone. I did mention this in the instruction for iConnect. If you you want to start with a good set of U-Boot env, see this thread: http://forum.doozan.com/read.php?3,7477,10982#msg-10982 Look for the section - Flash uboot.environment to 0xC0000 In Jefby bodhi - uBoot
WarheadsSE Wrote: ------------------------------------------------------- > Can it be compiled? Yes. Do you want to do that? > No. Why? Is there any technical reason not to?by bodhi - uBoot
Yeah:) I am aware that it'd take at least 1GB to run ZFS. Just want to see if it can be compiled on ARMV5by bodhi - uBoot
Termo, Could you post the lsmod output when you got your modules running? I might have missed some config options (I'm not running DVB on my plugs). Thanks!by bodhi - Debian
Termo Wrote: ------------------------------------------------------- > Can the dvb_demux.h header file be included in the > header file? I need it to compile the dvbhdhomerun > program... > > http://sourceforge.net/apps/trac/dv > bhdhomerun/wiki/Building It should be in there already.by bodhi - Debian
Here you go: http://forum.doozan.com/read.php?3,6336by bodhi - Debian
Johnklos, If you can get ZFS to compile on these plugs. I'd like to know! I've tried it about a year ago, but it failed because ARM was not supported then.by bodhi - uBoot
I forgot, if you're running davygravy's u-Boot image, then Ext4 might not work. Check at U-Boot serial console to see if the command ext4ls is availble (run help).by bodhi - Debian
toomyzoom, Booting ext3 or ext4 formatted rootfs is fine, but you need to set that type with u-Boot env. For exampe (usb_rootfstype is the env name): usb_rootfstype=ext3 usb_set_bootargs=setenv bootargs console=$console root=$usb_root rootdelay=$usb_rootdelay rootfstype=$usb_rootfstype $mtdparts $usb_custom_params And when you boot ext3 rootfs and got ext2, that was because your rootfby bodhi - Debian
johnklos, The original U-Boot store the envs at 0xA0000. Davygravy's built u-Boot stores it at 0xC0000 (the normal convention that Jeff has established). This is one of the good reasons why I defined them in the new U-Boot builds at 0xC0000. They can coexists and you can choose to boot different rootfs without having to worry about redefining them. And when you booted in to Debia/Arch, usby bodhi - uBoot
Heads up! I'll release kernel 3.14 build hopefully in about a week. http://www.phoronix.com/scan.php?page=news_item&px=MTYzNDgby bodhi - Debian
johnklos, Use nanddump and nandwrite in Linux. Simplest. Remember to make sure the nandwrite uses the correct option that nanddump used regarding OOB. Also make sure to look at the usage for nanddump and nadwrite in your installation. example: nanddump to /tmp/usb/ /tmp # ./nanddump -nf usb/mtd0 /dev/mtd0 Block size 131072, page size 2048, OOB size 64 Dumping data starting at 0x0000000by bodhi - uBoot
My old Pogo kernel boot log: 0.000000] Linux version 2.6.31.8 (afenn@kt) (gcc version 4.3.2 (sdk3.3-ct-ng-1.4.1) ) #5 Wed Sep 28 12:09:12 PDT 2011 [ 0.000000] CPU: Feroceon 88FR131 [56251311] revision 1 (ARMv5TE), cr=00053977 [ 0.000000] CPU: VIVT data cache, VIVT instruction cache [ 0.000000] Machine: Feroceon-KW [ 0.000000] Using UBoot passing parameters structure [ 0by bodhi - uBoot
ebbes, Do you have the original u-Boot envs still in in location 0xa0000 ? cesvcid=xxxxx ceboardver=PPV4A3 … ...by bodhi - uBoot