**** BEGIN LOGGING AT Tue Mar 13 03:00:03 2018 Mar 13 03:00:39 roughly my uenv.txt.. since I'm newbish at arm/u-boot.. https://sources.debian.org/src/vmdebootstrap/0.5-2/examples/beagleboneblack-customise.sh/ Mar 13 03:01:03 but with initrd/vmlinuz switches to the newer kernel will not boot Mar 13 03:01:18 kernel starts to load, that's about it Mar 13 03:02:13 o.O Mar 13 03:02:22 why is it manually overriding so many u-boot variables? Mar 13 03:02:29 I've never ever needed to set most of those Mar 13 03:03:00 not sure, that script is quite old.. since it's part their guide on building custom images for bbb Mar 13 03:03:23 and only an example for users to follow Mar 13 03:03:23 I just set uname_r, dtb, cmdline, and console Mar 13 03:03:48 if i have initrd and kernel set to the right file.. that should be enough though, right? Mar 13 03:04:12 our images are based on the console images from rcn originally, although not much remains of them Mar 13 03:04:42 normally those are determined from uname_r by u-boot's boot script Mar 13 03:05:08 at least, that's the case when using the default u-boot used on beaglebone images Mar 13 03:05:29 yeah, I mean.. I should probably blame their kernel.. Mar 13 03:05:34 Hi Can i propose the same projects that are listed in the IDEAS page? Mar 13 03:05:47 chillfan: why not just get a prebuilt debian stretch image and go from there? Mar 13 03:05:50 since I can't see a reason for it not booting and getting stuck, maybe the initrd is missing the support Mar 13 03:06:13 well, I want more of a custom image.. since this will just be a home server and keep it small Mar 13 03:06:22 join Mar 13 03:06:23 I'm not using initramfs myself... it doesn't really have much benefit at all Mar 13 03:06:27 I suppose I'll just have to compile my own later Mar 13 03:06:28 hello Mar 13 03:06:36 Hi Can i propose the same projects that are listed in the IDEAS page? Mar 13 03:06:38 Hi Can i propose the same projects that are listed in the IDEAS page? Mar 13 03:06:38 chillfan: I don't suggest getting a big image like the iot (let alone lxqt) images Mar 13 03:06:42 Hi Can i propose the same projects that are listed in the IDEAS page? Mar 13 03:06:48 hhg_: stop spamming Mar 13 03:06:54 sorry Mar 13 03:07:16 hhg_: and ask a clear question. i have no idea what you're talking about Mar 13 03:07:45 chillfan: just get a console image (which is pretty minimal), remove any packages you don't care about and install whatever you do care about Mar 13 03:08:35 there are some project ideas that are listed in the page right? Can i take any of those ideas as my proposal? Mar 13 03:08:47 what page are you talking about? proposal for what? Mar 13 03:09:11 GSoc Mar 13 03:09:23 oh I don't know anything about that. try #beagle-gsoc Mar 13 03:09:47 chillfan: at least it'll get you a system that works without much fuss Mar 13 03:10:05 #beagle-gsoc Mar 13 03:10:19 typing the channel name doesn't make you magically join it Mar 13 03:10:48 join #beagle-gsoc Mar 13 03:11:01 try with a / in front of it Mar 13 03:11:08 ok thx Mar 13 03:29:38 ah, /dev/urandom never blocks even in current kernels, I was thinking of the getrandom() system call instead Mar 13 03:48:47 There seems to be a problem with the latest two revs of Ubuntu for X15, the filesystem isn't found. i.e. Mar 13 03:48:54 U-Boot 2017.01-00360-gc604741cb3 (Aug 11 2017 - 15:47:09 -0500), Build: jenkins-github_Bootloader-Builder-592 CPU : DRA752-GP ES2.0 Model: TI AM5728 BeagleBoard-X15 Board: BeagleBoard X15 REV C.00 DRAM: 2 GiB MMC: OMAP SD/MMC: 0, OMAP SD/MMC: 1 ** Unable to use mmc 0:1 for loading the env ** Using default environment setup_board_eeprom_env: beagle_x15_revc SCSI: SATA link 0 timeout. AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 im Mar 13 03:49:20 Any advise? Mar 13 03:49:30 don't paste multiline output into irc, it just becomes a big unreadable mess. use a paste service like pastebin.com Mar 13 03:52:50 Sorry, how's this: Mar 13 03:53:32 ehm, next time just paste the url and not a piece of html to embed it Mar 13 03:54:34 what does ls /dev/mmc* show? Mar 13 03:55:10 Checking... Mar 13 03:55:26 BTW: the url is: https://pastebin.com/index/i0LHY4Ki Mar 13 03:55:55 the url is https://pastebin.com/i0LHY4Ki Mar 13 04:01:41 ls /dev/mmc* doesn't exits Mar 13 04:01:44 exist Mar 13 04:01:52 well that's not good Mar 13 04:02:23 check lsmod ? dmesg ? Mar 13 04:03:14 asmod: command not found Mar 13 04:03:41 (spell checker! ) lsmod: command not found Mar 13 04:04:52 oh, cat /proc/modules then I guess Mar 13 04:05:51 a quick scan through dmsg, I don't see any attempt to mount/load mmc support... Mar 13 04:06:11 no mention of mmc devices at all? Mar 13 04:06:21 dmesg | grep -i mmc (let's hope grep works) Mar 13 04:07:59 the only kernel modules under /lib/modules are for kernel/fs/... Mar 13 04:09:06 grep of dmsg shows two lines: the command line "... root=/dev/mmcblk0p1 ro ..." Mar 13 04:09:22 sounds like it's failing to load kernel modules Mar 13 04:09:31 and: bias_mmc_omap5: disabling Mar 13 04:09:53 either because they're missing in /lib/modules/$uname_r or because they haven't been indexed using depmod Mar 13 04:10:06 (missing in /lib/modules/$uname_r in the initramfs I mean) Mar 13 04:10:11 They're missing Mar 13 04:10:46 That is, the only kernel modules under /lib are the few for filesystems. Mar 13 04:11:14 actually, wait it's probably compiled in Mar 13 04:11:26 I'm puzzled by how this got released and nobody else noticed it, I wonder if there couldn't be something specific to your setup that's causing the problem. Would it be appropriate to suggest trying another SD card (of a different size), perhaps? Mar 13 04:11:55 myself: if the card were an issue with the kernel, there'd be *some* log message about it almost certainly Mar 13 04:12:08 srd: ls /sys/class/mmc_host Mar 13 04:12:48 myself: maybe noone uses ubuntu instead of debian? ;) Mar 13 04:13:16 myself: my thoughts exactly, last night. today I tried two cards, different brands, different sizes (8G, 32G) same thing. Mar 13 04:13:19 I mean the BeOS builds could've been broken for months... Mar 13 04:13:38 BeOS builds? o.O Mar 13 04:14:18 ls of /sys/class/mmc_host is empty Mar 13 04:15:19 does /sys/bus/platform/drivers/omap_hsmmc exist ? Mar 13 04:16:24 yes Mar 13 04:16:53 okay so the driver is compiled-in but there are no mmc host devices, that means they're not enabled in DT Mar 13 04:19:03 that's weird, they should be Mar 13 04:20:02 does /sys/bus/platform/drivers/omap_hsmmc contain anything other than the "bind", "uevent", and "unbind" attributes? Mar 13 04:21:34 no Mar 13 04:22:05 ls -d /sys/devices/platform/ocp/*.mmc Mar 13 04:22:43 cat /proc/device-tree/ocp/mmc@4809c000/status Mar 13 04:23:12 no ocp under platform Mar 13 04:23:54 uhh what? Mar 13 04:24:43 what's in /sys/devices/platform then? Mar 13 04:25:17 also can you pastebin the full dmesg output? Mar 13 04:25:41 this is where I open a port for screen/tmux and let someone come in and poke around on their own :P Mar 13 04:25:49 cat of .../mmc@4809c000/status is "okay" Mar 13 04:27:42 how on earth can there be no ocp under /sys/devices/platform ... Mar 13 04:30:15 dmesg is here: https://pastebin.com/kqcBeyPQ Mar 13 04:33:34 it does detect a variety of devices, all of which should live inside /sys/devices/platform/ocp Mar 13 04:33:57 oh huh Mar 13 04:34:03 it's called 44000000.ocp for some reason Mar 13 04:34:06 weird Mar 13 04:34:30 okay well, ls -d /sys/devices/platform/44000000.ocp/*.mmc then Mar 13 04:34:37 ok.... Mar 13 04:35:28 480b4000.mmc Mar 13 04:35:40 4809c000.mmc Mar 13 04:35:53 ls -l /sys/devices/platform/44000000.ocp/4809c000.mmc Mar 13 04:37:00 of_node->... Mar 13 04:37:08 uevent Mar 13 04:37:11 modalias Mar 13 04:37:13 just copy/paste to pastebin please Mar 13 04:37:18 driver_override Mar 13 04:37:23 power/ Mar 13 04:37:27 don't paste multiline output into irc Mar 13 04:37:31 subsystem->... Mar 13 04:37:52 also that's not the output of ls -l Mar 13 04:38:02 but anyway... so the device is there, the driver is there Mar 13 04:38:07 but the driver isn't bound to the device Mar 13 04:38:10 w.. t.. f.. Mar 13 04:38:22 well fuck it Mar 13 04:38:38 echo 4809c000.mmc >/sys/bus/platform/drivers/omap_hsmmc/bind Mar 13 04:40:07 also, since it sounds like all ingredients for booting are in the kernel (assuming the fs driver kernel modules you mentioned don't include ext4 for the rootfs) there shouldn't be any need for an initramfs in the first place Mar 13 04:40:24 and I'm getting the impression the initramfs here is just broken Mar 13 04:40:31 or maybe not, dunno Mar 13 04:40:46 no wait, the kernel should have probed the driver in this case Mar 13 04:41:02 initramfs could only be to blame if it were a kernel module Mar 13 04:41:16 I don't know, this is really really fucking weird as hell Mar 13 04:41:48 pastebin.com/HwGcXtjd Mar 13 04:45:45 echo 4809c000.mmc >/sys/bus/platform/drivers/omap_hsmmc/bind Mar 13 04:45:58 sh: write error: No such device Mar 13 04:46:22 okay maybe that kernel is just fucked Mar 13 04:46:57 OK, well, thanks. I thought I'd give Linux/Ubuntu a try... Mar 13 04:47:30 or more specifically, for some reason mmc on that kernel with the x15 is fucked Mar 13 04:48:48 any suggestions when I should try again? a few days? weeks? months? Mar 13 04:49:36 I'd like to benchmark what I'm using against Linux... Mar 13 04:50:18 where did you find this image anyway? you might want to try the latest debian image from https://beagleboard.org/latest-images Mar 13 04:50:27 those should actually be tested Mar 13 04:54:22 argh, I tried debian, but switched to Ubuntu because I had trouble getting WiFi networking to work (I've configured WiFi no prob on other platforms) Mar 13 04:54:44 I'll try again tomorrow... Mar 13 04:54:46 thx Mar 13 04:54:47 which ubuntu image are you using exactly? Mar 13 04:55:27 searching... Mar 13 04:56:47 from: https://elinux.org/BeagleBoardUbuntu Mar 13 04:57:08 https://rcn-ee.com/rootfs/2018-03-09/elinux/ubuntu-16.04.4-console-armhf-2018-03-09.tar.xz Mar 13 04:57:55 tar.xz ? not the .img.xz ? Mar 13 04:58:14 oh wait Mar 13 04:58:16 huh Mar 13 04:58:42 oh it's a setup script? not a prebuilt image? weird Mar 13 04:59:13 I doubt it matters, but you can also try a prebuilt image from https://elinux.org/BeagleBoardUbuntu#BeagleBoard-X15 Mar 13 05:01:08 No, sorry, the webpage has a typo. the actual image file is also available (with the correct URL) Mar 13 05:01:25 okay you did use the prebuilt img Mar 13 05:01:52 wget https://rcn-ee.com/rootfs/2018-03-09/microsd/bbx15-ubuntu-16.04.4-console-armhf-2018-03-09-2gb.img.xz Mar 13 05:01:54 yes. Mar 13 05:04:56 I've sent an email to rcn about this Mar 13 08:09:50 Hello, I am looking to enable all the 4 UARTs on the BeagleBone Black. Mar 13 08:10:11 Can someone help point me in the right direction? Mar 13 08:10:47 it has more than four Mar 13 08:12:55 7 actually, but uart0 is used as serial console, the pru uart is kinda special, and uart3's rxd isn't available on the expansion headers (though its txd is, and if you really want it you can still get to uart3 rxd with some effort) Mar 13 08:13:23 I think most of them should be enabled by default though? all you have to do is configure pinmux using config-pin Mar 13 08:13:26 Sorry, I got logged out. Mar 13 08:13:39 Yes it has more than 4 UART3 is TX only. Mar 13 08:13:41 https://pastebin.com/raw/QHkeGjZv Mar 13 08:13:53 But I need to use 4 of them for my application. Mar 13 08:14:23 and if you want to use uart5 you'll need to disable hdmi Mar 13 08:15:34 @zmatt. Understood. Mar 13 08:15:41 uart3 rxd can actually be accessed by soldering onto one of the pads of the jtag header, but that's located on the bottom side so it's a bit icky Mar 13 08:16:01 I dont need 5 UARTs. I am OK with 4. Mar 13 08:16:18 uart1, uart2, uart4, and uart5 it is then Mar 13 08:17:04 I changed the /boot/uEnv.txt to contain "capemgr.enable_partno=BB-UART1, BB-UART2. BB-UART4, BB-UART5 Mar 13 08:17:04 if you disable video in /boot/uEnv.txt then all four should be automatically enabled (assuming you use a sufficiently recent image in the default config) Mar 13 08:17:23 are you using a kernel that's *that* old ? Mar 13 08:17:58 But that did not work for me. Mar 13 08:18:05 that's for 3.8 kernels Mar 13 08:18:49 if you're using a recent image, you don't have to enable the uarts, they should be enabled by default. all you need is disable hdmi by uncommenting the "disable_uboot_overlay_video=1 Mar 13 08:18:56 " line that should be in /boot/uEnv.txt Mar 13 08:19:39 and configure your pins using e.g.: config-pin P9.11 uart Mar 13 08:19:42 OK, I did reflash the BBB. I am a first time BeagleBone Black user. Mar 13 08:19:59 there's a lot of outdated information on the web Mar 13 08:20:01 so beware of that Mar 13 08:20:19 Where is this documentation? All the web searched points me to these steps. Mar 13 08:21:24 I have no idea how newcomers are supposed to know this, but that's also because I'm not a newcomer and don't generally try to look for introductory materials :) Mar 13 08:21:55 :-D Mar 13 08:22:14 Newcomers ask people like you, who aren't newcomers Mar 13 08:22:24 but yeah, poor documentation is a known problem Mar 13 08:23:04 the old mechanism should actually still work too though Mar 13 08:23:08 I have a made a cape board with 2 MAX3232 to bring out the 4 UARTs. Mar 13 08:23:11 but it's not quite as flexible Mar 13 08:23:27 and now I am not able to get it to throw out or accept any data. Mar 13 08:23:35 the pins on the BBB stay low. Mar 13 08:23:53 so, for a long time now something called "cape-universal" is enabled by default Mar 13 08:24:08 which basically enables all peripherals, and allows runtime configuration of pinmux using the 'config-pin' utility Mar 13 08:25:19 the older way of enabling overlays should also still work, but enabling any such overlay will implicitly disable cape-universal so you can't mix the two approaches Mar 13 08:25:36 OK. Mar 13 08:25:44 the way you tried to enable them however no longer works Mar 13 08:26:08 I had to send out the only board I have/had to get the enclosure made. Mar 13 08:26:20 I can't try it now now:-( Mar 13 08:26:21 instead you need to set them in individual vars you can find under "Additional custom capes" in /boot/uEnv.txt Mar 13 08:28:38 I captured the advice in https://pastebin.com/5DDBiV7i Mar 13 08:28:38 or, if you've put a CAPE identification eeprom on your cape, program it suitably, and make an overlay, then your cape will actually get autodetected and the overlay automatically loaded ;) Mar 13 08:29:06 Oh! wow, I am not going to do all that for this. Mar 13 08:29:26 hehe, I wasn't really seriously suggesting it Mar 13 08:30:03 although overlays can be reasonably not-obnoxious to make if you use my overlay-utils Mar 13 08:30:47 for example, this source code: https://github.com/mvduin/overlay-utils/blob/master/uart4.dtsi is how enable one uart and configure its pins Mar 13 08:31:02 ('make uart4.dtbo' would produce the compiled overlay) Mar 13 08:31:28 Matt, I have not idea what tools are available and where to look for them. Mar 13 08:32:27 also, if you want to get a nice overview of the current pinmux state, I made a utility for that: https://github.com/mvduin/bbb-pin-utils/#show-pins Mar 13 08:32:37 I will try the tool when I get my BBB back. Mar 13 08:33:16 Thanks for the tools and pointing me in the right direction. Mar 13 08:33:22 making overlays is something you probably shouldn't bother with though, at least not as long as cape-universal and config-pin does the job for you Mar 13 08:33:38 OK. Mar 13 08:34:17 I flashed the bone-debian-9.3-iot-armhf=2018-03-05-4gb.img Mar 13 08:34:27 yeah that would be fine Mar 13 08:34:52 So, I have a fairly recent, if not bleeding edge kernel right? Mar 13 08:35:30 fairly recent. Mar 13 08:36:23 When are you around next Matt? Mar 13 08:36:42 I guess, I am going to need more help Mar 13 08:36:45 I'm frequently here Mar 13 08:37:08 I am Bangalore, India. Its 2PM here. Mar 13 08:37:34 It could be exactly opposite where you are :-) Mar 13 08:37:37 in general you can usually get help here if you ask sensible questions and have patience Mar 13 08:37:38 2AM Mar 13 08:37:47 nah, it's 9:37 Mar 13 08:38:32 OK. I will get my board back in 3 hours may be. Mar 13 08:38:46 In the meanwhile, I will test my UART capes. Mar 13 08:39:14 zmatt: 9:39! you're early! Mar 13 08:39:38 uhh, we're both right? Mar 13 08:39:41 09:37 < zmatt> nah, it's 9:37 Mar 13 08:39:43 09:39 <@LetoThe2nd> zmatt: 9:39! you're early! Mar 13 08:40:04 it's called "the passage of time" Mar 13 08:40:05 ;) Mar 13 08:40:28 :-( Mar 13 08:41:25 https://electronics.trev.id.au/2017/04/10/enable-uarts-element-14-beaglebone-black-rev-c/ Mar 13 08:41:42 These are the steps I followed earlier, with no luck. Mar 13 08:42:11 tsk, they let their ssl cert expire Mar 13 08:43:06 that's bizarre... that article is less than a year old, yet what he's describing only applies to really ancient images Mar 13 08:43:37 unfortunately he doesn't have a comments section Mar 13 09:04:40 Am I here? Mar 13 09:05:02 getting philosphical Mar 13 09:05:44 my feeling is that yes, you are indeed here. Mar 13 09:05:51 zmatt, I had shorted P9.11 and P9.13 to create a loopback to try on minicom and nothing came up after following the procedure in the link shared earlier. Mar 13 09:06:11 you configure both P9.11 and P9.13 to uart mode? Mar 13 09:06:14 *configured Mar 13 09:06:25 (double-check with my show-pins script perhaps) Mar 13 09:06:43 Nope. I did nothing more that what was on the page. Mar 13 09:07:25 I did not know I had to configure the pins explicitly. I assumed that the /boot/uEnv.txt change took care of all the underlying things. Mar 13 09:07:42 Evidently not. Mar 13 09:08:17 you're talking about this page? https://pastebin.com/5DDBiV7i Mar 13 09:08:46 No this one - https://electronics.trev.id.au/2017/04/10/enable-uarts-element-14-beaglebone-black-rev-c/ Mar 13 09:08:50 the uEnv.txt change disables hdmi which is necessary to free up a whole bunch of expansion header pins for free use Mar 13 09:08:57 Hello, everyone! Can anyone get the DSP examples for the BeagleBoard X15 working? They compile without errors, but when I run them I get an error: "TIOCL FATAL: OpenCL needs at least one CMEM block in off-chip DDR to operate, plus optional CMEM block in on-chip (MSMC SRAM or OCMC RAM) memory." Mar 13 09:09:04 but I already pointed out that those instructions are obsolete Mar 13 09:10:27 @zmatt, I just wanted to point to what I referred to, while trying to get the UARTs up. Mar 13 09:10:31 (they were also obsolete a year ago, so I don't understand why instructions like these are in this relatively recent article) Mar 13 09:10:45 ohh, you were just explaining what you did Mar 13 09:10:55 Yes sir. Mar 13 09:11:26 I will have no new updates until I get my board back. Mar 13 09:11:27 on current images, the uEnv.txt change given in that article does nothing whatsoever Mar 13 09:14:22 OK, disabling HDMI and setting the pin mux should do the trick. I will try this and update. Thanks for the help zmatt. Bye now. Mar 13 09:29:25 hello all Mar 13 09:29:47 can I use platformIO to compile for debian stretch?? Mar 13 09:29:47 http://docs.platformio.org/en/latest/platforms/linux_arm.html Mar 13 10:04:44 sorry i go tdisconnected Mar 13 10:04:47 got* Mar 13 10:05:04 will arm-none-eabi-g++ compiler work? Mar 13 10:26:49 thaytan: this is a linux platform, so you need a linux compiler Mar 13 10:26:59 whoops Mar 13 10:27:02 and gone with the wind Mar 13 10:27:25 aand nick completion messed it up even more :-) Mar 13 12:24:35 * bradfa dreams of a 64 bit beaglebone-like borad... Mar 13 12:25:31 bradfa: you mean something like the ultra96? : Mar 13 12:25:31 :p Mar 13 12:25:41 bradfa: or the RasPi 3? Mar 13 12:27:03 thinkfat: that one's missing the PRU (which really is the main reason you want a beagle) Mar 13 12:32:19 agraf: what's the ultra96? google shows me lots of LED light things, foam board, and some 96boards links that lack anything called "ultra" Mar 13 12:32:55 thinkfat: I'm not a fan of the raspi, I'd like a TI amxxxx style SoC on a bone-like platform for bone-like pricing and features and community Mar 13 12:33:46 bradfa: xilinx had it on display at the embedded world conference, but it'll only launch for real later Mar 13 12:33:56 bradfa: basically a xillinx mpsoc in 96board form factor Mar 13 12:34:09 definitely not bone-like pricing though ;) Mar 13 12:34:20 but you could probably just write your own PRU in the FPGA if you wanted to Mar 13 12:34:21 agraf: ah, ok. Some of the zynq parts seem interesting, especially once the yosys tools can handle it Mar 13 12:36:38 thinkfat: it's not that the broadcom SoC is bad, I just am not a fan of the whole "GPU with some ARM on the side" and the whole parts not being available for normal humans except assembled (maybe this changed?) and the raspi community except for a few individuals seems to espouse all of the things I dislike about technical communities Mar 13 12:38:05 if raspi team would make a raspi3-like board without that GPU and add in another 1 or 2 USB interfaces on the SoC and add proper Ethernet and release the SoC reference manuals (like TI does) then I'd get more interested Mar 13 12:38:33 the $5 raspi boards are super attractive, but only due to their price, there's nothing else interesting about them to me Mar 13 12:38:47 the reference manuals are available, no? Mar 13 12:38:52 I've yet to even come up with a hobby project where raspi was a decent choice to solve a problem Mar 13 12:39:06 agraf: for the SoC? like the multi-thousand page kidn of reference manual? Mar 13 12:39:26 bradfa: well, at least for all the peripherals you usually end up accessing from the arm side, yeah Mar 13 12:39:28 agraf: TI's am57xx part reference manuals are like 8000 pages long, that's what I want from any silicon I have to work with Mar 13 12:39:45 am33xx reference manual is like 3500 pages long, iirc Mar 13 12:39:57 even simple micros like cortex-M parts have 1000+ page manuals Mar 13 12:40:07 broadcom puts out like 150 pages, last I checked Mar 13 12:40:19 it doesn't give me warm fuzzies Mar 13 12:40:22 :) Mar 13 12:40:24 warm fuzzies are important to me :) Mar 13 12:40:49 heck, the TI am57xx errata sheet is longer than the broadcom manuals :) Mar 13 12:41:10 * bradfa hugs his errata Mar 13 12:59:03 Hi, I need help with configuring BeagleBone Black as SLAVE in SPI. Mar 13 12:59:40 I couldn't find any good/complete example/procedure to bring it to work. Mar 13 12:59:51 Any help is appreciated Mar 13 13:00:12 Currently, I can use BBB as master Mar 13 13:12:36 Hi all. I have a BeagleBone Black clone of some sort (don't know more, sorry). It doesn't have a removable storage and I'm trying to write a new image to it. I think I've read that I'm supposed to be able to connect it to my main computer as an external USB drive, but now I can't find that info again. Can somebody say if that is supposed to work? Perhaps point to a webpage somewhere that I can read about it? Mar 13 13:20:38 I can find info about it presenting itself as a network interface though. Could that be what I saw way back and now misremember as external USB disk? Mar 13 13:53:44 hi, I want to remove the HDMI to use all the GPIO on P8 so I've uncommented "enable_uboot_overlay_video=1" Mar 13 13:53:56 but after reboot HDMI seems to be still here Mar 13 13:54:25 mouha: Try =0 Mar 13 13:54:27 I have blkdiscard /dev/mmcblk1 to be sure to boot on SD Mar 13 13:54:39 =0 ? ok Mar 13 13:54:56 mouha: =1 says "enable the video overlay" which means "enable the video hardware" basicall Mar 13 13:54:57 y Mar 13 13:55:28 very confusing as in "disable_uboot_overlay_video=1" Mar 13 13:55:33 there is disable to =1 Mar 13 13:55:53 my previous line was wrong Mar 13 13:56:01 was "disable" not "enable" Mar 13 13:56:19 as from the current iot images Mar 13 13:56:38 Ah, if it is "disable", then =1 would make sense Mar 13 13:56:49 indeed . but ...no Mar 13 13:56:55 Not sure if that's all that's needed, though. Mar 13 13:57:31 no it seems Mar 13 15:02:27 bradfa/agraf: the doc you're talking about isn't even from broadcom, it's written by someone from rpi foundation, and it (poorly) documents only a small subset of the peripherals Mar 13 15:03:08 zmatt: iirc the person who wrote it is from the broadcom lab that developed the chip Mar 13 15:03:32 zmatt: and yes, the documentation is poor, but there is documentation Mar 13 15:03:59 it's possible I'm wrong about that point, it's been a long time since I looked into it Mar 13 15:04:28 there is a tiny bit of documentation, but not remotely enough Mar 13 15:05:04 not publishing errata (there's just some community-maintained wiki) also doesn't win points with me Mar 13 15:05:07 zmatt: it's mostly register listings, yes Mar 13 15:05:14 for a few peripherals Mar 13 15:05:14 zmatt: no actual functional documentation for most parts Mar 13 15:06:11 so yeah, that and the fact you can't actually buy the SoC as mere mortal are major things I dislike about the rpi Mar 13 15:06:51 and no (full) schematics published either iirc Mar 13 15:49:52 I'm connecting to two SPI slaves and want to use SPIDEV0.0 for the first slave and SPIDEV0.1 for the second slave. I'm trying to use P9.12 as the second CS but that pin does not have a mode avaialable for SPI when using config-pin -l P9.12. How do I use P9.12 as the second CS? Mar 13 15:57:03 * zmatt checks pins spreadsheet Mar 13 15:59:10 hm, the second hardware chip select for spi0 isn't on any expansion header pin... that means you'd need to use a gpio chip-select, but that isn't supported by cape-universal Mar 13 15:59:23 you'd need to switch to using an overlay for your hardware setup instead Mar 13 16:00:50 ok thanks. If i work on my code now just using 0.0 will there be issues later on once I change to an overlay? Or from the code will it still just look like spidev0.0 and 0.1? Mar 13 16:01:09 it will look the same from the code Mar 13 16:01:14 cool, thanks Mar 13 16:03:00 although when customizing the DT (including using overlays) you'd also have the opportunity to label the spi peripherals with their actual purpose and use an udev rule to make named symlinks, thus avoiding the need to hardcode such numbers into software. e.g. our dsp control software opens /dev/spi/dsp and doesn't need to care to which pins we actually connected the dsp Mar 13 16:03:14 (that helps reusability/portability across hardware variants) Mar 13 16:05:26 ok i'll look into that when I get there Mar 13 16:07:53 I just added an example of how to configure a gpio chip select: https://github.com/mvduin/overlay-utils/blob/master/spi0-gpio-cs.dtsi Mar 13 16:39:29 zmatt: Thanks! Mar 13 16:47:02 zmatt: nice! Mar 13 16:47:37 have you seen the ConfigFS interface for overlays? Mar 13 16:48:04 overlay-utils has scripts for it in bin/ Mar 13 16:48:04 the e-ale examples use it for some quick demos. Mar 13 16:48:22 would love to have some of your examples in bb.org-overlays, /opt/source or bone101 Mar 13 16:48:33 go ahead Mar 13 16:48:33 sweet. i’ll check it out. Mar 13 16:49:18 in general, my way of building overlays from normal-looking device tree fragments would greatly enhance readability of overlay sources I think :) Mar 13 16:49:34 even if the perl script I use to preprocess the source is a bit icky Mar 13 16:50:07 nice scripts. seems we should include these utils. Mar 13 16:50:38 for pocketbeagle, we’ve started enabling everything in a way that might block overlays because we can overlay in the bootloader. Mar 13 16:51:07 plus it makes it easier to make the step of customizing the main dtb, since with some care you can make DT fragments that work both when built as an overlay using my script and when #included into a main dts Mar 13 16:51:46 (though this is only true if you don't include any top-level metadata) Mar 13 16:52:18 does it need perl scripts and C preprocessor cant do it? Mar 13 16:52:52 there is not even remotely any way to do this with C preprocessor Mar 13 16:52:54 that’s a nice bonus. Mar 13 16:53:16 should be highlighted to folks patching dtc Mar 13 16:53:28 have you seen the yaml efforts? Mar 13 16:53:35 no Mar 13 16:54:34 would including it in the yaml translation make for a consistent syntax? Mar 13 16:54:47 to be honest, I never understood why dtc required such ridiculous input for overlays, it could just have accepted normal DT fragments Mar 13 16:55:02 google result: https://elinux.org/images/b/be/YAML_and_Devicetree_171102_0010.pdf Mar 13 16:55:22 dunno. Mar 13 16:56:14 oh, they're merely doing a literal representation of the DT in yaml syntax? don't care Mar 13 16:57:23 it doesn't yield any significant improvement, and shoehorning DTs into the YAML structure (which doesn't fit well at all) actually makes it worse Mar 13 16:58:13 I had hoped you meant people were working on generating DTs from a more human-friendly config model that happened to use YAML as format Mar 13 17:06:32 making it more human readable is the goal. Mar 13 17:08:26 yeah I saw when continueing to read that they were doing more... although at first sight it didn't look very appealing Mar 13 17:08:43 YAML just looked like the wrong syntax to use for those definitions Mar 13 17:09:32 but I'm willing to be proved wrong Mar 13 18:00:54 zmatt: hye, when i create a pointer that points to the pru dram and i access it at any time Mar 13 18:01:04 if the pru is writing to the memory at that instant, will it crash? Mar 13 18:01:23 my board is randomyl crashing completely at times, and sometimes the pru just doesnt output anything Mar 13 18:03:49 lol no Mar 13 18:04:14 sorry i got disconnected Mar 13 18:04:23 i have no clue why my board just dies Mar 13 18:04:28 like there is no heartbeat Mar 13 18:04:37 i have to hard reset it Mar 13 18:04:42 hard to say Mar 13 18:06:10 but no, concurrent access to pru dram (or any other ram) by pru and a8 is not a problem Mar 13 18:06:44 (in the sense of bus lockup or whatever I mean. it can of course be a problem for software correctness sometimes) Mar 13 18:14:00 the only exception on that rule I can think of would be that if one initiator is prioritized over the other and the higher-priority initiator spams continuous access to the shared memory it might be able to lock up the lower-priority initiator, but if it is possible at all (I don't know since I'd need more details on the pru interconnect) it wouldn't happen by accident Mar 13 18:14:41 okay thats good to know Mar 13 18:16:23 there Mar 13 18:16:27 it hung again Mar 13 18:16:36 while mapping pru dram it hangs sometimes Mar 13 18:16:41 any idea why? Mar 13 18:16:47 while mapping pru dram? Mar 13 18:16:50 that sounds really odd Mar 13 18:17:13 it might be a good idea to monitor the serial console for kernel panics Mar 13 18:17:54 how do i do that Mar 13 18:18:23 https://elinux.org/Beagleboard:BeagleBone_Black_Serial Mar 13 18:19:42 alrigh till try this and let u kno Mar 13 18:19:50 alright ill* Mar 13 18:26:29 how do you know it crashes while mapping the pru dram? Mar 13 18:26:44 that just seems like such a weird thing Mar 13 20:25:20 holy, this is test! Mar 13 20:25:46 holy: test Mar 13 20:30:49 Why my tab complete feature in HexChat uses "," after username instead of ":"? when i talk to a user "," works like ":"? Mar 13 20:32:57 i change to ":" Mar 13 20:33:51 Does anyone here use or used virtual keyboard in eglfs environment? Mar 13 20:45:21 probably something you can configure in hexchat Mar 13 20:59:33 zmatt: I changed it to ":".is it works now? Mar 13 21:00:51 virtual keyboard added to Qt open source version 5.11! Mar 13 21:55:11 "works" in what sense? Mar 13 21:55:15 it's just text either way Mar 13 21:55:32 oh, he left **** ENDING LOGGING AT Wed Mar 14 03:00:01 2018