00:48 <rcn-ee_> jgnoss, for now just use stretch..

01:28 <jgnoss> thanks for the info

01:29 <jgnoss> is that guide at https://elinux.org/BeagleBoneBlack/SGX_%2B_Qt_EGLFS_%2B_Weston#Install_Graphic_SDK still valid for stretch

09:43 <Duality> hi

09:46 <Duality> anyone know what this is: l4_wkup_cm:clk:0010:0: failed to disable

09:47 <Duality> not sure if this is a problem or not but it is reported as an error in my dmesg

12:07 <zmatt> Duality: it's not a problem

12:07 <zmatt> like, it's technically a bug but it won't cause any problems

12:08 <zmatt> "timer_probe: no matching timers found" and "omap_voltage_late_init: Voltage driver support not added" are also not problems nor even bugs, or rather the bug is that these messages are erroneously generated :P

13:08 <busterswt> Hi folks - I've got a handful of PocketBeagle devices that are exhibiting an issue where when powered on, the PWR led will turn on but the 4x USR leds will not blink. Essentially, it's not booting. But that same SD card can boot another PB. When the PB is connected to a machine w/o an SD card installed, it shows up in the list of connected USB

13:08 <busterswt> devices. When the SD card is installed, it does not show up. If you leave it plugged in, the CPU gets pretty warm. I'm at a loss here as to what might be causing this. In some cases, the device booted successfully once or twice, and then no more. Any suggestions on where to look?

14:44 <kveremitz> rcn-ee_: wtb beagle.org image bumps pl0x :) I see the digikey tech forum (eewiki successor) is all up-to-date :)

14:44 <kveremitz> thanks for that, as always :D

15:04 <busterswt> Does anyone know if there was a change in the way serial numbers are reported on a given device? I have many pocket beagles here with the same 5 digit code on their CPU, and reporting the same serial number within bonescript.

15:49 <zmatt> an sd card booting some pocketbeagles but not others does sound weird

15:52 <zmatt> the AM335x getting warm if boot is hanging sounds normal, since that generally means there will be continuous 100% cpu load

15:52 <zmatt> have you tried to see if anything useful shows up on the serial console?

15:55 <busterswt> In the case where it won't boot from SD, nothing shows up on the serial console

15:56 <busterswt> the PWR light is on, but USR lights are off. I'm able to shut down the unit by holding PWR button for about 8-10 secs

15:56 <busterswt> On units that boot, I see console activity pretty quick;ly

15:59 <zmatt> hm

15:59 <zmatt> what's on the sd card, a stock image or a custom image?

16:00 <busterswt> stock image, in this case

16:00 <zmatt> are these new pocketbeagles or have they previously had hardware connected to them via the expansion headers?

16:01 <zmatt> (or any other opportunity for receiving some sort of hardware damage)

16:05 <zmatt> though hardware damage sounds odd given you mentioned they do show up via usb when no sd card is present

16:07 <busterswt> I do believe the working and non-working ones have all been connected to the same custom board(s) that use level shifters for 5V->3.3V

16:08 <busterswt> and in one case, a unit was working fine and was properly shut down, then a subsequent start would fail in the way described earlier

16:08 <zmatt> and the fact boot hangs if (and only if) an sd card is present means bootrom was actually able to load the MLO (containing u-boot SPL), or at least it thinks it did... otherwise it would just have fallen back to the next boot device (same as when no sd card is present), i.e. it would show up via usb

16:08 <zmatt> hmm

16:09 <zmatt> that would definitely make me suspicious of the external hardware, and particularly how it behaves during power-up and power-down

16:09 <busterswt> agreed

16:10 <busterswt> i powered up one that failed yesterday, and the USR lights happened to flash, but hung - nothing on serial console. and now it's back to its old tricks

16:10 <busterswt> so, i dunno.

16:11 <busterswt> regarding the serial numbers... should i be concerned that of the 8-10 17414 units I have all show a serial number of 1741GPB4 inside the OS?

16:12 <zmatt> recently a colleague managed to fry a beaglebone such that it crashed during very early boot (sometimes before u-boot, sometimes during u-boot, very rarely during early kernel) ... still have no idea how he managed to accomplish that

16:12 <busterswt> yeah, it is the strangest thing. i can have other PBs connected to the same external hardware and they work fine. and they continue to work OK.

16:12 <zmatt> it wouldn't be the first time a manufacturer fucks up serial numbers unfortunately. I do recommend reporting it to the manufacturer and/or to jkridner

16:13 <busterswt> I'm assuming the manufacturer is not the vendor? These did come from an approved vendor, fwiw

16:15 <zmatt> I guess you should report it to the distributor and have them report it upstream... to exclude software issues first check the raw eeprom contents with: head -c 64 /sys/bus/nvmem/devices/0-00500/nvmem | hexdump -C

16:15 <busterswt> ok sure, i can do that.

16:15 <busterswt> thanks for letting me bounce this off you

16:20 <busterswt> two different units reporting those same eprom contents, btw

16:20 <zmatt> okay yep, that would be a manufacturer screw-up

16:21 <zmatt> in our db of BBBs I have one pair with the same serial number

16:21 <busterswt> cool, i'll report it up the chain. thanks

16:21 <zmatt> also 49 units that claims to be BeagleBone Black Industrial even though they're definitely not

16:22 <busterswt> oy

16:23 <zmatt> at least those don't differ from the regular BBB in a way that matters to software

16:24 <zmatt> so it's not as bad as the batch of BeagleBone Black Wireless devices whose eeprom claimed to be a regular BeagleBone Black, which definitely _doesn't_ use the same device tree :P

16:24 <busterswt> so what i'm hearing is, it's the wild west out there

16:24 <zmatt> like, in absolute numbers it doesn't happen often, but still more often than it should

16:24 <busterswt> sure

16:25 <zmatt> it's just often not noticed... except for the BBBW thing anyway :P

16:25 <busterswt> you guys provide a reference arch and then the manufacturer may or may not put some spin on it?

16:26 <zmatt> I'm not with beagleboard.org

16:26 <zmatt> I'm just a beaglebone user

16:26 <busterswt> ahh ok

16:28 <zmatt> but no, manufacturers can't just put a "spin on it", at least not without calling it something else

16:30 <zmatt> since although the design is open, you still can't use the trademarks without approval... https://beagleboard.org/logo#manufacturer

16:30 <busterswt> gotcha.