**** BEGIN LOGGING AT Mon Mar 12 03:00:01 2018 Mar 12 11:45:22 Hi Mar 12 11:45:51 I am using beaglebone black and i want to connect camera through it. Mar 12 11:46:14 And i am facing problem to connect camera in it and access in MATLAB Mar 12 12:12:17 * zmatt . o O ( okay. good luck? ) Mar 12 13:13:21 The CPU hardware limits on my beaglebone black wireless show 300 MHz - 800 MHz. Shouldnt this show a max of 1000 MHz? does anyone else have a black wireless? Mar 12 13:16:52 swain: known issue, should be solved I think by updating the kernel Mar 12 13:17:46 also exists on the beaglebone blue and other devices that use octavo's osd335x. they neglected to program the efuses that indicate the supported speedbins Mar 12 13:17:49 zmatt: ok. Ill look into that. Thanks Mar 12 13:19:20 hmm, or maybe they fixed it in u-boot actually Mar 12 13:20:06 i havent found anything related to it from google searches. I didnt know it was a known issue until you said that. Mar 12 13:20:46 well I reported it to jkridner Mar 12 13:21:16 a while ago already, so I'm sort of *assuming* it's been fixed by now Mar 12 13:22:29 yeah, this -> https://github.com/RobertCNelson/bb.org-overlays/commit/f22f11f562b50462e18d7466c998bfac3a9ffd71 Mar 12 13:23:15 not sure why the comment is claiming it's temporary for the v4.9.x-ti tree, because that's not true Mar 12 13:23:47 anyway, that should mean that updating the overlays package fixes the issue I think Mar 12 13:24:35 ok. was about to ask what I was looking at ha. know of any writeups explaining updating the overlays that I could look at? Mar 12 13:24:37 wait, is this the fix or not Mar 12 13:24:43 hm Mar 12 13:25:33 it is Mar 12 13:25:52 strange, since this is not a recent commit Mar 12 13:26:49 swain: which image (cat /etc/dogtag) and kernel version (uname -r) are you using? Mar 12 13:27:36 BeagleBoard.org Debian Image 2018-01-28, 4.9.78-ti-r94 Mar 12 13:27:58 flashed to eMMC or running from sd card? Mar 12 13:28:03 flashed Mar 12 13:28:06 ok Mar 12 13:28:21 so then you should definitely be using u-boot overlays, so... hum.. Mar 12 13:29:53 can you check: Mar 12 13:29:55 xxd -g4 /proc/device-tree/opp_table0/oppnitro-1000000000/opp-supported-hw Mar 12 13:31:41 i dont get anything when I put that into the command line Mar 12 13:31:53 huh Mar 12 13:31:57 the file doesn't exist, or? Mar 12 13:32:17 no such file or directory Mar 12 13:33:58 oh they changed @ to - in kernel 4.14 it seems Mar 12 13:34:07 try oppnitro@1000000000 instead of oppnitro-1000000000 Mar 12 13:35:07 got this : 00000000: 00000004 00000200 ........ Mar 12 13:37:44 yeah, so, hmm Mar 12 13:37:48 what should that mean? Mar 12 13:38:29 that indicates it will only allow 1 GHz if the chip indicates it supports it Mar 12 13:38:59 this overlay should patch it to 00000006 00000100 -> https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/OSD3358-00A0.dts#L27 Mar 12 13:39:13 ah, so the chip is indicating it only supports 800 MHz? Mar 12 13:39:44 the chip isn't indicating anything, and the kernel has a default fallback that assumes support up to 800 MHz Mar 12 13:40:35 oh. I havent messed with overlays before. Do i need to clone the repository? Mar 12 13:40:45 you can try changing your /boot/uEnv.txt to force loading of this overlay, the compiled version of which (OSD3358-00A0.dtbo) should already be installed in your /lib/firmware/ Mar 12 13:41:15 I don't understand why it's not loaded automatically, as I would have assumed based on the name of purpose of this overlay Mar 12 13:41:25 *name and purpose Mar 12 13:49:02 ok. Mar 12 13:50:21 well i do see OSD3358-00A0.dtbo in my firmware. Mar 12 13:52:08 yes, so adding it as manually loaded overlay in /boot/uEnv.txt should work Mar 12 13:52:58 by setting either dtb_overlay or uboot_overlay_addr4 ... not sure what the difference is Mar 12 13:55:18 soo I should add the text of the overlay into the uEnv.txt? sorry, I havent done anything with overlays or uEnv.txt yet besides flashing the emmc. Mar 12 13:55:41 no, configure the path into either of the two variables I just mentioned Mar 12 13:55:48 the variables are already in that file, but commented out Mar 12 13:55:57 ah Mar 12 13:55:57 (the path to the dtbo) Mar 12 13:56:45 oh crap those options disable cape-universal Mar 12 13:56:46 hold on Mar 12 13:56:52 there must be one that doesn't Mar 12 13:57:53 try: uboot_silicon=/lib/firmware/OSD3358-00A0.dtbo Mar 12 13:59:08 ok. and what should this do? Mar 12 13:59:35 make u-boot apply that overlay (without disabling cape-universal as side-effect) Mar 12 14:00:10 (I found that variable by quickly examining the patch for u-boot overlays) Mar 12 14:00:14 use that as a command or do I need to add that to the uEnv.txt Mar 12 14:00:23 add that to uEnv.txt Mar 12 14:02:17 just add that text to the file? also I have bbb.uEnv.txt. also it says to rename as: uEnv.txt to override old bootloader in eMMC. do I need to do that? Mar 12 14:03:06 first line of the file - ##Rename as: uEnv.txt to override old bootloader in eMMC Mar 12 14:04:31 what? Mar 12 14:04:37 no, just modify /boot/uEnv.txt Mar 12 14:04:56 I have no idea what that other file is, never seen it Mar 12 14:05:16 oh shit. sorry yeah that file confused me. Mar 12 14:08:00 should I add that with the uboot overlays or just at the end of the file? or does it matter. Mar 12 14:08:12 doesn't matter where in the file Mar 12 14:08:56 ok done Mar 12 14:12:22 should I see a 1MHz cpu freq now? Mar 12 14:12:30 1 GHz Mar 12 14:12:36 after reboot, yes Mar 12 14:12:49 thats what I thought. Mar 12 14:18:58 it worked. Thats awesome. Thank you. I dont see a 300 MHz step. Should I still have one? Mar 12 14:21:15 for some reason the overlay disables that one... no idea why Mar 12 14:21:52 according to the comment it's doing that for the 4.4-ti kernels, so you can regain it by customizing this overlay Mar 12 14:21:56 if you care Mar 12 14:22:15 yeah not a big deal to me. Mar 12 14:26:50 anyway, it may still be worth complaining about this on the group / mailing list since this ought to work correctly by default obviously Mar 12 14:27:07 if I did want to include that step in the future how would I customize this overlay? Mar 12 14:27:39 you can git clone the overlays repository, change it, and use the makefile to compile the dtbo Mar 12 14:28:00 and probably rename it to avoid conflicts with the file that's part of the overlays package Mar 12 14:28:29 gotcha. cool thanks Mar 12 14:29:12 if you want a less hideous way to write overlays, you can also try my https://github.com/mvduin/overlay-utils repository Mar 12 14:30:04 and then create a 1GHz.dtsi file containing https://pastebin.com/raw/5pxLQCjF and do "make 1GHz.dtbo" Mar 12 14:30:18 ok ill check it out Mar 12 14:31:59 this would be the full OSD3358-00A0.dtsi written in the style accepted by my overlay-utils: https://pastebin.com/raw/4QGawJ4k Mar 12 14:32:18 (I'm pretty sure u-boot ignores the metadata at the top) Mar 12 16:42:48 Hello everyone. I've got a BBBW that I have been trying to get SPI working on. I'm running bone-debian-9.3-iot-armhf-2018-03-05-4gb.img.xy and I've changed the kernel to 4.9.82-bone10 using the apt-get install method. I've used config-pin to set the mode of P9.17, 18, 21 and 22 to their respective SPI modes. ls /dev/spi* shows spidev1.0, 1.1, 2.0 and 2.0. I am trying to run some C++ code to use the SPI interface to talk to an Arduino MEGA 2560. Mar 12 16:42:49 The same code runs just fine on my raspberry pi with the latest raspbian stretch installed. On the BBBW when I run the program I get "SPI: SPI_IOC_MESSAGE Failed: Invalid argument" every time the transfer function is called. When I use write() instead of transfer I don't see any errors. Oscope does not show any activity on any of the pins regardless if I use transfer or write(). Can someone help me figure out what I'm doing wrong? I've also tried Mar 12 16:42:50 a few different images and several different kernels with no luck. Thanks in advance Mar 12 16:43:46 I think generally you'll want the -ti kernel rather than -moses kernel Mar 12 16:44:10 if write() works but SPI_IOC_MESSAGE doesn't then I'm curious what arguments you're passing to it exactly Mar 12 16:44:22 I didn't have any luck with those either. I changed to the bone one trying to make it work Mar 12 16:44:23 you're not seeing any activity though? that's odd Mar 12 16:44:30 write() does not work Mar 12 16:44:33 the -bone kernel sorry Mar 12 16:44:40 it doesnt give an error bt the pins dont change at all Mar 12 16:44:46 lol sorry I was multitasking and my hands typed a random other words Mar 12 16:44:52 yeah that's weird too Mar 12 16:44:56 no problem :-) Mar 12 16:45:53 you're aware that config-pin is not persistent btw? Mar 12 16:45:59 across reboots Mar 12 16:46:19 yeah Mar 12 16:46:21 are there any messages in kernel log? Mar 12 16:46:25 i use it after every reboot Mar 12 16:46:32 how do I see kernel log? Mar 12 16:46:47 otherwise I might need to see some code, since maybe it's doing something specific that the mcspi driver doesn't support Mar 12 16:46:54 dmesg Mar 12 16:47:39 ok dmesg gave a lot, let me look at it for a sec. Ill post code too Mar 12 16:49:04 int transfer(int fd, unsigned char send[], unsigned char receive[], int length) Mar 12 16:49:04 { Mar 12 16:49:04 struct spi_ioc_transfer transfer; // the transfer structure Mar 12 16:49:04 memset(&transfer, 0, sizeof(transfer)); Mar 12 16:49:04 transfer.tx_buf = (unsigned long)send; // the buffer for sending data Mar 12 16:49:04 transfer.rx_buf = (unsigned long)receive; // the buffer for receiving data Mar 12 16:49:06 transfer.len = length; // the length of buffer Mar 12 16:49:08 transfer.speed_hz = 1000000; // the speed in Hz Mar 12 16:49:10 transfer.bits_per_word = 8; // bits per word Mar 12 16:49:12 transfer.delay_usecs = 0; // delay in us Mar 12 16:49:14 int status = ioctl(fd, SPI_IOC_MESSAGE(1), &transfer); Mar 12 16:49:16 if (status < 0) Mar 12 16:49:18 { Mar 12 16:49:20 perror("SPI: SPI_IOC_MESSAGE Failed"); Mar 12 16:49:25 printf("error: %s\n", strerror(errno)); Mar 12 16:49:27 return -1; Mar 12 16:49:29 } Mar 12 16:49:31 return status; Mar 12 16:49:32 } Mar 12 16:49:34 unsigned int fd, i = 0, b, a = 112; // file handle and loop counter Mar 12 16:49:36 unsigned char value, null = 0x00; // sending only a single char Mar 12 16:49:38 uint8_t bits = 8, mode = 0; // 8-bits per word, SPI mode 3 Mar 12 16:49:40 uint32_t speed = 1000000; // Speed is 1 MHz Mar 12 16:49:42 // The following calls set up the SPI bus properties Mar 12 16:49:44 fd = open(SPI_PATH, O_RDWR); Mar 12 16:49:46 ioctl(fd, SPI_IOC_WR_MODE, &mode); Mar 12 16:49:48 ioctl(fd, SPI_IOC_RD_MODE, &mode); Mar 12 16:49:50 ioctl(fd, SPI_IOC_WR_BITS_PER_WORD, &bits); Mar 12 16:49:54 ioctl(fd, SPI_IOC_RD_BITS_PER_WORD, &bits); Mar 12 16:49:56 ioctl(fd, SPI_IOC_WR_MAX_SPEED_HZ, &speed); Mar 12 16:49:58 ioctl(fd, SPI_IOC_RD_MAX_SPEED_HZ, &speed); Mar 12 16:50:00 that code is in main Mar 12 16:50:21 for (i = 33; i<124; i++) Mar 12 16:50:21 { Mar 12 16:50:21 transfer(fd, (unsigned char*)&i, (unsigned char*)&b, 1); Mar 12 16:50:21 write(fd, &nl, 1); // write the new line character Mar 12 16:50:21 std::cout << i << std::endl; //output to the program console too Mar 12 16:50:21 fflush(stdout); // need to flush the output, as no Mar 12 16:50:25 usleep(100000); // sleep for 10ms each loop Mar 12 16:50:27 } Mar 12 16:50:33 that is where transfer is called Mar 12 16:52:03 is there anything specific I should be looking for in the output of dmesg? Mar 12 16:55:46 Hi Guys.. I have written a code in python for my project and running it on Beaglebone Black using Cloud 9 IDE.. I am pretty new to Beaglebone thing so please help me out..so here is the problem.. I am trying to run a stepper motor which has 1600 steps per revolutions.. So whenever I want to do certain revolutions I have to run a loop 1600*revolutions time....at times I have to run upto 26000 iterations...What i realized is that my Mar 12 16:56:06 can somebody help me with what can be an issue? Mar 12 16:56:23 It takes me almost 30 min to run the entire program on BBB Mar 12 16:56:29 Your question was too long and got cut off. Mar 12 16:56:51 Guest22465: ^ Mar 12 16:57:09 Okay let me cut it in parts and put again Mar 12 16:57:25 am trying to run a stepper motor which has 1600 steps per revolutions.. So whenever I want to do certain revolutions I have to run a loop 1600*revolutions time Mar 12 16:57:32 at times I have to run upto 26000 iterations...What i realized is that my beaglebone black is running slow Mar 12 16:57:43 It takes me almost 30 min to run the entire program on BBB Mar 12 17:24:20 Hi I trying to boot from my bbb from SDCARD that contains Yocto build, but I cannot get it to work, I have a boot partitiion with MLO and u-boot.img and root partition with extracted core-image-sato-beaglebone.tar.bz2 Mar 12 17:24:44 serial console doesn't seems to work it just display "CCCCC" and nothing comes up Mar 12 17:26:12 I think it still uses the uboot stuff that is on the eMMC. I had to flash the eMMC to get an image to work correctly. Flashing it updated the uboot stuff and then I could use the microSD card fine Mar 12 17:28:20 Guest22465, you might need to use a motor controller and encoder rather than just trying to get the correct number of steps from running code in a loop to do each step Mar 12 17:28:23 actually CCC indicates it's also not loading u-boot from eMMC Mar 12 17:28:35 oh Mar 12 17:28:47 I already erase eMMC Mar 12 17:30:31 that is my partition table https://justpaste.it/1i6qo Mar 12 17:31:06 agaford, I am using the Easy Driver to run the motor.. the concern is not about the steps but about why the program is running so slow Mar 12 17:38:56 do this apply to beagle bone black http://processors.wiki.ti.com/index.php/SD/MMC_format_for_OMAP3_boot? Mar 12 17:40:18 jose__: no Mar 12 17:41:11 if you want to use MLO and u-boot.img I think all that matters is that it's a bootable FAT partition Mar 12 17:41:20 and it might need to be the first partition Mar 12 17:41:22 not sure Mar 12 17:41:41 zmatt, any idea what is going on with my issue? Mar 12 17:41:56 jose__: the CCC indicates bootrom doesn't even consider your card bootable, i.e. it's not even loading the MLO Mar 12 17:42:25 agafford: never ever again paste such long output into IRC, use a paste service such as pastebin.com Mar 12 17:42:45 ok, sorry Mar 12 17:44:30 also don't send private messages... they're not going to make me notice sooner if I happen to be away or distracted Mar 12 17:44:46 you can ignore the corrupted packet log messages, they're annoying but not harmful Mar 12 17:45:35 if you put your code on pastebin.com (or other paste service of your choice) I'll take a look at it Mar 12 17:45:49 ok let me do that. Thanks for the help Mar 12 17:46:38 I'm also a bit confused that you said earlier you had /dev/spidev1.* and 2.* instead of 0.* and 1.* Mar 12 17:46:54 recent kernels should number them correctly Mar 12 17:48:13 cpp code is at https://pastebin.com/YTYXS53f Mar 12 17:48:54 zmatt: The parition is fat and have boot flag set, I creating the partitions with fdisk under Linux Mar 12 17:49:50 jose__: and MLO is a file in the root of that directory? Mar 12 17:50:07 jose__: can you pastebin the output of head -c 512 MLO | hexdump -C Mar 12 17:51:45 definitely have spidev1.0 and 2.0 not 0.0 and 1.0 Mar 12 17:52:10 it has been that way on two beaglebones and across multiple different images and kernels Mar 12 17:52:11 you're using the latest 4.9-ti kernel? Mar 12 17:52:16 hum Mar 12 17:52:25 curently no but yes I did use that one Mar 12 17:53:12 that's weird Mar 12 17:53:34 can you try a 4.14 kernel just for fun? (-ti or -bone, whichever you prefer Mar 12 17:53:35 ) Mar 12 17:53:59 ive tried 4.4 bone, 4.9 bone, 4.9 ti, and 4.14 bone. All gave 1.0 and 2.0 Mar 12 17:54:09 wha Mar 12 17:54:09 I'll do the 4.14 again with ti this time tho Mar 12 17:54:19 that makes absolutely zero sense Mar 12 17:54:42 the numbering bug has been fixed upstream in 4.14, and the am33xx.dtsi assigns the correct numbers Mar 12 17:55:36 i'll try this one linux-image-4.14.16-ti-r30 Mar 12 17:55:50 same should apply for 4.14-bone Mar 12 17:56:45 Only reason I went to bone was because I kept seeing RCN replying in messages and thought maybe he fixed something Mar 12 17:56:59 rcn makes all of these kernels Mar 12 17:57:09 the ti ones too? Mar 12 17:57:12 yes Mar 12 17:57:21 someone needs to buy him some beer :-) Mar 12 17:57:22 zmatt: https://pastebin.com/dyDbNBqH Mar 12 17:57:44 jose__: that's not an MLO, it's an MLO prepended by a raw mmc boot header Mar 12 17:58:23 iirc the am335x doesn't accept those on a FAT partition, and that seems to match your experience :) Mar 12 17:58:46 oh that is generated by yocto build using beaglebone target Mar 12 17:59:21 try not using the raw mmc boot layout instead of a FAT partition Mar 12 17:59:52 i.e. dd if=MLO of=/dev/whatever seek=256 && dd if=u-boot.img of=/dev/whatever seek=768 Mar 12 17:59:59 *try using Mar 12 18:00:07 ok Mar 12 18:01:24 I need some help regarding the on-board RTC (rtc0) and my external RTC (rtc1). I am trying to disable the on-board RTC and get the system clock to update time to rtc1. Is there a simple way to do this? I have read several forum posts but have not been successful. I am running Ubuntu 16.04 LTS with kernel- 4.14.24-ti-r37 Mar 12 18:02:07 ok that kernel has 0.0 and 1.0. Let me see if my code works Mar 12 18:02:16 which does? Mar 12 18:03:14 zmatt: Thanks I can boot the image now Mar 12 18:03:24 I'm not immediately seeing anything wrong with your code btw, hmm Mar 12 18:03:27 jose__: ok :) Mar 12 18:03:54 is the boot parttion used at all in this case or I can remove it? Mar 12 18:04:02 jose__: it's irrelevant Mar 12 18:04:07 you can remove it Mar 12 18:04:14 zmatt: great thanks for all the help Mar 12 18:05:54 agafford: why are you telling it to transfer one byte, but pass a pointer to a 32-bit integer? Mar 12 18:06:54 also, mode = 0 is not, as the comment claims, SPI mode 3 Mar 12 18:07:30 error is gone, now just need to check with oscope. Mar 12 18:09:30 because I copied the code from a raspberry pi example and that is what it was doing. I've been fighting this error just trying to get the initial test going Mar 12 18:10:50 what should the SPI mode be? 0 or 3? Mar 12 18:11:00 it should be whatever the SPI mode should be Mar 12 18:11:12 0 if it should be zero, 3 if it should be 3 Mar 12 18:11:18 lol true that was a silly question :-) Mar 12 18:11:42 yeah the code I copied had it like that, i didn't change it Mar 12 18:12:02 some devices accept both 0 and 3, in which case I recommend 3 Mar 12 18:12:46 (likewise for devices that accept 1 and 2, I recommend 1) Mar 12 18:13:08 mcspi has some limitations w.r.t. modes 0 and 2 Mar 12 18:13:38 although I'm not sure if the linux driver works around them or not Mar 12 18:13:46 I'll be talking to a MEGA 2560 setup as a slave Mar 12 18:15:47 so check its datasheet I guess? Mar 12 18:19:23 Yeah I'll do that. So the code runs on the BBBW without giving the error now, and I see activity on the oscope. Thank you so much for the help, I've been banging my head on the desk for over a week Mar 12 18:19:51 I'm still puzzled that you had such issues with other kernels Mar 12 18:20:02 they should all have worked fine Mar 12 18:20:17 with the possible exception of unstable spidev numbering Mar 12 18:20:46 yeah i don't know what was going on. Murphy got a hold of me and fried my first BBBW too Mar 12 18:21:03 do be careful when interfacing with external electronics Mar 12 18:21:11 today was the first time i noticed 0.0 and 1.0 instead of 1.0 and 2.0 Mar 12 18:21:13 especially if they have their own power supply Mar 12 18:21:21 which kernel are you using now? Mar 12 18:22:08 4.14.16-ti-r30 Mar 12 18:22:30 and you're sure 4.14-bone didn't have 0.0 and 1.0 ? Mar 12 18:22:34 when i used 4.14 I did a bone one and I'm not 100% sure what one it was Mar 12 18:22:38 no i'm not sure Mar 12 18:22:42 since that would be really really weird Mar 12 18:22:51 im going to check again tho to make sure Mar 12 18:23:04 I'll mail rcn about the unstable spi dev numbering in 4.9 Mar 12 18:23:24 it looks like he included my patch but didn't added the correct assignments in the DT Mar 12 18:24:43 I think i did linux-image-4.14.26-bone-rt-r13. Would the RT version make a difference? Mar 12 18:26:33 no, but you shouldn't use one unless you very specifically need it Mar 12 18:27:13 ok so I also just slowed the speed down to 1000 because my oscope is a USB one and kind of a clunker so I wanted wider waveforms.... Code gives me that error again with speed at 1000 but is ok if speed is changed back to 1000000 Mar 12 18:27:40 what is the minimum speed? Mar 12 18:28:30 I think max clock divider is either 4096 or 32768, not sure Mar 12 18:28:38 and base clock frequency is 48 MHz Mar 12 18:28:59 I'm not 100% sure I'll need the RT version. I've got to talk to two MEGAs with SPI that control the drive motors, 12 servos and a bunch of sensors on I2C and 4 analog sensors.... and it all has to work as fast as possible Mar 12 18:29:23 RT != fast Mar 12 18:29:33 in fact an RT kernel is less efficient than a non-RT one Mar 12 18:30:05 well I guess what needs to be fast is I need to be able to stop the drive motors instantly if the analog distance sensors think its going to run into something Mar 12 18:30:18 so I was thinking maybe i needed that real time capability Mar 12 18:30:37 possibly Mar 12 18:31:10 I'll use the non RT version until it runs into a wall because it was too slow to turn off the motors :-) Mar 12 18:31:46 note that using an RT kernel in itself doesn't make anything real-time, you also need to give your real-time threads/processes real-time priority (something you can also do on a non-RT kernel for useful effect) Mar 12 18:32:03 huh, rcn disables the spidev numbering fixes Mar 12 18:32:14 *disabled Mar 12 18:32:17 ? Mar 12 18:32:56 so he didnt build that ti kernel? or just off on the bone kernels? Mar 12 18:32:56 https://github.com/RobertCNelson/ti-linux-kernel-dev/blob/ti-linux-4.9.y/patch.sh#L558 Mar 12 18:33:35 ditto for 4.9-bone Mar 12 18:33:42 https://github.com/RobertCNelson/bb-kernel/blob/am33x-v4.9/patch.sh#L529 Mar 12 18:34:22 I'm guessing because people relied on the old broken numbering, so he kept it broken for bugwise-compatibility -.- Mar 12 18:34:40 even though without these fixes the numbering isn't even necessarily stable Mar 12 18:35:27 oh well, at least in 4.14 it's been fixed in mainline Mar 12 18:36:00 does it matter if the correct number is used when the file is opened? I guess what I'm asking is was it the fact that the number was wrong causing my issue or maybe something else in the 4.14.16-ti-r30 that was fixed Mar 12 18:36:33 well if spidev1.0 works for you now, then previously it would have been spidev2.0 (most likely) Mar 12 18:37:07 i dont have hdmi disabled so not testing on the second SPI bus at the moment, just pins 17,18, 21 & 22 Mar 12 18:37:21 is that spi0 or 1 ? Mar 12 18:37:25 * zmatt checks Mar 12 18:37:31 spi0 Mar 12 18:37:44 okay, so you're using spidev0.0 right now? Mar 12 18:37:59 yes I changed it after that kernel swap Mar 12 18:38:34 yet spidev1.0 didn't work when the numbering was 1-based? that's odd Mar 12 18:39:05 yeah, so im not sure if that was it or if something else was fixed in that 4.14.16 kernel Mar 12 18:39:07 unless for some weird reason the kernel encountered spi1 before spi0 in DT, which would have made spi1 spidev1 and spi0 spidev2 ... but that would be really odd Mar 12 18:39:43 i tried using spidev2 in my code but it was before i messed with any kernels so not sure if there was another issue or not Mar 12 18:39:58 well I know spidev should work fine in 4.9, we make heavy use of spi and only recently started transitioning from 4.9 to 4.14 Mar 12 18:40:24 yeah it was driving me nuts, felt like SPI should be basic stuff Mar 12 18:40:47 couldn't figure out what i was doing wrong, but at least its working now Mar 12 18:40:57 thanks again for the help Mar 12 18:42:02 I'm glad I'm comfortable with making device trees and udev rules, so our applications can simply open /dev/spi/dsp or /dev/spi/flash instead of hardcoding numbers :) Mar 12 18:42:44 maybe some day there will be decent user-friendly tools for making a DT :-/ Mar 12 19:07:54 zmatt: I pine for that day. Mar 12 19:17:25 zmatt: thinking about it, I think I set the speed to 1000 when u fried my first BBBW and was using the raspberry pi. I didn't change it back to 1000000 until last night. So that might have been the problem I was having with some of the kernels I tried. Mar 12 19:17:39 lol Mar 12 19:17:45 I* fried not u... Mar 12 19:17:52 1000 is definitely below the min speed Mar 12 19:18:20 Yeah it worked on the pi and my cheap USB oscope Mar 12 19:18:51 I think the min is 48MHz/32768 = 1465 Hz (approx) Mar 12 19:19:14 either that of 48MHz/4096 = 11718.75 Hz Mar 12 19:19:17 *or Mar 12 19:19:23 I'm too lazy to check the driver Mar 12 19:20:06 I'll check it. 1000000 is just too fast for my scope to show more than a single line lol... Need a better one Mar 12 19:21:02 it's possible to use a beaglebone as a 100 MHz logic analyzer, google beaglelogic Mar 12 19:30:26 End application I want it to go as fast as possible, just wanted to slow it down to see the waveform for testing Mar 12 19:52:38 Does anyone here know if the Beaglebone Black is UL certified? And is the Arrow Beaglebone Black Industrial UL certified? (or equivalent certifications) Mar 12 19:53:09 ask the respective distributors Mar 12 19:53:45 But aren't the distributors just using the same schematics? Mar 12 19:54:24 that doesn't absolve from certifications Mar 12 19:54:29 (I figured all BBBs are identical, irrespective of which distributor one buys from, since they are using the same open source schematic. Therefore either all or none are certified) Mar 12 19:54:37 if you produce, you have to certify Mar 12 19:54:46 I see Mar 12 19:55:03 they are all ever so slightly different, but mostly the same Mar 12 19:55:07 So, depending on which distributor we purchase from, they may or may not be certified? Mar 12 19:55:16 correct Mar 12 19:55:38 more importantly, the end responsibility lies with them, even if they get the certification from higher up right? Mar 12 19:55:39 Ok, that is good to know Mar 12 19:55:43 I guess Arrow and E14 are the ones you should check Mar 12 19:55:56 presuming you're in the US as you said UL Mar 12 19:56:15 Do you know off hand if any of the distributors have certified a BBB? (Yes, I am in the US, but would be ok with equivalent certifications such as ETL) Mar 12 19:56:52 no clue, the industrial designs might Mar 12 19:57:32 also there's a gazillion of certifications. I guess you are after a specific electrical safety certification. Mar 12 19:57:33 Ok, I appreciate the help. Will reach out to distributors directly. Mar 12 19:57:54 Yes, specifically UL (or ETL, or equivalent from another NRT). Mar 12 19:58:10 AFAIU they all more or less pass CE and FCC part $something Mar 12 19:58:33 though the FCC thing is a bit of a mystery, this thing is noisy as hell Mar 12 19:59:03 it passed extremely marginally in the specific testing setup Mar 12 19:59:15 a suitable enclosure would help a lot presumably Mar 12 19:59:23 * tbr tries to look surprised, fails Mar 12 19:59:45 maybe configure some of the PLLs into spread-spectrum mode Mar 12 20:00:08 What do you mean by noisy? As in interference? (Sorry, not an electrical engineer, just doing some research on behalf of a project team) Mar 12 20:00:30 yeah, electromagnetic emissions Mar 12 20:00:33 yes RF interference Mar 12 20:01:01 Hmm, good to know, thanks Mar 12 20:01:26 UL is mostly about electrical safety right? is that even relevant for a low-voltage device like the bbb ? Mar 12 20:03:02 Correct, UL is about safety. I don't know if it is only relevant above a certain threshold or not, but was told by compliance staff that UL or equivalent certifications are required for their purposes. Mar 12 20:04:09 ok Mar 12 20:04:26 depending on what you do with it, you might need to recertify yourself anyway. Mar 12 20:05:24 Is that possible? Would recertification not require the manufacturer to be in the loop? (unless no changes need to be made to the hardware as part of the certification process) Mar 12 20:06:29 you certify a product/device. If you build a BBB into something and add circuitry it's no longer a development board, sitting lonely on a bench Mar 12 20:07:13 I have no clue about UL and how you might be able to infer things or avoid such requirements Mar 12 20:07:17 just mentioning it Mar 12 20:08:02 I guess that makes sense. But if all we do is put software on it, and connect stuff to the ports using cables, I imagine that would not require re certification right? Mar 12 20:08:55 no clue, ask a lawyer/certification-expert :) Mar 12 20:08:58 Guest37901: as somebody having had lots of fun with UL, i just want to tell you: 1) as supplier. 2) have supplier written certification. Mar 12 20:09:16 Guest37901: if 1) or 2) fails, count device as not certified. Mar 12 20:09:58 Guest37901: 3) your application must be certified as-is when you sell it. if 1) and 2) have succeeded, 3) is (relatively) easy. if 1) or 2) have failes, 3) is hard. Mar 12 20:10:08 4) prepare lots of money to hand over to UL Mar 12 20:10:56 Ok, will do. We will work with our lawyer as we move forward, but haven't had this conversation with him yet. You are right about the cost; I've been looking into that and didn't realize how expensive all this is previously Mar 12 20:11:38 Guest37901: oh, and 5) prepare lots of time to work with UL, as well as 6) do not trust anybody or anything unless you have written, signed proof by UL themselves. everything else will blow up right into your uncertified face. Mar 12 20:11:53 cheap solution: just lie, and try to be working elsewhere before any customer finds out ;-) Mar 12 20:12:06 Lol Mar 12 20:13:21 Guest37901: oh, and you need no lawyer when it comes to the UL, because the UL doesn't give a sh*t about them. they tell you what they define as cerified by them selves, and nobody else. Mar 12 20:15:39 Thanks tbr, Leto, zmat. This information gives me a starting point. Mar 12 20:15:50 np, good luck Mar 12 20:20:21 back in the days printers and other peripherals used to come without cables as that saved boatloads on certification. Rumor has it that some even got away with "it's got no cable, so it gets tested without (aka dead/off)" Mar 12 20:20:50 though I suspect the truth is closer to cables with ferrites being more expensive Mar 12 20:40:16 zmatt: When I remove the boot partition I get this error https://pastebin.com/Xa0sxgSw can get to uBoot but fail to load, any clues what is going on Mar 12 20:41:08 the rootfs needs to be partition 1 probably Mar 12 20:41:26 while you now don't have a partition 1 at all, while the rootfs is partition 2 Mar 12 20:42:39 I think you can renumber partitions in fdisk, or just delete the root partition and recreate at as partition one (with the same start sector and length as it had before) Mar 12 20:42:49 anyway, I'm afk for a bit, bbl Mar 12 20:43:12 zmatt: thanks for the pointers Mar 12 21:54:51 so it worked when I create root partition as partion 2, even if there is a single partition in the SD uBoot is expecting to be partition 2 Mar 12 22:06:49 agafford2: I'm glad you're happy but please just talk in chat instead of using private messages Mar 12 22:08:32 jose__: you mean yocto builds an u-boot that expects you have a boot partition (which is what is suggested if it expects the rootfs in partition 2), yet doesn't work if you place it on one? Mar 12 22:08:36 nicely done Mar 12 22:08:36 -.- Mar 12 22:13:10 zmatt: Yes, and they README mentions you need a FAT boot partition, but it doesn't work because the other issue Mar 12 22:14:20 if you really want to use a FAT partition, you just need to remove the configuration header (the first 512 bytes) from the "MLO" file to get the *actual* MLO file Mar 12 23:44:22 PSA: some guy has set his email on github to root@beaglebone.localdomain, and is now linked as the author to a bunch of stuff I (and presumably others: https://github.com/search?utf8=%E2%9C%93&q=author%3Amaiorfi+beaglebone&type=Commits ) have written Mar 12 23:45:27 github support has explained that they do not do validation on commit emails before attributing them, and there's no way for them to remove an email from an account once claimed, and "thanks me for their understanding" Mar 12 23:45:31 *my understanding Mar 12 23:48:09 (wait nm it's debian@beaglebone.localdomain, same idea though) Mar 12 23:48:26 how on earth does anyone manage to commit stuff with that email address in the first place? given that this requires that 1. you're committing code while being root (wtf?) 2. you ignore the complaints from git that you haven't configured your username and email (does it even let you commit at all?) Mar 12 23:48:35 well ok that at least fixes the first question Mar 12 23:49:03 IIRC it didn't complain, and it was a rather high stress environment. The point is I'm not the only one Mar 12 23:49:58 I could equivalently ask who the hell would create an image that, when not connected to ethernet, makes up an IP address over USB, yet claims to have a fully valid FQDN Mar 12 23:50:36 I think github sucks for letting this happen, and I think it should be debian@localhost Mar 12 23:50:43 that is strange too Mar 12 23:50:50 uh, no, it should be nothing Mar 12 23:50:57 I mean whatever Mar 12 23:51:21 it definitely shouldn't be an FQDN when it was literally reimaged in the woods Mar 12 23:51:34 hostname is not relevant for git Mar 12 23:51:45 I don't understand how it ended up there in the first place Mar 12 23:51:46 yeah, but it's relevant for attribution in email-address-space Mar 12 23:52:13 and IIRC I did not get the usual "you can't proceed witout git config --global" Mar 12 23:52:27 btw it's not too hard to fix the author of commits Mar 12 23:52:37 not without leaving scars of rebases Mar 12 23:52:48 and like, I'm not actually worrid, I can fix this Mar 12 23:52:53 it just happened and I was like "woah what" Mar 12 23:53:02 it is a bit weird Mar 12 23:53:04 like look at this guys commit history (without the beaglebone search term) there's _tons_ more Mar 12 23:54:16 like I think github attributing emails to users without verification is the real problem Mar 12 23:54:50 I'm inclined to agree, although the impact is fairly limited Mar 12 23:55:12 but they don't seem to care, and like, reporting something invalid rather than beaglebone.localdomain seens like also a good thing to do Mar 12 23:56:32 is there an issue tracker for the image I can at least report this to? Mar 12 23:56:58 you're saying the image contains a global gitconfig that's causing this? Mar 12 23:57:32 I mean, I'm not sure I haven't booted the thing in months, ask me in a couple days after I've properly dusted it off Mar 12 23:58:00 It's also possible that git only prompts for that if what it finds when it asks the system is invalid? Mar 12 23:58:31 it has no mechanism for "asking the system" for your full name and email address Mar 12 23:59:03 $(hostname).$(domainname) Mar 12 23:59:04 ? Mar 12 23:59:10 that's not an email address Mar 12 23:59:33 $USER@($hostname).$(domainname) Mar 12 23:59:43 that's still almost never an email address Mar 13 00:00:42 ew, wtf Mar 13 00:00:57 it does default to that, but only if user.name is configured (but user.email isn't) Mar 13 00:01:49 it also warns Mar 13 00:02:27 it's a mail address Mar 13 00:03:29 so, I just did a test: if neither user.name nor user.email is sent, it complains and refuses to commit Mar 13 00:04:10 then how do these commits exist? Mar 13 00:04:12 if user.name is set but user.email isn't, then it loudly warns but still proceeds to commit with $USER@$HOSTNAME as "email address" Mar 13 00:04:33 yeah I totally believe I would have ignored a warning Mar 13 00:04:35 at least the version of git I'm using does this, maybe very old versions behave differently Mar 13 00:05:07 or user.name is already configured... if that's the case, that would definitely be something to complain about to rcn Mar 13 00:07:40 is pretending to have an FQDN at all okay though? Like, nothing's stopping ICANN from selling ".localdomain" registration rights, and somebody could register 'beaglebone.localdomain' and ... probably nothing terrible would happen, but networking pedants would be sad. Mar 13 00:07:58 RFC2606 defines .invalid and .localhost for things like this Mar 13 00:08:25 I agree that's strange too, I definitely wouldn't configure things like that Mar 13 01:31:28 Does anyone know if the omap rng on the bbb is an open design? Mar 13 01:35:29 chillfan: afaik it isn't. Mar 13 01:36:26 onerng, chaoskey. i've used both of them on other machines, not got around to bbb with them though Mar 13 01:37:39 Hm thought so.. I'll have to go with haveged then probably Mar 13 01:38:11 Is there anything simpler than haveged? less resources etc Mar 13 01:39:26 what do you mean by open design? there is a linux driver for it (enabled by default iirc) Mar 13 01:40:05 I mean the onboard device itself, the driver is enabled yeah Mar 13 01:40:27 I also once wrote some info about it -> https://e2e.ti.com/support/arm/sitara_arm/f/791/p/355064/1285226 Mar 13 01:42:02 on linux you can access it via /dev/hwrng Mar 13 01:42:34 yeah, I have rng-tools installed.. I just wonder if this is an open design, or I should use haveged or similar instead. rng-tools is working Mar 13 01:42:36 although for most application you'd just use /dev/urandom of course (or the getrandom system call) Mar 13 01:44:14 I don't understand what you mean by "open design" or how it's relevant? Mar 13 01:46:18 okay, reading a bit about haveged... it sounds really odd Mar 13 01:47:47 Well I mean open source, as in a design that's propritary.. ideally I want something that I can trust on the hardware level, or something in software that will do Mar 13 01:47:58 not propritary* Mar 13 01:48:17 though haveged seems to eat a lot of ram here Mar 13 01:48:19 note that systemd will normally also maintain an entropy seed for /dev/urandom Mar 13 01:48:29 I don't have systemd :) Mar 13 01:49:08 well, maybe if you're lucky your distro has a suitable substitute for this Mar 13 01:49:32 and nothing about the SoC's design is open, and the same is true for any relevant modern SoC Mar 13 01:49:53 Ah ok, thanks Mar 13 01:51:35 I'll see what software methods there are Mar 13 01:53:07 the kernel normally takes care of it (/dev/urandom) as long as there's *some* source of entropy. for most purposes this won't be a problem as long as it has some useful initial seed, which is easy to ensure in userspace Mar 13 01:54:33 the hwrng also seems to output high-quality randomness, which you can feed into /dev/urandom to mix it with the other entropy sources Mar 13 01:54:52 using any sort of bulky daemon for entropy gathering sounds like a complete waste Mar 13 01:55:06 yeah that's what I'm thinking Mar 13 01:55:32 the pools average around 250 I just have software that won't start without a little extra Mar 13 01:56:09 I'm not sure exactly when the kernel itself will use hwrng to feed the entropy pool of /dev/(u)random... I'm assuming it does though Mar 13 01:56:31 won't start? what? Mar 13 01:56:49 I'm sure it's the kernel keeping it at that level, but my programs are complaining "won't start until more entropy is gathered" Mar 13 01:57:19 wtf is that software doing Mar 13 01:57:35 it's dncrypt-proxy Mar 13 01:57:36 and why on earth does it think it needs more than 256 bitd of entropy? Mar 13 01:57:45 i have no idea? Mar 13 01:57:50 haha Mar 13 01:57:56 what is dncrypt-proxy ? Mar 13 01:58:11 https://github.com/jedisct1/dnscrypt-proxy Mar 13 01:58:57 have you tried searching for the origin of the error? Mar 13 02:00:06 no.. though I'd probably use an entropy daemon of some sort in any case.. I guess it's one of the enabled features Mar 13 02:00:27 an entropy daemon is sillyness Mar 13 02:02:15 as long as your system has functionality equivalent to systemd-random-seed (which can be done with a 2-line shell script at startup) you should be fine Mar 13 02:03:59 if a program still complains while the random pool is adequately seeded, that's a bug in that program Mar 13 02:04:09 well that would also be a daemon, but I have no systemd.. nor want it Mar 13 02:04:16 it's not a daemon Mar 13 02:04:25 and that's why I said "functionality equivalent to" Mar 13 02:07:06 No, I'm sure I used up the entropy somehow.. but it was relatively to do Mar 13 02:08:16 for basically every practical purpose it doesn't get "used up". once the rng is seeded you're good (unless its contents gets compromised, but that means your kernel got compromised in which case you have bigger problems that aren't fixed by any entropy gathering daemon) Mar 13 02:08:53 if the software still complains, it's doing stupid things. it should just read from /dev/urandom or use the getrandom() system call and not worry about it Mar 13 02:15:12 if the software can't be easily fixed, use the RNDADDENTROPY call to increase the magic number that makes the software happy Mar 13 02:16:09 annoyingly writing to /dev/urandom doesn't suffice :-/ Mar 13 02:16:31 but again, software shouldn't care and if it does, that's a bug Mar 13 02:17:32 chillfan: also, which kernel version are you using? Mar 13 02:17:39 kernel 3.16 Mar 13 02:18:49 blast from the past Mar 13 02:19:29 I suspect the feature set I enabled just wanted more entropy.. since I'm just setting it up the server was restarted a few times.. I guess it wants some guarentee idk Mar 13 02:19:29 holy cow that's ancient Mar 13 02:20:06 the kernel already provides that guarantee even if you read from /dev/urandom iirc Mar 13 02:22:40 only on very recent kernels Mar 13 02:22:54 it doesn't block on older kernels? Mar 13 02:23:00 not on linux Mar 13 02:23:01 Ah, perhaps that's why.. and dnscrypt wants to make sure Mar 13 02:23:32 chillfan: except if you're seeing the random pool and it still blocks, then it's buggy Mar 13 02:23:35 *seeding Mar 13 02:24:18 it could be, I haven't used it yet.. the maintainership was recently taken over iirc Mar 13 02:24:50 ?? Mar 13 02:25:02 the maintainer abandoned it in dec 2017 Mar 13 02:25:09 waht do you mean you haven't used it yet? how can you be complaining about an error it produced if you haven't used it yet? Mar 13 02:25:11 then someone took it onboard etc Mar 13 02:25:39 when I say used it, I've installed it and configured it.. I mean in the sense it's not been put to actual use yet Mar 13 02:26:12 I don't understand how that's important here Mar 13 02:26:24 Hah, I mean I can't be sure how reliable it is Mar 13 02:26:58 hmm, I also don't why my systems are not automatically feeding the entropy pool from the hwrng, since it looks like the kernel is supposed to Mar 13 02:38:19 ho, there we go... root 31626 2 0 03:37 ? 00:00:00 [hwrng] Mar 13 02:38:48 cool, now can get read continuously from /dev/random without blocking Mar 13 02:38:54 *now I can Mar 13 02:39:08 okay why the hell wasn't this enabled by default Mar 13 02:43:13 because the omap-rng driver never bothered to fill in the quality parameter, okay then Mar 13 02:44:42 hm interesting, I had to install rng-tools to make omap-rng work Mar 13 02:45:48 chillfan: I got it working by setting /sys/module/rng_core/parameters/default_quality to a non-zero value (max is 1024) and then unbinding and binding the omap_rng device Mar 13 02:46:02 I'm now checking how to ensure it's set right from boot Mar 13 02:46:33 the quality parameter indicates how much entropy/bit, with 1024 = 100% entropy Mar 13 02:46:59 any nonzero suffices to prevent /dev/random from ever blocking Mar 13 02:47:02 *nonzero value Mar 13 02:47:37 if you set it to 1, then it'll hash 1024 bytes of data from the rng for every byte read from /dev/random Mar 13 02:48:00 which should satisfy your paranoia ;P Mar 13 02:48:02 so 1024 is probably overkill Mar 13 02:48:18 1024 means you trust the hwrng Mar 13 02:48:32 1 is the most paranoid setting that doesn't disable it Mar 13 02:50:56 setting the rng_core.default_quality kernel parameter did the trick Mar 13 02:51:13 if I set it to 1024, I can read over 100 KB/s from /dev/random Mar 13 02:53:35 note that on old kernels there's also some bug with seeding the random pool from hwrng, see https://github.com/Lekensteyn/archdir/commit/7281f6c5c5be863e6bf1c6aaf4d8e896fbf5facd Mar 13 02:55:01 ah Mar 13 02:55:46 more generally it also sounds like there have been plenty of fixes and improvements to the kernel random device... is there a reason why you're still using an obsolete kernel release? Mar 13 02:56:04 haven't updated it yet Mar 13 02:56:28 I want to compile one soon Mar 13 02:56:32 3.14 hasn't been maintained in years Mar 13 02:57:45 well, the good news is, if you're feeling attached to the ".14", 4.14 is the current LTS series ;) Mar 13 02:57:56 3.16 :p Mar 13 02:58:03 oh 3.16 Mar 13 02:58:22 that's a weird one, I haven't seen that kernel version as much for some reason Mar 13 02:58:27 yeah.. I'm still using debian jessie on here, oldstable release.. so maintained.. I've had trouble with the stretch kernel actually Mar 13 02:59:08 linux-image-armmp from stretch.. maybe I'm doing something wrong.. Mar 13 02:59:32 we use 4.14-bone (recently switched from 4.9-bone) with some custom patches **** ENDING LOGGING AT Tue Mar 13 03:00:03 2018