**** BEGIN LOGGING AT Wed Aug 09 03:00:00 2017
Aug 09 03:55:10 <gshrikant> Hi, I'm trying to boot a BBB with a omap2plus_defconfig kernel over NFS, following the instructions from http://free-electrons.com/doc/training/linux-kernel/linux-kernel-labs.pdf.
Aug 09 03:55:49 <gshrikant> However, I'm running into a kernel panic on not being able to mount the rootfs. Here is the link to the boot log: https://pastebin.com/zmCSncKR
Aug 09 03:56:05 * zmatt looks
Aug 09 03:57:19 <zmatt> ok, looks like just an nfs-boot related issue and not a bbb-related issue
Aug 09 03:57:20 <gshrikant> I've verified that the NFS server does receive requests from the client. Here's how my NFS exports file looks: https://pastebin.com/hBV94CfL
Aug 09 03:57:57 <zmatt> I don't know much about nfs boot
Aug 09 03:58:09 <gshrikant> zmatt: Oh. I'm sorry if this is the wrong channel for it. Thanks for taking the time to look :-)
Aug 09 03:59:08 <zmatt> never hurts to ask :)
Aug 09 03:59:25 <zmatt> playing more with nfs boot is still somewhere on my to-do list
Aug 09 04:00:19 <zmatt> might it not be easier to just have u-boot also download an initramfs, so you have the full power of linux userspace available to mount the root filesystem ?
Aug 09 04:01:27 <zmatt> otherwise you'll also need to make sure everything needed for nfsboot is compiled into the kernel
Aug 09 04:01:32 <zmatt> it might not be by default
Aug 09 04:01:57 <zmatt> that might actually be the issue here, since it doesn't even seem to be trying
Aug 09 04:23:48 <gshrikant> zmatt: I did build the kernel with CONFIG_NFS_ROOT built in. I'll try it with an initramfs too.
Aug 09 04:27:52 <gshrikant> I'll try enabling the rest of the NFS options and try to see if it makes any difference.
Aug 09 04:33:16 <MrCurious> anyone know the size of the silicon wafer entombed in the BB die? 2mm^2?
Aug 09 04:34:27 <zmatt> you mean the size of the die entombed in the package :)
Aug 09 04:34:41 <zmatt> 2 sounds like way too low an estimate
Aug 09 04:35:38 <MrCurious> i think the # pins is dictating the size, not the SI
Aug 09 04:38:57 <zmatt> I'm looking for points of comparison... the "primus" die (omap-L137 / am17xx) is 6 x 4.4 mm
Aug 09 04:39:56 <MrCurious> but. if you dont expose all the pins… but just a subset, how small can it get
Aug 09 04:40:05 <MrCurious> using the existing SI
Aug 09 04:40:12 <zmatt> the size of the die :P
Aug 09 04:41:00 <MrCurious> every chip i have opened and exposed is far far smaller than the package…, and #pins determine size, not the silicon...
Aug 09 04:42:14 <zmatt> there are chips which are basically just a bare die with protective coating (WLCSP)
Aug 09 04:43:27 <zmatt> omap2420 (90nm) was 74mm^2, omap3530 (65nm) was 60mm^2
Aug 09 04:45:11 <MrCurious> https://www.geek.com/chips/ibm-et-al-achieve-28nm-node-with-high-k-metal-gate-cmos-process-744852/  i cant see more than 5mm^2
Aug 09 04:46:16 <zmatt> Apple A8 is 89mm^2
Aug 09 04:47:13 <MrCurious> 10mm^2 is 1/3 the chip package size
Aug 09 04:48:39 <zmatt> what are you referring to?
Aug 09 04:48:52 <MrCurious> need to think to ask jkridner tomorrow
Aug 09 04:49:24 <zmatt> even the smallest package of the am335x is 169 mm^2
Aug 09 04:49:33 <zmatt> so the die will be no doubt substantially less than that
Aug 09 04:49:37 <zmatt> but a lot more than 2
Aug 09 04:50:19 <MrCurious> milimeters or micrometers?
Aug 09 04:50:22 <zmatt> mili
Aug 09 04:50:24 <zmatt> duh
Aug 09 04:50:31 <jkridner> sizes of the dies are proprietary, despite people reverse engineering them. typical industry practice, I think.
Aug 09 04:50:37 <MrCurious> 16.9 cm x 16.9cm
Aug 09 04:50:42 <MrCurious> i do not believe you
Aug 09 04:50:48 <zmatt> MrCurious: what?
Aug 09 04:50:55 <zmatt> 13 mm x 13 mm = 168 mm^2
Aug 09 04:51:00 <zmatt> *169
Aug 09 04:51:27 <MrCurious> shoot, i was meaning 5 mm^2 meaning 5x5mm
Aug 09 04:51:38 <zmatt> jkridner: a bit curious since it's pretty easy to determine if one is willing to sacrifice one device
Aug 09 04:52:14 <jkridner> zmatt, MrCurious: I've seen devices be limited by either
Aug 09 04:52:17 <MrCurious> was just thinking the die could be far smaller packaged if only a subset of pins were exposed, no redesign other than pkg, and provide a useful device
Aug 09 04:52:30 <zmatt> MrCurious: that's what the ZCE package is
Aug 09 04:53:07 <jkridner> zmatt: you can get a pretty good idea of the am335x die size by looking at the Octavo pictures.
Aug 09 04:53:29 <zmatt> MrCurious: apparently, you can get a pretty good idea of the am335x die size by looking at the Octavo pictures ;-)
Aug 09 04:54:05 <MrCurious> ty
Aug 09 04:55:55 <jkridner> https://twitter.com/MacroFab/status/736254364474576898
Aug 09 04:56:14 <jkridner> that's a 27mm x 27mm package.
Aug 09 04:58:09 <MrCurious> now i see it. a pcb in a plastic package… https://sc02.alicdn.com/kf/HTB1F1IOGVXXXXagXVXXq6xXFXXXG/221098076/HTB1F1IOGVXXXXagXVXXq6xXFXXXG.jpg
Aug 09 04:58:53 <jkridner> MrCurious: OSD3358-SM: https://octavosystems.com/octavo_products/osd335x-sm/
Aug 09 04:59:36 <jkridner> zmatt: yeah, TI just doesn't want to make it any easier than that.
Aug 09 05:01:27 <MrCurious> so 20mmx20mm
Aug 09 05:01:39 <MrCurious> does that include flash and ram
Aug 09 05:01:51 <MrCurious> SiP, so yeah
Aug 09 05:03:14 <jkridner> 21mm x 21mm... RAM, yes. Flash, no. Just EEPROM.
Aug 09 05:04:19 <MrCurious> 64k ram… not going to be a linux machine
Aug 09 05:04:37 <MrCurious> that is more a stm32 competitor no?
Aug 09 05:06:36 <zmatt> jkridner: that twitter pic, I'm guessing left die is am335x, right one is ram, the small one is the pmic?
Aug 09 05:07:11 <zmatt> MrCurious: ?
Aug 09 05:07:14 <jkridner> big black blob is the DDR... in a complete package within the package.
Aug 09 05:07:28 <jkridner> MrCurious: ???  512MB of RAM.
Aug 09 05:08:01 <jkridner> there's more than 64k RAM inside the AM3358 itself.  likely at least double that.
Aug 09 05:08:11 <MrCurious> https://octavosystems.com/octavo_products/osd335x-sm/
Aug 09 05:08:18 <MrCurious> is that the wrong spec's
Aug 09 05:08:19 <zmatt> jkridner: ahhh, I was already a bit weirded out by that "empty" region, but on closer look it's a slightly different color as the rest of the module
Aug 09 05:08:51 <jkridner> MrCurious: that part has 512MB of RAM and 4KB of EEPROM.
Aug 09 05:08:54 <MrCurious> crap. misread dedicated ram as mempory and missed ddr3
Aug 09 05:09:29 <jkridner> oh, yeah, and that shows you have 256KB of L2.
Aug 09 05:09:32 <MrCurious> sorry
Aug 09 05:09:49 <MrCurious> below that line...
Aug 09 05:09:50 <zmatt> yeah you can lock 7/8 of L2 cache to act like ram
Aug 09 05:09:58 <zmatt> if you really want to
Aug 09 05:10:30 <jkridner> zmatt: bottom right looks like the PMIC to me.
Aug 09 05:10:43 <zmatt> that was my first guess, but then I was "where's the ddr3?"
Aug 09 05:10:54 <zmatt> funny that the pmic isn't even that much smaller as the SoC
Aug 09 05:10:55 <MrCurious> this one looks like you could shave 40% if you give up on pins/bga … https://twitter.com/MacroFab/status/736254364474576898
Aug 09 05:10:59 <jkridner> zmatt: yeah, you wouldn't expect it to be in a package.
Aug 09 05:11:12 <jkridner> zmatt: yeah, the PMIC is big.
Aug 09 05:11:22 <jkridner> zmatt: but in a very different process.
Aug 09 05:11:41 <zmatt> yeah I can understand power transistors will need a lot more area
Aug 09 05:12:12 <jkridner> man, I can't get usbmount to work to save my life. :-/
Aug 09 05:12:23 <jkridner> never tried installing it before.
Aug 09 05:13:02 <zmatt> usbmount?
Aug 09 05:13:55 <jkridner> yeah, automounter for USB mass storage devices.
Aug 09 05:14:00 <ds2> too bad there isn't a POP version of the AM335x
Aug 09 05:14:07 <jkridner> just udev rules and some scripts.
Aug 09 05:14:20 <jkridner> ds2: agreed.
Aug 09 05:14:32 <ds2> <--- really really miss POP options
Aug 09 05:15:01 <ds2> right now, I'd settle for an AM57x POP
Aug 09 05:15:14 <jkridner> journalctl shows 'mount -tvfat -osync,noexec,nodev,noatime,nodiratime /dev/sda1 /media/usb0', but nothing shows up when I run 'mount'.
Aug 09 05:15:50 <jkridner> ds2: that'd be even better, really, but can you PoP 4 DDR3 devices to get the full performance?
Aug 09 05:16:25 <ver|laptop> lol if only...
Aug 09 05:16:41 <ver|laptop> that'd be *huge*
Aug 09 05:17:04 <ver|laptop> and probably necessitate a 10-layer pcb ;)
Aug 09 05:17:55 <MrCurious> how many io's are exposed on a ddr3 layer?
Aug 09 05:19:08 <zmatt> ver|laptop: why would it be huge? the PoP version of the omap5 (omap5430) was smaller than the non-PoP version (omap5432)
Aug 09 05:19:16 <zmatt> ver|laptop: it just used a 0.4mm pitch, problem solved ;)
Aug 09 05:19:59 <ver|laptop> zmatt: I mean with 4 layers atop one another .. not a single processor/chip :P
Aug 09 05:20:34 <zmatt> ah
Aug 09 05:20:42 <ver|laptop> you'd have to start pretty small to get enough pin-space !
Aug 09 05:21:05 <MrCurious> or not expose many of them...
Aug 09 05:21:18 <ver|laptop> MrCurious: which immediately defeats the object!
Aug 09 05:21:28 <ver|laptop> you need address -and- data pins for RAM :D
Aug 09 05:21:38 <MrCurious> oops, sryy
Aug 09 05:21:41 <ver|laptop> unless someone's come up with a crafty method for access without...
Aug 09 05:21:44 <zmatt> plenty of space on the top
Aug 09 05:22:04 <ver|laptop> zmatt: oo .. can you do PoP with pins on the Top & Bottom?! that'd be awesome!
Aug 09 05:22:15 <zmatt> ??
Aug 09 05:22:24 <ver|laptop> BGA on -both- sides of the chip?
Aug 09 05:22:37 <ver|laptop> thats gotta be an assembly nightmare!
Aug 09 05:22:38 <zmatt> uhh, of course? how else did you envision PoP ?
Aug 09 05:22:44 * ver|laptop shrug
Aug 09 05:23:01 <ver|laptop> I don't do silicon assembly ..
Aug 09 05:24:20 <zmatt> omap5430 is 980 balls on the bottom (0.4mm pitch) and 240 balls on top (0.5mm pitch)
Aug 09 05:24:29 <zmatt> 14 x 14 mm package
Aug 09 05:25:20 <ver|laptop> neat
Aug 09 05:25:59 <MrCurious> what if top was also 980 balls (0.4 pitch, with 700 pass through)
Aug 09 05:26:04 <ver|laptop> I kinda assumed it was one square of pads for the 'bottom' package, and another hollow square for the next 'package' on top... ignorance ftw
Aug 09 05:27:48 <zmatt> jkridner: btw, the omap5 is an interesting example since it actually has the same memory bandwidth as the am57x, although the PoP version uses lpddr2 instead of ddr3
Aug 09 05:27:58 <MrCurious> make the top chip use 1/4 of the lanes, rot 90 and stack 4
Aug 09 05:28:19 <zmatt> jkridner: so presumably suitable devices exist(ed)
Aug 09 05:28:21 <ver|laptop> MrCurious: that could theoretically work!
Aug 09 05:29:05 <jkridner> ugh. usbmount keeps saying it executed the mount and that it succeeded, but nothing is mounted. :(
Aug 09 05:29:25 <zmatt> weird
Aug 09 05:35:43 <jkridner> grrrr.... nothing is telling me why it is going away.
Aug 09 05:36:45 <MrCurious> watch the log longer, looking for long period timeouts?
Aug 09 05:40:04 <ds2> jkridner: that I donno...but the various cousin chips....
Aug 09 05:40:46 <ds2> jkridner: do you have a race with the mknod?
Aug 09 05:42:09 <jkridner> don't think so. I added a cat of a file on the disk within the udev rule after the mount and it spit out the right file contents.
Aug 09 05:42:21 <jkridner> but at the end, the drive is no longer mounted.
Aug 09 05:42:57 <zmatt> hum
Aug 09 05:43:04 <MrCurious> variable scope?
Aug 09 05:43:09 <jkridner> and it isn't a udev rule that is doing the umount.
Aug 09 05:43:26 <ds2> is /media/usb0 dynamic or a static library?
Aug 09 05:43:54 <zmatt> ... library?
Aug 09 05:44:01 <jkridner> it is just a directory.
Aug 09 05:44:19 <ds2> static directory I mean
Aug 09 05:44:27 <ds2> so there no possible mkdir race?
Aug 09 05:44:55 <zmatt> how would an mkdir race result in it being mounted and then unmounted?
Aug 09 05:45:31 <ds2> can you look at /proc/mounts to see if it is listed there?
Aug 09 05:45:42 <jkridner> ds2: no, the mkdir is already done.... I can see that the mount is successfully happening.
Aug 09 05:45:49 <ds2> wondering if there is some insanity with initrd/pivotroot
Aug 09 05:46:07 * jkridner seems to have hacked it into submission at least once.
Aug 09 05:46:11 <zmatt> jkridner: maybe replace umount by a shell script that calls ps?
Aug 09 05:47:02 <jkridner> added 'fsck -p $DEVNAME || :'
Aug 09 05:47:33 <jkridner> but that doesn't explain why it was mounting and THEN disappearing.
Aug 09 05:48:06 <jkridner> nope, that wasn't it. still acting up.
Aug 09 05:48:37 <ver|laptop> yuk
Aug 09 05:48:41 <ver|laptop> usb ftl :p
Aug 09 05:48:50 <jkridner> within the udev script, I cat a file and can see that the drive is mounted properly... then it just disappears with nothing in journalctl or dmesg to indicate it going away. nothing in /proc/mounts
Aug 09 05:49:08 <zmatt> 07:46 < zmatt> jkridner: maybe replace umount by a shell script that calls ps?
Aug 09 05:49:15 <zmatt> to trace who/what is calling it
Aug 09 05:49:16 <jkridner> why ps?
Aug 09 05:49:25 <jkridner> oh!
Aug 09 05:49:43 <ver|laptop> thats clevah!
Aug 09 05:49:44 <jkridner> I was thinking about nuking umount to see if that'd help.
Aug 09 05:49:51 <ver|laptop> nuke systemd :D
Aug 09 05:49:52 <ver|laptop> :D
Aug 09 05:50:16 <ver|laptop> it'll miraculously work then :)
Aug 09 05:50:36 <ver|laptop> cos some crazy shitty script in /lib/whoknowswhere won't be executing :)
Aug 09 05:50:36 <zmatt> it could get umounted in ways other than an actual invocation of umount, but it's worth a try
Aug 09 05:51:26 <zmatt> ver|laptop: if it's systemd-related then it would be /lib/systemd ;P  and not a script
Aug 09 05:51:42 <ver|laptop> zmatt: some evil bainary then :p
Aug 09 05:51:54 <zmatt> I can't think of a reason why systemd would umount something though
Aug 09 05:52:03 <jkridner> wow, it managed to get unmounted without running /bin/umount :(
Aug 09 05:52:10 <ver|laptop> wait .. you put 'reason' with 'systemd' .. its 'because'
Aug 09 05:52:15 <jkridner> lol
Aug 09 05:52:18 <ver|laptop> jkridner: yikes.. weirdness
Aug 09 05:52:28 <ver|laptop> s/its '/its just '/
Aug 09 05:52:47 <jkridner> oh wait, they did call it!
Aug 09 05:52:49 <ver|laptop> jkridner: usb debug .. its not having a usb musb .. erm .. that ..
Aug 09 05:52:57 <ver|laptop> flapping thing?
Aug 09 05:53:01 <jkridner> something called 'usbmount remove'
Aug 09 05:53:08 <ver|laptop> ooh clues...
Aug 09 05:53:53 <ver|laptop> I'm still going with "because" rather than "reasons" .. sadly. But intrigued to watch the detective-work .. *popcorn*
Aug 09 05:54:06 <jkridner> I just don't know how it managed to get umounted when I'd removed the command.
Aug 09 05:54:43 <zmatt> it might be worth to set systemd log level to debug to see what's happening there
Aug 09 05:55:03 <zmatt> you can do that by sending it a signal
Aug 09 05:56:08 <zmatt> kill -56 1
Aug 09 05:56:47 <ver|laptop> killall init XD heh
Aug 09 05:57:48 <ver|laptop> sorry, my evil streak is havin an outing tonight :D
Aug 09 05:58:27 <jkridner> systemd-analyze set-log-level debug
Aug 09 05:58:36 <jkridner> systemd-analyze set-log-level debug
Aug 09 05:58:40 <zmatt> I assumed there was a nicer command for it, but too lazy to look
Aug 09 05:58:41 <zmatt> :)
Aug 09 05:58:48 <jkridner> systemctl -pLogLevel show
Aug 09 06:00:02 <jkridner> hmmm.... systemd[1]: dev-disk-by\x2duuid-36C7\x2dE879.device: Changed dead -> plugged
Aug 09 06:00:19 <ver|laptop> eww
Aug 09 06:01:13 <ver|laptop> something very odd going on at the usb layer I say ..
Aug 09 06:01:16 <ds2> has systemd made its way into toybox/busybox yet?
Aug 09 06:01:49 <zmatt> jkridner: nothing more?
Aug 09 06:02:04 <zmatt> I'd have expected a .mount to show up as well
Aug 09 06:04:34 <jkridner> there's a bit more, but I don't see any .mount
Aug 09 06:06:10 <zmatt> maybe I'm wrong, perhaps a manual mount doesn't show up as unit
Aug 09 06:06:51 <jkridner> 'Aug 09 06:05:45 pocketbeagle systemd[1]: Sent message type=signal sender=n/a destination=n/a object=/org/freedesktop/systemd1 interface=org.freedesktop.systemd1.Manager member=UnitNew cookie=1259 reply_cookie=0 error=n/a'
Aug 09 06:06:59 <jkridner> bunch of those after the insert.
Aug 09 06:07:14 <zmatt> possibly loglevel debug is more than needed
Aug 09 06:07:33 <zmatt> but yeah you can also monitor what systemd is doing via dbus
Aug 09 06:07:46 <ds2> or you can get rid of it once and for all ;)
Aug 09 06:08:36 <zmatt> or, you can also stop bitching about it given that it's doing its job just fine
Aug 09 06:10:09 <zmatt> jkridner: but you noticed something is invoking usbmount remove... can't you trace what?
Aug 09 06:10:33 <ds2> have your script dump out 'ps lax' which should list the PPID
Aug 09 06:10:42 <ds2> follow that through and it ought to give you an answer
Aug 09 06:10:44 <zmatt> yeah or ps f -fe
Aug 09 06:10:55 <ds2> if you like sysv :P
Aug 09 06:11:07 <jkridner> well, umount isn't being called anymore, but that doesn't help. still being umount'd
Aug 09 06:12:51 <zmatt> so it's not systemd since that would surely have resulted in some debug output...
Aug 09 06:13:07 <zmatt> I have no idea what else could be doing this
Aug 09 06:13:36 <zmatt> can't be many things that use the umount syscall directly
Aug 09 06:14:11 <zmatt> I know the kernel has auditing features you could use to trace that, but I have absolutely no idea how they work
Aug 09 06:16:06 <jkridner> well, it shouldn't be a surprise that it is systemd-udevd making the call
Aug 09 06:16:19 <jkridner> 0     0  6727  6721  20   0   1444   912 wait   S    ?          0:00 /bin/sh /usr/share/usbmount/usbmount remove
Aug 09 06:16:29 <jkridner> 1     0  6721  6350  20   0  11684  1576 SyS_ep S    ?          0:00 /lib/systemd/systemd-udevd
Aug 09 06:16:46 <zmatt> well then there's an udev rule involved
Aug 09 06:17:04 <zmatt> udevadm monitor -u
Aug 09 06:17:15 <zmatt> maybe?
Aug 09 06:17:33 <jkridner> I'll add -u
Aug 09 06:17:47 <jkridner> but without -u, all i'm seeing is 'add' events.
Aug 09 06:18:25 <jkridner> oh, -u just removes the kernel events.
Aug 09 06:18:37 <zmatt> ah, I didn't know -u -k is the default
Aug 09 06:18:58 <zmatt> maybe try using 'udevadm test' to simulate the add and see what rules get invoked?
Aug 09 06:20:51 <jkridner> ugh. /etc/udev/rules.d doesn't have the usbmount rules. :(
Aug 09 06:22:10 <jkridner> oh, /lib. thank you 'dpkg -L'
Aug 09 06:26:32 <jkridner> ugh, ugh, ugh.... no remove events are happening. even commenting out the rules and doing 'udevadm control -R; systemctl restart udev' doesn't change the behavior.
Aug 09 06:26:41 <jkridner> someone is messing with me.
Aug 09 06:27:18 <ver|laptop> hehe they sure are ..
Aug 09 06:27:24 <ver|laptop> and I blame poettring :D
Aug 09 06:27:32 <zmatt> jkridner: have you checked the system for ghosts?
Aug 09 06:27:34 <ver|laptop> but seriously..
Aug 09 06:28:52 <jkridner> my /bin/umount hasn't been called in a while.
Aug 09 06:31:56 <zmatt> I'm pretty sure there's also a way to enable udev debugging, so you can see what it's doing and why
Aug 09 06:41:43 <ver|laptop> there's a trigger ditty in udev no?
Aug 09 07:00:02 <jkridner> ditty?
Aug 09 07:05:15 * jkridner checks out https://github.com/hfuchs/usbmount
Aug 09 07:49:18 <jkridner> 'udevadm trigger --action=add /dev/sdc1' causes the mount and also suffers from the umount (not calling /bin/umount)
Aug 09 07:53:05 <jkridner> Whoa, 4AM! must sleep
Aug 09 07:58:39 <veremit> SQUIRREL! :)
Aug 09 07:58:44 <veremit> peace jkridner :D
Aug 09 08:15:09 <citylight2> Hi, is there a addon board to connect to a piar of 100W speakers?
Aug 09 08:16:04 <citylight2> somthing like  IQaudIO.com Pi-DAC audio card
Aug 09 08:16:04 <citylight2> Designed by Iqaudio.Com
Aug 09 08:16:15 <citylight2> its a DAC nd a power amp
Aug 09 12:23:01 <parduz> hello. Why my BBB tries to flash when powered up with a specific SD card inserted? It does boots from SD normally when i use and older SD. What should i look for (beside the button, which is good)?
Aug 09 12:39:14 <zmatt> parduz: ehm, that kinda implies the card is a flasher (i.e. its /boot/uEnv.txt has the line uncommented that makes it execute the flasher at boot)
Aug 09 12:40:41 <parduz> question is: it booted until yesterday.
Aug 09 12:41:08 <parduz> how could this changes by itself? I just compile and run an app on that BBB
Aug 09 12:44:36 <zmatt> I honestly have no answer to that
Aug 09 12:45:11 <zmatt> I'd suggest examining the card
Aug 09 12:46:34 <parduz> zmatt: ok. I have a PC booted from HBCD with that tiny Linux image with disk utilities.
Aug 09 12:46:58 <zmatt> hbcd?
Aug 09 12:47:43 <parduz> looking at the "current" (non-booting/flashing) SD and comparing visually with the old, booting SD i only see that the old one have a uEnv.txt in the ./ folder, the new one no.
Aug 09 12:47:57 <parduz> (hiren's boot CD)
Aug 09 12:48:07 <zmatt> the relevant path is /boot/uEnv.txt
Aug 09 12:48:21 <parduz> that files are identical
Aug 09 12:49:00 <zmatt> can you pastebin its contents (of the non-booting one) ?
Aug 09 12:49:18 <parduz> sure, i'd need five minutes
Aug 09 12:55:34 <parduz> zmatt: here it is https://pastebin.com/JyXCRtzW
Aug 09 13:02:38 <zmatt> ok
Aug 09 13:02:49 <zmatt> there's definitely absolutely zero reason for this to be starting the flasher
Aug 09 13:03:20 <zmatt> what happens if you power on with the S2 button pressed? (and this card inserted)
Aug 09 13:05:23 <parduz> i have to disassembe it to try this.
Aug 09 13:05:31 <parduz> again, five minutes
Aug 09 13:19:57 <parduz> zmatt: flashing (cylon led pattern)
Aug 09 13:21:44 <zmatt> ok
Aug 09 13:21:55 <zmatt> then I'm out of ideas
Aug 09 13:22:52 <parduz> :(
Aug 09 13:27:05 <parduz> .... pls tell me one thing i can't remember well.... to enable a LCD cape (and disable HDMI), shouldn't a line be uncommented, in that uenv.txt?
Aug 09 13:27:33 <parduz> it's been more than one year from when i did something related to that...
Aug 10 01:03:01 <jrighetti> hello, looking for anyone who as accesed i2C or SPI from the PRU without bitbanging
Aug 10 01:04:14 <jrighetti> I saw the google summer of code project in 2106 that accessed spi and i2c from the pru, but it uses bitbang and not the preiperial hardware like the host processor
Aug 10 01:04:24 <jrighetti> any tips are appreciated
Aug 10 01:04:27 <jrighetti> thanks!
Aug 10 01:06:14 <zmatt> jrighetti: dunno if there are examples, but it shouldn't be too hard
Aug 10 01:10:10 <zmatt> a bit of care is needed to ensure the peripheral is enabled but no linux driver is attached to it
Aug 10 01:10:16 <jrighetti> examples are appreciated, i am assuming i set the device overlay, then just read write to the correct address in PRU memory. anything else required and why are there no examples?
Aug 10 01:11:15 <zmatt> I don't know if there are examples, but not everything you can possibly do on the bbb happens to have an example :)
Aug 10 01:11:50 <jrighetti> it is a powerful board, i just don't want to be first to figure it out :)
Aug 10 01:13:54 <zmatt> the linux side depends a bit on how your bbb is configured currently.  if cape-universal is enabled then the peripheral is already enabeld (at least for i2c, not 100% sure about spi), in which case you can unbind the driver and forcibly enable the peripheral, both via sysfs, and do pinmux using config-pin
Aug 10 01:14:15 <MrCurious> pru examples…? http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html
Aug 10 01:14:32 <zmatt> if not using cape-universal you can indeed use an overlay to setup pinmux and enable the peripheral
Aug 10 01:15:06 <zmatt> MrCurious: I see nothing about i2c or spi there
Aug 10 01:22:01 <MrCurious> zmatt: found this with a google for beagle pru i2c
Aug 10 01:22:01 <MrCurious> https://github.com/chanakya-vc/PRU-I2C_SPI_master/wiki/I2C-Master-Controller
Aug 10 01:24:56 <zmatt> that's the bitbang driver jrighetti mentioned having already found and is not what he was asking about
Aug 10 01:25:16 <MrCurious> sry, just got in the door, was trying to help
Aug 10 01:25:50 <zmatt> ah, I have join/part hidden here... too much spma
Aug 10 01:25:52 <zmatt> *spam
Aug 10 01:26:14 <MrCurious> i was joined all day. just walked in the door, that would not have helped :)
Aug 10 01:26:23 <MrCurious> my fault for not completely reading back context
Aug 10 01:26:54 <zmatt> also, that example looks pretty bizarre
Aug 10 01:29:08 <zmatt> it seems it requires the host to write each individual byte to the pru and then poll for completion, and the pru then transfers that byte in a loop with no delay or anything to control the actual clock frequency
Aug 10 01:29:12 <zmatt> lol
Aug 10 01:33:06 <MrCurious> interesting thread on pru i2c… https://groups.google.com/forum/#!topic/beagleboard/DAXyYJOrDIc
Aug 10 01:35:54 <jrighetti> this gives me hope: https://e2e.ti.com/support/arm/sitara_arm/f/791/p/458311/1659097
Aug 10 01:36:24 <jrighetti> i will try to get ahold of Brad Griffis at TI
Aug 10 01:37:18 <jrighetti> thanks for your help, i will let you know if i find a solution
Aug 10 01:39:39 <zmatt> note that instead of manually dealing with prcm registers you can also do this via sysfs or in the DT
Aug 10 01:39:45 <zmatt> (enabling the peripheral)
Aug 10 01:42:09 <jrighetti> thanks!
Aug 10 01:42:24 <jrighetti> talk later, signing off
Aug 10 02:18:13 <MrCurious> on beagle bone blue, i have a lidar connected to the GPS connector.  in minicom, what /dev/ file would i want to use to talk to it? i have tried /dev/ttyS1 through /dev/ttyS5
Aug 10 02:27:19 <MagusOTB> How do I set up a static ip on beaglebone debian
Aug 10 02:27:37 <MagusOTB> I tried adding an entry in /etc/network/interfaces, but it keeps assigning itself a 169.254
Aug 10 02:37:39 <mag> MagusOTB: [I'm only poking my head in].  What net mgr are you using?  If its connman, try looking in /var/lib/connman (I think; if if that isn't it, look around /var).  If its systemd-networkd, 'man systemd.network'
Aug 10 02:41:34 <MagusOTB> I haven't installed any network managers
Aug 10 02:41:43 <MagusOTB> so whatever it is is probably the default one?
Aug 10 02:42:07 <mag> try 'ps' :)
Aug 10 02:42:12 <zmatt> connman probably
Aug 10 02:43:48 <MagusOTB> sec
Aug 10 02:44:48 <MagusOTB> I definitely have systemd network
Aug 10 02:45:53 <MagusOTB> okay apparently updating my terminal is taking way longer than I expected
Aug 10 02:51:50 <zmatt> uhh, I'm pretty sure systemd-networkd is not used by default on any of the standard debian images
Aug 10 02:52:11 <zmatt> I use it, but I think I'm a minority
**** ENDING LOGGING AT Thu Aug 10 03:00:01 2017