**** BEGIN LOGGING AT Fri Mar 30 03:00:01 2018 Mar 30 12:19:45 zmatt: Is there a forum or mailing list where I can propose a BB variant to the designers? Mar 30 12:31:38 esr: the guy to propose it to would be jkridner Mar 30 13:07:57 KotH: Thhanks, I just sent him mail. Mar 30 13:28:16 zmatt: did you try to point something out to me? Mar 30 13:28:26 * jkridner[m] scrolls back Mar 30 13:31:49 thought I had a pop-up pointing to something, but I don't see it now. Mar 30 16:02:05 jkridner[m]: eh, pretty sure it would have been the line immediately above it Mar 30 16:02:09 I can check Mar 30 16:03:11 02:15:16 < esr_> Is there an issue tracker where I can gripe about incomplete documentation and have it fixed? I collected some observations that could really help other newbies. Mar 30 16:03:14 02:20:03 < zmatt> no idea what the best place is for that Mar 30 16:03:17 02:20:23 < zmatt> jkridner[m]: ^ Mar 30 16:05:53 esr: the forum is https://groups.google.com/forum/#!forum/beagleboard ... it also behaves like a normal mailing list (beagleboard@googlegroups.com) Mar 30 17:18:55 hi Mar 30 17:19:05 i need help Mar 30 17:20:04 i´m from Ecuador Mar 30 17:20:48 I can not access my BBB's remote desktop Mar 30 17:26:18 hi , i need help , i´m from Ecuador. I can not access my BBB's remote desktop Mar 30 17:30:11 by default there is no remote desktop Mar 30 17:39:21 use VNC Viewer Mar 30 18:07:24 someone speaks Spanish? Mar 30 18:11:01 hi Mar 30 18:11:03 hola Mar 30 19:11:13 si Mar 30 21:59:51 Hi, anyone here? :) I can't get BBB to boot at all after power interrupt during flashing, it doesn't boot from SD when I hold the button. Is there a solution for this? Mar 30 22:01:37 aplavin: that sounds odd Mar 30 22:02:30 if you power on while holding down the S2 button (you can let go of the button once the power led turns on), the eMMC is entirely bypassed and its content is irrelevant Mar 30 22:02:52 well, I try exactly this: Mar 30 22:03:26 I write the image to sd card again, to be sure; insert it to BBB; hold the button; attach power Mar 30 22:03:35 then only the power led lights up Mar 30 22:04:04 if I hold the power btn for ~10 secs it turns off as expected Mar 30 22:04:21 are you sure you flashed the card right? since what you're describing sounds like bootrom doesn't consider the sd card to be bootable Mar 30 22:05:36 first I tried without rewriting the sd card (after successful boot & in-progress flashing), the same happened Mar 30 22:06:02 do you happen to have a serial cable for the debug console? Mar 30 22:06:17 nope :( usb & ethernet only Mar 30 22:08:23 so even if emmc is "broken" it should boot from sd? Mar 30 22:08:39 I mean totally broken, unread/writeable Mar 30 22:10:04 yes, doesn't matter Mar 30 22:10:30 I actually have beaglebones with totally broken eMMC, they boot from sd just fine Mar 30 22:11:40 then I guess will try once again to download & check & write the image Mar 30 22:11:41 (regardless, I very much doubt your eMMC is broken, it's probably just not bootable due to partial flashing) Mar 30 22:16:31 also, if the beaglebone is connected to your computer via usb: check if it is detected (as an unknown device type). this indicates bootrom was not able to find a bootable system Mar 30 22:18:41 what exactly do you mean by unknown device type? just checked: it's not shown in neither dmesg nor lsusb Mar 30 22:19:04 hmmm Mar 30 22:19:15 yet no activity whatsoever on the leds other than the power led? Mar 30 22:20:00 nope (also I forgot about ethernet - there is a green light, and also yellow if I connect the cable) Mar 30 22:20:08 yeah ethernet does its own thing Mar 30 22:20:23 okay that's.. odd Mar 30 22:20:48 is it expected that the pc detects the device? Mar 30 22:20:48 okay, next idea: try powering on while holding the S2 button, but without any sd card Mar 30 22:21:02 in this case your pc should *definitely* detect it as a device Mar 30 22:21:17 (specifically an usb network interface) Mar 30 22:21:43 if not, you might not be holding the button down properly (it is a bit finicky) Mar 30 22:22:56 oh, without sdcard but with button it's detected by everything - dmesg, lsusb, ifconfig Mar 30 22:23:15 ok, without powering it down, insert sd card and press the reset button Mar 30 22:24:42 it disappeared from devices, still no leds Mar 30 22:24:43 oh Mar 30 22:25:00 may it be the case that the so-called `console` images don't blink with leds? Mar 30 22:25:27 no, there's always led activity Mar 30 22:25:31 which image did you flash exactly? Mar 30 22:25:43 bone-debian-9.4-console-armhf-2018-03-18-1gb.img.xz Mar 30 22:25:59 it's the latest non-gui I found for 2gb or less Mar 30 22:26:48 if you don't have a big enough sd card for the stretch-iot image, I'm pretty sure you can shrink it down considerably (using resize2fs) before flashing it to sd card Mar 30 22:27:02 iirc there's only a couple of hundred MB in use Mar 30 22:27:11 but still, the console image should work fine too Mar 30 22:27:29 this is really weird, u-boot turns on some usr leds at a pretty early point Mar 30 22:28:52 just checking: you did decompress it before (or as part of) flashing the image to card right? Mar 30 22:29:31 actually never mind, if you didn't then bootrom would never have even attempted to boot it Mar 30 22:29:39 and clearly it does, since it doesn't show up on usb Mar 30 22:29:45 I did xzcat bone-debian-9.4-console-armhf-2018-03-18-1gb.img.xz | dd of=/dev/mmcblk0 bs=1M Mar 30 22:30:29 yeah that's fine (although I'd suggest bs=4M, or just do xzcat ....img.xz >/dev/mmcblk0 ) Mar 30 22:30:58 really weird, it almost sounds like there's a broken u-boot on that image or something Mar 30 22:31:30 the first time, when you were able to boot the image, that was probably without holding down the S2 button? (since it's usually unnecessary) Mar 30 22:31:31 currently flashing another image, older, from the main page: bone-debian-9.4-console-armhf-2018-03-18-1gb.img.xz Mar 30 22:31:54 that's the same image name you gave earlier Mar 30 22:31:57 yes, I didn't hold the button for the first time - then I had a working emmc installation Mar 30 22:32:02 yeah exactly Mar 30 22:32:04 sorry, bone-debian-7.5-2014-05-14-2gb.img.xz Mar 30 22:32:12 so then it used u-boot from eMMC to boot the sd card Mar 30 22:32:46 holy cow that's not "older", that's more like "I did an archeological survey, look what I found!" Mar 30 22:33:03 that's on http://beagleboard.org/latest-images :) Mar 30 22:33:22 and my bbb is older than that anyway Mar 30 22:33:36 yeah well, don't be silly, you don't want wheezy Mar 30 22:33:39 :P Mar 30 22:35:05 so what does the thing about u-boot mean? the image may have wrong u-boot, even though it booted the first time, right? Mar 30 22:35:52 the first time the u-boot on sd card wasn't used at all Mar 30 22:36:14 bootrom prefers to load u-boot from eMMC over uSD (unless you forcibly remove eMMC from the boot order by holding down the S2 button) Mar 30 22:36:44 I'm still not very fluent with all this embedded linux details - is it something like MBR on PC? or /boot/ partition? Mar 30 22:37:43 u-boot is kinda like grub, although it's also kinda like bios since it needs to do platform initialization Mar 30 22:38:06 the boot chain is: bootrom -> SPL -> u-boot -> linux Mar 30 22:38:31 SPL is part of u-boot, it's like a tiny stripped-down u-boot that just initializes RAM and loads the real u-boot Mar 30 22:38:52 they had to do that because u-boot couldn't fit its fat ass in internal SRAM :P Mar 30 22:39:36 anyway, the "maybe there's something wrong with u-boot on that sd card" theory can perhaps be verified by replacing u-boot on the card: https://pastebin.com/wHuaZkWX Mar 30 22:40:05 wow, the other (old) image works Mar 30 22:40:17 leds flash Mar 30 22:40:39 so it's not bricked :) Mar 30 22:41:08 yeah I think there might actually be something wrong with that console image... very few people use those images, and like I said u-boot is usually not even loaded from the card, so it seems quite possible that they managed to publish images with broken u-boot on card Mar 30 22:41:20 for some reason I didn't think to try another image, and that's it Mar 30 22:41:31 because your image booted once Mar 30 22:41:55 you didn't realize that the state of eMMC could be relevant for the bootability of the sd card :) Mar 30 22:42:14 yeah, that's true - thanks for the grub analogy :) Mar 30 22:42:56 so, try the new image but with u-boot replaced using my instructions Mar 30 22:43:43 so, flash the image to sd, then basically replace a part of it using your pastebin commands verbatim? Mar 30 22:43:48 yep Mar 30 22:49:17 or use v2018.03-r5 ... that one I know for sure works, since I recently flashed that to a beaglebone Mar 30 22:50:53 nope, still nothing with separate uboot Mar 30 22:51:08 ... the plot thickens Mar 30 22:51:25 which beaglebone do you have exactly? Mar 30 22:51:37 (revision) Mar 30 22:52:24 at least now I know it's not bricked :) I have an old beaglebone black, don't see the revision printed on the pcb anywhere Mar 30 22:52:42 ~end of 2013 Mar 30 22:53:19 no label either? I think my oldie had a sticker that mentioned the board revision (along with the serial number) Mar 30 22:53:47 (something like "A5A" or whatever) Mar 30 22:59:55 sorry, can't find anywhere :( is there different compatibility? Mar 30 23:00:21 I'm just trying to think of what could possibly be causing your boot issues Mar 30 23:01:23 I don't think the tiny differences between the various board revisions should matter, but maybe I'm overlooking something and some subtle issue is causing failures with recent u-boot on older bbb ? I don't know, I'm just guessing really Mar 30 23:01:37 when I get home I can try it on my A5A Mar 30 23:02:26 and what do you mean by v2018.03-r5? I can't see any images named like that Mar 30 23:02:32 u-boot revision Mar 30 23:02:36 in the two urls Mar 30 23:02:52 oh, it's not the image Mar 30 23:02:54 I see Mar 30 23:03:15 sorry for not being clear Mar 30 23:03:17 I take images from https://rcn-ee.com/rootfs/bb.org/testing/ if that's important Mar 30 23:03:31 should be fine Mar 30 23:03:44 in fact, the image itself is probably fine apart from u-boot, since you had it booting Mar 30 23:03:54 the mystery is just: why is u-boot failing? Mar 30 23:04:38 btw it's not very clear what are the differences between all the images - and I couldn't find it anywhere (like console vs iot, BBB-blank-debian vs bone-debian vs debian) Mar 30 23:04:47 do you know? Mar 30 23:05:23 console is really minimalistic and meant for people who just want a rudimentary base on which they install their own stuff Mar 30 23:06:00 iot is the standard image for most purposes, it doesn't have an x11 gui but it does include bonescript, cloud9, stuff like that Mar 30 23:07:59 bone-debian-*.img.xz is the standalone image (for booting from sd card), while *-blank-debian-*.img.xz are eMMC flasher images Mar 30 23:08:26 debian-*.tar.xz is probably just a tarball of the files on the standalone iamge Mar 30 23:08:27 *image Mar 30 23:24:36 I tried another image (2 gb lxqt), with and without MLO & u-boot from you link - no leds... Mar 30 23:39:21 zmatt: still here? I boot the "old" image from sd, going to flash it to emmc, and then boot a newer one using a working emmc u-boot Mar 30 23:39:26 does that sound right? Mar 30 23:39:40 also I find the revision in the web interface: rev 00A5 Mar 30 23:41:00 it would make more sense to just replace u-boot on the sd card by an older one directly Mar 30 23:41:41 some functionality like u-boot overlays won't work then though Mar 30 23:42:01 A5 ? Mar 30 23:42:06 hmm Mar 30 23:42:08 hmmmm Mar 30 23:42:26 oh wait no, nm Mar 30 23:42:47 okay what was changed between A5 and A5A... Mar 30 23:43:08 the old image looks different than the newer ones - uEnv.txt is located at /boot/uboot/ and doesn't have the line (uncommentable) enable BBB: eMMC Flasher: cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh Mar 30 23:43:22 and there is no script named like this Mar 30 23:43:32 only /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh Mar 30 23:43:34 yeah please try to find at least a newer image that works Mar 30 23:43:50 like what, a year ago? Mar 30 23:43:59 maybe a jessie image or so Mar 30 23:44:11 or just try an old u-boot specifically Mar 30 23:44:24 zmatt: and what's with the revision you say? Mar 30 23:44:56 nah I briefly thought A5 was the one with the wrong SoC variant on it, but that was A4A Mar 30 23:45:55 it doesn't look like there are relevant differences between A5 and A5A... so with a bit of luck the problem will also manifest itself on my A5A Mar 30 23:46:35 maybe try the oldest u-boot in https://rcn-ee.com/repos/bootloader/am335x_boneblack/ Mar 30 23:46:41 i.e. v2015.10-r10 Mar 30 23:46:42 I remember that before flashing I had an image from like ~jan 2017, but can't find a 2gb one from that dates anymore Mar 30 23:47:05 I don't think it's necessary to try whole images Mar 30 23:47:54 since we know that some old u-boot was able to boot the 2018-03-18 console image Mar 30 23:48:32 yeah, u-boot also was like ~jan 2017, I guess (as the whole emmc image) Mar 30 23:48:46 then try an u-boot from around that time Mar 30 23:49:06 once you find a working u-boot revision, you can try bisecting to discover when it broke Mar 30 23:49:38 the seek parameter doesn't change for MLO and u-boot from different dates, right? Mar 30 23:50:35 I'm pretty sure they've always been 256 and 768 Mar 30 23:53:46 for convenience, here's a list of u-boot versions that have both MLO and u-boot.img in that directory, excluding release candidates, sorted by version: https://pastebin.com/raw/adPbLgSM Mar 31 00:02:00 and if the mlo/u-boot I write to sd card have smaller sizes than before, should it work correctly? I mean, there is some area written by "previous" MLO, but not the "new" one Mar 31 00:03:21 oh, doesn't matter Mar 31 00:03:23 doesn't matter Mar 31 00:03:29 wow again! it worked Mar 31 00:03:44 2016.11-r2 works, but 2017.01-r14 doesn't Mar 31 00:04:05 surprising? :) Mar 31 00:04:58 do you know of any changelog or something? Mar 31 00:05:28 I was about to check for differences using git Mar 31 00:06:10 I'll try to narrow the range then Mar 31 00:07:21 actually, hold on Mar 31 00:07:32 hm, no Mar 31 00:10:04 2017.01-r6 works Mar 31 00:10:13 ohh, now that is interesting Mar 31 00:10:51 that makes things a lot simpler Mar 31 00:11:51 r10 also Mar 31 00:13:36 and r12 Mar 31 00:14:56 does iot stretch debian have apache by default? Looks like it might. I wonder how much overhead that is for startup time and memory and if it's worth disabling (I'm not using it) Mar 31 00:15:25 windsurf_: disabling unnecessary services is always useful Mar 31 00:15:52 zmatt: oh, strange - if I flash the same 2017.01-r14, which didn't work, after all other steps - it works (leds blink) Mar 31 00:16:05 aplavin: eh Mar 31 00:18:20 windsurf_: if you want to know what's taking time during startup, do: systemd-analyze plot >boot.svg and study the resulting image Mar 31 00:18:22 but the latest v2018.03-r5 still doesnt Mar 31 00:18:48 thanks zmatt I will Mar 31 00:19:03 aplavin: maybe you messed up the first time you tested 2017.01-r14 ? Mar 31 00:20:08 aplavin: maybe erase eMMC (sudo blkdiscard /dev/mmcblk1) to ensure bootrom will never load u-boot from there (if any is installed). that also means you won't need the S2 button for your tests Mar 31 00:20:18 everything is possible, but I try to be careful Mar 31 00:21:05 windsurf_: here's what I ended up with after a bit of optimization: https://liktaanjeneus.nl/boot.svg Mar 31 00:21:05 zmatt this is fascinating Mar 31 00:23:48 zmatt 5 second startup? Mar 31 00:24:14 mine's 32 Mar 31 00:24:18 from the moment the kernel starts anyway... u-boot itself also takes time Mar 31 00:32:09 zmatt: so, v2018.01-r11 does NOT work, and v2018.01-r10 does Mar 31 00:32:46 oh wow, it broke so recently? Mar 31 00:33:31 in any case, that's good news since even v2017.11 should be fine, it already supports u-boot overlays Mar 31 00:33:35 this time I tried twice (back and forth) so that should be true Mar 31 00:34:59 now only if rcn had bothered to tag the releases in his Bootloader-Builder project -.- Mar 31 00:35:43 unless maybe he did? Mar 31 00:36:17 thanks a lot for helping with this! that's totally not obvious issue as for me Mar 31 00:36:36 indeed Mar 31 00:37:27 and what image do you think is better? take console & install what's needed, or take iot and strip to < 2 gb? I don't need any of the web interface/ide, but do need all the gpio/pru/... Mar 31 00:37:28 r11: am335x_evm: overlay fixups, add MarsBoard AM335X Mar 31 00:38:35 afaik iot is < 2gb ? but regardless, installing stuff you need when you need it is almost always easier than figuring out what you don't need and removing it Mar 31 00:39:35 it says 4gb in filename Mar 31 00:39:36 bone-debian-9.4-iot-armhf-2018-03-18-4gb.img.xz Mar 31 00:40:25 that's the size of the image itself, i.e. the size of the sd card you need if you don't resize the image yourself Mar 31 00:40:45 interesting, why don't they specify 2gb if it fits Mar 31 00:41:07 I don't know honestly Mar 31 00:42:06 so, how do I resize if I don't have an sd card > 2gb? unpack the xz archive, then run resize2fs on the img file? Mar 31 00:44:08 yeah. I have a script that shrinks an image to its min size: https://pastebin.com/YmEnUWdj Mar 31 00:44:45 you probably don't want it min size when booting from it, but you can just expand it to span the sd card after you've flashed it Mar 31 00:45:01 oh crap Mar 31 00:45:12 shrink-image works on a filesystem image, not a card image Mar 31 00:45:15 ehm Mar 31 00:46:43 and do I send a bug report to some u-boot repo? Mar 31 00:46:43 fallocate -c -l 4M filename.img will remove the first 4MB of the file, hence turning the card image into a filesystem image ;) Mar 31 00:47:00 https://github.com/RobertCNelson/Bootloader-Builder Mar 31 00:47:26 then use the script in my pastebin to shrink it to min size Mar 31 00:49:27 then erase card (blkdiscard /dev/mmcblk0), partition it (echo 'start=8192,bootable' | sfdisk /dev/mmcblk0); cat filesystem.img >/dev/mmcblk0p1; resize2fs /dev/mmcblk0p1; install u-boot onto card Mar 31 00:53:36 aplavin: also, you mentioned pruss, so perhaps you're interested in this little project of mine -> https://github.com/mvduin/py-uio/#uio_pruss Mar 31 00:54:37 well, the iot is still a bit too large - 1.9g Mar 31 00:54:41 after shrink Mar 31 00:56:00 and is there anything which isn't easy to install in `console` image while easy in iot? Mar 31 00:56:48 oh wow, how did it get that big? Mar 31 00:56:57 it didn't use to be that fat-ass Mar 31 00:56:59 :) Mar 31 00:57:14 maybe they didn't include e.g. apache before Mar 31 00:57:23 it always had that Mar 31 00:58:24 anyway, just go for console Mar 31 00:58:59 ok, ty Mar 31 00:59:10 it sounded like you didn't need particularly much from the system anyway Mar 31 00:59:15 will flash to emmc then Mar 31 00:59:17 and whatever you need, just apt-get install Mar 31 01:00:08 and as for pru - nice to see that it works even from python! a year or two ago I didn't find anything like this Mar 31 01:01:19 I made this fairly recently... at least the pruss part of it Mar 31 01:02:09 as I understand the whole method of interfacing even with simple stuff like gpio changed, right? Mar 31 01:02:13 I'll probably make a better C/C++ library as well sooner or later, since I don't really use python myself Mar 31 01:02:25 I remember using adafruit bbio library Mar 31 01:02:27 for python Mar 31 01:02:58 well, not really. cape-universal (which has been around for quite a while) is enabled by default nowadays, but that doesn't have much impact on gpios other than that they're exported by default Mar 31 01:03:08 the sysfs gpio interface itself is still unchanged Mar 31 01:03:59 you can also still disable cape-universal and use overlays instead, just like in the olden days, except the overlays are no longer loaded at runtime. instead, u-boot applies them to the main DT before it's passed to the kernel Mar 31 01:04:22 (runtime overlays are actually still supported too, but they're deprecated and will go away) Mar 31 01:05:01 ah, I see Mar 31 01:05:12 I don't like cape-universal myself, but I acknowledge that it's easier for newcomers than messing with DTs Mar 31 01:06:15 I personally do prefer declaring gpios in DT (e.g. https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi), which also lets me initialize them and assign names to them. I then use an udev rule to create symlinks and set permissions (https://pastebin.com/GseLp62B) Mar 31 01:06:36 that way the software using them doesn't have to be privileged nor does it have to know or care about gpio numbers Mar 31 01:15:32 well, another strange thing happens... Mar 31 01:16:03 after flashing, when all 4 leds light up, I remove the sd card and turn off the board Mar 31 01:16:20 then it doesn't turn on without sd Mar 31 01:16:31 oh, the eMMC installer probably installed a bogus u-boot again, so you'll need to boot one last time from sd and use that to install the right u-boot onto eMMC Mar 31 01:16:32 (only power led lights) Mar 31 01:17:01 hm, and doesn't it install the same u-boot as on the sd card? Mar 31 01:17:38 it doesn't extract u-boot from its own boot sectors no, there are probably u-boot.img and MLO files sitting somewhere in the filesystem Mar 31 01:18:21 okay... so I edit uEnv.txt back to non-emmc-flashing mode, boot from this sd card, use the same two dd commands on the emmc? Mar 31 01:19:00 yep Mar 31 01:25:32 finally it boots from emmc :) Mar 31 01:25:37 \o/ **** ENDING LOGGING AT Sat Mar 31 03:00:01 2018