**** BEGIN LOGGING AT Wed Jan 25 03:00:02 2017 Jan 25 07:38:44 is it necessary to configure the AINx pins? Jan 25 07:52:15 no (you already asked that), your code on github has multiple issues though Jan 25 07:52:44 but I first need to get myself out the door Jan 25 07:54:45 zmatt: I hoped that my mind tricked me once again... but so I recalled correctly : \ Jan 25 07:55:10 zmatt: sure, no issue ;) Jan 25 08:30:16 Hello Jan 25 08:33:38 hi Jan 25 08:35:34 lo Jan 25 08:42:33 I have a problem for flashing eMMC from SD-card on beaglebone industrial board Jan 25 08:44:12 are you using the script? Jan 25 08:44:48 no, I did manually step as following url Jan 25 08:44:49 http://beagleboard.org/static/beaglebone/latest/README.htm Jan 25 08:46:23 Hold the Boot Button (S2) on the top right (near the SD card slot) and, while holding this button, insert the USB/power lead to connect the power. Jan 25 08:46:45 I have not experience in flashing eMMC. Howver, This may be useful to you http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC Jan 25 08:47:38 The blue on-board LEDs didn't light in sequence and it booted through SD-card instead of eMMC. Jan 25 08:48:08 Chew: did you read http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC ? Jan 25 08:48:26 ok,I will try to do with script Jan 25 08:48:30 maybe it could be useful, sorry but not experience, still, in flashing emmc Jan 25 08:48:30 thank you lore4 Jan 25 08:48:52 Chew: welcome, I hope it may be useful Jan 25 08:54:59 An issue with unreliable USB gadget on soft reboot of OMAP3530 is revisiting. Anyone remember any patches for u-boot > 2011.07 or linux > 2.6.39 meant to fix/improve this? Jan 25 08:59:56 tasslehoff: sorry, no idea : \ Jan 25 09:11:06 Hi! When I am booting from the BBB, it will boot using an external SD Jan 25 09:11:14 But without SD, whenever I boot Jan 25 09:11:24 All LEDs turn on and it won't boot Jan 25 09:11:37 What could be the problem here? Jan 25 10:22:44 zmatt: I still have issues on ADC... may you point me in the right direction, please? Jan 25 10:26:10 btw, I also added reserved bits to registers bit fields, but still not working... I read once again the functional description of TSC, but cannot figure out what i am missing : \ Jan 25 10:33:31 lore4: walk 100m north, then turn 34 degrees to right. walk no more than 23 steps and turn left Jan 25 10:33:47 that should be the "right" direction :) Jan 25 10:34:26 uhm... I believe that in that very spot there is a car mech... do you believe he gots it? :P Jan 25 10:37:59 of course. some of the best wisdom humankind has got came from car mechs. Jan 25 10:42:21 lol, I'll give it a try Jan 25 11:07:26 How can I modify a 4 GB image to fit on a 2 GB eMMc? I have a BBB Rev B and I need to flash it with a new image. Thanks! Jan 25 11:11:45 carpediem: how much space do you use on your uSD? Jan 25 11:11:58 sorry, image Jan 25 11:12:45 btw you can still use the 2gb image from the official website, it is old but it should still work Jan 25 11:13:09 There are some problems with flashing the 2 GB image Jan 25 11:13:22 It is booting from the SD Jan 25 11:13:47 but when I do a dd to copy the sd contents to emmc, it says failure due to inadequate space Jan 25 11:14:30 and I cannot find the uEnv.txt inside of /boot/ to enable flashing at boot Jan 25 11:14:43 I suspect that might be an Angstorm problem? Jan 25 11:20:44 lore4: Checking my SD, I can see 2 partitions, one of 96 MB and another of 1600 MB Jan 25 11:20:57 The 96 MB partition is mounted as boot Jan 25 11:22:26 *marked as boot Jan 25 11:23:41 if i recall correctly in the default distro the uEnv is in a different location Jan 25 11:23:52 in a subfolder of boot Jan 25 11:24:40 carpediem: did you check the /boot/ subfolders? Jan 25 11:25:03 you are dd-ing the whole disk, not one partition, right? Jan 25 11:26:47 at least, I recalled, in my fist days that I found the uEnv in a different location :P Jan 25 11:27:21 lore4: how do I dd the whole disk? Jan 25 11:28:40 I used the command Jan 25 11:28:58 dd if=/dev/mmcblk0 of=/dev/mmcblk1 Jan 25 11:30:19 it should be by specifing the device without the partition number. Jan 25 11:30:40 yes, there it seems to me that you did not specigy any partition Jan 25 11:31:59 still, as I told to others, I do not have experience in flashing emmc Jan 25 11:32:49 gtg lunch Jan 25 11:52:06 carpediem: 96 MB + 1600 MB should fit on a 2G eMMC just fine Jan 25 11:53:05 carpediem: you may get the "out of space" when using dd in the way you mentioned because you're trying to copy the whole card (which may perhaps be much larger) to eMMC, but that error is benign and can be ignored Jan 25 11:56:25 zmatt: That's interesting. How do I do it the correct way? Jan 25 11:56:54 lore4_lunch: Thanks! Jan 25 11:58:52 carpediem: by ignoring the error Jan 25 12:00:04 If i ignore the error and try to start up without the SD, it does not boot. Rather, all 4 LEDs light up and it stays like that. Jan 25 12:00:16 ^ This is after doing the dd Jan 25 12:00:34 ohh, wait, you're trying to dd a *mounted* filesystem? Jan 25 12:01:23 that's a recipe for a corrupted filesystem Jan 25 12:02:04 That's the meaning of all 4 LEDs lighting up at boot? Jan 25 12:02:21 so I should unmount the emmc and then dd into it, right? Jan 25 12:02:23 well the 4 leds is the last stage of boot progress indication from the bootloader Jan 25 12:02:41 wait, you had the eMMC *also* mounted? o.O Jan 25 12:03:08 I am not really familiar with dd and flashing process. Jan 25 12:03:14 So I unmount both Jan 25 12:03:19 SD and emmc Jan 25 12:03:41 Basically I did fdisk -l and it showed me the status for both Jan 25 12:03:43 neither source nor destination should be mounted, but that's a problem because one of the two is your root filesystem Jan 25 12:03:57 ^Yes! Jan 25 12:04:32 but you can unmount all filesystem except the root filesystem, and then remount the root filesystem as read-only Jan 25 12:04:38 mount -o remount,ro / Jan 25 12:05:18 then perform sync, then you should be able to dd safety I think Jan 25 12:06:05 (*note: with "unmount all filesystems" I do not mean pseudo-filesystems like /proc, /sys, etc of course, just real physical filesystems on either sd or eMMC) Jan 25 12:08:57 it says "mount: / is busy" Jan 25 12:10:06 hm, odd, I thought that remounting as read-only was always supposed to work... then again it's not something I commonly use Jan 25 12:11:21 note that it's still just a guess that this is the problem... debugging boot issues really needs a serial console cable so you can see what's going on instead of having to guess what's going on Jan 25 12:26:16 zmatt: I mounted the filesystem again, as read only Jan 25 12:26:41 Doing a dd again Jan 25 12:26:46 Hope it works this tim Jan 25 12:26:49 *time Jan 25 12:27:31 Do you happen to know the location of uEnv.txt file on these old images? Jan 25 12:27:46 sorry, I'm not really that much into archeology Jan 25 12:28:03 I run debian stretch with a 4.9 kernel :) Jan 25 12:29:26 zmatt: No problem. Thanks! Jan 25 12:30:02 One last thing, do you know how I can modify a 4GB image to fit into the 2GB emmc? Jan 25 12:38:30 resize the filesystem with resize2fs and then modify the size of the partition (i.e. remove and readd it with the new size) Jan 25 12:56:43 zmatt: It worked. Thanks a ton for your help! Jan 25 13:02:39 lore4: so, apart from cosmetic issues like the pointless if() around a while() with the same condition, I see two significant problems Jan 25 13:03:02 zmatt: lol Jan 25 13:03:07 actually, make that three Jan 25 13:03:33 that's good, I tought there were more than those :D Jan 25 13:03:53 well, I'm ignoring some of the pointless-but-not-harmful stuff Jan 25 13:04:04 I am listening Jan 25 13:04:38 first, you're not enabling bit 2 of the control register (but you are enabling bit 1, which may or may not be what you intended, I don't know) Jan 25 13:05:01 btw, I already changed the fifo size issue in header, and the %X to %d in arm process Jan 25 13:06:47 second, assuming you meant to enable bit 2 where instead you enabled bit 1... I suggest pondering a bit longer about what bit 2 does exactly (see also its description in my headers) and what, therefore, the right moment is to enable it :) Jan 25 13:07:04 yeah the one that u wrote me yesterday as suggestion! sorry! changed changed value from 3 to 7 now, which should be good Jan 25 13:07:55 bit 1 is enabled so that in the fifo data there will be also the channel id. Correct me if i am wrong Jan 25 13:08:31 the step number, yes that's the effect of bit 1, so that's entirely up to you whether you like that or not Jan 25 13:08:42 bit 2,now after your remark, is enabled to allow write in step configuration registers Jan 25 13:09:35 right, hence enabling it *after* writing the step config is pointless, and the writes to stepconfig will have been discarded :) Jan 25 13:10:19 (I don't know whether that also includes stepenable or not) Jan 25 13:10:39 that sounds sound. Hence I added .CTRL = 6 before setting stepconfig register. Right? Jan 25 13:11:06 indeed Jan 25 13:11:25 step enabled is enabled right before sampling enable, which now is the last thing that I do in the "adc initialization" Jan 25 13:11:53 thank you! Jan 25 13:12:12 also, if you configure one or more steps with continuous sampling, then once you enable the adc FSM_BUSY will always be true, hence your loop testing for it will hang forever Jan 25 13:12:44 also, I noticed you're confused about how a fifo port works Jan 25 13:14:04 ok, now the steps are: 1. bit 1 and 2 to 1 of CONTROL; 2. configure stepconfig (i.e. 1 for me) to one-shot, channel 0 of inp, and value 8 of inm; 3. configure stepdelay to 0; 4. stepenable = 2; 5. control = 7 (i.e. bit 0, 1, 2, = 1) Jan 25 13:14:58 zmatt: ADC FSM should stay to BUSY as long as there are steps to do and in contnious mode, right? Jan 25 13:15:28 uhm... probably, what i am missing of fifo port? Jan 25 13:15:43 yes, waiting for !BUSY only makes sense after making sure all steps are disabled Jan 25 13:17:14 *continous, sorry Jan 25 13:17:23 any read from a fifo port pops the oldest entry from the fifo. it doesn't matter where exactly in the fifo port's window you read (see also the comment on line 16 in my header) Jan 25 13:17:27 *continuous Jan 25 13:17:29 *continuous Jan 25 13:17:31 hehe Jan 25 13:17:37 xD Jan 25 13:18:01 reading from the fifo port when the fifo is empty is invalid and results in a fifo underflow error Jan 25 13:18:17 uuuuhhh Jan 25 13:18:32 so the busywait on fifo count is the best choise, right? Jan 25 13:18:51 *choice.... sorry, dunno what's happening to my hands Jan 25 13:19:41 it's one way... more typically one would the fifo threshold irq Jan 25 13:19:50 but polling the fifo count should also work Jan 25 13:20:17 right now, i am not using the irq as i am working on the PRU Jan 25 13:20:48 so far, I understood that the irq will get to the arm and not to the pru. Did I understand correctly? Jan 25 13:24:11 it's really clear to me why you're doing this on the PRU in the first place :) but you can also poll the irq status register of course Jan 25 13:24:21 and in fact the ADC irq also goes to PRUSS Jan 25 13:24:34 see https://goo.gl/7YooOO Jan 25 13:26:06 uhm... mumble... Jan 25 13:26:22 *it's not really clear Jan 25 13:26:23 sorry Jan 25 13:26:48 don't worry ;) Jan 25 13:27:06 also, where/how are you enabling the ADC in PRCM ? Jan 25 13:27:59 as far as I understood, I may put the fifo thresold to 1, then check the IRQstatus (i.e. 28h) to check if the threshold was passed. Am I right? Jan 25 13:28:11 PRCM? Jan 25 13:28:21 power/reset/clock management Jan 25 13:28:37 linux power manager? Jan 25 13:28:39 the adc is disabled and inaccessible by default Jan 25 13:28:52 echo BB-ADC > "slots" Jan 25 13:29:14 that loads the linux driver for the adc, which will absolutely conflict with any direct use of the adc Jan 25 13:29:26 T.T Jan 25 13:30:23 I explained a fair bit about this :) Jan 25 13:30:57 I understood that it was ok Jan 25 13:31:21 then my explanation failed apparently Jan 25 13:32:00 sorry : \ Jan 25 13:33:13 your options are either letting the kernel enable the adc for you, e.g. by loading the uio_pdrv_genirq driver for the adc and opening the resulting device, or bypassing the kernel entirely and enabling the adc manually via the PRCM registers Jan 25 13:35:18 for testing purposes I think you can just unbind the tscadc driver from the adc device and then bind the uio_pdrv_genirq driver to it Jan 25 13:36:09 if I use the kernel to enable the adc Jan 25 13:36:31 is it not the same as I was previously doing? Jan 25 13:37:47 well you're loading the kernel driver for the adc, which does make the kernel enable the adc, but the driver also configures the adc and handles irqs from it, and it will get very confused if you try to change the adc configuration under its feet Jan 25 13:38:37 it expects to have exclusive ownership Jan 25 13:39:15 hence, if I change the am33xx.dtsi to change the status of tscadc to okay Jan 25 13:39:32 that's basically what the BB-ADC overlay does Jan 25 13:39:36 that should as well load the driver and also configure the kenel to handle it Jan 25 13:39:48 ok Jan 25 13:40:47 but, if I remove the "compatible" which as far as I understood represents the driver, then the kernel should power the adc but not taking the control. Do I guess correctly? Jan 25 13:41:01 you guess incorrectly Jan 25 13:41:03 :) Jan 25 13:41:05 T.T Jan 25 13:41:30 this part I explained: the kernel enables the device *for* the driver Jan 25 13:41:41 if there's no driver to load, the kernel sees no reason to enable the device Jan 25 13:42:01 that's fair. Then, how do I power up the adc without making kernel the "owner"? Jan 25 13:42:30 I explained both options 10 minutes ago Jan 25 13:43:01 via uio_pdrv_genirq driver? Jan 25 13:43:49 otherwise, where are the PRCM registers? Jan 25 13:45:48 do you mean "unbind" and "bind"? Jan 25 13:45:57 you should be able to rebind the adc by doing something like: Jan 25 13:48:39 (one sec) Jan 25 13:48:47 sure, don't worry Jan 25 13:51:36 http://pastebin.com/raw/HLubaWJe Jan 25 13:52:32 this also works if you enable the adc with no or invalid 'compatible' attribute, except in that case the "unbind" step should be omitted Jan 25 13:52:53 (the device will exist in /sys/bus/platform/devices/ then but it won't have a 'driver' symlink) Jan 25 13:55:56 uhm... line 2 is similar to load the pru firmware into the firmware... I guess it is the one that removes the current driver from kernel, right? Jan 25 13:58:38 thank you, zmatt Jan 25 14:00:03 the unbind-line detaches the current driver from the device Jan 25 14:00:22 I then forcibly change which driver is deemed "appropriate" for the device, and then bind that driver Jan 25 14:00:30 (it refuses to bind otherwise) Jan 25 14:00:54 of course overriding like this is hacky, here's the nice and proper way: Jan 25 14:00:57 https://hastebin.com/raw/sekofexumo Jan 25 14:01:47 note that you do need to actually *open* the uio device to make the kernel enable it in PRCM Jan 25 14:02:14 that's why I make a symlink that lets you easily find it. the example given would produce /dev/uio/adc Jan 25 14:03:18 uhm... processing the info Jan 25 14:04:41 take your time Jan 25 14:05:26 note that the three bits of info are for three different files: the first is a device tree fragment you can put in an overlay or your main .dts, the second and third are separate files as indicated by comments Jan 25 14:05:49 so, if I get it straight, which usually it is not ( T.T ), the first pastebn unloads the tscadc driver Jan 25 14:06:55 yeah the pastebin is the dirty way of doing it: unbind any existing driver and then forcibly bind the uio_pdrv_genirq driver Jan 25 14:07:43 the hastebin shows the nice way, which informs the kernel that uio_pdrv_genirq is the appropriate driver to begin with (so the tscadc driver never gets loaded) Jan 25 14:08:26 the second line loads the uio_pdrv_genirq Jan 25 14:08:45 the third line connects the adc to the uio_pdrv_genirq. Right? Jan 25 14:08:57 driver_override doesn't load anything, it merely overrides the normal driver-matching rules Jan 25 14:09:14 https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-bus-platform Jan 25 14:09:28 oh, you may actually need to load the uio_pdrv_genirq driver also, now that you mention it Jan 25 14:09:44 normally the kernel should load drivers automatically, but that probably doesn't work in this case Jan 25 14:09:58 modprobe uio_pdrv_genirq # for doing it at runtime Jan 25 14:10:32 for loading it at boot, put it in /etc/modules Jan 25 14:10:41 if I "lsmod" then I found "uio ... ... uio_pdrv_genirq". If I get it right it should mean that it is already loaded. Right? Jan 25 14:10:48 yes Jan 25 14:11:13 what's the uio_pdrv_genirq driver? Jan 25 14:11:28 sorry, I am a bit stupid T.T Jan 25 14:11:37 struggling to make some link Jan 25 14:11:58 you're not stupid, it's just a lot of info Jan 25 14:12:42 so, uio is a kernel framework meant to allow userspace to access devices directly, hence Userspace I/O (uio) Jan 25 14:13:16 for PCI devices (which it was originally made for) often a small kernel-side component would still be needed, which is why uio is a framework rather than a single driver Jan 25 14:14:56 the reason has mostly to do with irq handling, but the details are irrelevant Jan 25 14:15:35 PCI is not relevant for us, and the issue doesn't exist here Jan 25 14:15:44 a one-size-fits-all generic uio driver works fine Jan 25 14:15:49 that's uio_pdrv_genirq Jan 25 14:16:09 the UIO Platform DRiVer with GENeric IRQ support Jan 25 14:17:17 hence the uio_pdrv_genirq is an "extension" of uio. i.e. uio + generic irq, right? Jan 25 14:18:15 it's a concrete driver based on the UIO framework... uio itself isn't a driver at all, hence can't be used from userspace by itself Jan 25 14:18:48 http://lxr.free-electrons.com/source/drivers/uio/uio_pdrv_genirq.c you can see the driver here, it's quite short Jan 25 14:19:53 lines 45-50 for example show that if you open the device, it asks the kernel power management to make sure the device is enabled/awake Jan 25 14:22:20 after opening it you can mmap() the register space(s) associated with the device Jan 25 14:22:42 uhm... I see the idea, but I am not as much into to catch the romance :P Jan 25 14:23:51 I am feeling like to I am watching a korean porno... you catch something of the movie, but cannot appreciate the details : \ Jan 25 14:23:59 well it lets you fiddle directly with registers, just like /dev/mem, but it's much safer since you can't access anything other than the device's register space (as declared in DT) Jan 25 14:24:23 also since you can set ownership/permissions in an udev rule, there's no need to run the process that uses the uio device as root Jan 25 14:24:58 the kernel enables power/clock for you, and disables it again when you're done with the device Jan 25 14:26:16 and you can easily receive irqs: basically the uio device acts like a socket of sorts, you write (u32)1 into it to enable the irq, and when the irq triggers the kernel disables it and sends you (u32)1 as notification Jan 25 14:27:44 so, "basically" Jan 25 14:28:01 uio is the frework from which uio_pdrv_genirq driver is based on Jan 25 14:28:17 and which allows userspace process to access system devices Jan 25 14:28:23 *framework Jan 25 14:29:05 yeah, another driver based on the uio framework is uio_pruss, which is quite a bit more well-known in the world of beaglebones :) Jan 25 14:29:23 this driver (i.e. uio_pdrv_genirq) allows prus to access devices memory Jan 25 14:29:30 no Jan 25 14:29:43 it allows linux userspace processes access to device memory Jan 25 14:29:55 (the one that is community based and has the main feature of sharing ddr areas, but can broke. Do I recall correctly?) Jan 25 14:30:56 I'm not sure what you mean, except that it indeed allows allocating shared memory in ddr ram Jan 25 14:31:28 (i am just recalling what I got from one of our first "talks" ;) ) Jan 25 14:31:36 note I'm not particularly impressed with the uio_pruss driver, I think it would have made more sense to just add the memory-allocation stuff to uio_pdrv_genirq Jan 25 14:31:52 but it's there, and well-known, hence I mentioned it Jan 25 14:32:05 roger that Jan 25 14:32:21 ok Jan 25 14:33:38 then if uio_pdrv_genirq (which now is more easy to recall its name since I know what it stands for) is to allow userspace linux process to access system devices, then why enable it instead of the tscadc driver? that's due to the fact that owterwise the kernel would keep the ownership and access to such devices? Jan 25 14:34:42 such devices e.g. tsc adc Jan 25 14:34:44 because when you open the device, the kernel will enable the adc in PRCM for you Jan 25 14:35:10 and the uio_pdrv_genirq driver doesn't really "do" anything on its own, and in particular won't get in the way Jan 25 14:35:15 and with opening the device you mean to "ls" the file that represents the device? Jan 25 14:35:21 no, open it Jan 25 14:35:23 as in, open() Jan 25 14:35:45 that's really tricky to me, sorry Jan 25 14:36:24 as in int fd = open("/dev/uio/adc"); (assuming you use my udev rule) in your ARM-side program Jan 25 14:36:53 ehy sorry Jan 25 14:37:05 open("/dev/uio/adc", O_RDWR) Jan 25 14:37:17 (or O_RDONLY would suffice actually) Jan 25 14:37:50 so, instead of loading tscadc driver, if you want to power the tsc adc , then one good choice is to specify uio_pdrv_genirq into the adc device tree file so that the uio_pdrv_genirq is not in your way when accessing the device Jan 25 14:38:23 thats file is the binary file which represents the device, right? Jan 25 14:38:40 device file, yes Jan 25 14:38:45 *if you want to power the adc via kernel Jan 25 14:39:04 the udev rule I gave in https://hastebin.com/raw/sekofexumo creates that symlink Jan 25 14:39:31 the actual device name will be something like /dev/uio0 except it's difficult to figure out what number the 0 might be if you have multiple uio devices Jan 25 14:39:48 hence a named symlink makes life easy Jan 25 14:40:56 that's fair ;) Jan 25 14:41:20 hence the udev rule fragment that you pasted should be added to /etc/udev/udev.conf ? Jan 25 14:41:45 I'll admit that if you're bypassing the kernel anyway (which PRU does) then maybe also doing PRCM manually might be the more sensible choice... though I'm not quite sure yet why you're using PRU to access the ADC in the first place, it seems like a rather complicated way to use the ADC, but I'm guessing you may have Bigger Plans™ for it Jan 25 14:41:55 # /etc/udev/rules.d/uio.rules Jan 25 14:43:27 for direct access to devices from linux userspace however, I can definitely recommend uio over /dev/mem Jan 25 14:44:01 zmatt: so far the plan is to process such samples in real-time Jan 25 14:45:07 ok, then PRU may make sense (depending on latency requirements of course) Jan 25 14:45:36 and if you are thinking to say "patch linux with the rt patch"... then I say that it is sensed, but it is just scouting some Hard-RT Jan 25 14:45:58 zmatt: you already answered ;) Jan 25 14:46:18 if you can fit the real-time stuff in PRU, doing so makes more sense in my opinion than using linux-rt Jan 25 14:46:30 zmatt: quick Q .. is it possible/easy to 'bus' up GPIOs? asking for another platform .. but figured you might know? Jan 25 14:46:55 veremit: what do you mean? Jan 25 14:47:15 zmatt: well .. can you address multiple gpios in one int? for instance Jan 25 14:48:04 zmatt: cool! brb Jan 25 14:48:32 veremit: from kernelspace you can, I think it's intended to also be supported in the new /dev/gpiochip* interface, and of course you can do it from userspace if you mmap the gpio controller directly (at least on TI SoCs) Jan 25 14:49:03 zmatt: have you done anythiing with nxp/freescale imx's ? Jan 25 14:49:10 iirc someone also made a driver that made a device out of a DT-declared bunch of gpios, but I think it never got accepted Jan 25 14:49:21 s/I think /evidently / Jan 25 14:50:07 nope, though all of the above should apply if they have even remotely sane gpio peripherals afaict Jan 25 14:50:30 zmatt: ok thanks for that :) Jan 25 14:56:34 veremit: if safety / privilege separation is important then I'd suggest digging up that patch/driver I mentioned Jan 25 14:57:02 while if performance is critical, mmap the gpio controller Jan 25 14:57:27 the new /dev/gpiochip interface is most appropriate for... ehm... for... ehm... Jan 25 14:57:49 ¯\_(ツ)_/¯ Jan 25 15:03:28 back Jan 25 15:07:55 zmatt: as far as I understood, I do not have enough background to understand most of all (i.e. all) magic which appens in DTs, drivers, devices and so on: what can I read to improve my knowledge? Jan 25 15:08:36 the kernel source code? Jan 25 15:08:39 :) Jan 25 15:08:42 jeez Jan 25 15:08:47 hehe Jan 25 15:09:03 I mean, there's plenty of info on the web, plenty of which is wrong or outdated Jan 25 15:09:14 <- seppuku Jan 25 15:09:45 I agree that the subject could be a bit more approachable than it is currently Jan 25 15:10:09 maybe there's some excellent introductory information out there, I might not know since I don't need it anymore myself hence don't go looking for it Jan 25 15:12:03 that's encouraging Jan 25 15:12:24 :) Jan 25 15:12:38 and it's really not that complicated... Jan 25 15:12:41 once you understand it Jan 25 15:12:53 lol Jan 25 15:13:13 at least, that's my opinion about the parts I understand, the rest is pure black magic of course Jan 25 15:13:13 I believe that the most of the difficult is in your second sentence Jan 25 15:14:14 so, let's say that i should go on by playing and build up my knowledge from that? Jan 25 15:14:53 yeah, and examine examples you can find Jan 25 15:15:02 though probably only the good ones, try to avoid bad examples Jan 25 15:15:07 *preferably Jan 25 15:15:10 ;) Jan 25 15:15:31 lol... which a priori is easy to say if an example is a good or bad one Jan 25 15:16:02 well it should be clear in retrospect, once you understand how it all works ;) Jan 25 15:16:52 if I start to understand xD Jan 25 15:17:42 ok, now coming back to ADC issue. In order to power ADC via kernel by uio_pdrv_genirq Jan 25 15:18:29 I should add the device tree fragment to /etc/udev/rules.d/uio.rules, am I right? Jan 25 15:22:11 but I believe it should be wrong. I should add it to my dts file, right? Jan 25 15:22:57 the latter yes Jan 25 15:23:06 good. Jan 25 15:23:50 I am using am335x-boneblack-emmc-hdmi.dts Jan 25 15:24:12 but wouldn't it better to add it to am33xx.dtsi or am335x-common.dtsi? Jan 25 15:24:14 just make a copy of whatever dts is closest to what you want and add the fragment to it Jan 25 15:24:24 ok Jan 25 15:24:48 the stock dts and dtsi files should be left unmodified Jan 25 15:25:00 you can also #include an existing dts file in your own dts file instead of copying it Jan 25 15:26:14 the whole idea is that the dtsi files contain generic definitions for multiple devices, while the top-level dts contains any customizations you want Jan 25 15:26:15 for example am335x-adc-uio.dtsi Jan 25 15:27:53 yeah I personally usually put reusable DT fragments into dtsi files Jan 25 15:28:37 anyway, I have stuff to do, good luck :) Jan 25 15:28:55 ty Jan 25 15:28:58 ;) Jan 25 16:08:14 zmatt: ok, I edited the dts and added an open of /dev/uio/adc to power the adc in the arm process Jan 25 16:09:28 now it seems that I am reading values, but the are a bit "odd" (i.e. min = 1400, max 3000)... but at least the channels seems right (i.e. 0) Jan 25 16:35:24 zmatt: changing the V semms not to effect the values sampled... Jan 25 16:36:41 I start to believe that the struct addressing is not working right in the fifo Jan 25 16:36:54 bye bye at all! Jan 25 16:36:59 :) Jan 25 17:38:20 Hello Jan 25 17:38:39 I have a big problem with my beaglebone green wireless Jan 25 17:38:58 it is not booting when I power it up Jan 25 17:39:15 only the power LED lights up Jan 25 17:39:26 the other don't Jan 25 17:39:44 the others don't light up Jan 25 17:39:59 and the board doesn't boot Jan 25 17:40:08 What can I do? Jan 25 17:40:20 How can I solve this problem? Jan 25 17:41:51 it was like that when you received it? Jan 25 17:43:36 don't Jan 25 17:43:57 It was working normally when suddenly it got stuck Jan 25 17:44:25 I tried to reboot it by pressing the rest button, but didn´t work Jan 25 17:44:56 so I pressed the power button, but didn't work either Jan 25 17:45:13 so I unplugged the usb cable and plug it again Jan 25 17:45:27 but the board did not boot Jan 25 17:45:45 do you have any CAPE or other external hardware connected to it ? Jan 25 17:46:59 I had some LED and switches coneccted, but I disconnect all of them Jan 25 17:49:08 can you measure the voltage on the 3.3v supply? (pin 3 or 4 of expansion header P9) Jan 25 17:51:11 because I have trouble imagining why it would suddenly become entirely unbootable (even no bootloader apparently) unless you somehow managed to cause hardware damage Jan 25 17:51:58 it is 3.41V Jan 25 17:54:13 oh wait I need to know vdd_3v3a of course, not vdd_3v3b ... ehm, I'm not sure where that can be measured on the bbgw... lemme check its schematic Jan 25 17:56:25 ok, TP4 Jan 25 17:56:42 but I don't know where it's located... on the BBB it's between the ethernet and the power connectors, but the BBGW has neither of those Jan 25 17:57:39 i need some assistance editing uEnv.txt on my bb black Jan 25 17:57:39 oh wait, or just measure any gpio that's normally pulled up Jan 25 17:59:12 how? Jan 25 17:59:24 Guest96171: check voltage on pin P8.43 for example (LCD_DATA2) Jan 25 18:00:03 ivorm: it generally helps to actually ask a concrete question Jan 25 18:02:11 ok, it is 2.70 V Jan 25 18:02:22 ouch Jan 25 18:03:35 ok in my /sys/devices/ folder there is no cape manager Jan 25 18:03:55 ivorm: no /sys/devices/platform/bone_capemgr ? Jan 25 18:04:12 i found cape manager in /sys/firmware/devicetree/base/bone_capemgr Jan 25 18:04:43 Guest96171: that sounds like you damaged some IC, most likely the processor Jan 25 18:05:10 now working through d molloys examples on device tree overlays you have to export slots Jan 25 18:05:34 ok. then im buggered Jan 25 18:05:42 ivorm: /sys/firmware/devicetree/base is merely a representation of the device tree (same as /proc/devicetree ) Jan 25 18:05:57 ivorm: hmm? what? Jan 25 18:07:02 ivorm: bone_capemgr should normally be located at /sys/devices/platform/bone_capemgr Jan 25 18:07:25 keep in mind that a lot of guides floating around on the internet however may be outdated Jan 25 18:07:27 i am a beginner here so apologies if i sound bafoonish Jan 25 18:07:57 bone_capemgr used to be directly in /sys/devices/ in ancient kernels Jan 25 18:07:59 so? Jan 25 18:08:01 yea. i have update image to linux 4.4.30-ti-r64 Jan 25 18:08:04 Guest96171: so, RMA Jan 25 18:08:07 what does the 2.7 V mean? Jan 25 18:08:23 Guest96171: 19:04 < zmatt> Guest96171: that sounds like you damaged some IC, most likely the processor Jan 25 18:08:46 is there any way around this or a fix? zmatt? Jan 25 18:09:05 ivorm: have you checked at the location I mentioned twice? Jan 25 18:09:24 one mom't Jan 25 18:10:30 so, I need to get a new BBGW? Jan 25 18:12:14 zmatt i found:bone_capemgr in /proc/device-tree Jan 25 18:12:30 Guest96171: modern SoCs like those on beaglebones (or rpis etc) have much more fragile I/O than typical microcontrollers like an arduino, they're easy to damage by overcurrent or overvoltage if you're not careful. this is a trade-off for high performance Jan 25 18:13:18 the 2.7V indicates something is heavily draining the 3.3v supply, probably an internal short-circuit inside the processor Jan 25 18:13:42 sorry Jan 25 18:14:15 ivorm: which is not where I told you to look however Jan 25 18:14:23 I applied 5V form the board it self to some GPIO pins Jan 25 18:14:36 when the problem happened Jan 25 18:14:45 Guest96171: then you should have read the manual, the GPIOs are absolutely _not_ 5V-tolerant Jan 25 18:15:21 so yes, you fried the cpu Jan 25 18:16:12 so, It can't be fixed? Jan 25 18:17:34 you can try contacting the manufacturer Jan 25 18:18:31 ok Jan 25 18:18:34 thank you Jan 25 18:19:12 the thing is i want to be able to work with the GPIO pins and cant seem to export slots because cape manager is not where all the guides say it should be. hence why i am asking if i should edit the uEnv to reflect where it actually is? Jan 25 18:19:35 ivorm: /sys/devices/platform/bone_capemgr Jan 25 18:19:52 uEnv has absolutely no influence over where things reside in sysfs Jan 25 18:20:04 that depends mainly on kernel version Jan 25 18:20:49 you don't need capemgr at all to work with GPIO though Jan 25 18:21:17 kernel version 4.4.30-ti-r64 i have Jan 25 18:21:26 yes you said that already Jan 25 18:24:40 Hmm interesting morning Jan 25 18:25:00 for suitable values of "interesting" Jan 25 18:25:56 I mean, morning ds2 :) Jan 25 18:26:54 :) Jan 25 18:27:30 3V3A should be available on the regulator for 3V3B. it is a pretty big part so probing isn't too hard Jan 25 18:28:00 TP4 is still easier, and LCD_DATA2 even more so Jan 25 18:28:29 LCD_DATA2 could be doing wacky stuff, wouldn't rely on that Jan 25 18:28:36 I hope I'm right about LCD_DATA2 though, I'm now a bit worried that.. yea that Jan 25 18:28:55 otoh he admitted to putting 5V on a GPIO, so case closed Jan 25 18:29:00 :D Jan 25 18:29:13 5V into a GPIO if done right could be surviveable Jan 25 18:29:34 not for long Jan 25 18:29:44 Microchip had an appnote for putting 180V into a pic micro controller Jan 25 18:30:18 just limited to a nondestructive current (which isn't specified on this part :() Jan 25 18:32:30 negligible, afaik the clipping diodes are meant just for esd protection and don't limit the voltage to a sufficiently low level to allow sustained current injection via that route Jan 25 18:32:58 so even if you avoid overcurrent through the diode, you're still destroying the gate oxide with overvoltage Jan 25 18:33:08 (which is cumulative) Jan 25 18:33:44 keep in mind that they already have to do wacky stuff to support 3.3V in the first place Jan 25 18:34:11 afaik the abs max for transistors in this technology node is 2.0V Jan 25 18:34:36 (which is a number you find in quite a few places in the datasheet) Jan 25 18:38:53 now tell that to everyone else.... @#$$!$#$@#$@#%@##@ are making it hard to do 1.8V I/O on most boards :( Jan 25 18:40:42 I would really have appreciated 1.8V I/O... and afaik all peripheral chips on the various BBs either support it (eth, hdmi, eMMC) or require it (wl18xx) Jan 25 18:45:47 the am335x also has saner specs at that I/O voltage, e.g. the specified pull-up current range for 1.8V I/O is 52-161 uA, while for 3.3V it's 19-243 uA Jan 26 00:29:36 Hi all, I hope you can help. I am following the ee-wiki guide to install on an SD card.All is fine up to the line ./sgx_build_modules.sh which is not generating the Jan 26 00:29:55 required file ./deploy/GFX_5.01.01.02.tar.gz (sorry for the mispressed newline) Jan 26 00:40:05 I figured it out, I needed to install 32 bit libraries on my 64 bit system. **** ENDING LOGGING AT Thu Jan 26 03:00:01 2017