**** BEGIN LOGGING AT Tue Apr 09 03:00:03 2019 Apr 09 10:36:44 Which is the latest Beglebone Apr 09 10:37:07 Which has both Wifi and Etherenet connectivity Apr 09 12:56:52 Hello Community, I need urs help. Apr 09 13:00:07 I want to connect wifi from BBB Wireless. For that I follow connmanctl commands procedure. But, Now I create one shell script file, which have all connmanctl commands. But, when I run it, it shows error from " connmanctl agent on"; error like: This is non-interactive mode. Apr 09 13:00:38 So, How can i run "connmanctl agent on" from shell script.!? or else any other option?? Apr 09 13:07:41 ? Apr 09 14:33:55 m Apr 09 17:35:53 zmatt : heads up, your symlink udev rule is going to be used to make am5 compatible with am3: https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec Apr 09 17:44:28 so, with u-boot 2019.04 dropping the am335x_boneblack target, i'm faced with the quandry i've been putting off in Debian, with the am335x_evm target being too large to fit with typical partitioning conventions Apr 09 17:44:40 rcn-ee[m]: i know you gave me a heads-up about this some years ago! Apr 09 17:45:31 was there ever anything done to make use of the mmcblkNbootN partitions, which would at least solve the issue for eMMC only installs? Apr 09 17:50:34 i know the beagleboard.org images create a partition offset at ... 4096 rather than 2048? Apr 09 18:38:42 vagrantc another option is to just copy MLO/u-boot.img into the base rootfs. and if you switch to uefi, the fat partition makes sense Apr 09 18:39:08 as much as we hate teh fat partition, efi would be a good generic user case. Apr 09 18:43:49 vagrantc: also you could rip out am335x-evmsk and am335x-icev2 from here: https://github.com/u-boot/u-boot/blob/master/configs/am335x_evm_defconfig#L32 Apr 09 18:43:55 might get you under 2048 Apr 09 18:47:46 rcn-ee[m]: ripping things out might just delay the inevitable Apr 09 18:48:46 rcn-ee[m]: for debian-installer, there's one rootfs image for all the boards, so that, while it would work technically, doesn't scale for N different boards Apr 09 18:49:49 https://d-i.debian.org/daily-images/armhf/daily/netboot/SD-card-images/README.concatenateable_images Apr 09 18:50:10 or, we would have to add another partition to the concatenatable images ... which isn't infeasible Apr 09 18:50:37 do the debian aarch64 image have a efi partition thou? Apr 09 18:51:55 some do ... arm64 is ... a mess. Apr 09 18:52:17 we have very few targets that it's even possible to support, unless they have EFI built-in Apr 09 18:52:28 what no way? i thought they learned from arm32 that things were a mess, thus they would fix all problems. ;) Apr 09 18:53:03 although i've experimented with u-boot's EFI implementation on arm64 ... the device-tree's out of sync with the kernel tend to have issues Apr 09 18:53:54 i guess my current thought is to build am335x_evm, and make a trimmed down variant that only includes the boneblack .dts ... that should last a while Apr 09 18:54:58 and you could drop the green, and just mirror that name to the black.. i'm not sure why that dts got pushed to u-boot kinda of a waste of a copy Apr 09 18:55:27 (should watch u-boot ml more often) Apr 09 19:15:35 rcn-ee[m]: what do you mean by "mirror that name" ? Apr 09 19:18:09 * vagrantc will try a variant that only includes the boneblack and the am335x-evm dts Apr 09 19:22:19 vagrantc, change this from green to black: https://github.com/u-boot/u-boot/blob/master/board/ti/am335x/board.c#L1042 Apr 09 19:22:26 it'll save you one more dtb required.. Apr 09 19:24:48 i see. Apr 09 19:25:28 i was hoping to get away with just an alternate defconfig, and building the am335x_evm unmodified Apr 09 19:26:32 was hoping just dynmically changing CONFIG_OF_LIST would be enough... Apr 09 19:27:11 that would be test 1, then if you need more room, patch ;) Apr 09 19:27:56 i notice the pocketbeagle .dts isn't listed in am335x_evm Apr 09 19:29:17 or any defconfig, for that matter Apr 09 19:30:33 the dts files need to be imported for that one, when i pushed that board, i did the old board only option. Apr 09 19:31:18 so the support is there in the board, but just no devicetree ? Apr 09 19:31:27 er, in the code Apr 09 19:31:41 correct.. Apr 09 19:32:10 been thinking i should get one to mess around with, but i guess that would mean more upstream work :) Apr 09 19:32:15 it's been like that for a year now, kinda figured someone would have added that addition.. Apr 09 19:32:50 email me your address, i'll have one in the mail tomorrow. ;) Apr 09 19:33:16 well, that's service :) Apr 09 19:41:20 fedex or UPS works best at your location? Apr 09 19:52:04 whatever's easiest, think they both work Apr 09 19:53:13 it's processing, i'll have a tracking number later that i will email to you.. Apr 09 19:55:50 one of these days i should have a project other than "maintain u-boot and linux in Debian on an arbitrary growing number of ARM boards" Apr 09 19:56:09 oh yes, i added arm-trusted-firmware to the mix... i forgot. :) Apr 09 20:29:54 hmmm... got it down to 569508 by just leaving am335x-evm and am335x-boneblack Apr 09 20:32:38 how about killing nand? Apr 09 20:32:46 dtb's take a lot Apr 09 20:34:41 i think that's below the necessary mark ... although who knows how many releases till that breaks Apr 09 20:35:38 i guess i could also leave out the am335x-evm devicetree Apr 09 20:57:09 rcn-ee[m]: the biggest reason i remember really not liking using the fat partition is some bizarre situations where the inode order on the fat partition mattered, and u-boot.img might not get loaded correctly if you didn't copy things onto the filesystem in the right order Apr 09 20:57:42 that's where moving to an offset really seemed better ... until we started hitting size limitations Apr 09 21:01:32 yeah, that was a x-loader hard offset.. atleast with efi in u-boot the fat layer is in pretty good shape now days.. it only took 10 years thou.. Apr 09 21:02:14 otherwise yeah, dd been way more reliable Apr 09 21:11:58 ah, right, it was x-loader loading the SPL/MLO bit ... which can still easily fit in the device offset ... and u-boot-spl is smart enough to handle the fat partition stuff Apr 09 21:12:46 530544 2019-04-09 20:48 ./usr/lib/u-boot/am335x_boneblack/u-boot.img Apr 09 21:12:54 that's with just the boneblack device tree Apr 09 21:13:04 that should be good enough ... maybe should yank nand too Apr 09 21:14:45 v2018.09 447108 bytes, dtb's add so lmuch Apr 09 21:18:21 they also add so much flexibility :) Apr 09 21:19:25 v2019.01 is 466912... .04 is now out, so i maybe i should upgrade ours to v2019.01. ;) Apr 09 21:19:28 i should probably reinstall my one remaining beaglebone black Apr 09 21:20:16 managed to fry one installing it upside down in an LCD cape... :( Apr 09 21:20:45 ouch! Apr 09 21:21:50 of course, the plan was to get it running to test am335x-evm build of u-boot, and i got sidetracked by testing if the cape worked in recent debian versions Apr 09 21:46:56 "too large to fit with typical partitioning conventions".... oof Apr 09 21:49:05 you just either need to create a dead partition at the beginning of your disk, or start the first partition later on the disk ... same issue happened with grub2 maybe a decade ago Apr 09 21:49:31 or make a fat partition and drop the u-boot.img there... Apr 09 21:50:43 ok, apparently 530k was too large and now i will definitely be reinstalling Apr 09 21:51:14 i was hoping that would fit with start sector 2048 ... Apr 09 21:52:21 what partitioning convention are you using though? it's probably a good idea to start the first partition at an allocation block boundary, just to ensure that writes to the filesystem metadata don't update the flash block that also contains the bootloader Apr 09 21:52:29 i.e. start sector 8192 Apr 09 21:52:36 bad MBR sector signature 0x050a Apr 09 21:52:53 that's also what beagleboard.org images use Apr 09 21:52:56 sure, debian still defaults to 2048 Apr 09 21:53:13 cfdisk still defaults to 2048 last i looked ... parted, etc. Apr 09 21:54:01 just because something is the default doesn't mean it's the best choice Apr 09 21:55:00 agreed ... just will be fighting the defaults Apr 09 21:55:45 so definitely 8192, and not 4096 ? Apr 09 21:59:08 echo $(( $(cat /sys/block/mmcblk1/device/preferred_erase_size) / 512 )) Apr 09 22:50:32 could also enable CONFIG_SPL_FS_EXT4 if the SPL could grow a little... Apr 09 22:51:20 SPL has plenty of space, u-boot is just bloated as fuck Apr 09 22:53:24 right Apr 09 22:55:07 I thoguht RN had that down with his partitioning scheme on eewiki .. Apr 09 22:55:21 ? Apr 09 22:55:36 zmatt: you're familiar with RN's build instructions for debian card images ? Apr 09 22:55:42 linuxonarm Apr 09 22:55:47 not particularly Apr 09 22:55:50 ah ok Apr 09 22:56:06 I've used them a few times, without realising how well thought out they were :) Apr 09 22:56:16 rcn-ee[m]++ :) Apr 09 22:59:15 i should look at eewiki again, since i'll be trying to get these things fixed in Debian Apr 09 23:02:56 yeah, the sfdisk "script" seems nice. Apr 09 23:23:11 his work is very understated :) Apr 09 23:47:28 hello Apr 09 23:58:02 Hi Apr 09 23:58:07 for a second I wondered what RN is Apr 09 23:58:12 it's the name of the far right party here Apr 09 23:59:42 How can we connect Beaglebone Black Wireless to bluetooth Apr 10 00:00:20 it has bluetooth already Apr 10 00:01:24 how can I connect bluetooth headphones to it Apr 10 00:01:40 the bluetooth is not enabled Apr 10 00:01:47 maybe rfkill is on Apr 10 00:01:51 I can't scan it from any of the devices Apr 10 00:03:19 this is not a BBB problem I think, you can follow any bt tutorial Apr 10 00:05:21 how can I check if rfkill is on or off Apr 10 00:05:33 there's a command name rfkill Apr 10 00:05:34 to check Apr 10 00:07:38 is there a way to find if bluetooth is on or off Apr 10 00:07:47 in the bbbw Apr 10 00:08:37 there must be tutorials online Apr 10 00:09:05 haven't found anything useful so far Apr 10 02:56:49 join #beagle **** ENDING LOGGING AT Wed Apr 10 02:59:57 2019