**** BEGIN LOGGING AT Tue Sep 17 03:01:14 2019 **** BEGIN LOGGING AT Tue Sep 17 08:07:17 2019 Sep 17 08:24:19 hi all, knows somebody when can i get beaglebone AI? Sep 17 09:28:31 Hey! Beginning a BB project, was wondering a few things. Sep 17 09:29:12 First of all, trying to find the stuff Brian Delacey did using Dart, but ... coming up a bit short. Sep 17 09:29:44 Found this: http://www.iotfestival.com/IoTDartAndBBBNotes.html - but... links are dead Sep 17 09:31:15 Secondly, we are hooking up GPS + cellular and wonder if anyone has experience with the available capes. I have found several, the Yantrr is a bit costly but looks good. Sep 17 09:33:59 Also wondering what people think of Python vs Nodejs vs C vs Dart here. Ideally I would like to use Dart (but it may be less well supported on the lib side), otherwise I will probably use Nodejs since I know it well. Any specific disadvantages compared to say Python or C except for the obvious? Sep 17 13:46:13 @gokr thought dart died, as soon as google decided to not intergrate it into chrome a few years back.. Sep 17 16:10:47 Hello! I've got a pocketbeagle, I create an image for it with Yocto, and I'd like to enable g_ether. Is it right to believe that g_ether should be supported by the pocketbeagle? Sep 17 16:11:16 I had an image working, and I broke the boot by auto-loading g_ether Sep 17 16:12:20 g_ether is a standard linux feature, it works on any linux system that has a usb gadget driver, which includes the am335x on the beaglebone and pocketbeagle Sep 17 16:12:57 so whatever you broke is something specific to your custom image Sep 17 16:40:34 zmatt: hmm right Sep 17 18:49:58 zmatt: I get the following screen output: https://pastebin.com/z15UpdzC Sep 17 18:50:39 I'm not sure why it fails to boot. Is it the "Loading Environment from FAT... ** No partition table - mmc 0 **", or "No USB device found"? Sep 17 18:51:13 nah, the problem is just that your kernel is crashing Sep 17 18:51:16 line 11 Sep 17 18:51:55 hard to tell from this since your kernel isn't producing any useful logging nor even a traceback for the crash Sep 17 18:52:31 which saves space no doubt, but is obviously no good for debugging Sep 17 18:53:36 zmatt: it's a yocto image :) Sep 17 18:54:07 I don't know much about yocto but afaik it's designed for customization? so presumably you can reconfigure the kernel Sep 17 18:54:17 zmatt: I took a working yocto image, and rebuilt the kernel with CONFIG_USB_ETH=m, because I want to have g_ether Sep 17 18:54:30 and now it fails to boot Sep 17 18:54:51 But I have serial access to my pocketbeagle, and I can reflash whatever I want if that helps for debugging Sep 17 18:54:56 it seems unlikely that that's the specific cause Sep 17 18:55:18 zmatt: let me try to go back to the original image Sep 17 18:55:21 unless this kernel really produces no output on the console whatsoever Sep 17 18:56:56 since it looks like it's crashing early, i.e. before modules get loaded, and changing an option to =m normally doesn't affect the kernel image itself, it just builds an extra module Sep 17 18:57:11 right Sep 17 18:57:24 let me rebuild the kernel with the older defconfig and see if that works Sep 17 18:57:26 are you using an initrd? (I can't tell since the first part of u-boot's output is cut off in your paste) Sep 17 18:58:04 if you're going to rebuild the kernel, maybe look for the option to get useful tracebacks and turn it on Sep 17 18:58:52 CONFIG_STACKTRACE=y Sep 17 18:59:08 CONFIG_DEBUG_BUGVERBOSE=y is probably a good idea too Sep 17 18:59:21 hmm I'm using "screen", and so I cannot go up in the output :/. Maybe I should use another serial command Sep 17 18:59:34 ok, I'll enable those two Sep 17 18:59:35 screen has scrollback Sep 17 19:00:00 do I need to enable it? scrolling with the mouse doesn't work, at least Sep 17 19:01:02 there's also a config option that will make normal scrollback work, lemme check Sep 17 19:01:56 echo altscreen on >>~/.screenrc Sep 17 19:01:57 see if that helps Sep 17 19:02:48 ah no! Sep 17 19:03:05 or maybe also, but I found this in my screenrc: Sep 17 19:03:40 https://pastebin.com/raw/GGGgbraX Sep 17 19:05:28 trying that! Sep 17 19:16:14 with or without those settings you can also access screen's own scrollback by entering copy/scrollback mode with ctrl-A + escape Sep 17 19:16:22 you can also enable logging to file Sep 17 19:17:39 these are some settings I use for logging => https://pastebin.com/raw/98dz9hzc Sep 17 19:35:28 so going back to the old defconfig worked Sep 17 19:36:56 zmatt: this is the one working: https://pastebin.com/DbGiGH7Q Sep 17 19:37:22 ok wow so you normally get no output whatsoever Sep 17 19:37:30 that's really something you should fix first Sep 17 19:37:31 now rebuilding with CONFIG_STACKTRACE and CONFIG_DEBUG_BUGVERBOSE Sep 17 19:37:37 because this makes it completely impossible to tell when shit is going wrong Sep 17 19:38:25 and this is without a 'quiet' option being passed to the kernel even :/ Sep 17 19:38:27 but how to fix? with your options above, right? Sep 17 19:38:43 no those have no effect on that Sep 17 19:38:47 hmm Sep 17 19:38:53 I'm building a core-image-minimal from Yocto Sep 17 19:39:03 I have no idea why you have so little output.. default loglevel maybe? Sep 17 19:39:48 you could try passing the 'debug' kernel parameter, but dunno if that maybe gets *too* spammy Sep 17 19:41:27 ok let me ask the yocto people about that Sep 17 19:41:57 that sounds like a good idea Sep 17 19:42:07 in the meantime, I re-generated the defconfig from yocto, and I'll try that image. Just to see if me playing with menuconfig is not the reason for the failure Sep 17 19:42:51 if it does crash then with CONFIG_STACKTRACE you can hopefully at least see where it's crashing Sep 17 20:07:53 so it seems like `rootwait console=ttyS0,115200` is wrong, it should be `rootwait console=ttyO0,115200` Sep 17 20:08:14 depends on which serial driver is used Sep 17 20:08:20 they say I should check in u-boot to change that. I'm trying to find out what that means Sep 17 20:08:34 zmatt: from my pocketbeagle, `ls -a /dev/tty` shows `ttyO0` Sep 17 20:08:49 does that make sense? Sep 17 20:09:59 the standard debian kernels use the 8250-omap driver hence ttyS0, while evidently your kernel uses the omap-serial driver, hence ttyO0 Sep 17 20:10:24 hmm Sep 17 20:10:30 is CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP enabled? Sep 17 20:10:35 oh never mind Sep 17 20:10:39 sorry, that's the other way around Sep 17 20:10:56 when using 8250-omap that makes ttyO0 an alias for ttyS0 Sep 17 20:12:14 I think the omap-serial driver is deprecated Sep 17 20:12:41 "TI plans on shifting away from omap-serial driver to the generic 8250 framework." Sep 17 20:12:49 right Sep 17 20:13:07 well I'm not really sure what I'm using there Sep 17 20:13:44 you are using omap-serial (CONFIG_SERIAL_OMAP) Sep 17 20:14:53 using 8250-omap would be CONFIG_SERIAL_8250=y and CONFIG_SERIAL_8250_OMAP=y Sep 17 20:15:00 right Sep 17 20:15:16 but then I should edit this ttyS0 to have ttyO0 somewhere Sep 17 20:15:26 switching to 8250-omap might be easier than changing u-boot to use ttyO0 Sep 17 20:15:28 reading about u-boot now :) Sep 17 20:15:38 oh Sep 17 20:15:58 I can try to edit my kernel options to have CONFIG_SERIAL_8250=y and CONFIG_SERIAL_8250_OMAP=y Sep 17 20:16:08 and CONFIG_SERIAL_OMAP disabled Sep 17 20:16:14 =n Sep 17 20:16:19 just commented out Sep 17 20:16:26 kernel config doesn't use explicit =n Sep 17 20:16:26 let me try that! Sep 17 20:16:50 right. Let me build again, then Sep 17 20:32:03 how did you know I used CONFIG_SERIAL_OMAP? Sep 17 20:40:40 because you said your console was ttyO0 Sep 17 20:40:48 in linux Sep 17 20:47:52 oh Sep 17 20:48:12 if you use 8250 it would have been ttyS0 Sep 17 20:49:38 I see Sep 17 20:49:52 well I rebuilt my image, and now I get nothing -_-. Let me try to figure out why Sep 17 20:50:27 is CONFIG_SERIAL_8250_CONSOLE enabled? Sep 17 20:52:12 zmatt: probably not. But I get an output, it just hangs at "Starting kernel..." Sep 17 20:52:29 I have CONFIG_SERIAL_CORE_CONSOLE=y Sep 17 20:52:45 But I forgot to add CONFIG_SERIAL_8250_CONSOLE=y Sep 17 20:54:08 I think you still ought to get a login prompt even without it, but that'll depend on how yocto spawns a getty I guess Sep 17 20:55:40 Rebuilding with CONFIG_SERIAL_8250_CONSOLE=y Sep 17 20:56:16 btw I think that `#CONFIG_SERIAL_OMAP=y` is still taken as a "yes" when building the kernel. I had to write `#CONFIG_SERIAL_8250_CONSOLE is not set` to remove a warning Sep 17 20:56:44 (a warning saying "could not set CONFIG_SERIAL_OMAP=y!", basically) Sep 17 20:57:22 it's also possible it just can't parse that line, hence lets the config var take on the default value, which could be y (not sure) Sep 17 20:57:39 https://pastebin.com/1ydPiACN Sep 17 20:57:42 oh, maybe Sep 17 20:58:09 but I'm just guessing Sep 17 20:59:05 actually this looks like output from yocto, so maybe they're just misparsing it Sep 17 21:01:08 I'm trying again with "# CONFIG..." instead of "#CONFIG..." and I haven't seen a warning yet Sep 17 21:13:18 zmatt: seems to be better, I have *a lot* of output now! Sep 17 21:13:35 hurray Sep 17 21:14:29 eventually you may want to use the 'quiet' kernel parameter to reduce output since logging a ton to a serial console can actually slow down boot noticably Sep 17 21:16:00 and that parameter has to be set in u-boot? Sep 17 21:16:13 because I still don't know how to do that :D Sep 17 21:16:23 I also use 460800 baud instead of 115200 for the serial console on our beaglebones, since (surprise) this makes it 4x faster! ;) (it also helps a lot in making vim more bearable when using via the serial console) Sep 17 21:16:32 well normally u-boot loads settings from a file Sep 17 21:17:21 oh, I get much more output, but I still don't have the console :/ Sep 17 21:17:50 Retrieving file: /extlinux/extlinux.conf Sep 17 21:17:59 that's probably where the kernel parameters are configured Sep 17 21:18:27 last line is 'INIT: Id "O0" respawning too fast: disabled for 5 minutes' Sep 17 21:18:51 sounds like it's trying to spawn a getty on ttyO0 instead of ttyS0 Sep 17 21:18:58 that'll be in some settings file in /etc/ Sep 17 21:19:35 CONFIG_SERIAL_8250_OMAP_TTYO_FIXUP=y? Sep 17 21:20:13 that would probably also help as a workaround Sep 17 21:20:21 although fixing the setting would probably be better Sep 17 21:20:21 palate: yes, on the MACHINE config file you have to fixup SERIAL_CONSOLES Sep 17 21:20:28 there ya go Sep 17 21:20:41 I was about to say, if you can't find it ask a yocto person :) Sep 17 21:20:52 haha Sep 17 21:21:11 https://github.com/e-ale/meta-pocketbeagle/blob/OE/master/conf/machine/pocketbeagle.conf#L15 Sep 17 21:50:15 zmatt: so I just switched to the OE/master branch of meta-pocketbeagle, maintained by tlwoerner, and it works like a charm :-) Sep 17 21:58:27 zmatt: I could have been lucky and start with that directly, but here I learned a lot in the process, especially about the kernel. That's good :-) Sep 17 21:58:37 Thanks a lot tlwoerner and zmatt! And good night! Sep 17 22:20:22 zmatt: can you set 460800 on the pocketbeagle as well? Would I need to change that both on the pocketbeagle side (https://github.com/e-ale/meta-pocketbeagle/blob/OE/master/conf/machine/pocketbeagle.conf#L15) and in the command I use (screen /dev/ttyUSB0 115200)? Sep 17 22:22:28 zmatt: asking because the specs say 115200: https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual#56_Serial_Debug_Port Sep 17 22:22:54 115200 is just the default, it has no special significance from a hardware point of view Sep 17 22:23:50 changing it required patching u-boot though Sep 17 22:24:20 along with making sure the kernel gets the right value Sep 17 22:24:41 and with a bit of bad luck userspace might have that value configured somewhere too Sep 17 22:27:24 those four commits are the patchset to make u-boot support high baudrates on TI SoCs => https://github.com/dutchanddutch/u-boot/commits/patch/v2018.03/uart ... iirc I tried getting those changes upstream, but I can't remember whether I succeeded Sep 17 22:27:47 in addition to that the default baudrate needs to be configured somewhere Sep 17 22:28:06 altogether it is a bit of effort :) Sep 17 22:35:53 right :) Sep 17 22:36:21 I guess I'll see that later :) Sep 17 22:36:27 Good night, and thanks again! **** ENDING LOGGING AT Wed Sep 18 02:59:57 2019