**** BEGIN LOGGING AT Sun Oct 07 02:59:59 2018
Oct 07 04:31:17 <tbr> thinkfat_: not uncommon to see stuff where they have an very low price and it adds up with shipping. To finland this one costs $33.57 total. Which, surprisingly is quite cheap, yes.
Oct 07 05:42:10 <ozzloy> is there a camera for the pocket beagle?
Oct 07 06:39:52 <tbr> ozzloy: any USB camera that works on linux should work
Oct 07 09:02:17 <zmatt> tbr: once you rig a usb host port onto the pocketbeagle
Oct 07 09:03:10 <tbr> zmatt: correct, but IIRC that's easy enough on the headers
Oct 07 09:53:31 <ayjay_t> you can buy an expansion but the only place i found it was tindie coming from japan :-(
Oct 07 19:49:57 <zmatt> I'm still deeply impressed that someone managed to program this in a Super Mario World romhack (that still runs on original SNES hardware)... https://youtu.be/pNNqgDiTMBk?t=240
Oct 07 19:50:09 <zmatt> I wonder how long it took him
Oct 07 21:02:57 <CoffeeBreakfast_> zmatt: look this https://www.youtube.com/watch?v=3qgjKb0ecBs
Oct 07 21:16:20 <zmatt> neat
Oct 07 21:20:01 <zmatt> (the fact that people make homebrew NES games that is)
Oct 07 21:22:06 <zmatt> of course romhacks have a big advantage of being able to reuse the "engine" of a game, hence allowing the designer to focus on the content rather than having to write everything from scratch :)
Oct 07 21:28:49 <CoffeeBreakfast_> this one is interesting: how put a 27MB video in much less than 4MB cartridge? https://www.youtube.com/watch?v=IehwV2K60r8
Oct 07 21:30:41 <zmatt> yeah I've seen it
Oct 07 21:44:08 <CoffeeBreakfast_> Do I need to disable SPIDEV in order to use McSPI0 from the PRU?
Oct 07 21:48:48 <zmatt> you should disable it and put a ti,no-idle; property on it to ensure the kernel will enable the module clock
Oct 07 21:49:28 <CoffeeBreakfast_> compatible="ti,no-idle"; ?
Oct 07 21:50:39 <zmatt> no just  ti,no-idle;
Oct 07 21:51:21 <CoffeeBreakfast_> sorry, a driver named no-idle is nonsense lol
Oct 07 21:51:32 <zmatt> correct
Oct 07 21:51:58 <zmatt> also, if it's status="disabled"; then no driver will be attached hence compatible is ignored anyway
Oct 07 22:39:29 <CoffeeBreakfast_> I longed to do bare-metal things.. if that is the term
Oct 07 22:57:28 <zmatt> note that if you just want to play with mcspi yourself, not necessarily using pru, then you can also use the uio_pdrv_genirq driver to gain access to its registers and irq from linux userspace
Oct 07 23:05:47 <zmatt> also, in case it's useful, here's my C++ header for mcspi, including some notes/observations on its behaviour: https://liktaanjeneus.nl/mcspi.h.html
Oct 07 23:09:15 <CoffeeBreakfast_> beauty
Oct 07 23:09:42 <CoffeeBreakfast_> but, again, DT overlay issues...
Oct 07 23:10:23 <zmatt> time to ditch overlays and just use a custom dtb ? ;)
Oct 07 23:12:00 <CoffeeBreakfast_> the thing is, I'm quite noob in DT... my overlay for using spi, pinmuxed, driverless doesn't work
Oct 07 23:12:33 <zmatt> oh right you still want to have the kernel do the pinmux for you
Oct 07 23:12:39 <zmatt> so status="disabled" is not an option
Oct 07 23:13:20 <CoffeeBreakfast_> (talking about controlling from the pru)
Oct 07 23:14:38 <zmatt> you could attach the pinmux to some random other device but that's rather ugly.  a better solution would be to configure the mcspi device to use some "safe" driver that won't get in your way
Oct 07 23:15:26 <zmatt> uio_pdrv_genirq would be a good choice, with the added benefit of also allowing you to interact with mcspi from linux userspace (e.g. to inspect its registers)
Oct 07 23:16:00 <zmatt> for that set  compatible="uio";  and install this file into your /etc/modprobe.d/: https://github.com/mvduin/py-uio/blob/master/etc/modprobe.d/uio.conf
Oct 07 23:17:08 <zmatt> you'll still need the   ti,no-idle;   property too, to ensure the peripheral clock is enabled even if the uio device isn't open
Oct 07 23:17:42 <CoffeeBreakfast_> but with prussdrv using uio..
Oct 07 23:18:25 <zmatt> fix prussdrv? :P  it's probably really easy to just find where the path is hardcoded and recompile the lib
Oct 07 23:19:07 <CoffeeBreakfast_> there is no other dummy/safe driver?
Oct 07 23:20:30 <zmatt> uhh I guess
Oct 07 23:20:43 <zmatt> maybe compatible = "simple-bus"; works?
Oct 07 23:21:11 <CoffeeBreakfast_> I'll try
Oct 07 23:22:41 <CoffeeBreakfast_> in which node? (compatible=..)
Oct 07 23:23:01 <zmatt> the spi peripheral, same as everything else discussed
Oct 07 23:27:57 <CoffeeBreakfast_> ocp { ... spi{ <- not this I guess (with ti,omap4-mcspi)
Oct 07 23:29:39 <zmatt> yes that, better known as &spi0
Oct 07 23:30:01 <zmatt> i.e. replace line 10 in  https://github.com/mvduin/overlay-utils/blob/master/spi0.dtsi  with   compatible = "simple-bus";  ti,no-idle;
Oct 07 23:30:39 <zmatt> (and ignore the bottom half of that file obviously)
Oct 07 23:35:22 <CoffeeBreakfast_> okay. And just to know: omap4-mcspi, spidev, two drivers?
Oct 07 23:36:20 <zmatt> omap4-mcspi is the driver for the spi peripheral, spidev is a driver (a dumb one that merely acts as a passthrough for userspace requests) for a device attached to an spi bus
Oct 07 23:36:32 <CoffeeBreakfast_> (our book about DT is about 20 pages so far (?))
Oct 07 23:37:34 <zmatt> once you replace the driver for the spi peripheral, the whole spi bus is gone (as far as linux is concerned)
Oct 07 23:37:39 <zmatt> ohh crap
Oct 07 23:37:46 <zmatt> nono don't use simple-bus, that will go very wrong
Oct 07 23:39:04 <CoffeeBreakfast_> okay
Oct 07 23:39:17 <zmatt> or at least, you'll need to ensure it has no child devices (e.g. the "spidev" ones)
Oct 07 23:40:55 <CoffeeBreakfast_> none
Oct 07 23:41:32 <zmatt> that means in particular that the cape-universal must not be loaded, since it declares such child devices
Oct 07 23:50:52 <CoffeeBreakfast_> then I need to check with show-pins for the pin mode right?
Oct 07 23:51:25 <zmatt> sounds like a sensible thing to do
Oct 07 23:56:41 <CoffeeBreakfast_> finger crossed
Oct 08 00:07:03 <CoffeeBreakfast_> no luck
Oct 08 00:08:33 <zmatt> what does your overlay look like? did you check kernel log for errors?
Oct 08 00:09:43 <CoffeeBreakfast_> https://pastebin.com/duQZPgii
Oct 08 00:10:50 <zmatt> overlay seems fine
Oct 08 00:11:10 <zmatt> define "no luck", what does show-pins say?
Oct 08 00:14:55 <CoffeeBreakfast_> P9.22 / spi boot clk              84 fast rx  up  7 gpio 0.02
Oct 08 00:15:46 <zmatt> ok so nothing claimed the pin.  check kernel log for probe error I guess?
Oct 08 00:16:24 <zmatt> I don't know, using simple-bus for this is Wrong™.  prussdrv should simply be fixed or ditched
Oct 08 00:16:34 <zmatt> if you're just playing around, use py-uio
Oct 08 00:17:00 <zmatt> actually if you're not just playing around, consider using py-uio too :P
Oct 08 00:19:01 <CoffeeBreakfast_> any keyword for searching in kernel log?
Oct 08 00:19:29 <zmatt> no, just any clue that something is going wrong
Oct 08 00:24:26 <CoffeeBreakfast_> bone_capemgr has anything to do with this?
Oct 08 00:24:40 <zmatt> why would it?
Oct 08 00:24:54 <CoffeeBreakfast_> just curious
Oct 08 00:25:45 <CoffeeBreakfast_> well, using uio for spi, and fixing prussdrv...
Oct 08 00:26:04 <zmatt> (*fixing or ditching)
Oct 08 00:27:00 <CoffeeBreakfast_> while porting py-uio in the background (your code is awesome, but I dont like python)
Oct 08 00:27:18 <zmatt> that's okay, I don't like python either
Oct 08 00:27:40 <zmatt> but if you want a working solution right now, using py-uio at least for initialization and firmware loading gives you a quick result
Oct 08 00:28:16 <zmatt> you can always replace it later
Oct 08 00:30:37 <zmatt> if everything is setup by py-uio, very little code is required for c++ programs that want to interact with pru via shared memory and/or interrupts
Oct 08 00:33:16 <CoffeeBreakfast_> got it
Oct 08 00:39:11 <CoffeeBreakfast_> the same dtsi, with uio instead of simple-bus is ok?
Oct 08 00:39:21 <zmatt> should be
Oct 08 00:58:47 <tek184> hello! I just attempted to flash the emmc on a bbb rev c with the latest image (i.e. Debian 9.5 2018-08-30 4GB SD IoT ) I have the four led lights lit up. Can I just turn off the board at this point? I was following this guide: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC
Oct 08 00:59:12 <tek184> do the four leds statically lit mean the sd card failed to boot?
Oct 08 00:59:14 <zmatt> it doesn't power off on its own? that's odd
Oct 08 00:59:48 <tek184> Is there a guide I can follow that is correct or updated? The above guide at elinux.org doesn't seem to work
Oct 08 01:00:03 <zmatt> it should still be correct
Oct 08 01:00:17 <tek184> zmatt: yes, the four LED's have been lit now for quite a while
Oct 08 01:00:20 <CoffeeBreakfast_> zmatt: the overlay works, and uio0 -> spi, uio[1..8] -> pruss
Oct 08 01:00:33 <zmatt> there isn't anything more to it than uncommenting the appropriate line of /boot/uEnv.txt on the SD card and booting from it
Oct 08 01:00:43 <zmatt> okay but was it flashing before?
Oct 08 01:01:04 <tek184> zmatt: yes I did that. yes, it was flashing before
Oct 08 01:01:44 <zmatt> it used to finish with all four leds on, then it was changed to finishing by powering off, maybe it changed back to finishing with all four leds on again for some reason, I dunno
Oct 08 01:01:49 <tek184> after I uncommented the script in /boot and saved I typed "sudo reboot"
Oct 08 01:02:20 <tek184> What is the safest way to turn off the bbb at this point?
Oct 08 01:02:27 <tek184> S3?
Oct 08 01:02:41 <tek184> pressed once? or held down till it shuts off?
Oct 08 01:02:42 <zmatt> power button if it works, otherwise just pull the plug
Oct 08 01:03:00 <zmatt> long-pressing the power button is equivalent to pulling the plug
Oct 08 01:03:10 <tek184> is there anything that I can test at this point?
Oct 08 01:03:21 <zmatt> just remove the card and power cycle the board
Oct 08 01:03:25 <zmatt> test what?
Oct 08 01:03:25 <tek184> \should I try removing the ssd and seeing if it flashed correctly?
Oct 08 01:03:36 <zmatt> yes?
Oct 08 01:03:41 <zmatt> I mean, it should have
Oct 08 01:03:50 <tek184> or not powering down after the four led's light up means that it failed?
Oct 08 01:04:05 <zmatt> failure = all four leds blinking
Oct 08 01:04:34 <zmatt> so I'm assuming it has simply finished successfully
Oct 08 01:04:36 <tek184> all four leds are just fully lit
Oct 08 01:04:51 <tek184> so pulling the plug won't corrupt the fs?
Oct 08 01:05:20 <tek184> at the point that they are all lit up, that is
Oct 08 01:05:21 <zmatt> stop worrying already, it doesn't sound to me like anything went wrong
Oct 08 01:05:24 <zmatt> :)
Oct 08 01:05:47 <zmatt> and while powering off cleanly is good practice, filesystems don't corrupt *that* easily
Oct 08 01:05:49 <tek184> zmatt: ok so I am going to pull the plug, remove the sdcard and ssh to check if it is the latest debian version
Oct 08 01:05:59 <zmatt> sounds good to me
Oct 08 01:06:05 <tek184> zmatt: ok thank you!
Oct 08 01:09:04 <tek184> zmatt: hmmm, I got this now: http://dpaste.com/3ER7K1N
Oct 08 01:09:51 <zmatt> fortunately it already gives you the commend to fix it
Oct 08 01:10:13 <zmatt> *command
Oct 08 01:13:44 <tek184> zmatt: I used ssh-keygen -R <ipaddress>
Oct 08 01:13:52 <tek184> seems to have worked
Oct 08 01:14:24 <tek184> "cat /etc/debian_version" gives me debian 9.5
Oct 08 01:14:38 <tek184> zmatt: thank you!
Oct 08 01:14:41 <zmatt> you can find the image date in /etc/dogtag
Oct 08 01:15:05 <tek184> It says BeagleBoard.org Debian Image 2018-08-30
Oct 08 01:15:29 <tek184> so yeah, it looks like it worked
Oct 08 01:46:42 <CoffeeBreakfast_> is there any way to get spi at the end of uio? i.e. uio8?
Oct 08 02:05:40 <zmatt> uio device numbering is arbitrary and should not be relied on in any way whatsoever
Oct 08 02:06:25 <zmatt> either scan for the device you want or use udev to create a symlink for it
**** ENDING LOGGING AT Mon Oct 08 02:12:16 2018

**** BEGIN LOGGING AT Mon Oct 08 02:14:09 2018
**** ENDING LOGGING AT Mon Oct 08 02:14:35 2018

**** BEGIN LOGGING AT Mon Oct 08 02:16:10 2018
Oct 08 02:42:19 <CoffeeBreakfast_> I love the style of that ti_mcspi.h
**** ENDING LOGGING AT Mon Oct 08 03:00:00 2018