**** BEGIN LOGGING AT Wed Feb 27 02:59:56 2019 Feb 27 15:50:19 m Feb 27 17:28:50 Hello Feb 27 19:17:01 I'm trying to build a BBB kernel using omap-image-builder, but after a whole bunch of downloads and other activity get this: "Error were encountered while processing: c9-core-installer" Feb 27 19:17:20 Does anyone have any ideas what I have wrong/missing? Feb 27 19:19:45 uhh, that error doesn't give any useful information Feb 27 19:19:56 c9 is cloud9 maybe Feb 27 19:19:59 you'll have to dig through the log to see what went wrong while attempting to install c9-core-installer Feb 27 19:20:09 yeah it is Feb 27 19:20:31 rowsail, umm why building a kernel with the "rootfs" building script? Feb 27 19:20:44 that's another great question Feb 27 19:21:24 OK - sounds like I am going about it all wrong. Feb 27 19:21:42 step 1: what are you trying to do? Feb 27 19:22:02 image-builder is for creating a complete filesystem image from scratch (suitable for flashing to an sd card) Feb 27 19:22:08 What I need to achieve is basically the same sdcard images that are considered the 'latest' via the BB website but with some additional drivers included. Feb 27 19:22:26 then just build a new kernel and install that onto the latest image Feb 27 19:22:30 in particular I am trying to get the Maxim quad UART chip to work via SPI. Feb 27 19:22:46 rowsail, we have "weekly" builds, so https://rcn-ee.net/rootfs/bb.org/testing/ Feb 27 19:22:50 or the lazy option, ask rcn to enable that driver as module for you ;) Feb 27 19:22:54 then using the kernel building script, add your driver: Feb 27 19:22:56 if it's in mainline Feb 27 19:23:25 there's a chance your driver is already enabled, what config? Feb 27 19:23:42 So I can build the kernel no problem - with the driver enabled, but when buildroot finishes I am left with an sdcard image which works, but has none of the scripts needed to move to eMMC. Feb 27 19:23:56 Nor does it appear to have capemanager. Feb 27 19:24:15 buildroot? how did buildroot come into the picture? Feb 27 19:24:28 dd if=/dev/microsd of=/dev/emmc ;) Feb 27 19:24:31 That was the first thing I tried Feb 27 19:24:50 buildroot is a completely different thing unrelated to the beagleboard.org debian images Feb 27 19:24:57 OK - will try that dd command - I tried something similar but it did not work. Feb 27 19:25:18 he was joking, don't do that Feb 27 19:25:40 buildroot's u-boot might have a hard-encoded, path for the microsd/emmc, so you'd have to patch something.. Feb 27 19:25:51 I don't think he wants to use buildroot Feb 27 19:26:15 given that he needed "basically the same sdcard images that are considered the 'latest' via the BB website" Feb 27 19:26:15 What is the preferred method of building an sdcard image? Feb 27 19:26:29 rowsail: just download the latest image and install your kernel onto that Feb 27 19:26:38 voila, now you have the latest image except with a different kernel Feb 27 19:26:43 ehh, not quite I guess Feb 27 19:27:09 OK - but what about the capemanager stuff - is that part of the kernel? Surely not? Feb 27 19:27:28 Err Feb 27 19:27:28 rcn-ee[m]: is there a tool included to make an sd card from eMMC that ensures first boot will be first boot again? (generate ssh keys etc) Feb 27 19:27:40 rowsail: capemanager nowadays is in u-boot Feb 27 19:27:44 OK Feb 27 19:27:56 Thanks - this is teh stuff I needed to know. Feb 27 19:28:03 rowsail: note that things didn't work with buildroot because buildroot doesn't use any of the beagleboard.org enhancements to u-boot or kernel Feb 27 19:28:14 it will get you a completely different system compared to the standard debian images Feb 27 19:28:35 I wished it made that clear - there are defconfigs for the beagleboards Feb 27 19:28:38 zmatt, yes, /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh Feb 27 19:28:44 standard debian images given you a completely different system compared to standard debian installation :) Feb 27 19:28:46 don't use buildroot unless you're an advanced user and understand what it does Feb 27 19:28:55 rowsail, what driver are you enabling? Feb 27 19:29:04 yeah I mean standard beagleboard.org debian images Feb 27 19:29:09 MAX3100 and MAX310X Feb 27 19:29:29 eventually the MCP2317 (GPIO expander too.) Feb 27 19:29:51 4.14 or 4.19 ? Feb 27 19:30:05 CONFIG_SERIAL_MAX3100=m CONFIG_SERIAL_MAX310X=m and whatever config option is needed for the MCP2317 ;) Feb 27 19:30:25 I have a product which is based around the BB. Very short dev time - so was hoping the BB was going to work 'out of the box' (to some extent)! Feb 27 19:30:50 rowsail: I mean, it mostly does, but there are an incredible amount of drivers, it's not weird that not all of them are enabled by default Feb 27 19:31:06 it's really easy (imho) to build and install a custom kernel Feb 27 19:31:26 Yep, got all that. I can build the kernel just fine. But you have been a big help now that I know I should be able to get a latest SD card image and copy over my recently built kernel. Feb 27 19:32:02 So I'll give that a go right now. Thanks! Feb 27 19:32:04 which kernel branch did you use? Feb 27 19:32:33 rowsail, there are 3 types of files, zImage, *.dtb's, and kenrel modules.. first two go under /boot/ third goes under /lib/modules/ Feb 27 19:32:43 uhh, just install the .deb Feb 27 19:32:49 don't mess with manually copying over files Feb 27 19:34:00 Now I'm lost again - the deb? All I have is zImage. Feb 27 19:34:08 rowsail: so my suggestion is: 1. build the .deb for your customized kernel (based on the latest 4.14-ti), 2. flash the latest image from beagleboard.org to eMMC on a beaglebone 3. install the .deb for your kernel 4. use the /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh script to create a new sd card for it Feb 27 19:34:20 rowsail: https://pastebin.com/raw/eLhrp1Hg here are notes on building a kernel Feb 27 19:34:30 if you have a zImage as final product rather than a .deb, you're doing it wrong Feb 27 19:35:00 OK - remember I was using buildroot! Feb 27 19:35:04 Aaargh. Feb 27 19:35:21 MCP2317 = CONFIG_PINCTRL_MCP23S08=m which was enabled.. Feb 27 19:35:23 Can we start from step 0? Feb 27 19:35:24 ... but I already explained that this will give you a totally different product Feb 27 19:35:50 do not use buildroot if you want anything resembling the standard beagleboard.org images Feb 27 19:35:54 How do I build just a new kernel with a slightly different config. Feb 27 19:35:57 https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/4c67db8d7b74cc9adbd90680b79ecc49f56edda1 Feb 27 19:36:06 Nope - will delete buildroot! Feb 27 19:36:06 buildroot is for advanced users who want to create customized linux (not debian) systems Feb 27 19:36:28 see my pastebin for how to build a kernel with custom config Feb 27 19:36:40 https://pastebin.com/raw/eLhrp1Hg Feb 27 19:37:05 I recommend using the ti-linux-4.14.y branch of https://github.com/RobertCNelson/ti-linux-kernel-dev/ as foundatoin Feb 27 19:37:10 *foundation Feb 27 19:38:07 OK - great - thank you so much. Really needed to speak with someone who knew what they were doing - there is way to much nonsense on the web re BB. I have literally spent weeks on this. Feb 27 19:38:47 oof Feb 27 19:39:09 yeah, that kinda happens, we have over 10 years of doc's.. if you need a kernel today, use the script and build the deb, otherwise, the build farm should finish by tomorrow. ;) Feb 27 19:41:21 Oh, I see Robert has enabled the Maxim parts in teh defconfig. Sweet. There's a lot of interest it appears with that part. Of course, the next stage is setting up the driver to use the right SPI port and CS line... but that's another story :-) Feb 27 19:41:34 rcn-ee[m]: btw, so my conclusion is that you should probably give bb-customizations a trigger to rebuild the initramfs (if used) Feb 27 19:42:05 rowsail, that should be configured in the overlay node. Feb 27 19:42:51 zmatt, i'll add that. should have the librobotcontrol modules load ripped out shortly, just testing a blue today.. Feb 27 19:43:31 Yes, overlays - the next area of study... Feb 27 19:44:15 it's just a small device tree loaded by u-boot, lots of examples to look at: https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm Feb 27 19:45:04 yours can probably be very simple Feb 27 19:46:02 I also have tools for making overlays more readable => https://github.com/mvduin/overlay-utils although I need to update the examples for cape-universal compatibility Feb 27 19:52:33 ok I've updated https://github.com/mvduin/overlay-utils/blob/master/spi0.dtsi for cape-universal compatibility Feb 27 19:53:50 whether you want to use my stuff or bb.org-overlays as basis for your custom overlay is up to you Feb 27 19:54:55 Thanks zmatt, I'm just building the kernel from your instructions. Feb 27 19:55:04 I think my spi0.dtsi is a lot more readable and understandable than bb.org-overlays/src/arm/BB-SPIDEV0-00A0.dts ;-) Feb 27 19:56:34 rcn-ee[m]: actually, I think that overlay is not quite compatible with cape-universal? it will add child nodes to &spi0, but the ones added by the universal overlay have different node names (for some reason) hence the result of overlaying will be duplicate child nodes for each chip select Feb 27 19:57:16 of course there's no reason to use the SPIDEV0 overlay when cape-universal is enabled, but that won't stop some people from doing it anyway ;) plus it may be used as basis for customized overlays Feb 27 19:59:17 zmatt, for spi, you just need the P*_pinmux disables, and two channel names.. (this one is fancy as it could have "3" spi devices plugged into the base board: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-mBC1-ETH-CLICK.dts ) Feb 27 19:59:33 I know, I just added that Feb 27 20:00:00 https://github.com/mvduin/overlay-utils/commit/07b48a3d Feb 27 20:00:51 yeap, and that's the one i looked at too.. Feb 27 20:01:27 okay bb-customiztions hook is active and pushed out.. Feb 27 20:19:36 zmatt, found another "buster" oddity... we have two cpufreq systemd services running... Feb 27 20:19:38 debian@beaglebone:~$ systemd-analyze blame | grep cpu Feb 27 20:19:39 3.784s loadcpufreq.service Feb 27 20:19:40 1.170s cpufrequtils.service Feb 27 20:20:07 heh Feb 27 20:21:26 https://packages.debian.org/sid/cpufrequtils vs https://packages.debian.org/sid/linux-cpupower , okay, linux-cpupower says it replaces cpufrequtils, so we will yank the old one.. Feb 27 20:24:37 there, fixed the other examples in overlay-utils for cape-universal compat I think Feb 27 20:24:40 brb, food Feb 27 21:44:07 guten nabend jemand aus deutschland hier Feb 27 21:48:09 Sorry for being a pain - but kernel build finished with: Feb 27 21:48:30 "mv: cannot stat '/home/dhowells/ti-linux-kernel-dev/*.debian.tar.gz': No such file or directory" Feb 27 21:48:40 and a few other similar messages. Feb 27 21:48:49 that's not an error Feb 27 21:49:06 OK - so the files in deploy are OK? Feb 27 21:49:42 yes, it should produce a linux-image-$VERSION.deb there (and tell you that it has done so) Feb 27 21:50:04 linux-headers-4.14.94-ti-r94.1_1xross_armhf.deblinux-image-4.14.94-ti-r94.1_1xross_armhf.deb linux-libc-dev_1xross_armhf.deb Feb 27 21:50:15 linux-image is the relevant package Feb 27 21:50:23 linux-image-4.14.94-ti-r94.1_1xross_armhf.deb Feb 27 21:50:23 linux-headers is generally optional Feb 27 21:50:32 guten nabend Feb 27 21:50:38 I'm not german but I think there's an extra N Feb 27 21:50:49 So now to transfer that to my BB and install right? Feb 27 21:51:02 he needs linux-libc also no ? Feb 27 21:51:11 to have uapi in accordance with the current kernel Feb 27 21:51:13 rowsail: yep, copy to bbb and so sudo dpkg -i FILE Feb 27 21:51:34 mawk: technically sure, but this is just a config change compared to the one he already has Feb 27 21:51:46 Thanks. Feb 27 21:52:16 I mean if he compiles programs and there has been hypotethically an ABI change between the two versions Feb 27 21:52:18 then it will fail Feb 27 21:52:22 having a linux-libc-dev package of vaguely the right era generally suffices Feb 27 21:52:24 uhh, no Feb 27 21:52:37 the linux kernel doesn't do breaking ABI changes anyway Feb 27 21:53:50 ah Feb 27 21:53:56 I thought that wasn't a given Feb 27 21:54:08 basically as long as your linux-libc-dev package is recent enough to use whatever kernel features you want to use, it's fine Feb 27 21:54:22 if that were the case, all applications would break when you install a new kernel Feb 27 21:54:53 yeah Feb 27 21:55:15 or to quote linus torvalds "WE DON'T BREAK USERSPACE" (capitalization appropriate for the typical context in which he says it, namely after someone broke userspace) Feb 27 21:55:22 lol Feb 27 21:55:30 I'm trying to find an example of ABI break Feb 27 21:55:34 but I don't remember where I got that Feb 27 21:55:36 maybe in kvm Feb 27 21:55:48 or in capabilities system Feb 27 21:55:50 note: there's no stable ABI (or API even) in the kernel Feb 27 21:56:14 but breaking changes to userspace is generally considered a big no-no Feb 27 21:56:38 yeah Feb 27 21:56:45 but sometimes it's required, for security Feb 27 21:57:18 I vaguely remember the kernel disabling setgroups() in a user namespace because that enabled escaping chmod in edge cases Feb 27 21:57:28 disabling for non-root at least Feb 27 21:57:43 also for kvm a structure got renamed from something2 to something, erasing the previous structure Feb 27 21:57:51 yeah, but that was on a rather new API and to fix a security hole Feb 27 21:57:53 but you would need a vastly different uapi version to get a problem from that Feb 27 21:58:09 and they made it easy for admins to change back to the old behaviour via a sysctl flag Feb 27 21:58:26 yeah Feb 27 21:58:27 iirc Feb 27 21:59:36 renaming the structure is technically not an ABI break but an API break, but it still sounds pretty rude Feb 27 22:12:48 rcn-ee[m]: weird that those devices are showing up so late in boot Feb 27 22:13:22 though I'll admit I find the boot time in general rather jarring, I'm used to 5-10 second boot time :P Feb 27 22:16:04 wonder why it takes 20 seconds to manually modprobe in his program vs /etc/modules-load.d/ ? i see two possible fixes, fix his program, or try to move them built-in. Feb 27 22:16:29 I don't think he modprobes? Feb 27 22:16:33 didn't check Feb 27 22:16:40 I thought he said he used a device dependency Feb 27 22:17:49 "have the robotcontrol systemd service wait for gpio/pwm/eqep/pru drivers to be loaded before starting" Feb 27 22:18:16 I'm assuming that's what he means, but maybe I'm wrong Feb 27 22:18:50 hmm, no it does'nt Feb 27 22:18:53 *doesn't Feb 27 22:18:59 okay now I'm curious Feb 27 22:19:07 ugh!!!! Feb 27 22:19:12 https://github.com/StrawsonDesign/librobotcontrol/blob/master/services/robotcontrol/src/rc_startup_routine.c Feb 27 22:19:27 he's just waiting for them to "show" up... and rc_usleep(500000); in a while loop.. Feb 27 22:19:36 LOL Feb 27 22:20:04 a systemd pre "load" these modules would work so much better.. Feb 27 22:20:13 or even modprobe xyz .. Feb 27 22:20:46 it's still kinda weird it takes such a long time for them to show up, but I guess that's just because of the ton of devices created by cape-universal Feb 27 22:24:59 yeah cape-universal isn't efficient, the guys behind libgpiod submitted and rfc (can't find it now) to possibly control the pinmux on the PI, that might be a direction for us down the road.. Feb 27 22:25:27 ugh, gpiod Feb 27 22:25:57 I should probably post to some mailing list explaining why gpiod is not remotely a suitable replacement for the sysfs gpio interface Feb 27 22:27:10 well it's being written by developers who don't want us to use the sysfs gpio interface (and plan to nuke it).. so it'll never really be good for us. Feb 27 22:27:45 if they wanted people to switch away from the sysfs interface, they shouldn't have made a replacement that sucks Feb 27 22:28:19 and which requires granting a "may fry hardware" privilege to any process that needs to access any gpio Feb 27 22:28:35 which is something I generally prefer keeping reserved to uid 0 Feb 27 22:30:13 the only advantage of gpiod is being able to toggle multiple pins at once, but that generally only matters for performance-critical uses of gpio, in which case you should just bypass the kernel and write to the gpio controller directly Feb 27 22:31:15 overall it basically offers the performance of the sysfs interface with the convenience and security of the raw hardware interface :P Feb 28 00:26:27 I see a new board is on the way! Cool. Feb 28 00:26:43 16GB! Feb 28 00:40:16 zmatt: rcn-ee: thank you - build worked! Much appreciated as reference to buildroot is made in so many books, and it's clearly not the way to go. Feb 28 00:52:27 Hello everyone Feb 28 00:52:54 this is the first time i use a beagleBoard-X15 Feb 28 00:54:00 i would like to connect a sensor with analog output 0-10v to the board. Feb 28 00:54:29 so what do i need between the beaglebaord and the sensor? Feb 28 00:55:03 i understand that i cannot put 0-10V to any gpios Feb 28 00:55:22 is there a card that i have to use specially for this? Feb 28 01:00:38 i believe to use a voltage divider. can someone guide me towards a link with schematics. Feb 28 01:03:52 Lemings: I don't think the x15 has any analog inputs? Feb 28 01:03:57 unless I remember wrong Feb 28 01:06:10 i don't know Feb 28 01:06:43 i did not find any project with x15 Feb 28 01:08:15 well the beagleboard-x15 is relatively expensive and relatively hard to interface with compared to many other boards, so it's probably not the most popular of boards Feb 28 01:09:59 but as i see we can send 0 to 1.8v to gpios Feb 28 01:10:21 it has 3.3v gpios, not 1.8v Feb 28 01:10:41 ok 3.8V Feb 28 01:10:47 maybe you're confused with older beagleboards? Feb 28 01:11:01 3.3v Feb 28 01:11:16 no i have only the x15 board i never used other boards Feb 28 01:11:24 but you said you had an analog signal, so gpios are of no use for that Feb 28 01:12:09 i saw something here but it s for beaglebone card https://beagleboard.org/Support/BoneScript/analogRead/ Feb 28 01:12:26 that's for the beaglebone, which does have 1.8V analog inputs Feb 28 01:12:50 so is there a solution to read value form a sensor with x15? Feb 28 01:13:32 ha ok beaglebone has 1.8v but x15 has 3.8V Feb 28 01:13:51 both the beaglebone and beagleboard-x15 use 3.3V (not 3.8V) digital I/O Feb 28 01:14:01 the beaglebone additionally has 1.8V analog inputs, the beagleboard-x15 has none Feb 28 01:14:25 unless maybe the pmic has a spare adc input, I could check that Feb 28 01:14:45 so i have to use a sensor with digital output Feb 28 01:15:01 thank you zmatt Feb 28 01:15:11 if it doesn't then your options are 1. find a different sensor that can be read digitally (e.g. via i2c), or 2. use a separate ADC (e.g. connected via i2c or spi) Feb 28 01:15:38 ok i see Feb 28 01:16:07 ah, the pmic does have three general-purpose ADC channels.... but they're all tied to ground, not pinned out Feb 28 01:16:15 that's unfortunate Feb 28 01:17:59 i have to use separate ADC (e.g. connected via i2c or spi) as you said Feb 28 01:18:38 or a digital sensor Feb 28 01:19:45 maybe this one MAX31865 Feb 28 01:21:39 for example yes (if you want to do temperature measurement using an RTD) Feb 28 01:21:44 are digital sensor very common? Feb 28 01:22:36 i would prefer a digital sensor instead of creating a new design with MAX31865 Feb 28 01:22:56 i did not find any digital sensor for now Feb 28 01:23:03 digital temperature sensor? Feb 28 01:23:38 yes Feb 28 01:25:04 zmatt: I'm looking for someone who can write my device tree overlay thingy. Paying job of course. Feb 28 01:25:36 Do you or rcn do such work? Feb 28 01:26:15 Lemings: MCP9808 and TMP100 are the first two results google found for me Feb 28 01:28:41 the TMP100 looks like an integrated circuit Feb 28 01:29:21 rowsail: in my overlay-utils project, make a copy of spi0.dtsi, in the node of the spi device change the compatible-property from "spidev" to "max3100" and add a declaration for its irq line similar to https://github.com/mvduin/py-uio/blob/master/dts/gpio-irq.dtsi#L27-L28 Feb 28 01:29:58 (optionally add pinmux for the gpio) Feb 28 01:30:12 Lemings: uhh yes, did you expect something else? Feb 28 01:30:29 Lemings: the sensor with analog output is presumably also one Feb 28 01:30:49 I have many more devices! One quad UART, two MCP2317 expanders, and 8 output driver. Feb 28 01:30:56 i was expecting to see a sensor but this IC is a temperature sensor? Feb 28 01:31:26 Lemings: why do you think "sensor" and "IC" are mutually exclusive? Feb 28 01:31:30 most sensors are ICs Feb 28 01:31:34 Happy to pay as I am slammed with just getting the harwdware built/tested/working. Feb 28 01:32:03 You can contact me offline if preferred: dhowells@rowsail.com Feb 28 01:32:23 rowsail: sorry, I have enough paid work as it is Feb 28 01:32:50 Understand. Is it worth me contacting rcn? Or is he is same situation? Feb 28 01:33:04 rowsail: in case it's of any use, some notes on DT syntax: https://pastebin.com/XC8vB33d Feb 28 01:33:25 no idea, but I suspect he's a busy man Feb 28 01:33:41 OK - thank you. That's a nice description. Feb 28 01:33:43 but doesn't hurt to email him of course Feb 28 01:34:21 Not sure I have an email for him (is there someway you could send it to me privately?) Feb 28 01:34:28 I think it's on the site Feb 28 01:34:47 it's also listed at https://github.com/RobertCNelson/ Feb 28 01:35:15 and of course in all of his git commits :P Feb 28 01:35:33 Duh! Feb 28 01:35:46 I get so used to not seeing emails on github! Feb 28 01:36:18 Thanks again - so appreciative of your help. Feb 28 01:38:38 with mcp2317 do you happen to mean mcp23s17 or mcp23017 ? because those have documented DT bindings: https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio-mcp23s08.txt Feb 28 01:38:40 as i see i need to build the sensor with TMP100 using a Ground Plane for Thermal Coupling to Heat Source Feb 28 01:39:00 as in the datasheet Feb 28 01:40:23 Lemings: out of curiosity, why did you get a beagleboard-x15 ? I'm getting the feeling that a beaglebone would have been far better suited to your needs Feb 28 01:41:38 because a friend gave it to me logn time ago and only now i try to use it. Feb 28 01:43:13 ok thank you zmatt Feb 28 01:43:20 are you sure it's worth the difficulty? especially since to interface anything to the beagleboard-x15 you'd have to make a pcb with the appropriate (somewhat expensive) hirose connector that mates onto the expansion header connectors of the beagleboard-x15 Feb 28 01:43:28 you can't simply stick wired into it like you can with a beaglebone Feb 28 01:43:31 *wires Feb 28 01:43:51 i have everything Feb 28 01:44:02 ok Feb 28 01:44:08 to connect to hirose connectors Feb 28 01:44:41 all gpios are available to connect directly Feb 28 01:45:40 but as i see everything with this card is expensive Feb 28 01:47:48 thank you zmatt for all your explanation, it was useful for me Feb 28 02:42:50 I need to write this down. How can I remove the contents from the eMMC again? Feb 28 02:43:05 erase eMMC? sudo blkdiscard /dev/mmcblk1 Feb 28 02:43:14 Thank you, sir. Feb 28 02:43:24 That works on the BBBW, right? Feb 28 02:43:30 any beaglebone variant Feb 28 02:43:37 Okay. Feb 28 02:44:29 I done wrote it down. I should not have to ask any longer. Feb 28 02:44:44 Jots! Feb 28 02:59:23 It is safer to have a mainline bone kernel or another one? **** ENDING LOGGING AT Thu Feb 28 02:59:57 2019