Quote And yes, perhaps it is time to use my script to reset your envs to the default envs, using netconsole. And then you don't have to append the DTB, just use the original 4.12.1 rootfs after untar it to the SD card.. just to re-iterate a couple of points. 1. This on a DIFFERENT POGOPLUG, not the one I changed envs. it is pristine from the original uboot install, U-Boot 2014.07-tby craigcoffman - Debian
Quote Was it a typo when you typed the post? the file name should be kirkwood-pogoplug_v4.dtb. Note that it would have been better to see the actual log of the session while you are doing this so that I can spot any typo you might have made! transcription error I assure you. I auto-complete those thing typically of course. Yes, would've seen an error, AND, it would have been a no-opby craigcoffman - Debian
small follow up & a question bodhi: i noticed i have 4.12.1 running on my dockstar, even with this uboot version: U-Boot 2014.04.R2-1 (May 15 2014 - 14:35:47) Arch Linux ARM Seagate FreeAgent DockStar i said I was running 4.4 on it as well. the question: i kind of hate to spend the time, but I was already spending time reading other threads here about various issues & I cameby craigcoffman - Debian
Hi bodhi, thanks for the response. Quote I did not see uImage.orig in here. Is uImage.stock.4.12.1 the original uImage? correct. I decided *.orig was not a super-helpful name & that things could get confusing without just sticking with using the version in the name. Especially once I start trying to "upgrade" kernels. Quote The zImage.fdt indicates that you have appendedby craigcoffman - Debian
Posted a follow up in the debian forum: https://forum.doozan.com/read.php?2,37694by craigcoffman - uBoot
OK. Took another pogo-plug that runs 3.14 currently as the victim. Output of fw_printenv on that box (printed while booted on 3.14 fs & kernel) root@whiterabbit:~# fw_printenv baudrate=115200 bootcmd_mmc=run mmc_init; run set_bootargs_mmc; run mmc_boot bootcmd_sata=run sata_init; run set_bootargs_sata; run sata_boot; bootcmd_usb=run usb_init; run set_bootargs_usb; run usb_boot;by craigcoffman - Debian
Got it. absolutely understand. I'm sure you read a dozen or more threads a day just like this one or close. I'm sure they all run together. 2 pogoplugs & dockstar now all on 4.4.0 which is good. It's simply easier to get them up & running on a fresh rootfs package, add packages & then move/restore data than to worry too much about all the nuances. Maybe good enougby craigcoffman - uBoot
bohdi: I posted the output of fw_printenv in the vary 1st message. the firmware did have the 4 new lines related to booting a non-dtb image), but I have since removed them. I have verified the enviroment is the same as on "pristine" boxes. Am I to understand that the uboot enviroment need to change from what it was even loading an image with the dtb file appended? Yeah, neveby craigcoffman - uBoot
Update: Downloaded the 4.4.0 rootfs kit, installed it a yet another different sd card. Built the uImage with the dtb file, same exact way as before. This booted 1st time. Something up with the 4-12 kernel & the pogoplug v4 maybe?by craigcoffman - uBoot
I realize I may have given too much information here & flooded you with a mix of relevant & possibly irrelevant data.... but to summarize I never had any problem dropping back to the old kernel & booting. Not an issue. BUT nothing I can do can get that new kernel (4.12.8) to boot. generated the Image & Initrd many times now.. always the same. You may have missed it in mby craigcoffman - uBoot
I wonder if I need to drop back to an earlier kernel?by craigcoffman - uBoot
bohdi: generated the uImage again with the dtb file embedded. re-generated the initrd too. Still no joy. actually re-downloaded the original tar ball, went thru it all step by step again. Even removed all 4 of the new lines from firmware... consulted another pogoplug mobile here & restored the usb_boot line to: usb_boot=mw 0x800000 0 1; run usb_load_uimage; if run usb_load_uinby craigcoffman - uBoot
Take a look at these lines from the output of fw_printenv: load_dtb=ext2load usb 0:1 0x1c00000 /boot/dts/kirkwood-pogoplug_v4.dtb load_initrd=ext2load usb 0:1 0x1100000 /boot/uInitrd load_uimage=ext2load usb 0:1 0x800000 /boot/uImage usb_boot=run load_dtb; run load_uimage; if run load_initrd; then bootm 0x800000 0x1100000 0x1c00000; else bootm 0x800000 - 0x1c00000; fi is this not correcby craigcoffman - uBoot
I give each a static IP by always creating/copying over the /etc/interfaces file. Too much trouble to go hunting it down each time. I would think that if the new kernel booted, it would be constrained by that file as well. Copying the original kernel image & ramdisk back into place always results in it coming back up correctly at the assigned static.by craigcoffman - uBoot
>Is this uImage has the DTB embedded inside? have you tried to regenerate this? >-bodhi uImage.new & uInitrd.new are the ones I generated. I copy them to the "active" filename on & off. Inititally I generated the uImage with & without the dtb file. Maybe I misunderstood, but I thought from one of you replies that the uboot version I was running was newby craigcoffman - uBoot
sysvinit seemed to be causing some grief with systemd (at least I suspect it was the case). it's possible the systemd install was a partial failure or something, & I *think* I saw it install (again) when I removed sysvinit. (it's also possible I'm confused as I "installed" several different times). what I was seeing with systemd was the inability to add new serby craigcoffman - uBoot
Here' you go. Very much appreciate your time. root@sirguy:~# nc -u 192.168.2.9 6666 U-Boot 2014.07-tld-1 (Jul 18 2014 - 00:59:45) Pogoplug V4 gcc (Debian 4.6.3-14) 4.6.3 GNU ld (GNU Binutils for Debian) 2.22 Hit any key to stop autoboot: 0 (Re)start USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... 2 USB Device(s) found scanning usb for storage devices... 0by craigcoffman - uBoot
another piece of information: I have: custom_params=init=/bin/systemd in my /boot/uEnv.txt The "original" file system I'm trying to install the kernel on (& that I want to keep) has been updated to debian_ver 9.1 & has systemd fully installed. (sysvinit removed). booting on the old kernel (3.14) all works fine.by craigcoffman - uBoot
Also installed the 4.12.1 rootfs on a separate sd-card just for a test. no modifications other than /etc/interfaces /etc/hostname /etc/hosts. Same behavoir... files are found, appear to load, process sticks, light stays orange. cannot ping or ssh to box. just in case this helps.by craigcoffman - uBoot
I cannot seem to get the new kernel 4.12.8 to work. here's my uboot env: root@tweedledum:~# fw_printenv baudrate=115200 bootcmd=run bootcmd_usb; run bootcmd_mmc; run bootcmd_sata; reset bootcmd_mmc=run mmc_init; run set_bootargs_mmc; run mmc_boot bootcmd_sata=run sata_init; run set_bootargs_sata; run sata_boot; bootcmd_usb=run usb_init; run set_bootargs_usb; run usb_boot; bootdeby craigcoffman - uBoot
I've got 4 pogo-plug mobiles. Getting ready to use them in a project. All have U-Boot 2014.07-tld-1 (Jul 18 2014 - 00:59:45) Linux-3.14.0-kirkwood-tld-1 installed. The installations are on very old, very slow 2GB SD cards & I want to move to larger, faster cards I made copy of the working good SD card with dd, then tried to "upgrade" the OS, found out the hard wby craigcoffman - uBoot
Bodhi: I'm not real concerned about this, but will work this end if you want to dig into the X issue to make sure it's not something in the 3.18 tar-fs. The dockstar is running an older arch-version of uboot... & we covered some issues related to the dtb file, etc. in this thread: http://forum.doozan.com/read.php?2,25827 There is also a serial console boot log posted theby craigcoffman - Displays
Bodhi: IIRC (now that I really think about it) the pogo plugs are running your Debian 3.14 kirkwood image. ONLY the dockstar is running the 3.18. This is because: 1) I didn't know about the 3.18 image until you & exchanged messages about the problems I had with ugrading the "install" on the Dockstar, & 2) the Dockstar would not boot (if you recall) the 3.14 imaby craigcoffman - Displays
gravelrash: the only important part in the xorg.conf is the "device" part which specifies the driver to use: Section "Device" Identifier "Tritton USB-VGA" Driver "sisusb" VendorName "sis" BoardName "unknown sis card" Option "SWCursor" "off" Option "HWCursor" "on" Option "CRT1Gamby craigcoffman - Displays
As detailed in my earlier thread on this usb-2-vga device, I had a lot of trouble getting it to work properly with my dockstar. In the end, I decided that since all I needed was the ability to run "slideshow" of graphics on the root window I wouldn't worry about all the problems I had with X crashing upon loading the various window managers &/or more than 1 or two Xterms or otby craigcoffman - Displays
update: removed & re-installed X. have elminate every error logged, but still the behavoir (exiting upon launch of any window manager or another application) persists. I CAN load twm, & launch xload & xclock & even xcalc. A second Xterm (in addition to the default loaded at startup) kills the session. I've monitored memory usage, /tmp usage & load during all thiby craigcoffman - Displays
Xorg.X.log from starting X with xinit (remotely) & then issueing the command: xfwm4by craigcoffman - Displays
As mentioned in another thread, I bought on of these for to use with one of my Pogoplugs (or my one dockstar). These are incredibly cheap & can be had on ebay for just a few bucks. (I paid $5). It's based on a SiS chip & I found some information indicating it would work, so I took a chance. My intended use for it is to hook it up to the same pogoplug that does the IR-control foby craigcoffman - Displays
Unfortunately it's not just that easy. Getting the hardware to put out the right signal (NTSC 480i) is the stumbling block. Just putting an adapter on the end won't do it & it looks like trying to get X to put out that signal may or may not really work. Hence why I was hoping there was some device made to put out the NTSC signal natively. Then there's the cost... @$40 fby craigcoffman - Displays
Those sort of cable are for doing video capture. It wouldn't help for hooking up to a display as there is no video display device/chip. More research has shown there it is to cheap devices available that are supported under linux to varying extents. The first is "displaylink" (not sure if this is a true brand-name) & the second is a device bering the the name "Triton&by craigcoffman - Displays