**** BEGIN LOGGING AT Tue May 22 03:00:04 2018 May 22 04:10:57 hmm, it seems that loads and stores by pru cores to local memories are uninterruptible bursts, regardless of length May 22 04:23:41 evneing May 22 04:35:34 wait what, why am I now getting completely different results May 22 04:35:54 oh lol never mind May 22 05:36:20 Not able to boot up BBB using the USB drive, the same USB drive is working fine after boot May 22 05:45:04 you can't boot a BBB from a USB-Mass storage device May 22 05:47:56 ^ May 22 05:50:13 (you could have the rootfs on USB mass storage, but that's a different story) May 22 05:54:00 i am having to do something similar on the rpi3. because we have no sdmmc device driver for the onboard eMMC :) May 22 05:54:06 v. awkward May 22 06:19:17 Sorry I'm not able to flash the rootfs from a USB Mass Storage Device May 22 06:24:17 that is correct May 22 06:24:32 you need a microSD card to do that May 22 06:26:30 Yes, using MicroSD card is working fine, but issue when flashing using pendrive on USB0 May 22 06:27:46 sumit_g: how hard is it to read? tbr already said you can't boot a BBB from a USB-Mass storage device May 22 06:29:55 kremlin: just configure the pins as gpio and use a bitbanging driver? :) I think sd cards are still required to support SPI mode? May 22 06:31:26 Sorry for that @tbr and @zmatt but I tried with the Sandisk USB drive its working fine but when using other Sandisk Cruzer its not working... May 22 06:31:43 zmatt: nah gotta do it properly. this controller is quirky May 22 06:32:04 kremlin: well my suggestion wouldn't involve the controller May 22 06:32:07 at all May 22 06:32:24 unless those pins can't be muxed to gpio? but that seems pretty unlikely May 22 06:33:09 sumit_g: you must have observed incorrectly, the BBB *cannot* boot from usb May 22 06:34:15 maybe u-boot supports booting from usb (haven't tried, don't care), but then the BBB will still need to load u-boot from eMMC or SD card May 22 06:34:32 zmatt: Yes I'm trying to flash the rootfs from USB Mass Storage device May 22 06:34:43 which is not supported, use an sd card May 22 06:35:36 oh i see what you mean May 22 06:35:59 kremlin: of course performance would be absolute shit and data transfer would use tons of cpu load, but hey May 22 06:37:10 yeah May 22 06:37:11 PIO May 22 06:37:32 oh, the rpi has two sd controllers... two totally different sd controllers? o.O May 22 06:38:13 surely the sdhci controller can't be hard to get to work? May 22 06:39:27 since that should just work mostly with the generic sdhci code that I'm assuming already exists in openbsd May 22 06:39:45 (the platform-specific part of the driver seems to be tiny in linux) May 22 06:41:33 oh, using the sdhci driver for the sd card means you lose wifi on the rpi3 May 22 06:41:57 if that's supported on openbsd, which I'm guessing it isn't ;) May 22 06:49:23 hello May 22 06:50:27 oh wow, damn, pruss can cause accesses by the cortex-a8 to block *indefinitely* May 22 06:50:45 can anyone help me, how to interface input/output (3.3 v) Beaglebone black to 5 v i/o voltage level May 22 06:50:56 (if both cores are spamming requests to one of the local memories and the cortex-a8 tries to do an access to the same memory) May 22 06:51:16 zam: depends on the details, but in general: a level shifter May 22 06:51:50 that mean, use leevel shifter circuit/ic May 22 06:51:52 ? May 22 06:52:05 yes May 22 06:52:43 can you suggest to me / link where to buy / develope a level shifter May 22 06:53:54 aliexpress, ebay, digikey, farnell, … May 22 06:54:10 thank a lot May 22 06:54:18 depends on how fast you need it May 22 06:56:07 are u know beaglebone shield like arduino shield. this is because, i need many voltage 3.3 and gnd pin May 22 07:00:52 I'd probably just throw something like this at it, or multiple of these. https://www.aliexpress.com/item/New-CJMCU-TXS0108E-8-channel-level-shifter-module-8-bit-bidirectional-voltage-converter/32688889200.html May 22 07:00:59 that's a random example May 22 07:02:55 there might be a cape May 22 07:08:06 if you must have a cape, you could look at this. https://www.tindie.com/products/land_boards/33v5v-sensor-connection-cape-for-the-beaglebone/ not tooo many 5V pins May 22 07:10:44 or build something custom based on one of the proto capes from adafruit or sparkfun May 22 13:00:48 how would you update a custom kernel for a beagle remotely, when you have no physical access to the device? May 22 13:05:46 why would that require physical access? May 22 13:07:04 just transfer the .deb produced by the build_deb.script to the target (by whatever means) and install it with sudo dpkg -i May 22 13:07:07 and reboot May 22 13:07:17 and pray you didn't break it ;) May 22 13:07:25 lol May 22 13:09:53 ye the problem is that I just have the uImage May 22 13:10:17 but I think thats a silly approach, there's no real reason to not have a .deb package with everything in it, to make the update May 22 13:12:15 doesn't seem there's an easy way to just update a uImage without getting lost in Uboot May 22 13:35:57 what even is an "uImage" ? May 22 13:36:06 I've never seen them used, only vaguely heard of them May 22 13:36:17 I know rcn's build scripts don't produce one May 22 14:42:06 uboot image May 22 14:42:25 lil packaged image file you can just throw to uboot and have it run May 22 14:42:37 has details about load addr/entry addr/etc May 22 14:52:51 so it's the kernel packed together with information that shouldn't be packed together with the kernel in the first place? May 22 14:53:14 since normally u-boot decides what to load where, not the thing being loaded May 22 15:06:52 zmatt: py-uio changes on the 16th require python3.6 due to pathlib. might want to mention in README May 22 15:15:52 pathlib already existed in 3.5 didn't it? May 22 15:16:04 it does => https://docs.python.org/3.5/library/pathlib.html May 22 15:16:14 "New in version 3.4" May 22 15:16:16 zmatt: yes, but not with a naked open(path) May 22 15:16:27 oh May 22 15:17:01 feel free to send a pull request to fix it May 22 15:17:11 zmatt: https://stackoverflow.com/questions/42694112/when-using-pathlib-getting-error-typeerror-invalid-file-posixpathexample-t May 22 15:17:42 or I guess I can just fix it May 22 15:19:48 zmatt: i can fork and try it out if you prefer May 22 15:24:20 ah I should have used path.open( .. ) instead of open( path, ... ) May 22 15:25:43 is that change sufficient to fix it for whatever python version you're using? May 22 15:25:59 - with open( path, 'rb' ) as f: May 22 15:25:59 + with path.open( 'rb' ) as f: May 22 16:05:13 stash? May 22 16:16:14 zmatt: i'll check, hold on May 22 16:17:00 zmatt: yes that works. May 22 16:17:37 committed and pushed May 22 17:53:33 argh, why is nodejs so awful /o\ May 22 18:16:57 Okay, so I'm still trying to netboot an (effectively) blank beaglebone. I've gotten as far as getting the kernel to boot and having it run a script that flashes the LEDs a certain way at startup, so I know the kernel is running and init is getting executed and whatnot, however I have no output on the console serial port, and no serial/ethernet devices showing up behind USB, so I have no way to see what the board is doing besides flashing the LEDs. May 22 18:17:03 I'm running with a kernel I compiled (but I've tried kernels from working SD installer cards and that doesn't work either), a filesystem I swiped off the initrd of an installer (but the filesystem is loaded after the kernel so who cares), and an FDT compiled from linux kernel source (though I've tried compiled from u-boot source and from a working installer SD card initrd). May 22 18:17:08 My guess is there's something wrong with the way I'm manually booting the kernel from u-boot. I tftpboot the zImage to 0x82000000, the initrd to 0x88080000, and the dtb to 0x88000000, then do bootz 0x82000000 0x88080000:xxx 0x88000000, where xxx is the size of the initrd in hex. I get (nearly) the exact same results if I ext4load the kernel, dtb, and initrd from a working installer SD, which is why I think this is where I'm misstepping. May 22 18:17:14 I've tried setting the u-boot console environment variable to ttyO0,115200n8, ttyS0,115200n8, ttyO3,115200n8, or ttyS3,115200n8. I've tried writing a program to and write "hello %s" to every file in the set "/dev/tty*" to see if I can get a hint at the name of the console port, but got no output. I've found various web sites that have said all four of these ports are the correct one. May 22 18:17:20 Sorry for the wall of text, but I figured it beats "my linux is b0rked, halp" May 22 18:17:37 have you made a correct DT for your custom board yet, like I told you last time? May 22 18:18:03 See, that's what I don't understand. The DT is clearly working, when I boot the board from the SD card May 22 18:18:17 n8vi: you're positive you have tx and rx correct on the serial output? May 22 18:18:31 Yes, as it does work when I boot from SD May 22 18:18:35 (e.g. works from u-boot) May 22 18:18:40 yup, that too May 22 18:18:54 n8vi: I don't understand how it possibly can, since you're using a different serial port as console May 22 18:19:12 what do you mean? May 22 18:19:23 n8vi: did you setenv bootargs console=$console May 22 18:19:27 you were using uart3 rather than uart0 as console right? May 22 18:19:39 or am I confusing you with someone else? May 22 18:19:44 I am using whichever one is pinned out on the beaglebone May 22 18:20:02 oh nm, you're trying to netboot an actual beaglebone May 22 18:20:05 sorry May 22 18:20:32 n8vi: make sure the console is passed in your bootargs May 22 18:20:38 then ttyS0 is correct May 22 18:20:47 ttyS0. Okay. May 22 18:20:56 That seems to be u-boot's default May 22 18:21:41 u-boot's default has the console set in bootargs? May 22 18:21:46 I don't see a bootargs variable defined by default in u-boot, but I do see an env var called "console" May 22 18:22:00 console=ttyO0,115200n8 May 22 18:22:07 how big is the dtb file? May 22 18:22:15 (I'm under the impression ttyO0 = ttyS0 May 22 18:22:20 so, you'll want "setenv bootargs $bootargs console=$console" May 22 18:22:21 let me look May 22 18:22:22 ttyO0 will typically work too, depending on kernel config May 22 18:22:29 Okay, I'll try that May 22 18:22:47 note: if ttyO0 works, it is equivalent to ttyS0 May 22 18:22:49 simply having console= set does not necessarily pass it to the kernel May 22 18:22:51 -rw-rw-r-- 1 tdb tdb 62765 May 22 13:10 am335x-boneblack.dtb May 22 18:22:55 so if ttyS0 doesn't work, neither does ttyO0 May 22 18:23:04 unless you have a really unusual kernel config May 22 18:23:08 although more ideal to pass via device-tree May 22 18:23:27 vagrantc: that is how it normally works in every u-boot I've seen May 22 18:24:17 n8vi: are you netbooting via usb or ethernet? usb right? May 22 18:24:23 zmatt: how what normally works? May 22 18:24:23 USB, yep May 22 18:24:33 vagrantc: console var in u-boot May 22 18:24:51 getting passed down as kernel parameter May 22 18:25:06 or, oh wait May 22 18:25:07 zmatt: i haven't observed that on the 20 or so boards i test regularly with mainline u-boot May 22 18:25:25 right it's u-boot's bootscript doing that of course May 22 18:25:26 maybe you use a boot script that sets bootargs May 22 18:25:28 and not manual boot May 22 18:25:45 well the default u-boot on beaglebone does May 22 18:26:14 but you're right he needs to set bootargs when booting manually May 22 18:26:34 n8vi: so be sure to set bootargs :) May 22 18:26:52 okay, that'll take a minute. I think I tried that once already, but it was long enough ago there may have been other things I've fixed since then May 22 18:26:57 n8vi: also, you could tftp boot a boot script instead and do this more systematically May 22 18:27:08 that actually is what I'm doing May 22 18:27:21 n8vi: https://pastebin.com/1jQ83gPK this is how I know you can manually boot a beaglebone from the u-boot commandline (though note this doesn't load an initrd, but you can probably adapt it) May 22 18:27:33 consider using a FIT May 22 18:27:34 I've got this whole tree of files and a makefile for populating my tftpboot May 22 18:27:46 to pass kernel + dtb + initrd + cmdline May 22 18:28:08 okay, I'm going to give this a try myself May 22 18:28:27 since I know I had netboot working pretty easily last time I tried (up to the point of getting the kernel loaded) May 22 18:28:39 Hello! May 22 18:28:43 ANyone online atm? May 22 18:28:49 Kinda up for talking bout beagles May 22 18:29:20 I actually have a little python script to generate my boot script, check checksums as the kernel, initrd, and dtb are brought over, retry if necessary, set the eeprom if necessary, and then mkimage the script May 22 18:29:34 You what? May 22 18:29:50 n8vi: that sounds really complicated May 22 18:30:10 compared to my 'dhcp && bootm' May 22 18:30:11 :P May 22 18:30:11 Yeah what does this mean i thought we could talk bout beagles here? May 22 18:30:25 Hardbeagle69: this is the support channel for beagleboard.org May 22 18:30:53 Oh i see May 22 18:30:58 if dhcp && bootm worked, I'd be doing that May 22 18:32:00 The way I'm doing it I have all the steps broken down where I can see them so I can learn what it is that actually is going wrong May 22 18:32:54 you're seeing the same problem when trying to boot a FIT in this way? May 22 18:33:41 actually I first need to be afk for a bit, but I will be back later May 22 18:33:57 son of a bitch May 22 18:34:10 I don't believe I didn't retry that May 22 18:34:17 lol May 22 18:34:29 This is what happens when you bang your head into a wall for two weeks May 22 18:34:31 that is the only thing I ever tried, and it Just Worked May 22 18:34:48 right, because you were previously testing this on a buggy custom board right? May 22 18:34:59 well, either the board is buggy or my usb bus is May 22 18:35:17 having an automated thing that makes a boot script that checks CRCs helps May 22 18:35:41 okay, this is many steps ahead of where I was May 22 18:35:45 FIT supports checksums too actually, but I don't know how you turn it on May 22 18:36:29 (iirc) May 22 18:40:11 and if you have any doubts about u-boot's usb driver, try ethernet instead ( use my netboot branch of u-boot I linked to a while ago, put bbb in ethernet boot mode by pulling down P8.43 and pulling up P8.45 ) May 22 18:41:51 ok, I'm afk, bbl May 22 18:42:39 So, now to find out if the kernel is really panicking as a result of me enabling the console properly. Holy shit, heisenberg. May 22 18:44:33 oh, nope, it's because I blew up my rootfs. That's easily fixed. May 22 19:00:30 woo, /bin/sh on the serial port. May 22 19:00:49 now to figure out how to get the usb ethernet gadget up May 22 19:08:09 zmatt: can I get a link to your x15 show-pins script? May 22 19:12:32 zmatt: I have the lower 10 bits of PRUSS2_PRU0 configured for gpi, and only the lower 7 are high after my program halts May 22 19:23:01 n8vi: modprobe g_ether May 22 19:23:17 yeah, I figured that out, thanks May 22 19:23:20 stash: I pushed branch 'bbx15-experimental' to https://github.com/mvduin/bbb-pin-utils May 22 19:23:23 bbl again May 22 19:24:35 hmm, udhcpc says "Network is down", however May 22 19:24:52 Well, I can much more easily deal with userland issues I can see May 22 19:59:33 and it's up. Hooray. May 22 20:08:52 see, in the end it was really easy ;-) May 22 20:52:44 fuck python May 22 22:11:13 zmatt: \o/ my man. May 22 22:14:34 lol May 22 22:14:58 does ruby have variable declarations and proper lexical scoping? otherwise fuck ruby too, without having even tried it May 22 22:15:53 * zmatt looks at the few lines of example code on the front page of ruby-lang.org and already hates it May 22 22:22:41 (in case you're wondering, no I didn't remember, I just grepped my irc logs :P ) May 22 22:32:07 Hahaha. I was wondering. May 22 22:49:04 Hello, I'm trying to send messages from the BBB PRU to the ARM host. I'm using the pru_rpmsg_send function per TI's example code. The problem comes when I try and send messages larger than 255 or on a different BBB 225. According to the documentation the max rpmsg size is 512 minus the size of the header which puts the maximum at around 490 bytes. Has anyone had this issue or any ideas what to try? Looking through kernel source May 22 22:49:04 also seems to imply it should be around 512 for the max not the 255 I'm getting. May 22 22:49:53 no experience with this remoteproc sillyness, sorry :) May 22 22:50:09 * zmatt prefers uio-pruss May 22 22:51:30 Isn't remoteproc the new way you're supposed to send messages back and forth? Is uio-pruss better? May 22 22:52:24 uio-pruss just maps pruss entirely into userspace (along with a chunk of reserved ddr3 memory if desired) and lets you take it from there May 22 22:52:53 the best way to do pru-arm interaction tends to be application-dependent anyhow May 22 22:54:51 so if you really *want* a message passing interface when using uio-pruss you'd have to make one yourself (which is not a huge thing, but also not completely trivial). I'm not really sure when that's a thing you'd want though May 22 22:55:12 I'm looking for a fast way of reading and writing buffers of up to 4096 bytes back and forth between the PRU and arm chip as fast as possible. If needed I can shrink the buffer size. May 22 22:57:14 that's not quite enough detail though, like what do you mean by "buffers" plural? how many buffers are in circulation? May 22 22:57:36 will a single ringbuffer per direction not do the job for you? May 22 22:58:52 Yes, a single buffers in each direction. By buffer I mean a C array May 22 23:00:25 I'm looking to essentially read a lot of sensor data using the PRU do some processing on it and send that data to the ARM. May 22 23:01:29 what's a "lot" ? how much data per time? May 22 23:01:56 so basically you just want to transfer a stream of small fixed-size messages? (one per sample/reading/whatever) May 22 23:02:15 sounds like a perfect match to a ringbuffer May 22 23:02:16 About 8Mbps May 22 23:02:34 is that b bit or byte? May 22 23:02:42 Bits. Sorry May 22 23:03:06 The data is variable length. May 22 23:03:26 variable length sensor data? May 22 23:04:16 1 MB/s, okay so not very little but also not very much May 22 23:05:39 The data is coming over a uart connection that's directly connected to the PRU May 22 23:06:43 So it will be variable length. It's not your fixed length. May 22 23:11:17 putting a stream of variable-length messages into a ringbuffer isn't an intrinsic problem. it's just a bit more effort to deal with May 22 23:16:49 for pru -> arm I'd use a single ringbuffer in DDR3 memory probably May 22 23:17:22 for arm -> pru it's better to use the memory in pruss itself if it at all possible, even though space there is limited May 22 23:18:21 since having pru read from memory outside pruss is really slow and tends to ruin determinism May 22 23:19:54 Alright, thanks for the suggestions. I'll give it a shot. May 22 23:21:15 one important bit: do keep the ring buffer pointer (used to communicate the writer's position to the reader) in the same memory as the buffer itself, i.e. both in ddr or both in pruss local memory May 22 23:22:17 that way, if the writer first writes data to the buffer and then writes the updated pointer, when the reader sees that updated pointer it is also guaranteed that subsequent reads by the reader will yield the newly written data May 22 23:24:58 and if writing in C/C++ rather than assembly you will need appropriate compiler barriers or appropriate use of the 'volatile' storage qualifier to make sure the optimizer doesn't "helpfully" reorder memory accesses May 22 23:28:16 hmm, I should add a ringbuffer communication example to py-uio... it's a pretty common thing to want May 22 23:29:08 Thanks for the pointers. I'll take note of that. May 23 01:08:30 it looks like on the bbx15 my low-effort python script can deal with a stream of about 100K 4-byte messages per second from pru, transferred via 256KB ringbuffer in ddr memory. if I go to 200K messages/second I eventually get a buffer overrun May 23 01:09:02 of course that's mostly just python being python :P May 23 01:09:33 and the small message size doesn't help with efficiency either probably May 23 01:12:28 50Kmsg/s seems stable on the beaglebone **** ENDING LOGGING AT Wed May 23 03:00:01 2018