**** BEGIN LOGGING AT Wed May 16 03:00:12 2018 May 16 03:16:10 myself: I am getting closer w/ the BBBlue and ArduPilot. May 16 03:17:09 So far, I just need to add the three phase motors to the ESCs. May 16 03:17:27 I still need to get a special connector, too. May 16 03:18:38 DS2 or something like that... May 16 03:21:31 I actually have no clue as to what to call this specific connector. Off to look it up via photos. May 16 03:25:06 Oops. XT60. **** BEGIN LOGGING AT Wed May 16 06:34:47 2018 May 16 11:21:57 Hello Guys, I used https://github.com/RobertCNelson/bb-kernel/tree/am33x-v4.17, './build_kernel.sh' to compile kernel; but 4.17.0-rc5-bone0.zImage is property of 'DOS/Windows executable (application/x-ms-dos-executable)'. The Beaglebone Black doesn't boot. Do you have any suggestions? Many thx! May 16 12:10:13 jerry: it's hard to understand what you mean May 16 12:10:53 jerry: do you have anything attached to the debug UART pins? does the kernel print anything? May 16 12:47:34 jerry: it's not a dos executable. whatever is telling you that it is is pulling that idea out of its ass. if you want anyone to be able to help you debug your boot issues, you're going to need to provide more information. ( http://www.catb.org/esr/faqs/smart-questions.html#beprecise ) May 16 12:48:15 zmatt: BUM. well are nice people. its pulling it out if its "BUM"! :-) May 16 12:58:52 LetoThe2nd: pull things out of the BoM? That's the Worst/Kaas scenario! May 16 13:58:30 Is there any information on the clock accuracy (drift, jitter,..) of the BBB? May 16 14:00:34 which clock? May 16 14:00:42 (there are three oscillators) May 16 14:00:50 200MHz PRU clock May 16 14:01:21 I thought maybe there exists a single document ;) May 16 14:02:19 not really, since different components are involved May 16 14:02:43 ok May 16 14:03:36 the 200 MHz pru clock comes from the Core PLL May 16 14:03:47 which itself uses the 24 MHz main oscillator as input May 16 14:03:59 that is Y2? May 16 14:04:30 yes May 16 14:05:18 I've noticed its absolute frequency is not that great May 16 14:06:51 I noticed the same in my data May 16 14:07:06 although it seems relatively consistent across different beaglebones... they all seem to be roughly 40 ppm off (too fast iirc but don't hold me to it) May 16 14:07:37 as for jitter, I think that's mainly a PLL spec May 16 14:08:24 it's mainly drift that is the problem May 16 14:08:40 note that if desired, pruss can use the Display PLL as clock source. If you're not using the lcd controller, this PLL is not used for anything else hence you would be able to freely configure its frequency May 16 14:08:59 I think it can even do small adjustments without unlocking the PLL May 16 14:09:10 interesting May 16 14:09:43 so you could a frequency error measurement from ntp or ptp to adjust the clock frequency May 16 14:09:49 *use a May 16 14:12:21 would it be possible to use an external clock May 16 14:12:24 ? May 16 14:12:26 no May 16 14:12:36 ok :p May 16 14:13:32 some peripherals accept external clocks, but internal clocks ultimately all derive from the main oscillator May 16 14:14:07 some bigger TI SoCs have fancier clock trees, but the am335x is relatively simple May 16 14:14:41 I see May 16 14:16:08 so you're seeing significant drift? May 16 14:16:24 as in, temperature-dependence? or do you mean over the device lifetime? May 16 14:17:54 between BBBs May 16 14:18:34 I have three of them with identical software, using the PRU to write data May 16 14:19:01 ah ok so not drift but production tolerance May 16 14:19:42 production dependent drift May 16 14:19:51 "drift" implies over time May 16 14:22:24 yes May 16 14:36:39 thx zmatt, bye **** BEGIN LOGGING AT Wed May 16 15:51:01 2018 May 16 16:17:43 hi May 16 16:19:02 can anyone help me, for connecting the HMC5883L mag sensor with BBB. I am currently geeting follwoing error : data = bus.read_i2c_block_data(0x3C, 0x03, 6) IOError: [Errno 16] Device or resource busy May 16 16:19:23 Any help would be greatly appreciated May 16 16:24:43 chinna_: check kernel log for errors, and make sure pinmux is set right May 16 16:25:07 may I know, what is pinmux May 16 16:25:17 I think EBUSY is probably due to the i2c controller observing the pins as being low, which would imply the pins aren't muxed May 16 16:25:21 or you're missing pull-ups May 16 16:25:32 which pins are you using? May 16 16:25:40 Pin 19 and 20 May 16 16:25:49 okay then you're probably just missing pull-ups May 16 16:26:05 Ok, what should I do for it? May 16 16:26:11 add pull-ups May 16 16:26:54 you need resistors (around 4.7 kΩ is fine, the exact value isn't too critical) between sda and 3.3v and between scl and 3.3v May 16 16:27:14 Excellent May 16 16:27:35 I will try and I update it in half an hour May 16 16:27:40 and I will come back to you May 16 16:30:29 #e-ale May 16 18:14:32 How do I set the pinmux on my X15 to enable pr1_pru1_gpi{0..9}? Is there a syntax reference for making a .dtsi? May 16 18:18:03 stash: it's not too hard, but I don't have a good reference May 16 18:18:08 lemme check May 16 18:22:57 hmm, I wanted to say "you can also use TI's pinmux tool to generate the pinmux block" but it doesn't seem to be cooperating May 16 18:23:22 possibly because it wants you to do it in u-boot May 16 18:24:54 (since changing pinmux or iodelay can cause glitches unless the device is in io isolation mode, which is only possible when running out of internal ram) May 16 18:25:31 zmatt: Yes. I was confused as to how to get from the TI pinmux tool to something I could load. May 16 18:26:34 I got the mvduio/pi-uio examples working, but can't figure out how to get signals out of the board. May 16 18:27:37 zmatt: mvduio -> mvduin May 16 18:28:23 pi-uio -> py-uio May 16 18:34:37 that's me btw :) May 16 18:34:52 just hold on, I'll cook something up May 16 18:39:55 zmatt: Wonderful. Thank you. May 16 18:52:20 something like this might work => https://pastebin.com/jGQFJvwQ May 16 18:53:48 although it kinda needs iodelay settings too May 16 19:01:25 zmatt: This is exactly what I was looking for. Thanks. May 16 19:07:57 Can the iodelay be figured out from the TI PinMux tool output? May 16 19:23:29 https://pastebin.com/cXvGVLrv May 16 19:23:46 this includes all pruss1 gpi available on the x15 expansion headers, and their iodelay May 16 19:24:09 I hope it actually works ;) May 16 19:24:26 I got the values from the datasheet, but presumably you can get them from the pinmux too also May 16 19:24:30 *tool May 16 19:24:43 brb May 16 19:33:47 I think I can crib the numbers from genericFileFormatIOdelay.txt. Correct? May 16 19:48:41 I haven't examined the output files of TI's pinmux tool in any detail. if it contains the same values, then yes May 16 19:54:24 stash: oh wait, to enable iodelay some flag needs to be passed in the pinconf May 16 19:54:40 I think May 16 19:55:08 yeah May 16 19:56:59 Do these conflict with the items in your dra7-uio-pruss.dtsi example, or can they be appended? May 16 19:57:27 oh and wtf, the datasheet doesn't list the pins in order.... ARGH May 16 19:57:47 you can just append them May 16 19:57:56 and maybe merge the two &pruss1 { ... }; nodes May 16 19:59:33 oh interesting, they actually give different iodelay values for parallel capture mode May 16 20:03:24 zmatt: I think I want to use direct connect mode. May 16 20:05:23 I have an old PRU program from am am335x that bit-bangs a 1-bit serial (to) and 8-bit parallel (from) bus to an FPGA. May 16 20:10:54 okay, here's a new try: https://pastebin.com/enr6R4aT May 16 20:11:23 I've included the iodelay for both in and out, so to change the direction you only have to change the pinmux May 16 20:12:14 actually that can be done nicer... May 16 20:14:45 https://pastebin.com/BU6hX6Zc May 16 20:16:58 zmatt: ah. ok the 700ps common delay was the difference. May 16 20:18:04 the lowest input g_delay of those 9 pins was 700 ps. since there's obviously no point in delaying the whole group of signals, I subtracted that from all of them May 16 20:22:17 it still blows my mind that TI included three programmable delay-lines for every IO of the processor as a way of lining up the signals May 16 20:22:25 I mean, it's effective I guess May 16 20:23:34 zmatt: Yes. I was trying to explain this to my HW guy, and failing. May 16 20:23:59 with quite a bit of range and precision too... based on the values I read from the iodelay peripheral, the adjustment step size is around 35ps May 16 20:24:09 and evidently the range is several nanoseconds May 16 20:24:51 well it's pretty easy to explain it to a HW guy... at least how it works May 16 20:25:23 I better not explain any of this to my EEs, lest they come up with some novel application. May 16 20:25:46 well you could compensate for pcb trace lengths May 16 20:25:58 for that you'll want to add to A_DELAY btw, not G_DELAY May 16 20:26:37 zmatt: this is cool. I'll compile it in tomorrow and go find a connector and some wires. May 16 20:27:35 I hope it actually works May 16 20:27:55 I also wonder how serious the risk of glitching is May 16 20:28:42 I think it shouldn't be too hard to allow u-boot to configure the ios at a later point (e.g. after reading settings from eMMC) May 16 20:28:45 or even the kernel May 16 20:29:35 but it would require placing some helper code in internal sram to put the ddr3 memory into selfrefresh, isolate the ios, reconfigure ios, deisolate the ios, take ddr3 out of selfrefresh, and jump back May 16 20:29:38 zmatt: the cape manager for bbb still hurts my brain a little. May 16 20:29:54 the kernel already has most of that though, it's used for suspend May 16 20:30:19 how so? May 16 20:30:46 cape manager is just a thing that reads i2c eeproms of capes, and loads the corresponding DT overlay May 16 20:32:26 zmatt: *just*. I never realized the DT was something that could be modified at runtime. May 16 20:33:24 oh yeah runtime overlays (which are kinda separate from cape-manager) are a big hack, and always had limitations and bugs May 16 20:33:30 that's why it's been deprecated entirely May 16 20:33:38 overlays are now handled by u-boot May 16 20:34:03 (hence cape-manager moved there as well) May 16 20:34:40 zmatt: thanks again. May 16 20:35:36 I'm glad that my "port" of pruss-uio to the x15 is of use to people :) May 16 20:36:06 ("port" being the appropriate DT config) May 16 22:31:05 well, I'm getting somewhere on my netbooting project - turns out I'm getting tons of errors on the ethernet-over-usb connection May 16 22:31:44 So I wrote a u-boot script that grabs a kernel, an initrd, and a FDT, one at a time, checks their checksums, and keeps fetching them until they work May 16 22:32:08 actually I wrote a python script that reads the files in tftpboot and generates the u-boot script May 16 22:32:43 My guess is the board is at fault here, thankfully this is a first draft board (and I didn't design it, lol) May 16 22:33:07 wtf May 16 22:33:31 that sounds.... bizarre May 16 22:33:39 yeah, I've had it rerequest the initrd like seven times in a row until it gets a correct CRC May 16 22:34:27 doesn't explain why I couldn't netboot an actual beaglebone in my testing, but that's probably a different issue, like I didn't properly wipe the emmc and it's still trying to boot off that or something May 16 22:34:46 but usb data is already crc-protected, so a board defect can't really cause corruption here, it would have to be software May 16 22:35:19 well ... the only modification I made to stock u-boot was to disable the eeprom check May 16 22:35:20 unless it's ram, in which case you'd have tons of problems and not just when netbooting May 16 22:36:00 well, this is an octavo board, so the am335x lives with all its supporting hardware. So unless 8vo is having an issue ... May 16 22:36:38 then it really has to be a software issue of some sort May 16 22:37:18 e.g. a borked musb driver in u-boot May 16 22:37:37 Well, there's a possibility it's my devel box May 16 22:38:13 Just a few moments ago, all of my usb peripherals went away for no apparent reason and I had to reboot. First time that's ever happened, but, it fits May 16 22:38:22 ooookay May 16 22:38:36 yeah, some major haunting going on over here May 16 22:38:42 maybe try actual ethernet netboot instead of usb netboot? May 16 22:38:59 This board doesn't and probably won't ever have 802.3 ethernet May 16 22:39:01 or see what happens with an actual beaglebone instead of your board May 16 22:39:08 yeah, I'm doing that next May 16 22:40:12 of course getting usb2 right on a board can be fun in itself... I hope your hw guys have read TI's high-speed interface layout guidelines May 16 22:40:25 yup May 16 22:40:30 but still, that should cause unreliability of the "doesn't work" flavor, not corruption May 16 22:41:42 yeah, I thought it was weird that I was getting tftp timeouts May 16 22:48:17 now I just gotta figure out how to get the console to print to the serial header. I thought it was a simple "setenv console ttyO3,115200n8", but apparently that doesn't work. I tried writing a program to printf("hello %d", dev_name) to every file in the set /dev/tty*, but apparently there's a file in there that the board crashes if you write to it. May 16 22:48:57 err... get the *kernel* to print to the serial header May 16 22:49:43 well that's how it would normally work May 16 22:49:56 although it should probably be ttyS3 May 16 22:50:10 (but depending on how you configured the kernel, ttyO3 may be accepted too) May 16 22:50:11 That's what I'm actually trying now May 16 22:50:25 nope, not that either May 16 22:51:20 then either your u-boot is weird and doesn't use that variable to construct the kernel parameters, or there's a problem with your DT May 16 22:51:49 well, the DT and the kernel I'm using are from a beaglebone install image from beaglebone.org May 16 22:52:06 okay so you're actually using a wrong DT, well that explains May 16 22:52:19 since your board is very clearly not a beaglebone May 16 22:52:39 Well, we've tried to make it as close to one as we can May 16 22:53:19 pretty much every change needs to be reflected in the DT May 16 22:53:27 the DT describes your hardware to the kernel May 16 22:53:53 on a standard beaglebone ttyS3 isn't enabled (by default) May 16 22:58:27 Huh, I swear I'd logged into one over the serial header May 16 22:59:54 Anyway, I should probably head home, but thanks for your help May 16 22:59:59 np May 17 01:20:06 myself: Otay...here is an update. May 17 01:22:01 I think I am connected to the Mavlink so far. The ESCs are connected to the motors, I need to get a female xt60 plug, and I need to configure the ESCs on ArduPilot. I then need to test the 8 channel receiver. May 17 01:22:16 ... May 17 01:22:33 Besides that...all systems are a "go" for now. I will update in the next week or so. **** ENDING LOGGING AT Thu May 17 03:00:02 2018