**** BEGIN LOGGING AT Tue Dec 06 03:00:00 2016 Dec 06 08:24:02 Hi, I have a beaglebone and when I insert my sd card and write something to it and remove it again the changes are not saved on the sd card. Probably because the sd card was not unmounted before removing. Is there a solution for this? Dec 06 08:32:14 DriesS: maybe sync and umount it? Dec 06 08:50:37 LetoThe2nd: does it make sense when we remove physical the sd card? Dec 06 08:50:54 if the card is not there anymore, how to sync then? Dec 06 08:56:03 DriesS: if you pull out the card physically without taking care it is not used by the software anymore you are out of luck anyways. Dec 06 08:56:42 LetoThe2nd: ok but I can not ask my clients to unmount it before removing because they don’t have access to the system :) Dec 06 08:56:55 DriesS: then you do have a problem. Dec 06 08:57:20 LetoThe2nd: how does it work with camera systems then? Dec 06 08:57:33 there you can also remove the sd card when the system is on no? Dec 06 08:57:48 DriesS: you can try to reduce caching and remount to ro whenever possible, but basically, you have to sync/unmount before pulling it out. or live with the resulting errors. Dec 06 08:58:19 and i am no camera firmware developer, but my guess is that they basically do what i just said Dec 06 08:59:27 basically, the camera starts syncing the card when you open the door to the card slot Dec 06 08:59:42 and the manual says you shouldn't do it while the camera is on. Dec 06 09:01:05 plus, cameras do bulk writes. you take a picture, it is fully synced, the card goes idle again. Dec 06 09:01:36 LetoThe2nd: but there is no important information on the sd card Dec 06 09:01:42 it is more for backups in case of Dec 06 09:01:45 if you have extended periods of idling, you can automatically sync/remount ro/umount Dec 06 09:01:52 so I can make my script taking the backup and running sync after Dec 06 09:01:56 DriesS: well what do want to hear from us now? Dec 06 09:02:30 LetoThe2nd: nothing, you helped me already much further :) Dec 06 09:02:41 great :) Dec 06 10:42:14 systemd can auto-mount on access and automatically unmount again after some idle time, transparent to applications (apart from the slight delay due to automounting) Dec 06 10:43:44 e.g. in the fstab options: noauto,x-systemd.automount,x-systemd.device-timeout=5s,x-systemd.idle-timeout=10s (the device timeout is for when the card is missing) Dec 06 10:53:33 zmatt: interesting, thanks Dec 06 10:54:38 it might actually be possible to maintain filesystem integrity even in the face of card ejects in the middle of writes, assuming SD has reliable-write commands similar to those in eMMC, but it would require a lot of care in the fs driver and lower layers, and some operations would become very slow Dec 06 11:12:08 hmm, or I guess you might still have a fundamental problem with having to update two separate filesystem structures coherently, but I'm not sure if FAT requires this. possibly a live unmount might leak free disk space, though an fsck at mount could fix that. moving a file would probably have an unavoidable window of non-integrity Dec 06 15:10:03 hi Dec 06 17:06:45 Hi, have you found beaglebone debian-lxqt very slow to work with ?? or at least a lot slower than ubuntu-lxde ?? Dec 06 17:09:55 I never really understood why people use a desktop environment on a beaglebone in the first place :P Dec 06 17:10:52 Just to see something on LCD ..... ;-))) Dec 06 17:12:26 cat /dev/random >/dev/fb0 Dec 06 17:12:27 :P Dec 06 17:12:51 we usually have the lcd output disabled anyway since we need the pins Dec 06 17:13:51 however lxqt debian8.6 is almost useless... perhaps the fact I'm using a white one and without an eMMC to work with , writing on sdcard (swap also) takes a lot of time Dec 06 17:13:51 the few projects that do use lcd output just run a single fullscreen application Dec 06 17:14:01 swap?! Dec 06 17:14:43 how else would you run firefox and libreoffice ? :P Dec 06 17:15:00 also, what performance class is the sd card you're using? Dec 06 17:15:27 isn't there a swap space in it ? (running top cmd I was seeing something related to swap ....) Dec 06 17:15:44 cat /proc/swaps Dec 06 17:17:04 just running QupZilla almost kills the board..... Dec 06 17:17:45 ah, at least I have my LCD7 clone working !!!!! Dec 06 17:20:53 if sd write performance is the problem, get a faster card. if graphics is slow, then it probably will help a lot to use a graphics stack that supports the GPU (e.g. Wayland, or Qt5 with eglfs backend), if you're out of ram then... curse how bloated everything has become :P Dec 06 17:21:14 I suppose I'm out of ram Dec 06 17:21:42 also there is kswapd0 running with no swap Dec 06 17:21:48 don't suppose, check. note that running out of ram doesn't cause slowness if you have no swap enabled Dec 06 17:22:31 or shouldn't Dec 06 17:23:05 ./proc/meminfo ? Dec 06 17:23:33 the "free" utility displays /proc/meminfo in a slightly more user-friendly way Dec 06 17:24:17 total used free shared buffers cached Dec 06 17:24:26 240116 226952 13164 2832 664 14368 Dec 06 17:25:13 ah the white had only 256MB of ram? Dec 06 17:25:25 unfortunately....yes Dec 06 17:26:06 remind me again why exactly you're trying to run a desktop environment and a web browser on this? Dec 06 17:26:21 I have to go, children waiting Dec 06 17:26:22 note that you're not really out of ram according to those numbers Dec 06 17:26:24 nothing, Dec 06 17:26:57 simply checking one of last debian images proposed on beagle website... Dec 06 17:27:47 yeah I agree that whatever they're suggesting to run should actually work Dec 06 17:28:08 bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img Dec 06 17:28:28 is that being recommended for the white? Dec 06 17:28:43 hmm seems it is Dec 06 17:29:18 the problem is running with 256Mb ram and from a class4 sd :-((( Dec 06 17:29:20 well at least the (no-gui) "IoT" image is under Alternate Debian Images Dec 06 17:30:40 I always worked armhf console perfectly for my purpose...touchscreen only for some gpio "touch" control.... Dec 06 17:30:50 (relaysetc) Dec 06 17:31:01 ditto, even de IoT image contains a ton of crap Dec 06 17:31:04 *(relays etc) Dec 06 17:32:11 I still need to find some time to try Wayland or Qt5/eglfs Dec 06 17:32:31 really have to go , later i'll tell you about LCD7 (clone) issue, solved (don't know why) Dec 06 17:32:51 ok :) Dec 06 17:32:53 too much unexperienced for those things.... Dec 06 17:33:11 just shell and a little php... Dec 06 17:33:12 bye Dec 06 17:41:36 zmatt, fred_tv: yeah, it is expected to work with White, but it gets a little less testing these days. Dec 06 17:42:02 agree on the performance being challenged by 256MB RAM and running off SD.... Dec 06 17:42:31 * jkridner would love to bring back an updated White with 512MB, but otherwise the White circuit---just don't know if there is enough demand. Dec 06 17:43:09 I like the on-board serial/JTAG as well as not having HDMI or eMMC for best use with daughterboards/capes. Dec 06 17:43:21 anyway, just planting a seed if people want to push for it on the list. Dec 06 17:44:42 for sd cards, people should check their speed class. eMMC sequential write speed is specified as 6.6 MB/s for the micron eMMC or 12 MB/s for the kingston eMMC Dec 06 17:46:04 so getting a speed class 6 or class 10 card would be a good idea (UHS is not applicable) Dec 06 17:51:41 jkridner: and I agree on-board serial and jtag would be nice, HDMI is something I never use either, but omitting eMMC would leave me uninterested Dec 06 17:52:10 zmatt: fair enough... eMMC is a great feature. Not sure if it'd still be a "White" to add it to the design. Dec 06 17:52:58 beige maybe? Dec 06 17:53:03 ;) Dec 06 17:53:11 I'm with zmatt on features. Dec 06 17:53:16 eMMC is a horrible feature Dec 06 17:53:24 I'd also be interested in swapping out the FTDI with an Atmel MCU like used on Arduino. Dec 06 17:53:32 look at all the time spent on "recovery" Dec 06 17:53:38 then we really are talking about another board. Dec 06 17:53:54 ds2: ? Dec 06 17:54:09 ds2: but the performance and reliability are so much better than SD... Dec 06 17:54:23 zmatt: "User button"...button another thing... lots to sort out with people Dec 06 17:54:24 but, it is a bit of a support-time consumer. Dec 06 17:54:26 ds2: it would be nice if there was a more user-friendly tool for putting a beaglebone in usb mass storage mode Dec 06 17:54:36 ds2: really need to populate it with a recovery image. :( Dec 06 17:54:48 zmatt: +1 Dec 06 17:54:51 jkridner: IMO - the choice of uSD socket on the SD only boards was bad Dec 06 17:54:54 of course I don't care anymore since I have a good working setup for it Dec 06 17:55:23 zmatt: this is recursing down a path to patch one issue with another problem Dec 06 17:55:40 ds2: not really? Dec 06 17:55:40 there are better (non push in/out) sockets Dec 06 17:56:12 I agree with that, here at the office I've often heard concerns about the usd slot w.r.t. vibration Dec 06 17:56:34 with the right sockets and class 10 (not that BBX shipped abomination), performance and speed isn't much of an issue Dec 06 17:56:51 fortunately that is a non-issue for us in the end since we don't use the usd slot Dec 06 17:57:45 long wait for huge download + long wait to write image to an SD card flasher + long wait for board to flash itself == horrible Dec 06 17:58:35 well, SD is still capped at 24 MB/s by the interface, versus 48 MB/s for eMMC (though the eMMC used is the bottleneck for writes) Dec 06 17:58:53 right, but I don't use flasher cards but flash via USB Dec 06 17:59:15 also I don't flash huge crap-filled images :P Dec 06 18:01:07 hmmm that serial port comment... gives me a useful mod Dec 06 18:01:41 ds2: I haven't heard much more about your SOM. How's that going? Dec 06 18:01:55 ds2: not sure why it hasn't been talked about. Dec 06 18:02:00 jkridner: speaking of serial ports, I really wish the BBB had bothered to connect hw flow control (especially the rts output) Dec 06 18:02:21 right now they're unused on the header *and* on the am335x Dec 06 18:03:39 jkridner: The VKS board is moving along. Need to work on other projects to fund inventory Dec 06 18:03:56 zmatt: if it doesn't hurt things, patches will be considered. Have OrCAD/Allegro? We'd have to work together to validate. Dec 06 18:05:18 zmatt: you mean the console UART or another one? Dec 06 18:05:57 we use Altium, where "we" doesn't really include me since I mostly do software. my contribution to hardware is mostly checking schematics, sighing deeply, and informing the hw people about the stuff they screwed up this time ;-) Dec 06 18:06:46 ds2: uart0 yes. its rts/cts are currently not connected on the am335x (iirc rts still goes to a test pad), and on the serial header Dec 06 18:07:10 you could avoid a second isolation buffer by just buffering the inputs, I see no reason to buffer the outputs Dec 06 18:07:24 (and *please* power that buffer from 3v3a, not 3v3b !) Dec 06 18:07:25 zmatt: well, maybe you can coax someone else into doing the update or file a bug with super-clear instructions describing why it can't hurt anyone and exactly how to connect/route it, etc. Dec 06 18:07:51 zmatt: I suspect routing it out might be the issue... there isn't room Dec 06 18:08:15 ds2: ah I haven't looked at the pcb at all Dec 06 18:08:21 IIRC - there should be a 2 bit version of the isolation buffer Dec 06 18:08:36 if I'm doing any new designs these days based on AM335x, it would be using the OSD3358 and using KiCad. Dec 06 18:09:22 jkridner: I'm not quite sold on the osd3358... I get the impression they copied the power supply scheme directly from the bbb, bugs included Dec 06 18:09:29 but breaking out gets real tight. I barely got out all the pins on the OSD3358 (larger pitch then a raw AM335x)... I am on 4L but the BBB's 6L is chewed up with the DDR things Dec 06 18:10:06 zmatt: that is flexible enough that the 3V3A/B issue can be worked around (I ignore 3V3B on the VKS) Dec 06 18:10:58 the size of the osd3358 is the biggest complaint from me Dec 06 18:10:59 ok. but then it does need to be solved in the pcb, we can't patch it afterwards like we do with BBBs Dec 06 18:11:34 zmatt: it can be... the A and B rails are broken out. Dec 06 18:12:42 zmatt: ~1M BeagleBones tell me it is good enough, despite issues that could be cleared up with proper communications/understanding. Dec 06 18:12:56 ds2: if the B supply output of the osd335x goes to other stuff on the pcb then there's almost certainly no way to patch that to become 3v3a since you can't cut the connection to the osd335x Dec 06 18:13:27 zmatt: it doesn't. it requires an external to chip shunt to route it Dec 06 18:13:56 jkridner: how many of those are on batteries? that's the main problem case Dec 06 18:14:41 Not sure. Do you mean the single-cell Li-Ion support? Dec 06 18:14:48 yep Dec 06 18:15:40 iirc, as long as VinAC is exclusively used to power things, it is all fine Dec 06 18:15:41 In my thinking, I'd probably switch to AM4x when fixing those issues. Dec 06 18:15:55 and LPDDR. Dec 06 18:15:56 but if the other inputs used.... Dec 06 18:16:01 x32 Dec 06 18:16:10 another concern is that afaik every time you cut power to eMMC there's a small chance you'll end up with a corrupted filesystem... that's a problem in end-user devices where corrupt fs is pretty much a dead device. a tiny li-ion battery to give you enough time to shut down cleanly solves it Dec 06 18:16:13 is there an AM4x with 2 PRUSS? Dec 06 18:16:38 zmatt: shouldn't the file system resolve that? Dec 06 18:16:47 ds2: yes. Dec 06 18:17:48 http://www.ti.com/general/docs/datasheetdiagram.tsp?genericPartNumber=AM4378&diagramId=SPRS851D Dec 06 18:17:56 ds2: "quad-core ICSS" Dec 06 18:18:07 er, "Quad Core PRU-ICSS" Dec 06 18:18:09 jkridner: my understanding is that a powerfailing eMMC can corrupt previously committed data Dec 06 18:18:44 jkridner: is that dual PRUSS or a single PRUSS with 4 PRUs? IIRC - the 4 PRU version has 2 crippled PRUs Dec 06 18:19:00 it's not a quad-core pru-icss, it's two pru-icss instances connected together, with one being stripped down Dec 06 18:19:07 I thought it was 2 PRU-ICSS, but now I'm less sure. Dec 06 18:19:23 zmatt: that is not a good combo either Dec 06 18:20:14 blah... no Vivante either Dec 06 18:20:54 icss0 can only be reached via the icss0<->icss1 interconnects cross-link Dec 06 18:21:35 the icss0 cores also have no master port to the L3 Dec 06 18:22:42 see block diagram in section 30.1 (page 3752 of SPRUHL7F) Dec 06 18:26:46 what would be nice is there is a single core CortexA, one or more uncommitted CortexM, 2 or more PRUSS blocks, a non SGX GPU in a chip the size and footprint of the AM335x Dec 06 18:29:25 oh and USB3 SS Dec 06 19:36:43 hey all. Trying to figure out how my BBBrevC boots up to eventually get to understand a device tree issue. Dec 06 19:37:00 1) where does the 'MLO' live these days? It is not on any partition I can find. Dec 06 19:37:27 acuster, it's dd'ed at start-ish of the drive Dec 06 19:37:53 ah ok, so hidden outside the partitions Dec 06 19:38:28 2) what determines the initial device tree used (over which others will be 'overlaid')? Dec 06 19:38:44 acuster, the board eeprom id... Dec 06 19:39:07 hardcoded in the uBoot? Dec 06 19:39:15 is there a way I can figure out which it is? Dec 06 19:39:53 my command line has "cape_universal=enable" but my $SLOTS gives cape_universal*n* Dec 06 19:39:58 acuster, https://github.com/RobertCNelson/omap-image-builder/blob/master/readme.md Dec 06 19:40:28 acuster, oh that, https://github.com/RobertCNelson/boot-scripts/blob/master/boot/am335x_evm.sh#L509-L598 Dec 06 19:41:25 cool, more to read. thanks Dec 06 19:42:56 one more, kind of historical. It seems the overlays have gone from BB..EMCC and BB..HDMI to cape_universal. Is the idea that we now use config-pin in general rather than messing with overlays? Dec 06 19:43:47 past 3.8.13-bonex, emmc/hdmi (and hdmi audio) are a big pain to do as overlays... Dec 06 19:43:56 (aka un-reliable) Dec 06 19:44:35 "loading -> unloading -> loading -> unloading" overlays is un-reliable.. Dec 06 19:45:04 with config-pin, we just load one overlay (cape-universal) and we just turn on and off the pin's.. while the perhiperal stays enabled... Dec 06 19:47:31 with the minor caveat that this keeps the peripherals enabled while unused, and doesn't work if you need to configure the driver via DT Dec 06 19:47:50 right, so am I right that it is the 'blessed' way to go about things now, i.e. kernel 4.4+? Dec 06 19:48:49 you don't need to use cape-universal if you don't want to of course Dec 06 19:48:59 zmatt: so for simple hacking config-pin is fine, for more serious stuff (e.g. a cape), you have to deal with DT and DTOs? Dec 06 19:49:18 s/have to/want to Dec 06 19:49:19 acuster, for serious stuff, just use the dtb-rebuilder and setup your cape in the dtb. ;) Dec 06 19:49:29 then no overlays. ;) Dec 06 19:50:08 that depends on what your "simple hacking" includes. I always use custom dtbs anyway Dec 06 19:50:12 * acuster had not yet tried to learn dtb-rebuilder; his head has already exploded a few times over Dec 06 19:50:40 allright, I'll use my point of view for now subject to revision. Thanks all. Dec 06 19:50:41 cape-universal is limited and conflicts with basically everything (that's why there are so many variants of it already) Dec 06 19:51:02 zmatt: yeah, I've started to see that. Dec 06 19:51:12 overlays don't always work right and have terrible diagnostics Dec 06 19:53:32 conceptually, DT are defining the kernel modules to handle specific hardware and defining parameters for use by those modules, right? Dec 06 19:54:24 somehow, everyone seems to have known what the root purpose of these files were so the docs I have found never give the fundamentals Dec 06 19:54:28 it describes the hardware to the kernel, or at least tells the kernel what it needs to know about it (which may include what you want from the hardware or its driver rather than hardware description as such) Dec 06 19:55:22 acuster, https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings Dec 06 19:55:41 how do i become an authorized distributor for Beaglebone? Dec 06 19:56:11 shamit: in 99.999% of cases, become a reseller of an authorized manufacturer or distributor. Dec 06 19:56:34 gone? Dec 06 19:58:16 acuster: to take an example of what kind of info is in DT, take a look for example at these lines: https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.36-ti-r71/arch/arm/boot/dts/am33xx.dtsi#L350-L359 Dec 06 19:58:42 (sentence construction fail...) Dec 06 20:00:00 zmatt: the 'compatible' line is informing the kernel of the presence of that UART or that it should load a module to handle that UART? Dec 06 20:00:45 acuster, it's a version string... used when something "differnet" yet still compabile-ish.. Dec 06 20:00:47 so, the node name "serial@44e09000" typically consists of just a generic name and the address Dec 06 20:00:59 compatible is used for matching a driver Dec 06 20:01:47 technically it doesn't directly name a driver but rather says this device is, or is compatible with, an am3353-uart from ti ("vendor,product") Dec 06 20:02:07 'driver' is always a part of the kernel, built in or module? Dec 06 20:02:12 or if there's no driver for that specifically, try one for omap3-uart Dec 06 20:02:53 right, I get the list. I don't get what is being matched since the terminology jumps around. Dec 06 20:03:23 kernel drivers embed a list of such compatible-strings to match against Dec 06 20:03:41 acuster, for the serial example above: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/tty/serial/8250/8250_omap.c#n1077 Dec 06 20:04:11 thanks, I was looking for that :) Dec 06 20:05:37 acuster, if you read thru 8250_omap.c searching for "of_" you can see how it's parsing the device tree optoins to correctly configure the driver for our device.. Dec 06 20:06:11 acuster: other information in the DT entry: ti,hwmods links this device to PRCM (power-, reset-, and clock-management) information that's still embedded in the kernel... afaik it's a long-term goal to get rid of it and represent it in DT Dec 06 20:07:47 and the root node of the DT, the compatible="ti,am33xx" is being matched by the kernel to see that it has been built for the right cpu? Dec 06 20:08:21 or SoC perhaps Dec 06 20:08:45 I'm actually not sure what it's being used for, maybe for things like SoC-specific workarounds in the kernel that don't belong to any specific driver Dec 06 20:10:03 clock-frequency is strange... normally you'd reference an actual clock, or it would be implicitly provided by the hwmods mechanism I just mentioned Dec 06 20:14:46 status = "disabled"; tells the kernel to basically ignore this DT node by default Dec 06 20:15:47 rcn-ee: who calls the boot script https://github.com/RobertCNelson/boot-scripts/boot/am335x_evm.sh, the kernel at startup or capemgr later on?? Dec 06 20:16:23 acuster, it's a systemd service file "generic-boot" or something like that.. Dec 06 20:16:33 thanks Dec 06 20:17:24 acuster, generic-board-startup.service Dec 06 20:17:33 later in the overall DT construction the uart0 node is enabled again here, in this file describing the beaglebone-family in general: https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.36-ti-r71/arch/arm/boot/dts/am335x-bone-common.dtsi#L185-L190 Dec 06 20:17:50 it also augments the node with information on setting up pinmux to be able to actually use the uart Dec 06 20:18:59 that's why most peripherals are disabled by default in the SoC description: board-specific details are needed to be able to actually use them Dec 06 20:20:05 rcn-ee: btw when I was working on reducing boot time I noticed generic-board-startup taking up a large chunk of it (as reported by "systemd-analyze plot >boot.svg") Dec 06 20:20:47 I never investigated why, I simply made a quick determination it did nothing useful for me and got rid it Dec 06 20:22:15 zmatt: what is the dts that is including 'am335x_bone_common.dtsi'? i.e. what is the root device tree that is actually used? I had hoped I could find it via /sys/firmware/devicetre/base but that's the same as /proc/device-tree which seems to be the current state of the device tree so I'm not sure which dto is used as the initial DT. Dec 06 20:22:40 acuster: dtbo is the suffix for overlays Dec 06 20:23:03 you both told me earlier the root is determined based on the EEPROM Dec 06 20:23:10 these dtsi files are not overlayed at runtime but at compile time, from a .dts file to a .dtb Dec 06 20:23:20 right Dec 06 20:23:21 am335x-boneblack by default on a BBB Dec 06 20:23:33 https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.4.36-ti-r71/arch/arm/boot/dts/am335x-boneblack.dts Dec 06 20:23:37 I am trying to figure out what I am overlaying against Dec 06 20:23:38 thanks Dec 06 20:24:52 oh, and who 'wins' between an include file and an including file? First come lexigraphically? Dec 06 20:25:05 rcn-ee: btw, are there standard overlays distributed for the two PRU options, or are they not okay with being introduced by overlay? or in other worsd, what am I supposed to tell people trying to get pruss to work? Dec 06 20:25:18 acuster: order of appearance Dec 06 20:25:42 thanks Dec 06 20:25:54 basically you should read DT as a series of statements... "create this node", "set this property to that" Dec 06 20:27:20 (there are also statements to delete nodes and properties, although these don't work in overlays) Dec 06 20:27:33 zmatt, one of the pruss-backends, bomb's pretty bad as an overlay.. Dec 06 20:28:26 I'm guessing rproc... Dec 06 20:28:41 yeap, the one ti want's be to enable by default. ;) Dec 06 20:29:15 considering the uio_pruss driver doesn't do much more than uio_pdrv_genirq, which I know works fine in overlays Dec 06 20:30:11 (uio_pruss does handle the pruss intc in kernel space, which should make it a bit more efficient at irq handling) Dec 06 20:31:07 uio_pdrv_genirq does work fine with pruss though, and has the benefit of being part of mainline linux Dec 06 20:32:22 i'd like to just go back till for pruss-uio, just install the bone kernel (v4.9.x varient) ;) Dec 06 20:34:06 zmatt, oh, generic-board-startup does take quite a bit, specially with ssh key generations.. Dec 06 20:34:09 is that the official advice for newbies trying to get pruss to work (inevitably following some tutorial that uses uio_pruss) Dec 06 20:34:26 rcn-ee: ssh key generation takes time of course, but that's just once. I'm talking about every boot Dec 06 20:34:48 rcn: read my mail ? Dec 06 20:36:45 also, if you can't make the choice using an overlay, wouldn't it make sense to at least enable one of the two by default? Dec 06 20:37:35 zmatt, we did.. in v4.4.x-ti, remoteproc_pruss was enabled by default. ;) Dec 06 20:37:41 users didn't like that.. Dec 06 20:38:00 v4.4.x-bone had pruss_uio enabled.. Dec 06 20:38:36 people didn't like it because it didn't work with existing example code that relies on pruss_uio Dec 06 20:38:39 but, when v4.4.x-ti remoteproc_pruss was enabled, you couldn't enable the pruss_uio overlay, as the pruss node was already used by remoteproc_pruss.. Dec 06 20:38:51 oh right Dec 06 20:39:07 which is why i just told people to install the v4.4.x-bone and it would j Dec 06 20:39:09 pruss_uio for inexplicable reasons needs config Dec 06 20:39:44 so while the curretn v4.4.x-ti pruss sitution sucks, it allows both worlds.. Dec 06 20:40:18 well no, since you just said you can't enable remoteproc_pruss Dec 06 20:41:01 "in v4.4.x-ti, remoteproc_pruss was enabled by default" ... this is a 4.4-ti tree we're looking at, and remoteproc_pruss isn't enabled Dec 06 20:41:06 afaict Dec 06 20:41:10 I thought he just said both and once wouldn't work? Dec 06 20:41:37 zmatt, oh, look about 4 months ago? maybe 6... remoteproc_pruss was enabled intially by default for ti.. Dec 06 20:41:58 till we had that 100 thread post on the google group, then made neither "default" in the main dtb.. Dec 06 20:42:09 to make all parties equally unhappy? Dec 06 20:43:32 okay, July 5, 4.4.14-ti-r34 is when both options became availaable (disabled by default) Dec 06 20:43:54 I mean, since remoteproc can't be enabled by overlay, then I would have expected the uio one to be enabled instead Dec 06 20:44:15 leaving both out of the DT only makes sense to me if there's a runtime choice possible Dec 06 20:46:57 zmatt: children sleeping now... some time available for lxqt now.... Dec 06 20:47:31 but almost sure I need a black one Dec 06 20:48:39 or just kill the gui and learn to love ssh Dec 06 20:49:56 :-))) Dec 06 20:49:57 zmatt, something is blocking generic-*.., "time /opt/scripts/boot/generic-startup.sh" shows: real 0m1.896s Dec 06 20:50:54 fred_tv: it's also worth mentioning that the display PLL can be used as clock source for PRUSS :) Dec 06 20:52:10 I was telling rcn-ee I had to remove "BONE_P9_27 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* mcasp0_fsr.gpio3_19 */" from LCD7 .dts file to bring it to life.. Dec 06 20:52:50 wonder if they just invertd that pin? Dec 06 20:53:08 it is pulldown by default Dec 06 20:53:53 it was not an hardware issue nor a enable pin misconfigured (my clone is using nothing more than lcd data and sync pins) Dec 06 20:53:54 or the backlight for this glass, was inverted by default, and the developer didn't look to closly.. Dec 06 20:54:14 fred_tv: isn't that pin the enable pin? Dec 06 20:54:31 the fact that it works when low and doesn't work when high kinda suggests strongly that it is Dec 06 20:54:59 p9_27 is NOT used on my board , there is nothing connected to it ! Dec 06 20:55:15 fred_tv, then removing it, shouldn't change anything. ;) Dec 06 20:55:22 that suggestion is incompatible with anything caring about its pinmux Dec 06 20:56:03 try exporting it as gpio, set as output, and toggle it Dec 06 20:56:25 that's the strange thing....I've traced all pcb P9_27 goes NOWHERE on LCD board Dec 06 20:56:55 but it stay blank unless I remove that row on dts.... Dec 06 20:57:27 fred_tv, does it work if its set as"PIN_OUTPUT_PULLDOWN" Dec 06 20:57:35 echo 115 >/sys/class/gpio/export ; echo high >/sys/class/gpio/gpio115/direction Dec 06 20:57:41 try it Dec 06 20:58:04 no board on hansd now , tomorrow at office Dec 06 20:58:27 (writing "high" or "low" to direction changes the pin to output with the specified initial level) Dec 06 20:58:57 (no, this is not remotely intuitive) Dec 06 21:02:08 looking at A2 schematics where P9_27 (gpio3_19) goes....wait Dec 06 21:02:56 hmm, it claims not-connected Dec 06 21:04:10 and yet, if you are right that removing that line causes it to work, then something has to be connected to that pin Dec 06 21:05:13 wait Dec 06 21:05:13 nm Dec 06 21:05:26 I'm an idiot and was looking at the wrong connector Dec 06 21:05:39 on the original board it is connected to the "ENTER" button Dec 06 21:06:24 if not pressed, pulled up to 3v3 by 10k resistor... Dec 06 21:06:56 if that were true then the pull direction wouldn't matter Dec 06 21:08:29 maybe the clone you've got uses it in some weird way Dec 06 21:10:10 if it is a button , dts row shouldn't be (PIN_INPUT | MUX_MODE7) rather than PIN_OUTPUT ???? Dec 06 21:12:44 yes, though PIN_OUTPUT is slightly misleading name: it just disables the input receiver Dec 06 21:14:00 ultimately it's the peripheral you mux to that decides whether to enable the pin as output Dec 06 21:14:30 not understood... Dec 06 21:16:57 if you mux to mode 7 (gpio) then the gpio controller decides whether that pin is driven high, driven low, or not driven Dec 06 21:17:09 not driven is the default for all pins at reset Dec 06 21:17:38 PIN_INPUT vs PIN_OUTPUT in the pinmux has absolute zero influence on this Dec 06 21:18:38 ah ok ! Dec 06 21:19:20 PIN_OUTPUT just disables the input receiver, so if you do that with a gpio then it will always read as zero regardless of the pin's actual state Dec 06 21:20:33 in fact, but it has to be used as input if you have to detect the LCD7 board button is pressed or not.... Dec 06 21:20:56 yes, so it is weird Dec 06 21:22:02 normally you disable the input receiver on pins used exclusively as output (hence the name), to save power Dec 06 21:22:02 just asking myself how and IF the original LCD7 cape button works... if set that way Dec 06 21:22:57 another case where it would be useful is if the pin is floating or may be subject to intermediate voltage levels for extended periods of time Dec 06 21:23:11 aha ! Dec 06 21:23:48 noted this on dts: Dec 06 21:24:23 section bb_lcd_lcd_pins: pinmux_bb_lcd_lcd_pins: Dec 06 21:24:37 BONE_P9_27 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* mcasp0_fsr.gpio3_19 */ Dec 06 21:24:55 section bb_lcd_keymap_pins: pinmux_bb_lcd_keymap_pins: Dec 06 21:25:07 BONE_P9_27 (PIN_INPUT | MUX_MODE7) /* mcasp0_fsr.gpio3_19 */ Dec 06 21:25:27 lol Dec 06 21:25:35 then to answer your question: no, this overlay did not work Dec 06 21:25:54 yeah I see it now, lovely Dec 06 21:26:24 perhaps that's why removing first line mine works ?? Dec 06 21:26:43 yes, but then you will have had errors in the kernel log and should have mentioned those Dec 06 21:28:03 but a tremendous doubt remains : on my board that pin is floating: NC not connected : why should it influence its work ?? Dec 06 21:30:28 no but the kernel doesn't accept conflicting claims to pins, so either the lcd device would work but buttons would not, or the buttons work but lcd does not Dec 06 21:32:07 the choice between those options is the probe order, which is random (definition 5 of http://www.catb.org/jargon/html/R/random.html ) Dec 06 21:33:50 I have no buttons on my board so I don't care abut their configuration. That line, instead, should not be present into "bb_lcd_lcd_pins", isn't it ? Dec 06 21:34:22 correct Dec 06 21:35:13 if you don't have buttons I'd suggest also removing the bb_lcd_keymap_pins and (further down) gpio_keys sections entirely Dec 06 21:35:59 and the backlight section also (it is fixed on board by a resistor) not any pwm control Dec 06 21:37:41 yeah then you'll want to delete bb_lcd_pwm_backlight_pins, the backlight node, and fragment@2 Dec 06 21:37:43 and the leds also (no leds) ... :-))) it's only a lcd with resistive touch sensor Dec 06 21:38:27 touchscreen, not touch sensor since the sensing is actually done by the adc :) Dec 06 21:39:48 about syntax: if I remove i.e. fragment@2 does it matter if no 2 is present anymore ? Dec 06 21:40:24 no, the top-level node names of an overlay are in fact entirely irrelevant Dec 06 21:40:26 should they have an order with no holes ?? Dec 06 21:40:41 all that matters is that their names are distinct Dec 06 21:40:47 good Dec 06 21:42:05 for the rare occasion that I make overlays I actually made a script that converts a .dtsi file into overlay format so you don't manually have to write that ugly shit -> https://github.com/mvduin/overlay-utils Dec 06 21:42:32 I really don't understand why dtc doesn't do this for you Dec 06 21:43:28 i'll take a look ! Dec 06 21:45:08 metadata properties are simply put at top-level (see TT3201-001-01.dtsi for example) Dec 06 21:45:51 beware that my script doesn't try to genuinely parse the DT syntax, it just assumes you use sane indenting Dec 06 21:46:42 since I don't know how the whole thing works, when I modify the dts, I issue a ./install and reboot: is it right or is there a simpler/different way to commit the configuration to be executed immediately ? Dec 06 21:48:33 I don't use capemgr myself, but iirc to load an overlay just write its name to the slots file in sysfs, and for unloading same but with overlay name prefixed with a minus Dec 06 21:51:40 ah no, -slotnumber Dec 06 21:53:04 echo DTSNAME >/sys/devices/bone_capemgr*/slots ??? Dec 06 21:53:30 echo -slotnumber >/sys/devices/bone_capemgr*/slots ??? Dec 06 21:53:49 first to add , second to remove ? Dec 06 21:56:04 afaik yes, so in your case you need to remove first and then re-add it Dec 06 21:56:47 cape name is without version, so BB-BONE-LCD7-01 in your case Dec 06 21:58:12 does this way make it permanent at next reboot ? Dec 06 21:58:15 wait, you need a specific version actually, so the syntax for that is... if I'm reading this right (the capemgr driver source code), BB-BONE-LCD7-01:00A1 Dec 06 21:58:36 o Dec 06 21:58:37 A2 sorry Dec 06 21:58:41 ok Dec 06 21:58:51 and you need to install the dtbo first Dec 06 21:59:34 the capemgr always looks for its dtbos in /lib/firmware/ regardless of whether it's for a detected cape or a manual override Dec 06 22:00:43 beware that removing an overlay does not always work quite right, it is possible that you get a kernel panic on unload or subsequent load, or the result might not work Dec 06 22:01:04 in that case, obviously reboot is needed Dec 06 22:03:20 dtc -O dtb -o NAME.dtbo -b 0 -@ NAME.dts ?? Dec 06 22:04:19 no? Dec 06 22:05:12 do you mean with my overlay-utils project or with the original bb.org-overlays ? Dec 06 22:05:35 the original bb.org Dec 06 22:05:54 I thought you had already used it before? there's an ./install.sh Dec 06 22:08:09 once I have modified dts, I run ./install.sh, it rebuilds all dtbo, write a new initramfs and all is working after a reboot Dec 06 22:09:11 just need to modify a single dts , compile a new dtbo and replace in slots Dec 06 22:09:32 right.. no idea why it rebuilds them all but removing "make clean" from the ./install.sh hopefully fixes that Dec 06 22:09:34 instead, to check if it works without reboots Dec 06 22:12:26 you can also rebuild a single dtbo with the makefile: https://github.com/beagleboard/bb.org-overlays/blob/master/Makefile#L170 Dec 06 22:12:40 copy it to /lib/firmware/ and then reload it via capemgr Dec 06 22:14:01 or to try it without copying, unload the original via capemgr and load the new one using the bin/add-overlay utility in my overlay-utils project Dec 06 22:14:29 it doesn't care where the dtbo is located, you just give it a path Dec 06 22:15:07 right Dec 06 22:15:48 note that capemgr and the newer configfs mechanism for loading overlays aren't really aware of each other's existence, so overlays loaded by capemgr can't be seen or removed via configfs and vice versa Dec 06 22:15:53 my utils use configfs Dec 06 22:17:22 at last I'll go for ./install and reboot.... no need to modify dts files...just this one for LCD7 but now IT WORKS Dec 06 22:17:47 ? Dec 06 22:17:55 that is a dts file Dec 06 22:19:13 I mean usually I don't need to modify dts frequently and made experiments... Dec 06 22:19:24 ah yeah Dec 06 22:20:15 Tomorrow new issue to check: same LCD7 clone sitting on a BBblack prevent it to boot..... Dec 06 22:20:27 with white one is perfect Dec 06 22:21:19 perhps just load the correct dtb Dec 06 22:21:24 not booting from eMMC, or not even from uSD ? Dec 06 22:21:43 not even from SD Dec 06 22:22:07 not even with the S2 button held down during power up? Dec 06 22:22:08 no BB leds working.... Dec 06 22:22:14 not even the power led? Dec 06 22:22:16 not tried yet Dec 06 22:23:15 what does S2 at boot do ? Dec 06 22:24:00 S2 at power on (it is only sampled at power on, not at reboot/reset) influences the boot device order Dec 06 22:24:59 from {emmc,sd,uart,usb} to {spi,sd,usb,uart} Dec 06 22:27:17 ah ok, but it boots normally drom either SD or eMMC when no LCD cape installed Dec 06 22:27:53 that's because the u-boot installed on eMMC will still attempt to locate and boot a linux system on sd first Dec 06 22:28:29 but what about LCD7 cape ?? Dec 06 22:28:58 I mean the hardware board not the overlay Dec 06 22:29:02 ok, did you even read the LCD7 cape's wiki page at all? :P Dec 06 22:29:20 no :-((((( Dec 06 22:30:30 in the latest series they actually cut the physical pins that are used for eMMC signals Dec 06 22:30:51 they were apparently causing signal integrity to degrade sufficiently to cause problems at high speeds Dec 06 22:31:11 do you mean: Dec 06 22:31:14 The LCD7 Cape was originally designed for BeagleBone (White), which boots from SD card. When using with BeagleBone Black and booting from eMMC, the integrity of eMMC signals on some LCD7 Cape may be affected Dec 06 22:31:48 look at the two images under "known issues" Dec 06 22:33:34 reduced signal integrity would explain why it doesn't boot from uSD: probably ROM configures eMMC at a fairly low speed and loads SPL (first u-boot stage), but then SPL probably configures it at full speed and fails to load the second stage Dec 06 22:33:39 that's just my guess though Dec 06 22:34:39 they refer to http://www.elinux.org/File:Bbb-cape-pinout.jpg for eMMC signals but none of those pins are connected on my LCD board... Dec 06 22:35:13 nor on revision A3 of the LCD7 caoe Dec 06 22:35:15 *cape Dec 06 22:35:34 it's just the stubs that are causing trouble Dec 06 22:37:02 ah , picking noise or degrading signals ? Dec 06 22:37:47 reflections Dec 06 22:39:09 gotto go Dec 06 22:42:20 thank you for all Dec 06 22:42:33 time to bed here **** ENDING LOGGING AT Wed Dec 07 03:00:00 2016