**** BEGIN LOGGING AT Sun Dec 13 02:59:58 2015 Dec 13 04:15:37 hrm. having the same issue with bbb as bbx15 with u-boot 2016.01-rc2 Dec 13 04:15:40 spl: could not find mmc device. error: -19 Dec 13 04:15:41 SPL: failed to boot from all boot devices Dec 13 05:03:32 that mail reminds me again that it's really offensive u-boot produces a file named "MLO" that isn't actually an MLO :/ Dec 13 05:09:15 vagrantc: the failure on BBB is odd.. did it break in mainline or is it broken by one of the patches? Dec 13 05:10:08 wait, did it even work in mainline to begin with.... Dec 13 05:10:11 it's a mainline breakage Dec 13 05:10:28 BBB has worked in mainline for quite some time Dec 13 05:11:06 beagle-x15 supposedly has worked in mainline, but sounds like is missing some important patches Dec 13 05:12:26 * vagrantc wonders if it has to do with a switch to devicetree Dec 13 05:14:29 b4857aa90105ea85bf029f8eb99e72fbadc0e2d0 spl: mmc: Unify non/driver model spl_mmc_find_device() Dec 13 05:14:33 that's my current suspect Dec 13 05:17:54 certainly sounds like a good candidate (by name alone, not in the mood to actually stare at u-boot code) Dec 13 05:18:47 * vagrantc has never liked the boot button on the bbb.... Dec 13 05:19:07 i guess i can try building for the x15 instead... Dec 13 05:20:43 what's the button got to do with anything? Dec 13 05:21:52 well, since i've a non-working u-boot SPL on eMMC, i have to force it to boot from microSD Dec 13 05:23:11 you know you can use a jumper wire too, I use that quite often instead of the button Dec 13 05:23:19 I actually have a Dec 13 05:23:26 oh, that'd be nice. Dec 13 05:23:46 whereabouts? Dec 13 05:24:11 I actually have a jumper wire with integrated resistor for the purpose, in case it boots into an OS that configures the sysboot pins as outputs Dec 13 05:25:09 sysboot2 (aka lcd_data2) @ P8.43 to ground Dec 13 05:26:02 it's safe to use a wire with basic HDMI-disabled device trees Dec 13 05:26:36 i'll probably just struggle with the boot button some more. Dec 13 05:26:39 :) Dec 13 05:29:05 I also made a little tool for those buttons by blunting the point on one of those things -> http://images.hema.nl/products/tapas-prikkers-80881023-productzoom_rd.jpg Dec 13 05:30:01 oh, yes, a toothpick might make it easier to poke, at least Dec 13 05:30:08 nice suggestion Dec 13 05:30:43 something flat-ended (like the backside of those things) works quite well too Dec 13 05:33:56 so it works on SD card but not on eMMC? (I'm assuming you tested it on card before flashing to eMMC) Dec 13 05:37:36 you and your assumptions. Dec 13 05:37:57 i've had updates go so smoothly for so long i've just been writing to eMMC ... wheee. Dec 13 05:38:37 * vagrantc should get on a microSD card susbscription service Dec 13 05:39:26 lol Dec 13 05:41:08 I should finish my own a bootloader... I really don't like u-boot Dec 13 05:45:26 it's got a unixy charm about it ... which maybe doesn't win everyone over Dec 13 05:46:20 a unixy charm.. lol Dec 13 05:56:53 well, reverting that patch got me into u-boot itself Dec 13 05:58:42 though it didn't automatically boot Dec 13 05:58:46 so hrm. Dec 13 05:59:01 and now, it's CCCCC Dec 13 05:59:32 and inserting the SD works fine... Dec 13 05:59:39 well, ish Dec 13 06:00:40 ah, the old mmcblk0/mmcblk1 switcheroo depending on weather you have SD inserted or not. Dec 13 06:01:24 nope, the emmc is borked. Dec 13 06:11:33 "programming" the emmc with a screwdriver isn't recommended Dec 13 06:13:00 but I don't think you can 'break' it via software .. Dec 13 06:21:01 well, after trying to re-image with the old version, it still gives me the CCCCC... thing trying to boot from serial or something? Dec 13 06:21:31 so the new version of u-boot did something extra to the emmc ... Dec 13 06:51:11 well that's odd. Dec 13 07:22:33 please don't tell me they copied the kernel's behaviour of numbering mmc devices in order of discovery :P Dec 13 07:24:56 Hi Dec 13 07:25:19 I need help learning to write i2c device driver Dec 13 07:25:39 I am using am335x TRM Dec 13 07:26:00 I feel sorry for you already Dec 13 07:26:07 and trying to write linux device driver for i2c Dec 13 07:26:26 why? linux already has one obviously Dec 13 07:26:44 yes it has Dec 13 07:26:53 I just want to learn Dec 13 07:27:12 try a different processor .. like .. I dunno .. Dec 13 07:27:17 somethign that don't run linux :) Dec 13 07:27:23 pick a different peripheral... i2c is horrible Dec 13 07:27:40 zmatt .. i2c is fine .. there's no 'good' protocol :p Dec 13 07:27:45 using i2c i could learn a lot Dec 13 07:27:46 veremit: the peripheral Dec 13 07:28:00 i2c and spi are both prolific Dec 13 07:28:09 veremit: I'm not talking about the protocol Dec 13 07:28:20 New apparently wants to learn device driver programming Dec 13 07:28:20 eh Dec 13 07:28:29 by writing a driver for some peripheral Dec 13 07:28:31 -shrug- Dec 13 07:28:35 New: am I right? Dec 13 07:28:39 yes Dec 13 07:28:43 exactly Dec 13 07:29:05 i am having trouble mapping register to ram addressing Dec 13 07:29:12 adress mapping Dec 13 07:29:21 i used i2c1 Dec 13 07:29:30 address : 4802a000 Dec 13 07:29:46 i did ioremap Dec 13 07:29:52 this is not a "linux device driver tutorial" channel though Dec 13 07:30:11 note that you should not hardcode the addres Dec 13 07:30:15 it comes from device tree Dec 13 07:30:23 ok Dec 13 07:30:43 when using DT the kernel will take care of a number of things for you Dec 13 07:31:10 like also making sure the module you're using is actually enabled Dec 13 07:31:33 (this happens via the "ti,hwmods" properties, I don't know really what magic is involved) Dec 13 07:31:49 New: other than that I can't really help you though since I'm no kernel developer Dec 13 07:31:51 Still I was able to get address 4802a000-4802afff in /proc/ioremp as my_device Dec 13 07:32:05 New: other than recommending a different peripheral than i2c to practice on Dec 13 07:32:09 but when i tried ioread32 from that address it gives Unable to handle kernel paging request at virtual address 4802a000 Dec 13 07:32:44 which means you didn't use the virtual address obtained from ioremap Dec 13 07:32:51 but the physical address Dec 13 07:33:23 but again, this isn't a channel to help you with basics of linux kernel programming Dec 13 07:33:57 So what should i do now Dec 13 07:34:36 I have no idea, I personally find the linux kernel a rather hostile place to program in and avoid it myself Dec 13 07:36:41 I have no problem with baremetal (no-OS) programming, and directly accessing peripherals from userspace is also easy, but kernel drivers are... a bit intimidating Dec 13 07:38:06 you continuously have to pay attention that you're playing by the kernel's rules... which moreover seem to change all the time due to rapid development Dec 13 07:39:19 documentation is often missing, or obsolete Dec 13 07:40:45 so I personally leave kernel programming to those who do it on a daily basis and keep up with what's going on in that thing... I'm so far perfectly happy with doing things from userspace Dec 13 11:10:59 hello everyone i have a new cape for beaglebone black Dec 13 11:11:34 i wanted to know about the software by which i can design it Dec 13 11:12:33 eagle, kicad, ... - choose your poison Dec 13 11:12:49 thankyou Dec 13 11:14:58 I get the impression the quality of life of my coworkers involved in hardware design significantly improved when we acquired an Altium license Dec 13 11:15:24 mine too actually, when receiving PDFs of schematics to review :P Dec 13 12:57:14 What were you using before that? Dec 13 12:57:52 IE before altium was "orcad DOS" or something? Dec 13 12:58:24 a mix of things I think... eagle, designspark Dec 13 12:59:43 free and crap :P Dec 13 13:01:25 hmmh Dec 13 13:01:32 there seems to be some problems in usb hotplug :( Dec 13 13:01:36 any workarounds for that? Dec 13 13:01:39 (in BBB) Dec 13 13:02:03 try random things Dec 13 13:02:21 use different cable, insert a hub, upgrade kernel Dec 13 13:02:34 nope, nope and nope :) Dec 13 13:02:46 sacrifice a black goat, who knows it might work Dec 13 13:03:04 define "problems in usb hotplug" Dec 13 13:05:24 zmatt you mention eagle that pretty much sumarizes it LOL, don't forget exorcism can't hurt ... USB issues. Dec 13 13:07:40 GenTooMan: apparently designspark pcb is fun too... exporting to whatever format the pcb shop needed apparently resulted in sufficient roundoff error to cause all sorts of constraint violations Dec 13 13:07:55 trace width/distance stuff Dec 13 13:10:44 zmatt: problems like if I have a device connected at boot, taking the device out makes the lsusb still show the device Dec 13 13:10:52 and replugging the device gives dmesg errors Dec 13 13:10:57 Error -110 Dec 13 13:11:21 ok that sounds weird above and beyond the usual usb problems Dec 13 13:11:25 also some usb flash sticks are only detected once and hotplug stops working Dec 13 13:11:36 after reboot it works again once Dec 13 13:11:57 updated kernel from 3.8 to 3.12 but it didn't change anything Dec 13 13:12:01 and it happens on 3 different boards Dec 13 13:12:18 3.12 is still very ancient Dec 13 13:12:19 Rev B6 Dec 13 13:12:41 try 4.1.13-ti-r36 Dec 13 13:13:43 I really can't imagine how unplugging a device could go unnoticed, that's really quite weird Dec 13 13:14:01 you want to know what's even weirder? Dec 13 13:14:07 have a kernel log to show? (pastebin) Dec 13 13:14:08 it works if I power BBB from usb Dec 13 13:14:17 currently no, I'm at the wrong office :) Dec 13 13:14:30 but if BBB is powered from DC jack or from cape, it doesn't work Dec 13 13:15:07 any chance the supplies are inadequate? (though that's usually more commonly a problem when powering via usb...) Dec 13 13:15:36 no Dec 13 13:15:45 even tried with lab power Dec 13 13:16:07 5V 1000A supply that should work! Dec 13 13:17:09 Jartza: one thing to try: using an usb charger, i.e. power via usb but no actual usb host connection Dec 13 13:17:26 well this lab-power can "only" supply up to 10A, but still :) Dec 13 13:17:27 it could be that the presence of the host connection is somehow affecting the driver Dec 13 13:17:56 especially since the two ports are in a single subsystem Dec 13 13:18:36 (a subsystem that also happens to be a crawling horror) Dec 13 13:18:39 now I have to say I can't remember if I used usb-charger or host connection Dec 13 13:18:45 I need to check that when I get home Dec 13 13:19:34 so that's one thing you can try Dec 13 13:20:16 also try the latest stable ti (4.1.13-ti-r36) and/or bone (4.3.2-bone2) kernel Dec 13 13:20:28 yea Dec 13 13:21:11 save kernel logs obviously Dec 13 13:22:18 but dunno, lots of people seem to have trouble, but usb has been working just fine for us, it's weird Dec 13 13:23:05 you mentioned powering from cape... custom? Dec 13 13:23:40 I should note that I've seen reeaaaly inexplicable things happening somehow as a result of external connections Dec 13 13:26:30 like we had an lcd screen connected via an LVDS framer, and if its backlight was still on when you tried to shutdown (it's not allowed to be, I will admit that), then the BBB would immediately power on again after power off Dec 13 13:27:46 even though I can't imagine how exactly power to the backlight would manage to accomplish this... via the lvds interface? back through the framer? to the lcd data pins? which themselves have no reason to be able to trigger a power up? Dec 13 13:29:46 it would be nice to have magic glasses that allow you to *see* current flowing Dec 13 13:40:32 sounds too me a potential ground loop / ground level issue. LVDS signals that are 'straight' through can have issues if the absolute voltage pushes things into the edge of the receivers. Since the 'grounds' between connected equipement can get squirelly. things can get messy. This is why they oft stuff a few caps into the lines between systems when using LVDS. Dec 13 13:41:58 with the minor detail that you can't capacitively couple LVDS... it's not DC balanced Dec 13 13:43:33 but sure I already assumed currents were flowing in ways they really ought not to be.... going from there to explaining the actual power-up still requires significant handwaving Dec 13 13:44:04 * GenTooMan gives zmatt the wand of 'weird currents' Dec 13 13:45:09 I acidentally powered a low power device once from a RS232 level shifter that was leaking current into the circuit. "what the heck" is all I can say. Dec 13 13:45:49 Just takes a few micro amps... Dec 13 13:45:49 yeah I've also seen an interesting case of a device being powered through the ftdi serial cable attached to it Dec 13 13:46:10 or well, not the device, just the (low-power pic) processor Dec 13 13:46:20 hence why a low power reset circuit is a good thing. Dec 13 13:46:48 yeah they were too lazy to enable the brownout detector Dec 13 13:47:10 and that serial port should have had some kind of isolation Dec 13 13:47:20 especially since it was an end-user one, not debug Dec 13 13:47:51 I also now have a BBB with an interesting problem Dec 13 13:48:18 I assumed it was entirely dead since it gave the power led blip of doom Dec 13 13:49:05 but then I discovered it only did that when usb powered, it came up on dc power ... it didn't boot, but I didn't remember whether it was bootable to begin with Dec 13 13:55:16 http://gerbil.xs4all.nl/bbb-powerup/ here are scope pics of powerup via dc jack and (failed) powerup via usb Dec 13 13:55:46 yellow = 3v3a, green = sys_5v, blue = 1v8, pink = 3v3b Dec 13 13:57:06 try to spot the issue :P Dec 13 16:14:18 voltage looks a bit low on the 3.3vb like 1.5V that happen on reset normally? Dec 13 16:51:08 on the USB it appears 5V shuts off and 3.3A comes next (cascade) still showing 3.3b at 1.5V are you sure that's not the processor power? Dec 13 17:22:35 zmatt: yea, custom cape with power ic (undervoltage/overvoltage/overcurrent/reverse polarity/overtemp/whatnot protection) Dec 13 17:27:01 but I doubt any power-problems Dec 13 19:25:10 Jartza: in fact it is very clear something on the 3v3b is drawing in insane amount of current Dec 13 19:26:44 which is interesting, since that greatly reduces the candidates Dec 13 19:27:03 oh sorry differnt conversion Dec 13 19:28:02 Jartza: yeah I'm not saying power problems with your cape, rather that it might influence USB in some magical non-obvious way... are the issues also present when capeless? Dec 13 19:28:19 *different conversation Dec 13 19:28:36 * zmatt needs caffeine... Dec 13 20:19:37 zmatt: yeah... I updated the kernel to 4.1.12-ti-r29 and it seems the usb is at least somehow fixed :) Dec 13 20:19:47 that version came with debian 8 update Dec 13 22:22:46 hi Dec 13 22:22:52 i need help Dec 13 22:23:31 i want to make alarm clock using beaglebone and 7 segment display Dec 13 22:23:39 can anybody help? Dec 13 22:23:58 please Dec 13 23:07:16 KotH: long time no speak! how is .ch? Dec 13 23:11:38 <_av500_> ah, the kiwi Dec 14 01:33:49 * zmatt yawns Dec 14 01:35:45 ugh Dec 14 01:35:50 (waking up with headache)-- Dec 14 01:37:59 I really wonder what the hell is shorting the 3v3b to ground on this BBB ... http://gerbil.xs4all.nl/bbb-powerup/hoover-dc-zoom.png Dec 14 01:38:22 funny enough it was still sufficiently alive to see ROM attempting to uart-boot (CCCC) Dec 14 01:42:15 so, something happened to the eMMC on the beaglebone black while testing u-boot 2016.01-rc2... and it does the ... heh... the CCCCC thing indefinitely when booting from eMMC now Dec 14 01:42:52 booting from SD works, but it issues odd errors ... is there a way to reset the eMMC to factory defaults? Dec 14 01:42:53 vagrantc: that means ROM doesn't think eMMC is bootable Dec 14 01:43:12 define "odd errors" Dec 14 01:43:35 U-Boot SPL 2016.01-rc1+dfsg1-1~20151213~2 (Dec 14 2015 - 01:35:01) Dec 14 01:43:35 MMC: block number 0x100 exceeds max(0x0) Dec 14 01:43:35 MMC: block number 0x200 exceeds max(0x0) Dec 14 01:43:35 *** Error - No Valid Environment Area found Dec 14 01:43:35 *** Warning - bad CRC, using default environment Dec 14 01:44:16 but you "booting from SD works" ? Dec 14 01:44:30 that is booting from SD Dec 14 01:44:42 it doesn't continue beyond that? Dec 14 01:44:53 but it doesn't have bootdelay set ... so doesn't autoboot Dec 14 01:45:06 which is odd, because the default environment has autoboot set Dec 14 01:45:09 can you try SD-booting a known-good image? Dec 14 01:45:36 instead of one that has your funky 2016 u-boot Dec 14 01:45:37 a very reasonable suggestion... Dec 14 01:46:00 in general, I wouldn't trust sent back in time from the future Dec 14 01:46:05 *trust software Dec 14 01:46:11 although u-boot 2015.10+dfsg1-4 has the same issue, but was working fine before this happened Dec 14 01:46:35 zmatt: it's a release-candidate for a release that comes out in a month. Dec 14 01:46:46 I understand, I was just joking Dec 14 01:46:50 ah. Dec 14 01:47:13 * vagrantc looks for a small known-good image Dec 14 01:47:16 I think normally the sd-u-boot should not be examining eMMC, but I don't know whether that's actually true Dec 14 01:47:28 or wait Dec 14 01:47:35 are you in an u-boot prompt>? Dec 14 01:48:09 i could get to one, sure. Dec 14 01:48:27 any suggestions for a minimal console-only working image? Dec 14 01:48:30 ums 0 mmc 1 Dec 14 01:48:49 yeah, rcn-ee's console images Dec 14 01:49:38 you can also use one of his flashers instead to restore eMMC Dec 14 01:49:52 ideally, i'd like to get out of this with the rootfs on eMMC not purged, but it's easily replaceable if i have to wipe it clean Dec 14 01:50:14 ah, then I'd use u-boot's ums mode Dec 14 01:50:35 if you want I can extract a known-good u-boot you can write onto sd card Dec 14 01:51:11 or use BBBlfs, that tool has been a lifesaver for me Dec 14 01:51:12 i've tried with versions i've used in the past, and it still exhibit the same behavior Dec 14 01:51:33 somehow, something trashed somehting on the eMMC Dec 14 01:51:42 then try BBBlfs, its u-boot doesn't give a shit about eMMC Dec 14 01:53:34 assuming you've never used it yet, here are the instructions for use: Dec 14 01:54:11 clone https://github.com/ungureanuvladvictor/BBBlfs and compile it Dec 14 01:54:23 ignore the bundled scripts, they're really bad and broken Dec 14 01:54:56 go to the bin/ subdirectory Dec 14 01:55:02 oddly enough, booting from SD card boots to the eMMC rootfs ... :) Dec 14 01:55:13 oh Dec 14 01:55:19 then you're fine Dec 14 01:55:27 so the eMMC is "working" ... just not u-boot from eMMC Dec 14 01:55:39 you can repair u-boot on eMMC from here Dec 14 01:56:17 also, it means your rootfs and/or u-boot is ancient and doesn't use uuid to identify the filesytem Dec 14 01:56:25 so, i've dd'ed a known-good version to the eMMC and it just does CCCCC until i plugin the SD Dec 14 01:56:44 it's definitely using UUID to identify the filesystem Dec 14 01:57:28 ok, I suppose that's possible too Dec 14 01:57:54 it's using distro_bootcmd to load the first boot.scr it finds, and there's no boot.scr on the SD Dec 14 01:58:38 how does u-boot decide whether to boot eMMC or SD anyway? I mean, in theory it can know where it came from itself, but I don't think I've ever seen such logic in it Dec 14 01:58:40 also, SD loads it's environment from the eMMC regardless of what's in SD.... which brings up an interesting point Dec 14 01:58:58 environment was invalid though wasn't it? Dec 14 01:59:03 it usually is Dec 14 01:59:13 i did run saveenv at some point ... Dec 14 01:59:17 ah Dec 14 01:59:22 well first things first Dec 14 01:59:24 hoping that would "fix" the issue Dec 14 01:59:40 since CCCC means you don't even have a valid configuration header Dec 14 01:59:50 and ROM doesn't consider eMMC bootable as a result Dec 14 02:00:07 i'll put the u-boot version on the SD from before this issue occurred, run saveenv ... see if that fixes anything Dec 14 02:00:20 wait Dec 14 02:00:29 let's first examine the situation :P Dec 14 02:01:05 * vagrantc has been examining on and off again for 24 hours... :) Dec 14 02:01:21 can you do dd if=/dev/mmcblk$n seek=256 count=1 | hexdump -C Dec 14 02:01:27 where $n is whatever the eMMC is Dec 14 02:01:36 1 presumably, since you also had SD card inserted Dec 14 02:01:43 i want to get to a point where i can git bisect the commits where the SPL got all fscked. Dec 14 02:01:46 ehh Dec 14 02:01:48 skip I mean Dec 14 02:01:49 not seek Dec 14 02:01:50 ah, that's a good idea. Dec 14 02:01:57 seek is for the output Dec 14 02:02:47 since I've seen u-boot produce an "MLO" that's not actually a valid MLO but already had a configuration header (padded to 512 bytes) prepended Dec 14 02:03:08 at one point i figured out how to erase the part on the emmc where it stores the u-boot env ... will need to do that once this is all over so i can test the defaults reliably Dec 14 02:03:42 I think it used to save it in mmcblk$nboot1 but not sure if that's still true Dec 14 02:03:48 zmatt: ok, so dd if=/dev/mmcblkX skip=256 count=1 | hexdump -C Dec 14 02:03:50 ?? Dec 14 02:03:56 yes Dec 14 02:05:03 zmatt: well, output is identical for both /dev/mmcblk1 and /dev/mmcblk0 Dec 14 02:05:14 something involving CHSETTINGS Dec 14 02:05:30 (unless it's managed to be a sha256 hash collision) Dec 14 02:06:01 it should not need sha256 for comparison Dec 14 02:06:07 it should look very simple and clean Dec 14 02:06:22 it looks like a bunch of numbers :P Dec 14 02:06:32 i wanted to look at it in a way where i could verify they were identical Dec 14 02:06:45 http://pastebin.com/AdB3iCWJ Dec 14 02:07:08 that's what should be there Dec 14 02:07:38 ROM looks for that header in sectors 0, 256, 512, 768 (in that order) Dec 14 02:07:54 http://paste.debian.net/343921/ Dec 14 02:07:57 and if it fails to find one, proceeds to try to locate a bootable FAT partition Dec 14 02:08:19 long ago abandoned the bootable FAT partitions... Dec 14 02:08:55 ok, paste a hexdump of the next sector for me? (I only care about the first 8 bytes thereof) Dec 14 02:09:13 512? Dec 14 02:09:18 or 257? Dec 14 02:09:18 no Dec 14 02:09:21 257 Dec 14 02:10:09 when ROM finds a sector with a configuration header, it expects the real MLO to begin in the next sector Dec 14 02:10:22 http://paste.debian.net/343922 Dec 14 02:10:24 which has a header of two 32-bit integers Dec 14 02:11:23 ok, it requests loading 0x1165c bytes to 0x402f0400 Dec 14 02:11:29 there were pretty major changes in SPL MMC handling between u-boot 2016.01-rc1 and 2016.01-rc2 Dec 14 02:11:45 zmatt: any further diagnosis? Dec 14 02:11:54 that fits Dec 14 02:12:04 that's no reason for ROM for reject this as non-bootable Dec 14 02:12:34 SPL should be loaded and executed Dec 14 02:12:47 it's a y2k16 error. Dec 14 02:12:59 so where on earth would the CCC come from... Dec 14 02:13:05 since that's what you got right? Dec 14 02:13:26 yup, without the SD inserted... it prints C indefinitely ... Dec 14 02:13:52 which i've always been able to recover from before by booting from SD and dd'ing a known good version to eMMC Dec 14 02:14:20 ohh wait, SPL supports YMODEM as fallback doesn't it? Dec 14 02:14:35 maybe the CCCC isn't coming from ROM at all but from SPL Dec 14 02:14:50 could be... but why? Dec 14 02:15:15 wouldn't it first print the SPL data, though? Dec 14 02:15:21 right Dec 14 02:15:36 e.g. U-Boot SPL 2016.01-rc1+dfsg1-1~20151213~2 (Dec 14 2015 - 01:35:01) Dec 14 02:15:45 * zmatt scratches head Dec 14 02:15:51 this is really odd Dec 14 02:16:19 ROM doesn't check many things before declaring something to be bootable Dec 14 02:16:31 and once it executes something, that's the point of no return Dec 14 02:16:59 so if eMMC looks even remotely bootable, you should not be getting CCCC Dec 14 02:17:11 assuming you didn't accidently power up with the SD button held :P Dec 14 02:17:31 toothpick worked great, BTW Dec 14 02:18:11 i started off planning to work on getting a recent version of u-boot on the bx15, and now i'm back to debugging a BBB Dec 14 02:18:19 this is one of those situations where JTAG would immediately tell you at which point things are going wrong Dec 14 02:19:23 serial is about as fancy as i've gotten Dec 14 02:19:46 ... can you package up the first 4 MB of your eMMC for me? Dec 14 02:20:01 I have a BBB with jtag header Dec 14 02:21:18 just dd if=/dev/mmcblk1 of=foo.img bs=1024k count=4 ? Dec 14 02:21:27 yeah Dec 14 02:21:54 if your first partition starts at 1 MB then 1 MB suffices of course (though really it ought to start at 4 MB) Dec 14 02:22:02 i did just switch back to 2015.10 ... in which it is slightly less broken, but still pretty good and borked Dec 14 02:22:22 just confirm whether it's still CCCCCing at you Dec 14 02:22:25 though i can switch back to a more broken version pretty easily Dec 14 02:23:01 yup, still CCCC Dec 14 02:23:14 since breakage inside the u-boot mess is something I can't bring myself to care about, but the CCCC intrigues me Dec 14 02:24:14 alright ... thanks for being intrigued Dec 14 02:24:39 i've got a spare BBB which probably doesn't exhibit this issue yet ... i can probably debug with that... :) Dec 14 02:28:31 zmatt: https://www.aikidev.net/~vagrant/bbb-borked.img.xz Dec 14 02:29:21 i guess xz didn't matter much Dec 14 02:29:22 heh Dec 14 02:34:56 downloaded it Dec 14 02:36:10 have fun with broken! Dec 14 02:36:24 * vagrantc digs up the spare bbb for more breakaging Dec 14 02:36:25 right I'm trying to see how to get BBBlfs to work again now that I switched from NetworkManager to systemd-networkd ... i already knew BBBlfs implicitly relied on NetworkManager initializing the RNDIS interface, I know have confirmation of that fact since it doesn't work anymore Dec 14 02:36:51 (it previously failed to work on a server with just ifupdown and one someone's Arch laptop which probably also didn't have NetworkManager) Dec 14 02:38:36 whoah. WAT. Dec 14 02:38:52 ok, so it behaves differently from a cold boot and a warm reboot Dec 14 02:39:05 you mean you *did* power up with SD button held? Dec 14 02:39:06 :P Dec 14 02:39:22 mystery solved Dec 14 02:39:33 no, didn't boot with the SD button held... Dec 14 02:40:12 note I said "power up", not "boot" Dec 14 02:40:37 but, what then did you just observe? Dec 14 02:40:51 unless it can be held without touching it, i've cold booted it at least 3 times since it started exhibiting this behavior Dec 14 02:41:02 ok Dec 14 02:41:04 it booted off the eMMC fine now. Dec 14 02:41:20 after installing an older u-boot version (2015.10) Dec 14 02:41:45 and saveenv and all that nastiness. Dec 14 02:41:56 eesh... how can i wipe saveenv Dec 14 02:42:08 i think i've emailed it somewhere Dec 14 02:42:19 mmcblkXbootY Dec 14 02:42:46 I forgot which of the two boot partititions, just wipe 'em both Dec 14 02:43:30 i've never been able to wipe them from linux, it's read-only Dec 14 02:43:44 huh Dec 14 02:44:02 they shouldn't be... I've been able to write them just fine Dec 14 02:44:26 sudo dd if=/dev/zero of=/dev/mmcblk0boot0 Dec 14 02:44:27 dd: writing to ‘/dev/mmcblk0boot0’: Operation not permitted Dec 14 02:45:26 i did eventually figure out how to wipe it from u-boot at some point ... but guess i didn't document that in any useful place. Dec 14 02:45:33 clearenv ? Dec 14 02:45:34 mmc erase or something Dec 14 02:46:53 no clearenv or env clear Dec 14 02:47:45 lol, ok running this in a separate terminal makes BBBlfs work again: Dec 14 02:47:54 while sleep 0.1; do ip link set usb0 up; done Dec 14 02:48:34 that tool is.. brittle Dec 14 02:54:32 * vagrantc kicks self Dec 14 02:58:09 ok, 2016.01-rc1 kinda works bootdelay seems to have no effect. **** ENDING LOGGING AT Mon Dec 14 02:59:58 2015