**** BEGIN LOGGING AT Wed Dec 20 03:00:02 2017 Dec 20 03:26:00 hello, I have a question about connecting to a beaglebone green over USB: what driver do I need on the host side? I am using Linux and can't see the usb0 device Dec 20 04:16:52 found it, it's cdc_ether Dec 20 06:05:10 hello Dec 20 06:05:11 hi Dec 20 06:06:35 hi anyone there??? Dec 20 09:02:31 * zmatt . o O ( no, this channel is just inhabited by around 200 bots ) Dec 20 09:11:53 damn I've missed zmatt answer Dec 20 09:12:09 @zmatt are you still around ? Dec 20 09:22:06 here my question : I'm using a BBB on SD with "bone-debian-9.1-lxqt-armhf-2017-08-31-4gb.img" and I'm fighting to be able to have the max of GPIO on P8 by disabling HDMI. Dec 20 09:22:12 When I decomment uEnv.txt "disable_ubtoot_overlay_video=1" reboot and "echo 70 > /sys/class/gpio/export" + "echo 0 > /sys/class/gpio/gpio48/value" I'm rejected Dec 20 09:40:31 mouha1: https://pastebin.com/raw/Jg925yYH Dec 20 09:41:39 also, if you don't care about video, why are you using the lxqt image instead of the iot image? Dec 20 09:42:56 because it's a long time that I didn't used BBB so I took the image I thought appropriate Dec 20 09:43:18 the iot image is recommended for most purposes Dec 20 09:46:52 I just got it as you said Dec 20 09:48:10 ok ; I install the iot image and this would let me having the overlay directly ? Dec 20 09:49:45 iot vs lxqt is not directly related to your original problem, I just mentioned it is silly to use the lxqt image when you're going to disable video anyway Dec 20 09:49:55 for your original problem, see pastebin link Dec 20 09:50:51 yes indeed thanks for this Dec 20 09:51:05 ok I try with the user butn Dec 20 09:51:36 if the bootloader on eMMC is indeed the problem, the solution is reflashing eMMC (or just erasing it if you prefer to run from sd card, or if you specifically want to preserve the contents of eMMC then it's also possible to just upgrade the bootloader on it with a bit more effort) Dec 20 09:53:07 well to be honest I've tried to reflash the eMMC and waited 1H and it didn't worked out. So I took the easy way with sd card Dec 20 09:53:23 reflashing eMMC does not take an hour Dec 20 09:54:20 I added 45 + 15 in case of Dec 20 09:54:24 but I read 45" Dec 20 09:55:32 even that sounds a bit excessive... but I guess I'm not sure, I generally flash much smaller images than the lxqt image Dec 20 09:55:42 iot image will flash much faster than the lxqt image Dec 20 09:56:15 btw maybe you can tell me : I need a max of GPIO on p8 so this is the good way right ? Dec 20 09:56:41 because currently : echo 0 > /sys/class/gpio/gpio70/value Dec 20 09:56:41 -bash: echo: write error: Operation not permitted Dec 20 09:57:25 ohh, did you think to change the direction to output? Dec 20 09:58:17 damn I didn't since I've reboot with the SD Dec 20 09:58:33 (shame icon) Dec 20 10:00:06 btw, do be careful with using the last 16 pins of P8. most of them need to have specific values during power-on to ensure successful boot configuration. the beaglebone has integrated pull-up and pull-down resistors to ensure this normally, but they are quite weak (100 Kohm) hence it's easy to mess with this when connecting external hardware Dec 20 10:00:33 oooo Dec 20 10:01:40 we ran into that when connecting them to an external LVDS framer which had integrated pull-downs on its inputs... pretty weak pull-downs, but not weak enough Dec 20 10:01:56 so we had to add some external pull-ups on the right pins to fix that Dec 20 10:02:46 https://goo.gl/Jkcg0w if you go to the P8 tab of this spreadsheet I made, the critical pins are marked bright yellow Dec 20 10:03:32 next to the pin is an "L" or "H" indicating whether it is (and must be) pulled low or high during power-up Dec 20 10:06:06 actually it's inded to manage the sainsmart relays Dec 20 10:07:25 using these pins as outputs is generally safe, as long as the load has high input impedance (i.e. no significant current flows into or out of the load) Dec 20 10:07:53 well these are opto diodes : http://s3.amazonaws.com/s3.image.smart/download/101-70-103/16%2Brelay%2Bboard.rar Dec 20 10:08:27 leds (including those inside optocouplers) are significant loads Dec 20 10:08:56 so I can't directly connect the GPIO to optocouplers ? Dec 20 10:09:47 if connecting the yellow-marked pins, you have to make sure the led pulls the pin in the right direction Dec 20 10:10:40 besides "echo 1 > /sys/class/gpio/gpio70/value " or "echo 0..." doesn't change a thing Dec 20 10:10:59 i.e. pin --|>|-- gnd for pins that should be pulled down ('L') or pin ---|<|-- vdd for pins that must be pulled high ('H') Dec 20 10:11:00 I don't have any error, but it's still at 0v Dec 20 10:11:13 that's an unrelated issue Dec 20 10:11:36 sorry I didn't understant your last sentence Dec 20 10:11:44 I don't Dec 20 10:12:49 you mean : using a voltmeter for measurement is an unrealted issue? Dec 20 10:12:53 the --|>|-- is supposed to represent the led inside the optocoupler Dec 20 10:13:08 ok :) Dec 20 10:13:16 I mean that the issue I was talking about is to ensure the board will continue to boot properly Dec 20 10:13:24 I see now Dec 20 10:13:48 pins not responding to you trying to toggle gpios is an unrelated issue, probably configuration Dec 20 10:14:21 you can try checking the pin configuration using my 'show-pins' utility, which you can find here: https://github.com/mvduin/bbb-pin-utils/ Dec 20 10:15:17 oh great Dec 20 10:15:32 I need to try this Dec 20 10:16:46 also, do make sure the optocoupler doesn't require too much current. it is recommended to avoid running more than 4 mA through gpios of the beaglebone Dec 20 10:17:39 good to know ! Dec 20 10:18:48 (actually 4 or 6 mA depending on which pin, but it's simpler to just stick to max 4 mA for all pins) Dec 20 10:19:00 well I m confused "P8.46 / hdmi / sysboot 1 41 fast 0 lcd d1 0-0070 (nxp_hdmi_bonelt_pins)" Dec 20 10:19:17 it's configured to hdmi Dec 20 10:19:35 so the configuration is still bad, even if "echo 1 > /sys/class/gpio/gpio70/value " doesn't complains any more Dec 20 10:19:38 yes Dec 20 10:20:31 yes the gpio driver doesn't really know that the pin isn't configured to gpio Dec 20 10:20:37 hence no complaint Dec 20 10:21:33 if you've uncommented disable_uboot_overlay_video=1 in /boot/uEnv.txt then you're back at my original suggestion regarding the bootloader :) Dec 20 10:22:17 which also makes me wonder if your attempt at reflashing eMMC failed because it wasn't flashing at all maybe? Dec 20 10:22:44 (since even an attempt to reflash eMMC would at least erase eMMC, including the bootloader that resides there) Dec 20 10:22:54 yes suire Dec 20 10:24:12 but I thought that uncomment the uEenv.Txt with "cape_disable=capemgr.disable_partno" Dec 20 10:24:15 was ok Dec 20 10:25:08 with BB-BONELT-HDMI Dec 20 10:26:21 at the very least it should be "bone_capemgr" instead of "capemgr" Dec 20 10:26:31 that version applies when *not* using u-boot overlays Dec 20 10:27:17 ok ! so now I m lost :-D Dec 20 10:27:31 how to disable the HDMI then ? Dec 20 10:28:07 do you care about the current contents of your eMMC ? Dec 20 10:28:14 absolutely not Dec 20 10:28:29 I really need to drive these relays that s all Dec 20 10:28:34 then erase it with: sudo blkdiscard /dev/mmcblk1 Dec 20 10:28:48 uncomment the line disable_uboot_overlay_video=1 in your /boot/uEnv.txt Dec 20 10:28:49 and reboot Dec 20 10:29:08 the /boot on the SD ??? Dec 20 10:29:13 yes Dec 20 10:29:21 where else? Dec 20 10:29:23 ok (:-X) Dec 20 10:30:08 if you added any other lines to /boot/uEnv.txt, you can remove those Dec 20 10:30:40 (cape_disable= does not apply when using u-boot overlays) Dec 20 10:31:01 well actually this is almost "enable_uboot_overlay_video=1" Dec 20 10:31:08 that is uncommented Dec 20 10:31:24 huh, can you pastebin the contents of your /boot/uEnv.txt ? Dec 20 10:32:00 I'm expecting something like https://pastebin.com/JVr005Cf unless they changed it again Dec 20 10:32:14 line 32 of that pastebin would be the one to uncomment Dec 20 10:32:30 https://pastebin.com/cPDQa92d Dec 20 10:32:54 (btw, in case it's not clear: the purpose of erasing eMMC was to ensure the bootloader on SD card is being used, which will ensure all options in /boot/uEnv.txt work as they should) Dec 20 10:33:29 yes I got that part ;) Dec 20 10:33:40 yes, so uncomment line 30 of your /boot/uEnv.txt Dec 20 10:33:48 and besides in your file @ 12 you have the same Dec 20 10:33:52 i.e. change Dec 20 10:33:55 #disable_uboot_overlay_video=1 Dec 20 10:33:55 to Dec 20 10:33:58 disable_uboot_overlay_video=1 Dec 20 10:34:08 done I reboot Dec 20 10:34:20 after reboot, check the pin configuration again with show-pins Dec 20 10:39:25 crazy I think I boot on the mmc Dec 20 10:39:44 even with the blkdiscard Dec 20 10:40:07 blkdiscard completely wipes eMMC Dec 20 10:40:27 so no, you're not booting from eMMC anymore Dec 20 10:41:10 df -H ==> /dev/mmcblk0p1 3.5G 2.9G 367M 89% / Dec 20 10:41:21 mmcblk0 is sd card Dec 20 10:41:25 mmcblk1 is eMMC Dec 20 10:41:40 indeed Dec 20 10:41:45 (mmcblk0p1 is partition 1 of SD card) Dec 20 10:42:09 right Dec 20 10:43:07 "P8.45 / hdmi / sysboot 0 40 fast rx down 7 gpio 2.06 << lo P8_45 (pinmux_P8_45_default_pin)" Dec 20 10:43:10 alleluya Dec 20 10:43:13 :) Dec 20 10:43:24 please tell me that this is right Dec 20 10:43:32 yes Dec 20 10:43:36 I don't see any more show stopper Dec 20 10:43:43 once you change it to output, the << should change to >> Dec 20 10:44:38 no "echo 70 > /sys/class/gpio/export" is rejected Dec 20 10:44:44 DF%LGK DFG 35°Y %FMGK DFG% DF%Pi=à)ç Dec 20 10:44:45 no need to export Dec 20 10:44:49 it's already exported Dec 20 10:45:05 it's rejected because you can't export it twice Dec 20 10:45:56 when using cape-universal (enabled by default), all gpios which can be used are exported by default Dec 20 10:46:25 so the fact it wasn't exported before was actually an indication the pin was occupied for non-gpio use :) Dec 20 10:46:36 which is clever Dec 20 10:47:31 I owe you a big thanks Dec 20 10:47:44 not only for your help but also your patience Dec 20 10:47:48 np Dec 20 10:48:03 I was far from the solution Dec 20 10:48:28 and I remember to use carefully the bright yellow pins Dec 20 10:50:42 yeah. if you want to be able to use them unrestrained you might want to use something like a 16-channel bus switch that isolates all of them during boot (controlled by a gpio or the reset signal) Dec 20 10:56:21 anyway, I'm afk Dec 20 14:21:47 Hi @ all Dec 20 20:55:57 okay Dec 20 20:56:29 is there anyone know how to do factory reset for BeagleBone Green Wireless? Dec 20 20:57:27 I am trying to install TI SDK Dec 20 20:57:55 not on your scedule, apparently... Dec 20 21:08:07 also, why would he want to do a "factory reset" if he's going to use a different image anyway? Dec 20 22:49:24 I am having problem getting my bbb to read uenv.txt files anyone here can help? Dec 20 22:53:18 error: question too vague Dec 20 22:54:59 I am trying to get u-boot to load kernel image and dtb automatically using an uEnv.txt file that I have written Dec 20 22:55:44 when I manually entered the contents of the uEnv.txt one by one manually from the u-boot command prompt Dec 20 22:56:30 I can boot the system, but not when I try to get u-boot to read and load the uenv.txt file Dec 20 22:57:55 uhh, uEnv.txt contains environment variables for u-boot, not commands Dec 20 22:58:23 hence the name Dec 20 22:58:46 I understand that Dec 20 22:59:13 but you should be able to get it to load a kernel and dtb of your choice by setting the uname_r and dtb variables Dec 20 22:59:45 in the uenv.txt command such as the following can be entered "setenv ipaddress 192.168.1.55" Dec 20 22:59:55 nope Dec 20 23:00:01 I meant ipaddr Dec 20 23:00:27 it reads key-value pairs, not commands Dec 20 23:02:48 e.g.: https://pastebin.com/raw/4VAar3NW Dec 20 23:03:21 that's the uEnv.txt variables I use to get that kernel and dtb loaded Dec 20 23:04:13 https://pastebin.com/8d2JGL87 Dec 20 23:06:00 instead of repeating myself, I'll just copy-paste: 23:57 < zmatt> uhh, uEnv.txt contains environment variables for u-boot, not commands Dec 20 23:07:47 what you have sent is the content of the uenv.txt file located on mmc1 when the actual Linux operating system as booted Dec 20 23:07:57 I am looking at u-boot level Dec 20 23:08:36 there is meant to be an ability on u-boot to allow booting from mmc 0 which is the sdcard slot Dec 20 23:09:02 yes, it works the same for eMMC and SD card (it tries SD card first, then eMMC) Dec 20 23:09:52 normally an ext4 rootfs is used... using a FAT partition might still be supported too but I have no idea if that's still true and if it needs any special considerations Dec 20 23:09:59 No it tries eMMC first and the only time it attempts SD card is if the button closer to the SD card is pressed on power up Dec 20 23:10:17 no, those are the rules used by the ROM bootloader to locate u-boot Dec 20 23:10:54 the boot script used by u-boot (at least the ones that ship with beaglebones and beaglebone debian images) first try to boot linux from SD card and then eMMC Dec 20 23:10:59 *tries Dec 20 23:11:56 I am not using debian. I have built a custom zImage, am335x-boneblack.dtb and root files system Dec 20 23:12:38 which I can interrupt the boot process and start loading the kernel image manually from the command prompt Dec 20 23:12:58 as follows "fatload mmc 0:1 0x80200000 zImage" Dec 20 23:14:10 which would load the image I built to the location specified, I can further to likewise for the dtb "fatload mmc 0:1 0x80f00000 am335x-boneblack.dtb" Dec 20 23:14:57 if you're booting the system in an entirely custom way (i.e. not the default u-boot and not a rootfs that has the kernel and dtb in standard locations) then you'll have to consult u-boot's complicated boot script yourself to figure out what works for you Dec 20 23:15:05 or custom build u-boot with the rules you want Dec 20 23:17:55 the whole idea of the uenv.txt file as I understand it, is that it allows environment variables to be setup so during the u-boot phase it can read the contents of the uenv.txt and boot Dec 20 23:18:30 correct, it reads variables which are then used in the boot script embedded in u-boot Dec 20 23:18:58 note: this is assuming you're using rcn's u-boot. I have no idea if mainline u-boot even cares about a file name "uEnv.txt" Dec 20 23:19:05 *named Dec 20 23:19:07 when you boot the operating system as in your example the contents of the eMMc is mount to a directory /boot/ Dec 20 23:19:26 no Dec 20 23:19:46 eMMC is mounted at / Dec 20 23:20:09 my error correction /boot Dec 20 23:20:24 /boot is not a mountpoint, it's just a subdirectory Dec 20 23:24:08 my problem is not that I can't load a debian image to the bbb. My issue is purely academic. I what to understand u-boot working behaviour Dec 20 23:24:26 https://pastebin.com/raw/eCuPKTgg Dec 20 23:24:43 to understand u-boot's behaviour, you'll need to study its bootscript Dec 20 23:25:12 you can either dig into the source code for that, or print the built-in environment variables using printenv Dec 20 23:25:35 I have been doing that Dec 20 23:26:56 when the board boots I can interrupt it and detect that it has loaded my own built u-boot which is has been loaded on the first partition Dec 20 23:27:43 I can then setup my bootargs to point to my development pc for is rootfs using nfs Dec 20 23:28:28 so what I am looking for is a way to automate this process, which I believe I should be able to achieve this with u-boot Dec 20 23:28:34 it may be simpler to just build an u-boot with exactly the boot commands you want Dec 20 23:28:45 or build an u-boot with "saveenv" capability and use that Dec 20 23:29:08 anyway, I'm afk for a bit, back in 20-30 minutes ors o Dec 20 23:29:26 no worries thanks for your time Dec 21 00:57:21 with the OSD3358 and OSD335x-sm from Octavio systems it is almost tempting to DIY ones own beagle bone compatible board. Dec 21 01:02:04 I believe that's exactly what they're intended for Dec 21 01:10:14 Definately they are targeting small companies, otherwise only the brave (crazy?) could make a decent BB design because of the complex issues of all the power RTC and other system components. Dec 21 01:29:09 Anyhow I'm working through a BBB design I had in mind years ago just now it might actually be doable with the OSD3358 being what it is. The BBB had IO issues for what I wanted to do (namely the big issue). Dec 21 01:33:25 pinmux choices didn't accommodate your plans, I'm guessing? Dec 21 01:34:19 it isn't all that complex Dec 21 01:51:05 Well first the tool I had was KiCAD as my PC died that had an EDA tool I was used to using. So there was that. Then I had to overcome lazyness. However there are existing KiCAD parts made for the OSD3358 and more importantly it works because the PocketBeagle used the same part. Next comes knowing the processor which at the time I didn't. Last comes the fact I didn't have a lot of time. I still down but I have more incentive to Dec 21 01:51:05 get it done. **** ENDING LOGGING AT Thu Dec 21 03:00:00 2017