**** BEGIN LOGGING AT Mon Jul 27 02:59:58 2015 Jul 27 04:51:41 Hi Jul 27 04:52:29 I want to know, Can I flash the emmc using tftp server? Jul 27 04:53:31 Any one? Jul 27 04:54:38 depends Jul 27 04:55:28 you can, though I'm not sure anyone has a ready-to-go setup for that Jul 27 04:56:11 Guest29846: I've use netbooting for baremetal applications succesfully Jul 27 04:57:48 however that's just ROM directly netbooting the application Jul 27 04:58:33 for flashing you'd have ROM netbooting u-boot (hopefully you can build a sufficiently small version to avoid the need for an SPL) Jul 27 04:58:57 which would need to be preconfigured to netboot the kernel Jul 27 04:59:31 and you'd need an NFS server hosting the root filesystem containing the eMMC flasher Jul 27 05:00:18 definitely a non-trivial exercise, though once setup it definitely yields a pretty chill way to (re)flash a BBB\ Jul 27 05:00:48 I once made such a setup for a dm814x Jul 27 05:02:09 not for reflashing but just for kernel/bootloader development: edit & compile on my laptop, press reset button on the target which fetches the newly compiled version straight from my laptop Jul 27 05:02:27 (big bonus: unbrickable setup) Jul 27 05:03:43 the simplest way to host BOOTP + TFTP btw is using dnsmasq Jul 27 05:03:52 much simpler than more descriptions I've seen on the net Jul 27 05:16:04 note BTW that USB-booting works exactly the same as Ethernet booting, except via RNDIS Jul 27 05:21:44 * zmatt hunts for the resistor he needs to verify his setup actually still works Jul 27 05:30:33 Guest29846: my dnsmasq config for this purpose -> http://gerbil.xs4all.nl/dnsmasq-bbb.conf Jul 27 05:34:29 that should take care of getting u-boot (or SPL if used) onto the beaglebone if you configure it for netbooting (pull sysboot0 up, pull sysboot2 down) Jul 27 05:34:49 the rest is left as exercise for the reader ;P Jul 27 06:01:17 Hi Jul 27 06:01:31 Does beaglebone supports Android Jul 27 06:02:16 when I did some googling - I saw the support for beaglebone with respect to Android started (and stopped) at Jelly bean Jul 27 06:02:25 Is there any specific reasn for this? Jul 27 06:03:00 All I wanted to know was will there be some support if start working on Andorid (JB) for beagle bone - If I get stuck? Jul 27 06:10:10 not from the people here at least Jul 27 06:10:34 TI or one of its partners might have commercial support Jul 27 06:11:04 there might be something like rowboat, but I don't know details Jul 27 07:14:16 Phani: http://lmgtfy.com/?q=beaglebone+android Jul 27 07:18:22 thing is ... if you wanna go android, bbb prob is the wrong device for you Jul 27 07:18:39 no "real" gpu acceleration, just a single core... blah. whatever. Jul 27 07:18:40 ^^ Jul 27 07:18:45 hes gone. Jul 27 07:19:48 gurki: gpu works fine Jul 27 07:20:31 like ... with acceleration, full hd and stuff? Jul 27 07:20:45 i only ever used bbb for its ios ... id switch to raspi should i need gpu Jul 27 07:21:14 it has the same 3D GPU as, say, the OMAP 3 series Jul 27 07:21:25 nice :o Jul 27 07:21:36 i guess i got sth wrong here ... Jul 27 07:22:25 lcdc is a bit crappy as display subsystem, e.g. no compositing there so you need to do that in the gpu (or cpu, but that sounds less desirable) Jul 27 07:23:16 lack of video/camera input to be composited with other stuff makes that less of a problem though Jul 27 07:24:21 no X support yet, but android doesn't use X anyway does it? Jul 27 07:27:21 and dunno whether full HD is possible... it ran pretty smoothly on 1280x1024 but it didn't negotiate the (larger) true screen size as frame buffer size even though I think lcdc should support it Jul 27 07:27:34 iirc the hdmi framer imposed some restrictions Jul 27 07:30:24 thx for all that info :) Jul 27 07:32:51 the official graphics SDK has a structure similar to https://github.com/powervr-graphics/Native_SDK ... but much older and almost no examples Jul 27 07:33:30 I've been considering trying to see if combining the am335x drivers with those OGLES/OGLES2 demos actually works Jul 27 07:33:35 should, I think Jul 27 07:36:05 other interesting experiments would be getting wayland running on it (for windowing) or in the opposite direction use it without fbdev (for lower overhead) Jul 27 07:47:11 the rpi might still be nicer for graphics though, given that it's primarily a GPU (with an ARM core stuck to the side), dunno if anyone ever compared their abilities Jul 27 07:47:40 in both cases the limiting factor is probably software/driver support rather than the raw hardware capability Jul 27 07:48:29 at least the rpi gpu is documented (unlike the SGX) Jul 27 07:56:12 guys, I have some weird stuff on connecting with serial line to beaglebone, actually the serial freeze after like 30 seconds. I have to close minicom and reopen it to get back to BBB shells. is this behavior normal? Jul 27 07:56:51 it does freeze also if I leave a command like top working.. Jul 27 07:57:18 it's my 1st time using serial so if there is some behavior that I'm not aware.. Jul 27 08:00:19 hardware and software flows are off... Jul 27 08:57:20 funny, the serial doesn't crash using windows, so it must be a driver / module problem Jul 27 10:02:06 Hi Jul 27 10:45:39 it was the gnd pin, I think I solved my usb-serial issue with bbb :-O Jul 27 13:12:38 Hi, I tried using a rev B board (Angstrom) and had problems with running out of disk space when updating software. Does the rev C with Debian have the same sort of problem or is the extra 2GB of flash more than enough? Jul 27 13:13:16 if you are concerned with space, use a large microsd Jul 27 13:14:08 IMHO you only run into issues if you want the packages for everything and the kitchensink installed Jul 27 13:14:48 Do you mean run from the SD instead of flash? Jul 27 13:15:54 yes Jul 27 13:17:18 Is there a noticeable speed reduction when running from flash? Jul 27 13:18:02 that will entirely depend on the characteristics of the sd card Jul 27 13:18:26 there are some that are really good at random access, others "suck" Jul 27 13:19:14 the advertized speed is in most cases irrelevant and has no correllation Jul 27 13:19:35 i'm interested it this, too. any advice on which uSD to use in order to reach the same performance of the internal eMMC? Jul 27 13:21:54 Do I boot from the SD card using the installer image, then resize the partitions, is that possible? Jul 27 13:23:24 Samsung EVO cards take top honors: http://thewirecutter.com/reviews/best-microsd-card/ and http://www.tomshardware.com/charts/microsd-cards-2014/-4-Random-Write-512-KB-MB-s,3483.html Jul 27 13:24:54 Wow. The performance disparity in Tom's review is almost inexplicable. That's just... wow. Jul 27 13:25:59 All the Transcend cards place in the top third, too. Jul 27 13:34:07 myself: keep in mind that those "tests" usually are for linear loads. like writing and reading images, video etc Jul 27 13:34:39 I would /never/ base a buying decision on such a review. for reasons, see above. Jul 27 13:36:21 tbr: I picked the 4k random write test since that's usually closer to how a root filesystem gets used, and yes you're right, the results are very different than the sequential write test. Jul 27 13:36:44 *nod* Jul 27 13:37:55 also, there seems to be no specific/industrial products in those reviews, which could be interesting to see Jul 27 13:41:43 Is the Debian image running from an SD card compatible with the Rev B board? I couldn't find anything online about compatibility. Jul 27 13:42:21 yes, I run one of the debian images on both a BBW and a BBB RevA5 Jul 27 13:42:55 just don't use a flashing image but a "normal" image Jul 27 13:43:40 Thanks, I had no idea. Jul 27 15:47:18 quit Jul 27 15:57:33 What is responsible for the leds on the RJ45 connector? Jul 27 15:58:04 Every ~50 boots, those leds do not turn on Jul 27 15:58:26 ip link says eth0 is DOWN Jul 27 15:58:30 Phy issue I think Jul 27 15:59:11 dmesg whines every boot about the phy but I thought it was normal Jul 27 15:59:59 do you connect the RJ45 before or after boot? Jul 27 16:00:40 before Jul 27 16:01:09 I leave it connected, and I powercycle over and over again to repro Jul 27 16:01:33 took me 43 tries yesterday and 57 today Jul 27 16:02:16 Is all that stuff about the phy not found normal in boot? http://pastebin.com/pF2bZ893 Jul 27 16:04:56 IIRC there are two interfaces and it doesn't find the second one. Or at least that's how I _guessed_. Jul 27 16:06:25 device tree erroneously enables the second one Jul 27 16:07:20 messages about mdio:01 are harmless Jul 27 16:07:38 the ones about :00 aren't Jul 27 16:07:49 but there was a hardware issue - somthing with a capacitor, if I remember correctly Jul 27 16:07:54 finding it on :02 is due to a bug that I thought was fixed Jul 27 16:08:07 nerienna: the true cause has never been determined with certainty Jul 27 16:08:14 other than that the LAN chip Jul 27 16:08:22 may not be getting reset quite right Jul 27 16:08:46 (or maybe is buggy) Jul 27 16:09:53 https://groups.google.com/d/topic/beagleboard/9mctrG26Mc8/discussion is the topic about it Jul 27 16:10:11 yes, I have more than 10 beaglebones at work, some of them have the problem, others don't Jul 27 16:10:33 the LAN chip is apparently also sensisitve to ESD Jul 27 16:11:50 still, the cases where it results in phy address 2 (even though PHYAD1 has a pull-down at the cpu side, a pull-down at the PHY side, and an external pull-down ... how the fuck does the PHY manage to sample it high?) are reasonably easy to work around Jul 27 16:12:09 hardware (the MDIO controller) already scans all 32 phy addresses Jul 27 16:12:48 ideally the bootloader would then change the phy address to 0 (it's reconfigurable via a PHY register), but no such code has been written yet agaik Jul 27 16:13:01 instead PHY-search code was added to the kernel as a hack Jul 27 16:13:53 properly resetting the PHY would also fix the problem, but you can't since its reset is tied to the global nRESET Jul 27 16:14:07 that's just an xacto blade away, though ;) Jul 27 16:15:22 * zmatt looks at the PHY Jul 27 16:16:03 if you're comfortable disconnecting its nRESET and connecting it to a GPIO, and patching the bootloader to assert its reset for the dataspeed-specified minimum about of time, that go for it Jul 27 16:16:29 since by default the amount it is reset is... cutting it very close Jul 27 16:17:27 an easier alternative would be an external reset-hold circuit on the nRESET pin, accessible on the expansion header Jul 27 16:18:27 also remove one of the caps, or compensate with a heavier pull-up Jul 27 16:20:16 since... https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/y0YOSrDKZgIJ Jul 27 16:20:31 https://17376924468624948387.googlegroups.com/attach/266cab04a0e46cb/power-on%20reset.png?part=0.1&view=1&vt=ANaJVrEazk4HtGdiEi2OYcy-Jg61BtC252zJzpGdnjHs5K8fj7ujPpxK9S7UqCwyTIt9rdiKdLQ0cghBUuvDE2vHpLggTtVSDDxGkDXnzwdrhU2sQGHQXls Jul 27 16:20:44 that red line is nRESET Jul 27 16:21:06 not exactly the shape I'd personally want to see in digital signal Jul 27 16:22:50 zmatt, Wow thanks for all that info, glad to see we are not alone with that issue Jul 27 16:23:41 zmatt, Currently reading through the thread about it, if I understand you correctly, there is no software patch available yet? Jul 27 16:23:49 there is one Jul 27 16:24:07 and it should be included in all kernels from rcn-ee afaik for quite a while now Jul 27 16:24:13 no bootloader-level patch yet though Jul 27 16:25:04 We are still running with 3.8.13-bone53, any idea how recent the kernel must be to get the patch? Jul 27 16:25:13 I'd still prefer to see a hardware patch, since if the PHY can missample that strapping option (again: it has internal pull-down in both PHY and AM335x, *and* external pull-down), it can missample anything Jul 27 16:27:26 and I suspect the problem is 1. the reset-time is borderline too short and/or 2. the reset signal shape is dubious, far too big a cap for its pull-up resistor Jul 27 16:28:58 jsabeaudry: is your problem consistently reproducible btw? because that would make an interesting test case Jul 27 16:29:33 * adibis missed the start of the conversation but it seems interesting Jul 27 16:29:52 adibis: it's about the ethernet PHY issue Jul 27 16:30:02 it sometimes missamples strapping options at reset Jul 27 16:30:06 somehow Jul 27 16:30:38 I've done measurements and noticed the reset time is making a really close call w.r.t. the minimum specified in the datasheet Jul 27 16:31:12 minimum time for the rest of the values to stabilize? Jul 27 16:31:36 just minimum time specified for PHY nRESET to be low Jul 27 16:31:59 the phy doesn't require nRESET to be held low during/after power-on, it just requires one good proper reset before you start using it Jul 27 16:32:03 how is there a software patch for this? Jul 27 16:32:10 Or is it just for soft reset? Jul 27 16:32:22 by working around the misbehaviour that results from it Jul 27 16:32:40 which so far only appears to be PHYAD[1] being 1 when it should be 0 Jul 27 16:32:52 hence the PHY appears at phy address 2 instead of 0 Jul 27 16:32:52 so just re-program the default options before first use? Jul 27 16:32:55 zmatt, I seem to get it every ~50 boots or so, I wouldn't call it consistent :) Jul 27 16:33:13 they don't use that either, they just scan for the phyad and then use that afaik Jul 27 16:33:24 even though you can indeed reprogram (nearly) all strapping options Jul 27 16:33:55 seems faster than scanning every time. (?) Jul 27 16:34:09 adibis: well it's done once at boot Jul 27 16:34:19 and otherwise would need to be done... once at boot Jul 27 16:34:28 also, the MDIO controller does the scanning Jul 27 16:34:40 (always, whether you want it to or not) Jul 27 16:35:44 hmm - is the reset ciruit re-programmable or fixed hardware dependent? Jul 27 16:36:02 people have noticed that adding more capacitance to nRESET makes the issue appear more consistently, maybe I'll try that if I find the time Jul 27 16:36:25 some aspects are programmable, but not really any useful ones Jul 27 16:37:30 the power-on-reset is generated by the PMIC Jul 27 16:37:49 which is reprogrammable, except the custom settings are lost when the PMIC enters OFF-mode Jul 27 16:38:25 the power-on sequence always comes from its EEPROM, and TI refuses to let customers reprogram that Jul 27 16:39:02 power-on-reset drives nRESET low, which is tied directly to the PHY Jul 27 16:39:43 there's also a big cap and small pull-up on nRESET Jul 27 16:40:03 those people have fiddled with, apparently with successs Jul 27 16:42:05 hmmmmm Jul 27 16:42:08 I was thinking Jul 27 16:42:32 because adding capacitance making the problem worse while removing capacitance making it better really puzzled me for some time Jul 27 16:42:47 the chips may however have different thresholds Jul 27 16:43:49 big enough capacitance might perhaps mean the PHY is taken out of reset first, then the AM335x which subsequently asserts its reset-hold circuit causing the PHY to be reset again, but waaaay too briefly Jul 27 16:44:23 and it's possibly that second blip that causes the bug? Jul 27 16:44:43 the PHY needs something like a 25 ms reset pulse iirc Jul 27 16:45:53 the AM335x generates 250 ns reset pulse Jul 27 16:46:05 I'm not familiar with "reset-hold circuitry", that seems like it would complicate things Jul 27 16:46:13 though actually the cap would stretch that again Jul 27 16:46:29 only if the pulldown is stiff enough to discharge the cap Jul 27 16:46:40 assuming... that Jul 27 16:47:07 we really need a scope capturing this when it goes wrong Jul 27 16:47:59 I pondered whether it would help for software to detect a cold reset, reconfigure the reset-output pulse of the AM335x and execute a warm reset Jul 27 16:48:10 but the max configurable reset pulse is 255 cycles @ 24 MHz Jul 27 16:48:26 which is still only 10 microseconds Jul 27 16:49:48 the PHY actually requires 100 μs as minimum nRESET input time Jul 27 16:50:03 and power supplies need to be stable for at least 25 ms at that time Jul 27 16:50:46 huh, jkridner's not on right now. I was gonna say, I'd love to help scope *all* the things if he's got a board handy that exhibits the problem reliably Jul 27 16:51:46 I wonder if the warm-reset pulse even resets the PHY at all Jul 27 16:52:31 but, the PHY is wonky anyway Jul 27 16:52:35 I wonder if there's anything from the PHY we could monitor to independently confirm that Jul 27 16:52:39 see this post about something that happened to me https://groups.google.com/d/msg/beagleboard/9mctrG26Mc8/UwgD7xbEllYJ Jul 27 16:52:48 phy reset you'll notice if you have link Jul 27 16:52:50 link leds go out Jul 27 16:53:09 and then on again due to autonegotiation Jul 27 16:53:23 which also means the link partner will log the link down-up Jul 27 16:53:31 unfortunately, u-boot *also* resets the PHY Jul 27 16:53:37 the kernel yet again resets the PHY Jul 27 16:53:58 presumably to try as hard as possible to confuse the link partner :P Jul 27 16:54:12 hahahah Jul 27 16:54:38 crap I really need to do shopping before the stores close Jul 27 16:54:44 What is the repo for a kernel that contains the patch, https://github.com/RobertCNelson/linux-dev seems to still be at 3.8.13-bone53 Jul 27 16:55:32 it should be included all recent kernels including the ancient 3.8.x series... the versions are mentioned somewhere in the forum thread Jul 27 16:56:25 it was solved a short time after "bone47"... Jul 27 16:56:30 according to rcn-ee Jul 27 16:57:07 zmatt, ok, I'll spin it for a 100 times with bone70 once I find the code for it Jul 27 16:57:26 apt-get install? Jul 27 16:57:45 Oh, I got the binary, I'm looking for the source Jul 27 16:58:04 https://github.com/RobertCNelson/linux-stable-rcn-ee/releases Jul 27 16:58:21 for 3.8 series you'll probably need to scroll back waaaay back Jul 27 16:59:54 since those releases aren't part of any head, it doesn't seem to automatically pull the tags for it Jul 27 17:00:03 maybe explicitly fetching with --tags fixes that Jul 27 17:01:07 git fetch origin 3.8.13-bone70 should also get you the release as FETCH_HEAD (from which you can then make a branch) Jul 27 17:01:46 (or replace "origin" by whatever the name you give this repo as remote) Jul 27 17:01:51 great! Many thanks! Jul 27 17:02:07 note also that 3.8.x is ancient history Jul 27 17:02:16 consider moving to 4.1.3 :P Jul 27 17:03:19 -bone72 actually seems the latest 3.8.13 Jul 27 17:03:31 is the 4.1 able to mananage dt overlay made for capemgr? Jul 27 17:03:49 4.1 has both bone_capemgr and proper mainlined overlays Jul 27 17:04:27 (i.e. I disable bone_capemgr in my kernels and DTs to free up the relevant pins since we don't use any standard capes, still have overlays using the new mainlined mechanism) Jul 27 17:06:32 the new configfs mechanism also doesn't require bullshit CAPE-metadata when loading a custom overlay \o/ Jul 27 17:07:40 good. next question then: is there some documentation to help morons like me to migrate from .dts made for capemgr to this phantasmagoric proper mainlined mechanism? :) Jul 27 17:08:42 same dtbos are accepted -- any metadata (properties of the root node) is ignored Jul 27 17:09:34 the minimal overlay source code is now: /dts-v1/; /plugin/; / { target = <&foo>; __overlay__ { /*...content...*/ }; }; Jul 27 17:10:00 target-path = "/path/to/node"; is allowed as alternative to targeting by label Jul 27 17:10:21 loading: Jul 27 17:10:28 make a subdir (any name) in /sys/kernel/config/device-tree/overlays Jul 27 17:10:38 Inside it you will find three files: dtbo, path, and status. You can either write the path of the dtbo file to path, or write the contents of the dtbo file to dtbo. Assuming no error occurs, the status will change from unapplied to applied. Jul 27 17:11:38 It is possible to (attempt to) unapply an overlay by removing the corresponding directory you created. It is even possible this will succeed without kernel panic. You can (currently) only remove overlays in reverse order you added them, not remove one from the middle of the stack. Jul 27 17:12:29 note that targeting by label (as before) requires the main DT to be compiled with symbols (cmdline option -@), but that's the case for all standard DTs Jul 27 17:12:40 sounds exciting. and what is the equivalent of the old `cat $SLOTS`? should i just take a look at the subdirs in there? Jul 27 17:12:44 yep Jul 27 17:13:38 hopefully ls -U also gives you the order Jul 27 17:13:45 thanks a lot. will try it asap Jul 27 17:14:13 I'm afk for a bit Jul 27 17:15:52 remember: chocolate and beer! Jul 27 17:15:56 :) Jul 27 17:19:32 Is there a karma bot here? Jul 27 17:19:49 +1 zmatt Jul 27 17:21:25 * samael 2nds Jul 27 18:38:14 :D Jul 27 22:37:35 hi Jul 27 22:38:43 I'm trying to boot a bone black from the serial (really boot from the rom code, not chainload from an uboot or anything). Jul 27 22:39:54 the section 6.7.2 page 58 of the system reference manual says that on pressing the button near the sd card port, the boot order should be spi -> sd -> usb -> uart Jul 27 22:40:11 however i still see the messages from my (broken) mlo on the emmc Jul 27 22:40:14 any idea ? Jul 27 22:42:30 have you tried blowing away the mlo on eMMC Jul 27 22:42:54 well i can't since i can't boot Jul 27 22:43:11 (i can't use sd for some reason) Jul 27 22:43:54 how long are you holding the boot button? Jul 27 22:44:36 from before i reset the board to after the broken's mlo messages appear Jul 27 22:44:46 ah, however i only tried with hot reset… Jul 27 22:44:58 hot reset does not work Jul 27 22:45:11 need to pull power completely then reapply power Jul 27 22:45:58 ok, i'm, err, trying to try at the moment (my kermit seems stuck) Jul 27 22:47:21 right, the mlo messages don't appear. nothing else appear (the doc talks about some CCCC letters), but thanks, that seems better already Jul 27 22:47:56 try with an sd... after doing a hard reset Jul 27 22:52:40 as i said, i have an sd but nothing to flash it Jul 27 22:53:05 (and tbh i'm not exactly sure my sd does work) Jul 27 22:53:52 oh... Jul 27 22:54:11 mmmh i tried to send a mlo through the xmodem protocol after cold-booting with the button pressed, but it does nothing Jul 27 22:54:36 maybe there is some timeout for the spi and usb steps to fail Jul 27 22:54:47 USB SD readers are pretty cheap if you don't have one in your system Jul 27 22:55:11 can probably pick one up for 5-10 dollars Jul 27 23:04:06 yeah, but not tonight (1am here) and mostly being able to boot custom stuff solely over uart (read: without physical sd card swapping) is interesting for factory and maintainance and this kind of stuff Jul 27 23:04:22 but that would be the reasonable thing to do, sure :) Jul 27 23:04:46 i'll continue reading the am335x doc, thanks for the cold boot trick ! Jul 27 23:07:15 ok Jul 27 23:23:48 "The ROM code will ping the host 10 times in 3s to start x-modem transfer.", ok i just need to be crazy fast… Jul 27 23:35:16 Mmmmmm xmodem Jul 27 23:35:25 wonder if it will also do xmodem-1024 Jul 27 23:46:32 it apparently *is* xmodem-1k mode Jul 27 23:47:09 see section 25.1.8.5.2 of the big fatass am335x 4000-ish pages doc Jul 27 23:50:17 still xmodem does not react when i bootup the board… Jul 27 23:54:10 sysboot setup right? Jul 27 23:57:09 ds2, do you mean the values of the pins ? i guess, it's beaglebone black engineers choice, not mine ^^ Jul 27 23:57:22 yes Jul 27 23:57:24 read the schematics Jul 27 23:59:01 according to the bbb doc, the lower bits of sysboot, with the button down, are 11000b Jul 27 23:59:35 leading to a boot order of spi -> sdcard -> usb -> uart Jul 28 00:00:10 mmmh, maybe the usb does not timeout… i'll connect it to a phone charger rather than to my computer Jul 28 00:05:53 use the barrel connector for power Jul 28 00:06:40 yeah… atm i don't have ideas anymore Jul 28 00:07:08 i'll try the barrel connector at home, i'm at school and i don't have my alim right now Jul 28 00:07:32 i don't have much hope it'll do any difference tho Jul 28 01:01:56 holy f*ck guys that was that !!! Jul 28 01:02:04 now I can sleep in peace Jul 28 01:02:12 thank all :) Jul 28 02:25:50 navaati: once usb-boot gets enumerated by an rndis driver, it's indeed all over -- you'll be in usb-boot, it will no longer try other modes Jul 28 02:26:40 why on earth would you want uart boot mode instead of, say, usb-boot or ethernet boot? Jul 28 02:35:32 perhaps the PC you have ready access to is work-managed and you don't have access to install rndis drivers, but you have a uart you can use? Jul 28 02:37:11 well an uart on a PC itself is of no use since you need 3.3V TTL signalling rather than RS232 levels Jul 28 02:39:10 the ftdi cables typically *do* need an actual third party driver to be installed, rndis is built into windows (in fact invented by microsoft), and only needs "installation" in the same sense that a mouse needs installation.... then again, if you don't have admin rights you're not going to get usb boot to work anyway most likely Jul 28 02:40:22 doesn't uart boot take ages? Jul 28 02:41:44 * zmatt uses Ethernet boot when doing baremetal tests, and plans to use it for flashing BBBs Jul 28 02:47:24 myself: actually, the rndis driver *is* installed on working on your host PC Jul 28 02:47:31 myself: it was preventing uart boot from working :) Jul 28 02:47:58 *install and working Jul 28 02:48:53 but as non-admin you're presumably not going to be allowed to run a BOOTP server Jul 28 02:50:26 though, on linux, "BBBlfs" just uses libusb to perform the remaining exchange Jul 28 02:51:47 which itself doesn't require special privilege since the user logged into a physical seat is normally allowed to access associated usb peripherals Jul 28 02:52:34 possibly the same is true on Windows (I have no idea really) **** ENDING LOGGING AT Tue Jul 28 02:59:58 2015