**** BEGIN LOGGING AT Wed May 23 03:00:03 2018
May 23 07:27:31 <yeonghee> hello
May 23 07:27:39 <yeonghee> can i ask some question?
May 23 08:14:18 <kedidie> **never ask to ask, just ask
**** BEGIN LOGGING AT Wed May 23 08:27:17 2018
May 23 12:21:39 <fred__tv> OT: hw to disable a fbdev lcd screensaver (black screen timeout) ?
May 23 12:21:52 <fred__tv> cat /sys/module/kernel/parameters/consoleblank
May 23 12:21:52 <fred__tv>   shows 600
May 23 12:21:59 <fred__tv> no setterm installed
May 23 12:31:33 <danizl> Hey, I was wondering if anyone could point me in the right direction with a problem i'm having installing a wi-fi driver on my pocketbeagle?
May 23 12:31:54 <danizl>  make[1]: Entering directory '/usr/src/linux-headers-4.9.82-ti-r102' Makefile:629: arch/armv7l/Makefile: No such file or directory
May 23 12:32:20 <danizl> I installed that linux header using sudo apt-get install but it's giving me an error and saying it doesn't have it
May 23 13:43:04 <mrigendra> I have a general question regarding platform driver
May 23 13:43:20 <mrigendra> what is the use of platform_device_id
May 23 14:30:31 <Ragnorok> It's a search term that leads to stuff like https://lwn.net/Articles/448499/
May 23 14:36:18 <mrigendra> I have already referred to that
May 23 14:37:50 <mrigendra> my problem in understanding is platform_device_id is a board file identification thing correct?
May 23 14:38:04 <Ragnorok> No history here.  I've only done LKM so I'm not conversant.  Sorry.
May 23 14:39:32 <mrigendra> So you don't know except writing linux kernel module?
May 23 14:39:43 <mrigendra> but how can you write without knowing it?
May 23 15:04:46 <zmatt> looks like platform_device_id is a thing from the board file age yes
May 23 15:12:35 <mrigendra> So whatever name we fill inside platform_device_id will be used to match driver.driver.name
May 23 15:12:38 <mrigendra> correct?
May 23 15:13:14 <zmatt> I've never dug into how board files used since they aren't used anymore (on ARM anyway)
May 23 15:13:24 <zmatt> *how board files work
May 23 15:13:25 <mrigendra> I see many drivers using different name in platform_device_id and driver.driver.name
May 23 15:13:44 <zmatt> isn't driver.driver.name simply the driver name?
May 23 15:14:55 <mrigendra> Well I think device tree identification way , still uses platform_device_id thing.
May 23 15:15:06 <BBBfan> hello everyone.
May 23 15:15:21 <mrigendra> its same as we use i2c_device_id and of_device_id both inside i2c client drivers.
May 23 15:16:11 <mrigendra> one part matches the device tree node (of_device_id part) and i2c_device_id is used to load up the driver module
May 23 15:16:20 <mrigendra> Thats my understanding.
May 23 15:16:35 <zmatt> I'm pretty sure that understanding is not correct
May 23 15:17:21 <mrigendra> hmm maybe becuase till now I haven't saw a single driver working with only of_device_id and get its probe caleed.
May 23 15:17:21 <zmatt> of_device_id is all that's needed to match the compatible-string in DT and load up driver module
May 23 15:17:32 <zmatt> afaik
May 23 15:17:36 <mrigendra> Have you ever tried that yourself?
May 23 15:17:55 <mrigendra> thats what I used to think too.
May 23 15:18:14 <BBBfan> can someone point me to a good implementation of BBB for a 3D printer?
May 23 15:19:07 <mrigendra> https://groups.google.com/forum/#!category-topic/beaglebone/beagleboardorg-beaglebone-black/2gw6QJTo96I
May 23 15:20:00 <mrigendra> Robert nelson himself says there is some bug. However the of_device_id should work and should only be used on newer kernel
May 23 15:22:08 <mrigendra> Anyways my question was if I am using platform_device_id, isn't the names should be same in both places
May 23 15:22:19 <zmatt> I don't know
May 23 15:22:27 <mrigendra> wherever i2c_device_id is used in i2c client drivers names are always same.
May 23 15:22:37 <mrigendra> device and driver name both.
May 23 15:23:36 <mrigendra> same thing i don't find in platform client driver.
May 23 15:26:36 <zmatt> but wait are we talking about i2c or platform devices?
May 23 15:27:48 <zmatt> since my impression was you were talking about an i2c driver, and you linked to https://lkml.org/lkml/2015/7/30/519 in that thread which is about i2c, yet you're asking about platform_device_id rather than i2c_device_id
May 23 15:29:11 <mrigendra> the framework will be same for  both
May 23 15:29:28 <mrigendra> I was applying my i2c driver knowledge to platform driver
May 23 15:30:13 <mrigendra> such as thiking if I am using i2c_device_id , same way in platform  drivers I should be able to use platform_device_id
May 23 15:30:22 <mrigendra> to load my module.
May 23 15:30:25 <zmatt> you are wrong
May 23 15:30:31 <mrigendra> that link is for older question.,
May 23 15:30:39 <zmatt> platform devices use a MODALIAS based on compatible-string
May 23 15:30:42 <zmatt> check sysfs
May 23 15:31:15 <mrigendra> Umm are you saying about MODULE_DEVICE_TABLE that uses MODALIAS internally
May 23 15:31:26 <zmatt> @nena:~$ cat /sys/bus/platform/devices/4804c000.gpio/modalias
May 23 15:31:27 <zmatt> of:NgpioT<NULL>Cti,omap4-gpio
May 23 15:31:36 <mrigendra> same thing is with i2c drivers too.
May 23 15:31:50 <zmatt> @nena:~$ cat /sys/bus/i2c/devices/0-0024/modalias
May 23 15:31:50 <zmatt> i2c:tps65217
May 23 15:32:00 <zmatt> big difference
May 23 15:32:19 <mrigendra> hmm
May 23 15:33:22 <zmatt> it looks like i2c is just encrusted with more legacy magic
May 23 15:42:26 <mrigendra> https://elixir.bootlin.com/linux/v4.8/source/drivers/ata/pata_samsung_cf.c#L641
May 23 15:42:34 <mrigendra> https://elixir.bootlin.com/linux/v4.8/source/arch/arm/mach-mmp/sram.c#L147
May 23 15:42:41 <mrigendra> these two are platform client drivers
May 23 15:43:01 <mrigendra> in samsung MODULE_DEVICE_TABLE is used
May 23 15:43:12 <mrigendra> but in sram there is none,
May 23 15:43:53 <mrigendra> So how to probe will work?
May 23 15:45:19 * zmatt isn't really awake enough for more digging
**** BEGIN LOGGING AT Wed May 23 19:14:08 2018
May 23 20:52:13 <set_> myself: Here is another update. I have found some other info. I am going to try this person's idea on ArduCopter and the BBBlue.
May 23 20:52:19 <set_> I will let you know what happens.
May 23 20:52:20 <set_> ...
May 23 20:52:54 <set_> https://github.com/imfatant/test
May 23 23:58:36 <set_> Hello...
May 24 00:04:18 <harry>  Hello all,  I am wondering if there is a method to flash the eMMC on the BBB by using serial commands or the USB port? I am trying to automate the flashing step and do not want to use an SD card, as this is a manual process.  Thanks for your help!
May 24 00:04:46 <Guest74695>  Hello all,  I am wondering if there is a method to flash the eMMC on the BBB by using serial commands or the USB port? I am trying to automate the flashing step and do not want to use an SD card, as this is a manual process.  Thanks for your help!
May 24 00:04:54 <zmatt> don't spam your question
May 24 00:04:59 <zmatt> asking once is sufficient
May 24 00:05:26 <Guest74695> i did not know that it posted the first time because i got an error, i apologize
May 24 00:06:07 <zmatt> probably the "error" was nickserv telling you the nickname you chose is registered by someone and you have to pick a different one
May 24 00:06:32 <zmatt> to change your nickname type /nick followed by the nickname you want
May 24 00:07:21 <zmatt> and yes it's possible to boot, and therefore to reflash, the beaglebone via the usb device port (and actually also via the serial console, although that's probably too painfully slow to seriously consider)
May 24 00:07:39 <harry44> thanks zmatt, changed my username
May 24 00:08:12 <harry44> is there a procedure on how to flash the emmc through USB? or even Ethernet?
May 24 00:08:14 <zmatt> is that really much less manual than booting it from a flasher card though?
May 24 00:08:29 <zmatt> ethernet is an option too, albeit more complicated
May 24 00:09:19 <harry44> well, i have the BBB on a custom PCB and i have a bed of nails test setup which automates the PCB testing and micro programming on my custom board
May 24 00:09:40 <harry44> so i was hoping to tie the BBB flashing into my automated testing (through labview)
May 24 00:09:41 <zmatt> can't you just flash the emmc directly?
May 24 00:10:15 <zmatt> if the emmc pins are accessible (like they are on a beaglebone) you can just hold the cpu in reset and interface with the mmc bus directly
May 24 00:10:37 <harry44> im actually using the emmc pins coming off the BBB for a wifi interface
May 24 00:11:04 <zmatt> uhh, so how can it be booting from emmc?
May 24 00:11:34 <zmatt> are you sure you're not talking about the mmc2 interface which is also available on the expansion headers?
May 24 00:12:42 <zmatt> (emmc cmd/clk = P8.20-21, mmc2 cmd/clk = P9.15/P8.18)
May 24 00:28:08 <zmatt> okay, I guess it wasn't important
May 24 00:43:30 <set_> ...
May 24 00:44:06 <set_> Hello...I am receiving an error message, RCOutputAioPRU.cpp:SIGBUS error gernerated, which tells me that my uEnv.txt file needs to be changed.
May 24 00:44:43 <set_> ...
May 24 00:44:47 <set_> Blah. Forget it.
May 24 00:47:04 <zmatt> I have a great deal of trouble imagining any situation where a SIGBUS would be indicative of needing to change anything in uEnv.txt
May 24 00:48:22 <zmatt> SIGBUS means  1. the programmer is directly messing with memory-mapped i/o (most likely via /dev/mem, or *maybe* uio, but far more likely /dev/mem) and  2. the programmer fucked up
May 24 00:53:44 <set_> I am actually typing sudo ./ardurover in the terminal.
May 24 00:54:10 <set_> https://github.com/ArduPilot/ardupilot/blob/master/libraries/AP_HAL_Linux/RCOutput_AioPRU.cpp
May 24 00:54:13 <set_> ...
May 24 00:54:37 <set_> This is what I found online and I cannot tell right away as to why I receive this error.
May 24 00:54:50 <zmatt> I'm not feeling an urgent desire to dig through its voluminous source code to spot potential fuckups
May 24 00:54:58 <set_> Okay.
May 24 00:55:00 <set_> That is okay.
May 24 00:55:06 <zmatt> but
May 24 00:55:15 <set_> but?
May 24 00:55:28 <zmatt> actually no never mind
May 24 00:55:32 <set_> Okay.
May 24 00:55:57 <zmatt> I was trying to think if I had something that allows for proper identification of the cause of the sigbus without too much hassle
May 24 00:56:05 <zmatt> well actually, I guess you could try running it in gdb
May 24 00:56:17 <set_> Okay.
May 24 00:56:50 <zmatt> sudo gdb ./ardurover
May 24 00:56:59 <zmatt> and then type "run" and press enter
May 24 00:57:11 <set_> Okay.
May 24 00:57:13 <set_> Brb
May 24 01:01:07 <set_> https://pastebin.com/VQZhaJNF is what it shot back at me.
May 24 01:01:24 <set_> I will look up 0x0006555a
May 24 01:01:26 <set_> ...
May 24 01:01:36 <zmatt> lol no, look up Linux::RCOutput_AioPRU::init
May 24 01:01:41 <set_> Oh.
May 24 01:01:42 <set_> Okay.
May 24 01:01:50 <zmatt> also
May 24 01:02:12 <zmatt> when you're at this point, can you do... ehm... hold on lemme check the right commands
May 24 01:02:20 <set_> Okay.
May 24 01:05:12 <zmatt> "disassemble" and "info reg"
May 24 01:05:56 <set_> So, while in a gdb session, I should type those commands?
May 24 01:06:09 <zmatt> after the crash, yes
May 24 01:06:14 <set_> Okay. Hold.
May 24 01:06:17 <set_> I will try,.
May 24 01:06:18 <zmatt> oh never mind
May 24 01:06:23 <set_> Dang!
May 24 01:06:30 <zmatt> I should just have looked at the source code
May 24 01:06:45 <zmatt> so yeah, it maps pruss memory via /dev/mem
May 24 01:07:17 <zmatt> which means there's absolutely no mechanism in use for ensuring that pruss is even accessible
May 24 01:07:24 <set_> Oh.
May 24 01:07:28 <zmatt> and in this case it isn't, and it crashes
May 24 01:07:33 <set_> Ah.
May 24 01:07:36 <zmatt> this is just bad programming
May 24 01:08:08 <set_> I was following this guide on the BBBlue and Ardupilot.
May 24 01:08:25 <zmatt> but also they're presumably assuming that pru has been setup to run some particular software
May 24 01:08:36 <set_> Oh.
May 24 01:09:27 <zmatt> (but apparently didn't feel bothered to ensure that this is the case, instead of crashing with a SIGBUS when it isn't)
May 24 01:10:26 <set_> So, this is the set up I have now. The BBBlue has nothing attached to it and I am trying to compile on it.
May 24 01:10:34 <set_> So-motion!
May 24 01:10:43 <set_> sorry. Slow-motion.
May 24 01:12:48 <set_> I know compiling on the BBBlue takes hours.
May 24 01:13:00 <set_> I still want to not Cross-Compile this time.
May 24 01:13:09 <zmatt> hey, it's your time
May 24 01:13:11 <set_> ...
May 24 01:13:44 <set_> I know. I would be done and done again. The funny thing is that I already did this and completed all tasks.
May 24 01:13:45 <set_> ...
May 24 01:14:31 <set_> I Cross-compiled the arduCopter and put it on the BBBlue. I then erased for "who knows why," and then tried this new set up.
May 24 01:15:40 <set_> ...
May 24 01:15:59 <set_> The old set up was not available any longer and this new set up does not work. There is no way to go back now.
May 24 01:16:11 <set_> <<<<< did not take notes. Crud!
May 24 01:20:09 <set_> https://pastebin.com/4zdAJM3a is a "hardware" config file that I was supposed to make. Does this make sense to anyone?
May 24 01:22:18 <zmatt> it's setting gpio 2.16 (P8.36) to output-high and configures P8.15 to pru-ecap
May 24 01:23:18 <set_> Oh.
May 24 01:23:24 <zmatt> as for why they want you to do that in a shell script instead of just doing it themselves, I can't begin to guess
May 24 01:23:51 <set_> Who knows?
May 24 01:24:09 <set_> I cannot get my brain around why this works, does not work, or should work right now.
May 24 01:26:13 <set_> brb/yell at the wall time.
May 24 02:42:44 <peterk_> hello all
May 24 02:55:26 <zmatt> bye peterk_
**** ENDING LOGGING AT Thu May 24 03:00:03 2018