**** BEGIN LOGGING AT Thu Mar 08 03:00:03 2018 Mar 08 04:09:26 jkridner|p: yeah Seeed has an interesting definition of "wiki" Mar 08 04:09:54 "our wiki, which is actually just statically generated documentation without any ability to edit it" Mar 08 04:10:58 Seeed-Studio just opened up their "Hub" again online for the BeagleBone Black/Green/etc... Mar 08 06:08:14 hey anyone here? Mar 08 06:13:45 http://www.catb.org/esr/faqs/smart-questions.html Mar 08 09:10:11 good morning. i want to protect my emmc content by running a readonly root FS on my beagle. the problem is, when i do that, i can't access GPIOs anymore (write). What is the right way to have a readonly root FS but don't lose functionality? Mar 08 09:11:11 microdevel: why should a gpio be affected by a read only rootfs? Mar 08 09:11:26 'was just about to ask the same thing... Mar 08 09:12:57 maybe i'm doing something wrong? i think sys is also readonly Mar 08 09:13:09 microdevel: then you're doing it wrong (TM) Mar 08 09:13:55 ok so you have it seen running successfully with a ro rootfs and writeable sys? Mar 08 09:14:19 not "it", but certinaly have seen and am using such systems. Mar 08 09:14:39 microdevel: so maybe, elaborate a bit on what you have done? Mar 08 09:15:55 ok so general question: to me it seems to be the best protection against sudden power loss. would you agree? Mar 08 09:17:18 read only rootfs are an integral part of most strategies to protect against unplanned power losses. Mar 08 09:17:29 (generic answer to a generic question) Mar 08 09:20:00 thanks, im happy with that.in your application, which way do you set rootfs to RO? kernel parameter or fstab? Mar 08 09:21:45 fstab, usually. Mar 08 09:24:24 ok, thanks for help Leto! Mar 08 09:24:35 good luck. Mar 08 09:24:43 =) Mar 08 10:04:43 microdevel1: whether the rootfs is readonly or not has no effect whatsoever on /sys Mar 08 10:05:54 zmatt: yes, i see. i was messing up fstab somehow :) Mar 08 10:08:37 also, if you want to protect against powerloss but still want the ability to write, consider reconfiguring the eMMC to SLC mode with reliable writes enabled. this should prevent power loss during write from affecting any sectors other than the one being written (hence ext4 journal should have no problem dealing with it), and also increases the total amount of data you can write before eMMC is bust by a Mar 08 10:08:43 factor of 10 or more. it ... Mar 08 10:08:45 ... also makes writes considerably faster. the price: eMMC's storage capacity is reduced by 50% Mar 08 10:09:03 ew, two different mechanisms to split up my message kicked in... wth Mar 08 10:09:28 * LetoThe2nd hands zmatt some gaffa tape Mar 08 10:13:31 sorry for repeating the message, but I just want to check if the problem is now fixed: Mar 08 10:13:37 also, if you want to protect against powerloss but still want the ability to write, consider reconfiguring the eMMC to SLC mode with reliable writes enabled. this should prevent power loss during write from affecting any sectors other than the one being written (hence ext4 journal should have no problem dealing with it), and also increases the total amount of data you can write before eMMC is bust by ... Mar 08 10:13:43 ...a factor of 10 or more. it also makes writes considerably faster. the price: eMMC's storage capacity is reduced by 50% Mar 08 10:13:46 much better Mar 08 10:30:07 zmatt: Have you seen cases when you apply 5V power to beaglebone and it wont start automatically? Mar 08 10:31:36 yes, with a lab supply that had a too gentle voltage slope when enabling the output Mar 08 10:31:48 zmatt: yeah i remember when we were talking about SLC mode some weeks ago Mar 08 10:32:15 so then the only way is to additionally press power button? Mar 08 10:32:27 oh it does respond to power button? that's odd Mar 08 10:32:37 the situation I'm talking about results in a pmic lockup Mar 08 10:32:52 how are you powering the beaglebone? Mar 08 10:32:55 yep, connect supply, nothing but press power and it boots Mar 08 10:33:14 via the power jack Mar 08 10:33:50 is there more stuff connected to the beaglebone? (e.g. via expansion headers) Mar 08 10:34:13 hdmi monitor and usb receiver Mar 08 10:34:20 usb receiver? Mar 08 10:34:25 yeah for keyboard Mar 08 10:35:08 so, the only thing I can think of is that it begins to power on but a pmic fault triggers Mar 08 10:36:20 possibly because external stuff has a high inrush current and/or the power supply can't keep the input voltage stable during the inrush current Mar 08 10:36:28 so lets assume to hardwire the beaglebone to a circuit board. what would be necessary to enable safe powerup? control 5V supply and possible toggle powerbutton? Mar 08 10:36:48 power button is normally not needed Mar 08 10:36:59 you might want to use a scope to debug this Mar 08 10:37:08 and in case of pmic lockup? power cycle? Mar 08 10:37:23 check what's happening with the 5v supply during power-up Mar 08 10:37:44 pmic lockup is easy to prevent, so usually not a worry Mar 08 10:38:00 problem is i saw this happening only once but this is a problem if you design a circuit board Mar 08 10:38:07 just make sure that during power up the supply goes from 0 to at least 4.3 V within 50 ms Mar 08 10:38:13 hmm Mar 08 10:38:33 ahhh where did you get that numbers from? couldnt find any info on that Mar 08 10:38:38 still, if the supply is unstable during power-up, this is something you should be able to see on the scope even if it doesn't trigger the fault Mar 08 10:38:48 true Mar 08 10:38:52 pmic datasheet Mar 08 10:39:07 I've also put a bunch of notes on this rather rough wiki page: https://elinux.org/BeagleBone_Power_Management Mar 08 10:40:29 ahh now i know who wrote this info, was reading it days ago ;) Mar 08 10:41:19 is there a way to tell properly if the board is booting? Mar 08 10:41:37 i mean from a signal point of view? i would love to use pmic pgood Mar 08 10:41:48 reset line Mar 08 10:42:07 but also, either PGOOD will go high, or a fault occurs and the board will power off Mar 08 10:42:50 ok so reset line is low when board is off / not booting and high as soon as the board starts? Mar 08 10:44:08 yes, though beware that there's a silly big cap on reset, so it goes up rather slowly: https://photos.app.goo.gl/VBQQRl7VVacQcPUk2 (green is PGOOD, brown is reset) Mar 08 10:44:56 https://andicelabs.com/beaglebone-powercape/ here they use 3.3V line to check if board is booting, dont understand why Mar 08 10:46:09 yeah its rather slow but still usable i think Mar 08 10:49:08 well, if the 3.3v goes up then the board will proceed to boot shortly thereafter (unless a pmic fault occurs and the board powers off) Mar 08 10:49:24 of course none of these really indicate the board is booting :) Mar 08 10:51:01 yeah but to really check if the board is booting one could use GPIO in uboot? Mar 08 10:51:11 or LEDs Mar 08 10:52:31 yeah or a gpio output configured in the device tree (this gets it enabled during early kernel initialization) Mar 08 10:52:42 all depends on what it is you want to determine really Mar 08 12:36:26 Hi everyone. Trying to disable HDMI on a BBB with bone-debian-9.3-iot-armhf-2018-03-05-4gb.img. Mar 08 12:36:31 Edited /boot/uEnv.txt Mar 08 12:36:52 Uncommented disable_uboot_overlay_video=1 Mar 08 12:37:03 are you booting from sd card or eMMC ? Mar 08 12:37:13 Rebooted, but gpioinfo keeps telling me the LCD related GPIOs are used Mar 08 12:37:24 yeah, sd card right? Mar 08 12:37:28 Booting from eMMC (used the SD and turned it into an installer) Mar 08 12:37:31 oh Mar 08 12:37:32 hm Mar 08 12:37:47 Checked that u-boot is up to date Mar 08 12:37:54 this is usually due to an old u-boot on eMMC being used, resulting in u-boot overlays not working Mar 08 12:37:58 how did you check that? Mar 08 12:38:41 did you change anything else in /boot/uEnv.txt ? Mar 08 12:38:56 also I've never heard of "gpioinfo" Mar 08 12:39:11 try my show-pins script maybe: https://github.com/mvduin/bbb-pin-utils/blob/master/show-pins Mar 08 12:39:14 eh Mar 08 12:39:25 https://github.com/mvduin/bbb-pin-utils/#show-pins that's the link I wanted Mar 08 12:39:47 since if hdmi is enabled, the pins aren't used for gpio Mar 08 12:40:30 Re u-boot being up to date, I followed https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays Mar 08 12:41:07 I actually suspect that hdmi is disabled and you just got confused by this utility Mar 08 12:41:24 Possible... gpioinfo is one of the utilities which use libgpiod. Mar 08 12:41:24 especially since apparently it uses the awkward chardev interface for gpio Mar 08 12:42:21 yeah, I'd skip libgpiod entirely... I still don't understand why on earth they think the new gpio chardev is any sort of improvement Mar 08 12:42:44 in any case, I suspect it doesn't even work on beaglebones in their default configuration Mar 08 12:43:53 zmatt: show-pins seems to think the LCD GPIOs are free, so you are probably right. Mar 08 12:44:49 Too bad, one of the poins in libgpiod was a GPIO monitoring utility which does exactly what I want (log GPIO changes with a timestamp). Oh well. Mar 08 12:44:54 by default "cape-universal" is enabled, which means that all usable gpios are automatically exported Mar 08 12:44:59 you can do that anyway Mar 08 12:45:15 open the 'value' attribute of the gpio in sysfs Mar 08 12:45:39 then use poll() or epoll to wait for POLLPRI / EPOLLPRI events Mar 08 12:46:00 oh, and configure the 'edge' attribute to 'rising', 'falling', or 'both' ... otherwise you won't receive any events Mar 08 12:46:14 Yes, I could, but I need faster reaction time than shell-level. I do have hackish C code to use GPIOs, I just thought I'd used libgpiod if it was a simpler approach. Mar 08 12:46:40 I'm not talking about "shell-level" Mar 08 12:47:25 I meant going through /sys. Mar 08 12:47:34 this is probably the fastest way you're going to get an event (although it might be interesting to benchmark it against using uio_pdrv_genirq to deliver a gpio-triggered irq to userspace Mar 08 12:47:44 what about it? /sys is a direct interface to the kernel Mar 08 12:51:29 It's just that I have code that does it already from (hold still) /dev/mem doing direct register access. Mar 08 12:51:45 in both cases there's an annoying amount of overhead due to going through the kernel... if you want *fast* gpio then /dev/mem is the way, but that doesn't get you notifications Mar 08 12:52:55 for receiving events from a gpio I suspect there's not a big difference between using gpio-sysfs, gpio chardev, or uio_pdrv_genirq Mar 08 12:53:02 performancewise I mean Mar 08 12:59:19 I think there's actually a decent chance gpio-sysfs is the fastest of the three since (iirc) it doesn't require an additional syscall to read the event from the fd or rearm it Mar 08 13:00:19 if you need accurate timestamps on edges, consider using one of the eCAP peripherals instead Mar 08 13:00:47 (it can timestamp edges on its input with 10ns accuracy) Mar 08 13:04:52 zmatt: interesting. Any pointer to get me started on eCAP? Mar 08 13:06:07 unfortunately I don't think there's a kernel driver for using it in capture mode, but you could use uio_pdrv_genirq to map it into userspace and receive its irqs Mar 08 13:07:00 using uio_pdrv_genirq is a topic that could use more docs and examples though, I don't think many people other than me use it on the beaglebone :) Mar 08 13:07:45 a while ago I made some examples in python though -> https://github.com/mvduin/py-uio Mar 08 13:08:10 all recent stuff there is related to uio-pruss, but the older examples are still there, including one for eQEP ... which isn't eCAP, but it's something Mar 08 13:08:21 hmm, maybe I can make a quick example for eCAP, that would be nice to have anyway Mar 08 13:15:26 eCAPs seem really promising. Thanks a lot zmatt! Mar 08 13:37:07 I have failed to install my driver(getting start step 2), error message is "non 7-zip archive". Can anyone help me? Mar 08 13:39:26 It could be that your file is corrupt so that 7zip does not recognize it. You can try downloading the driver again Mar 08 13:43:16 Jerry_: if you're using windows 10 and your beaglebone is running a recent image, you don't need to install any drivers Mar 08 13:53:02 however, I can not open the website http://192.168.7.2 Mar 08 13:54:10 I have downloaded another driver named 'BONE-D64.exe' sized about 1MB, it can still not be installed Mar 08 13:55:11 are you using windows 10? Mar 08 13:55:29 yes I am Mar 08 13:56:00 then I'd recommend fixing the problem by reflashing the beaglebone with the latest image Mar 08 13:56:06 and not install any driver Mar 08 13:57:15 OK, I will try Mar 08 13:57:17 thanks Mar 08 15:03:43 zmatt, Hi Mar 08 15:04:23 Could you compare two result from your show_pins script? Mar 08 15:04:37 https://paste.ubuntu.com/p/Mn5893vX43/ Mar 08 15:05:04 this one for a debian that touch screen not work (gsl1680) Mar 08 15:05:34 https://paste.ubuntu.com/p/XZscHGkCdq/ Mar 08 15:05:50 this one for an ubuntu that touch screen works Mar 08 15:06:08 both with the same hardware Mar 08 15:14:14 mehdi: which pins of the bbb are used for the irq and the shutdown pin (which the linux-sunxi wiki page called "iocntl" for some weird reason) Mar 08 15:14:17 ? Mar 08 15:37:03 hi live chat, i try to build a custom image with the image builder from https://github.com/beagleboard/image-builder/blob/master/readme.md but i got a certificate error, For building i use a beaglebonegreen with the lastest image Debian 9.3 2018-03-05 4GB SD IoT does anyone tried this ? Mar 08 15:43:03 zmatt, Could you see these pics Mar 08 15:43:05 https://pasteboard.co/HaXYnpm.jpg Mar 08 15:43:41 https://pasteboard.co/HaXYQI2N.jpg Mar 08 15:44:11 https://pasteboard.co/HaXZ32l.jpg Mar 08 15:44:35 https://pasteboard.co/HaXZdgz.jpg Mar 08 15:44:50 uhh can't you just locate the two signals I'm interested in instead of spamming a pile of screenshots? Mar 08 15:45:29 Sorry zmatt Mar 08 15:45:41 i don't know much about hardware Mar 08 15:45:42 based on the name I'd guess "TP.INT" is the interrupt line from the touchscreen Mar 08 15:46:16 well someone made this schematic I assume? Mar 08 15:46:38 were you not given a list of which pin is used for what? Mar 08 15:46:49 also, what device tree are you using in ubuntu? Mar 08 15:48:33 since the DT on ubuntu looks like it's already mostly tailored for your board Mar 08 15:48:52 the person who design the schematic is now unavailable! also the one who get things done in ubuntu.i don't have any other information.only the .dts file without some dtsi Mar 08 15:49:23 that "TP.WAKE" signal, where does it go? Mar 08 15:49:39 (pin 4 of CN5) Mar 08 15:50:03 okay sounds like you need some better internal communication Mar 08 15:50:12 since apparently someone already made a working device tree once Mar 08 15:50:19 zmatt, RP.WAKE p9.28 Mar 08 15:50:20 https://pasteboard.co/HaXZojG.jpg Mar 08 15:50:51 uhhhh what? Mar 08 15:51:14 oh Mar 08 15:51:15 huh Mar 08 15:51:17 wth Mar 08 15:51:40 okay whoever made that dts on your ubuntu system also did some really weird stuff Mar 08 15:52:05 P9.28 there is still configured as part of the pinmux for mcasp0 Mar 08 15:52:13 but it's not configured for mcasp0 but as gpio Mar 08 15:52:16 o.O Mar 08 15:53:11 but that gpio is not exported, so probably it's just floating with weak pull-up Mar 08 15:53:29 on your debian it has pulldown Mar 08 15:54:02 so that's presumably keeping the touchscreen controller in standby Mar 08 15:55:33 try: echo 113 >/sys/class/gpio/export ; echo high >/sys/class/gpio/gpio113/direction Mar 08 15:56:15 but really you should just make a proper device tree (or device tree overlay) for your board Mar 08 15:57:04 (e.g. based on the ubuntu one, although that one clearly also still needs improvement) Mar 08 15:57:13 Hey is anyone out there who could answer a few questions regarding the BeagleBone computers Max Output resolutions? Mar 08 15:57:58 the best way to find out is by asking those questions Mar 08 16:01:29 Is there a Beaglebone model that can output up to 4k resolutions? Mar 08 16:01:32 no Mar 08 16:02:02 Whats the max resolution any of them support right now? Mar 08 16:02:15 zmatt, it know load the driver without error!! oh my god.i think the touch now working Mar 08 16:02:22 now Mar 08 16:03:33 echo 113 >/sys/class/gpio/export ; echo high >/sys/class/gpio/gpio113/direction ? what is doing this command? Mar 08 16:06:39 doglookingforbon: the AM335x supports resolutions up to 2048x2048 pixels, but the limiting factor is the max 126 MHz pixel clock. Mar 08 16:08:08 and memory bandwidth Mar 08 16:08:37 it doesn't have much focus on graphics... just enough for e.g. some touchscreen interface Mar 08 16:11:27 zmatt, should i do any other setting for touch screen in eglfs environment? Mar 08 16:13:53 mehdi: sorry, to answer your earlier question: the two commands I gave did: 1. export gpio 3.17 (which is P9.28) via sysfs. this would normally happen automatically if the gpio were properly declared in your DT Mar 08 16:14:07 and 2. configure it as output-high Mar 08 16:14:19 thus enabling your touchscreen controller Mar 08 16:15:12 no idea about eglfs and touchscreen Mar 08 16:15:43 doglookingforbon: the beagleboard-x15 does have stronger video capability, but I don't have any specs at hand Mar 08 16:16:18 doglookingforbon: the x15 at the very least supports 1080p60 Mar 08 16:17:46 doglookingforbon: that might actually be its limit though Mar 08 16:18:05 zmatt, thank you man.thank you so much Mar 08 16:18:24 Could i ask another question?!! sorry Mar 08 16:19:42 don't ask to ask questions, just ask your question Mar 08 16:20:57 Is it hard to declare the p9.28 in dt file? if no could you send me a link to get start Mar 08 16:23:37 you're going to have to learn how to write DT stuff anyway since there's still a lot more stuff on your board that's not yet declared in your DT (e.g. the rs485 and CAN stuff I saw) Mar 08 16:24:17 plus right now there are buttons and leds declared that don't exist on your board (because you used the overlay for an LCD cape) Mar 08 16:25:02 but I might have an example for gpio declarations somewhere Mar 08 16:30:01 oh i also need to work with rs485 and CAN! my god Mar 08 16:31:27 well I assume so? that's what I saw in your schematic Mar 08 16:31:35 and ubuntu does configure those Mar 08 16:32:04 I really don't understand why you're doing this from scratch again if the work has already been mostly done previously by someone else Mar 08 16:33:47 the one who worked on this project now unavailable and he does not give the source also.but i have the source of dts without dtsi files! Mar 08 16:34:21 i think PINs declared in dtsi files Mar 08 16:35:27 here's an example of how you can declare gpios in device tree btw: https://pastebin.com/raw/CPiC2CnB Mar 08 16:36:46 anyway, I'm afk Mar 08 16:37:11 thank you so much Mar 08 17:01:12 hi Mar 08 17:02:20 can somebody make me aware who provides android support for beaglebone wireless support Mar 08 19:56:06 hi from e-ale Mar 08 19:58:09 Greeting from SCaLE Mar 08 19:58:21 great ! Mar 08 21:52:05 Hello, how can I disable DCAN's automatic retransmission? Mar 08 23:07:05 SummerBreeze: Automatic retransmission is part of the CAN spec, isn't it? A spec-compliant controller will have it built in. Mar 08 23:07:41 I have a hunch of what you're up to, though, and I wish everyone trying to do it would just get together and work on a common solution already. :P Mar 08 23:09:42 my guess: https://www.reddit.com/r/CarHacking/comments/7mgix1/can_transceiver_with_beaglebone_black_prus/druc264/ Mar 08 23:35:08 myself: you got me ;) Mar 08 23:35:57 Yes, it is a part of the specs, but in same scenarios it could be disabled. Mar 08 23:37:53 According to TRM, Bit 5 of the DCAN's CTL register can be set to 1 so the automatic retransmission is disabled Mar 08 23:38:18 I tried to disable it using devmem2, but the retransmission persists Mar 08 23:39:43 Ooooo, okay, that's important info. Mar 08 23:40:06 Can you twiddle other bits in that register and observe that they have the expected effect? (Confirm that you're twiddling the right register..) Mar 08 23:41:14 I guess I can, but the question is which register would have the most obvious effect? Mar 08 23:42:21 I dunno, whatever your other diagnostic tools can easily show you. I'm trying to bisect the problem between "register works, but this bit isn't implemented the way I expect" versus "I don't appear to actually be hitting the register I was trying to hit". Mar 08 23:43:13 good dissection to pinpoint what's going on Mar 09 00:36:48 Hi. We're having some issues booting a Blue from an SD. Mar 09 00:38:10 Might anybody be able to help us figure out what's wrong? Mar 09 00:51:11 hey Hendrix, I don't have a Blue but it's basically a Black with a cape built in, should boot the same. Mar 09 00:51:22 what're you trying, and what're you expecting, and what are you observing instead? Mar 09 02:50:02 <<<<<< finally learning about config-pin and setting up services Mar 09 02:50:43 Dudes and Ladies...I was unaware of how my system was set up. Mar 09 02:50:44 ... Mar 09 02:51:53 P9.21 and P9.22 was set to default as uart pins but was not stating it was uart pins. I set up uart on those two, specific pins and now I can set up a service for running software on boot. Mar 09 02:51:56 Am I right? Mar 09 02:52:19 Sheesh! Mar 09 02:52:45 <<<<< slow mo' Mar 09 02:53:46 When did config-pin take over our system for pin mux? Mar 09 02:54:26 e.g. 04-16 or 11-17? **** ENDING LOGGING AT Fri Mar 09 03:00:00 2018