**** BEGIN LOGGING AT Tue Jun 27 03:00:08 2017 Jun 27 03:39:10 When I attempt to import the audio cape over lay with “echo BB-BONE-AUDI-02 >/sys/devices/platform/bone_capemgr/slots” I get an error. Jun 27 03:39:24 [ 134.360205] of_resolve_phandles: Could not find symbol 'clk_mcasp0' Jun 27 03:39:25 [ 134.366875] bone_capemgr bone_capemgr: slot #6: Failed to resolve tree Jun 27 03:40:28 sounds like the overlay isn't compatible with the main device tree Jun 27 03:41:27 I have to comment out this line to make it work: Jun 27 03:41:28 /*clocks = <&clk_mcasp0>;*/ Jun 27 03:41:37 What changed? Jun 27 03:41:48 that doesn't sound like a recipe to make something work Jun 27 03:41:50 And what should I chage that *to*? Jun 27 03:42:39 which kernel version are you using, and which dtb? Jun 27 03:43:10 “uname -a”: Linux beaglebone 4.4.54-ti-r93 #1 SMP Mon Jun 26 01:51:50 PDT 2017 armv7l GNU/Linux Jun 27 03:44:38 Version: DTC 1.4.4 Jun 27 03:45:44 eh, no not the dtc version... the device tree file you're using... Jun 27 03:46:03 which I guess you might not necessary know... Jun 27 03:46:31 I cloned it from: git clone https://github.com/beagleboard/bb.org-overlays Jun 27 03:47:10 ok, plan b: which beaglebone variant do you have? (black / green) Jun 27 03:48:15 BeagleBone Black. Jun 27 03:49:51 okay... the default dtb for the black most definitely does define the clk_mcasp0 symbol Jun 27 03:50:11 can you pastebin the content of your /boot/uEnv.txt ? Jun 27 03:51:40 Sure. Jun 27 03:54:02 it's strange that the audio oscillator is only declared in a few dts files, it should have been declared in all boneblack/bonegreen dts variants (or rather, in a shared dtsi) Jun 27 03:54:04 https://pastebin.com/hTwDpq8q Jun 27 03:54:48 line 20. that dtb variant doesn't include clk_mcasp0 Jun 27 03:55:59 it looks like am335x-boneblack-audio.dtb is essentially the same but with the audio osc declaration Jun 27 03:56:26 try that one instead Jun 27 03:58:14 Okay. How did you list the defined symbols? Jun 27 04:01:13 I just searched which dts sources contained "clk_mcasp0" Jun 27 04:01:32 ( https://pastebin.com/raw/ugtJ6UVq ) Jun 27 04:05:58 That got it. Thanks. Now I’m getting in the dmesg: “[ 297.959712] snd_pcm_dmaengine: exports duplicate symbol snd_dmaengine_pcm_close (owned by kernel)“ Jun 27 04:06:17 Is that simply a warning or am I going to have to hunt that one down next … Jun 27 04:09:03 ?! Jun 27 04:10:00 that sounds like a kernel bug, misbuild, or an attempt to load a kernel module belonging to a different kernel version Jun 27 04:10:20 definitely not "simply a warning" Jun 27 04:11:32 but, I'm afraid I'm off for now Jun 27 04:11:39 good luck Jun 27 04:11:56 Thanks for the help. I’ve been bashing at this for 3 days and not getting anywhere. Jun 27 05:44:29 Hello there #beagle people! Jun 27 05:45:05 I am the poor schlub in this ticket: https://github.com/RobertCNelson/netinstall/issues/64 Jun 27 05:45:22 and feeling exceedingly silly because I can't get my setup working Jun 27 05:46:07 after installing bb-cape-overlays, I'm still seeing: Jun 27 05:46:17 b Jun 27 05:46:22 bone_capemgr bone_capemgr: loader: failed to load slot-3 BB-CAPE-DISP-CT4:00A0 (prio 0) Jun 27 05:46:44 is there somewhere I can get more detailed failure information? Jun 27 06:00:46 the setup is a fresh debian stretch install with the 4.9 kernel enabled using the flag "--use-lts-4_9-kernel" on netinstall (also "--firmware"). Beaglebone Green Wireless. Sandisk Extreme Pro 16GB SD card. Jun 27 06:01:39 Default on all the options when setting up (so just accepted the default fat16 partition/ext4 root/1GB swap) Jun 27 06:09:33 I'm also seeing "wlcore: ERROR could not get firmware ti-connectivity/wl18xx-fw-4.bin: -2" Jun 27 06:10:02 but primary concern is the screen at the moment Jun 27 06:41:16 What does the "RUN" button do on my browser where "Your board is connected! BeagleBoard.org BeagleBone Black rev 00C0 S/N xxx running BoneScript 0.6.1 at 192.168.7.2" is shown? Jun 27 08:31:32 Hello, I have an issue with my board, could somebody give me some advise to make it work again ? plz Jun 27 08:32:27 what 'issue'? we can't read your mind ... Jun 27 08:32:50 It's a BBBwireless that froze since I install the driver on a laptop that was connected to it Jun 27 08:33:26 Yes, thanks :D I was checking if somebody was available to help me Jun 27 08:33:54 I try to reflash it Jun 27 08:35:10 so the wifi and bluetooth work again when I do the manip but the reflash does not complete and when I remove the sd card nothing work everything is frozen Jun 27 08:42:07 did you leave it long enough for the flash to complete? eg. at least 5-10minutes Jun 27 08:44:09 yes more like 45 min actually Jun 27 08:44:41 and it doesn't complete the 4 leds never light all together Jun 27 08:45:09 oh that doesn't sound good :/ Jun 27 08:47:56 yes... Jun 27 08:48:38 wat image are you using for flashing .. and is it set up for flashing, or is it just a generic boot image?? Jun 27 08:48:41 When I reflash only USRO n USR 1 light at first the two other led light very few Jun 27 08:49:01 there have been some changes to the bb images over time .. Jun 27 08:49:21 https://beagleboard.org/latest-images Jun 27 08:49:31 this one (the first one) Jun 27 08:50:51 Well I follow the steps with 7zip then imagewritter... Jun 27 08:53:04 what do you think, can I do something more ? Jun 27 08:54:18 hold on a sec .. lemmie check it out Jun 27 08:57:26 Thanks ! Jun 27 08:59:03 The odd thing is that everything when wrong from the moment I install new driver on a laptop while the BBB was connected Jun 27 09:11:46 Ad: sorry about that ..s ucked down the Farcebook rabbit hole .. 2 sec Jun 27 09:12:23 ok so the first link on that page ie. https://debian.beagleboard.org/images/bone-debian-8.7-lxqt-4gb-armhf-2017-03-19-4gb.img.xz Jun 27 09:12:41 and did you follow the instructions at the end of that section about turning it into a flasher image?? Jun 27 09:12:53 lol no don't worry... Thank you for helping... Jun 27 09:13:22 If it's with 7 zip... yes Jun 27 09:13:34 I have a file.img Jun 27 09:13:35 "To turn these images into eMMC flasher images, edit the /boot/uEnv.txt file on the Linux partition on the microSD card and remove the '#' on the line with 'cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh'. Enabling this will cause booting the microSD card to flash the eMMC. Images are no longer provided here for this to avoid people accidentally overwriting their eMMC flash." Jun 27 09:15:14 right, I didn't do that Jun 27 09:15:19 so you need to write the image, then edit that file :) Jun 27 09:15:32 How can I do it with windows? Jun 27 09:15:47 I don't think you can Jun 27 09:15:57 not without a virtual machine or such Jun 27 09:15:58 ho... Jun 27 09:16:03 bad news Jun 27 09:16:11 ok Jun 27 09:16:47 ok I will install linux... It's been a while I'm considering doing it anyway Jun 27 09:16:56 there's a newer image up at http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flasher:_.28lxqt-4gb.29_.28All_BeagleBone_Variants_with_a_4GB_eMMC.29 Jun 27 09:17:16 tbh the http://elinux.org/Beagleboard:BeagleBoneBlack_Debian page is always more up-to-date Jun 27 09:17:53 hrm I jhaven't seen etcher before Jun 27 09:18:12 all looks good here :) Jun 27 09:21:37 Ok thanks !!! I ll try then I come back to you later If you're still here... Jun 27 09:22:22 I'll be in/out but there's a few here can fil in the gaps :] Jun 27 13:25:21 Hi, all : I'm trying to reflash my BBB wireless so I download Ubuntu to be able to remove the # from the 'cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh' but as I'm not the owner of the file I cannot change it : does anyone could give me an hand with this ? plz Jun 27 13:28:14 Hi hi !! you still there thank god :) I downloaded Ubuntu to be able to remove the # from the 'cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh' but I have no permission to do so : I'm not the owner of the file. Do you know how to change it ? Jun 27 14:00:11 Hi, ok done whith a little help from my friend ! Sorry guy it was easy I know : I'm a noob :) Jun 27 14:27:45 Hi! I ordered a parcel from the USA to Russia in the Arrow.com store and now it is on customs clearance. Jun 27 14:27:53 At the moment, the customs office is requesting from you and from me information about the lack of encryption and cryptography capabilities in Beaglebone Blue on the official letterhead of the companies. Jun 27 14:28:01 I contacted Arrow.com support in the US and they advised me to contact you to satisfy this request. I already sent a technical description of Beaglebone Blue from your website to the customs and they were not satisfied with this, because there is no clear indication of the lack of these capabilities. Jun 27 14:28:08 Could you give me confirmation of the lack of encryption and cryptography in Beaglebone Blue? Jun 27 15:04:02 Sounds like they're asking you to prove a negative Jun 27 15:23:10 Can someone confirm this board is the same as the beaglebone black - https://corpshadow.biz/bizstore/beagle-board/beaglebone-black-kit-rev-c.html Jun 27 17:07:37 whyme: Looks like the same thing Jun 27 17:30:37 trying again at a slightly more reasonable hour! Jun 27 17:30:38 Hello there #beagle people! Jun 27 17:31:00 I am the poor schlub in this ticket: https://github.com/RobertCNelson/netinstall/issues/64 and feeling exceedingly silly because I can't get my setup working. after installing bb-cape-overlays, I'm still seeing: Jun 27 17:31:07 bone_capemgr bone_capemgr: loader: failed to load slot-3 BB-CAPE-DISP-CT4:00A0 (prio 0) Jun 27 17:31:24 the setup is a fresh debian stretch install with the 4.9 kernel enabled using the flag "--use-lts-4_9-kernel" on netinstall (also "--firmware"). Beaglebone Green Wireless. Sandisk Extreme Pro 16GB SD card. Default on all the options when setting up (so just accepted the default fat16 partition/ext4 root/1GB swap) Jun 27 17:31:45 I'm also seeing "wlcore: ERROR could not get firmware ti-connectivity/wl18xx-fw-4.bin: -2"; but primary concern is the screen at the moment Jun 27 17:32:43 is there somewhere I can get more detailed failure information? Jun 27 17:47:10 kscz: uhh, netinstall? I didn't even know it existed Jun 27 17:47:17 have you tried a normal prebuilt image? Jun 27 18:00:30 a separate boot partition is also quite odd, they haven't been used in the prebuilt images for ages Jun 27 18:01:25 swap on an SD card also sounds like a recipe for pain Jun 27 18:16:24 ack, sorry zmatt, got distracted Jun 27 18:17:09 netinstall is my preferred method because I like to pull the package from debian's official repositories Jun 27 18:17:56 While seeed is all well and good for providing a pre-built image, I prefer things which I have a bit more insight! Jun 27 18:18:45 I meant the prebuilt images from robert nelson actually (though presumably that's also what seeed provides) Jun 27 18:19:26 ah, well, robertCnelson also provides the netinstall image, so I presume it's equally blessed :-P Jun 27 18:19:45 dunno, I've never before seen it mentioned nor heard of anyone using it Jun 27 18:20:12 and as I just said above, its default choices sound strange to me Jun 27 18:20:18 huh, well, if you click on the link you can see my back-and-forth with rcn himself Jun 27 18:20:46 but I was feeling incredibly guilty for abusing the github issue system to get help Jun 27 18:20:59 so I came here hoping robertCnelson hung out in the channel Jun 27 18:21:06 he used to Jun 27 18:21:18 no longer does unfortunately :/ Jun 27 18:21:22 alas! Jun 27 18:21:39 I'm sure that's because about a billion people come with dumb questions (like me!) Jun 27 18:22:23 if you think your question is dumb, you clearly haven't spent much time on irc yet :) Jun 27 18:22:30 hahahaha Jun 27 18:23:08 well, ignoring the weirdness of the netinstall defaults, do you have any advice on the capacitive touchscreen cape specifically? Jun 27 18:23:33 it seems to be a bastard child waiting for the kernel 4.9 migration Jun 27 18:23:35 https://www.element14.com/community/docs/DOC-81966 Jun 27 18:24:25 since the beaglebone blue robotics libraries are tied to kernel v4.4, RCN said he's waiting to flip the default from 4.4 Jun 27 18:24:37 but I can't get the blasted thing up and running Jun 27 18:24:55 and the single "it didn't work" line in the dmesg is not helping me debug Jun 27 18:24:58 it does work with kernel 4.4 ? Jun 27 18:25:06 no Jun 27 18:25:13 well Jun 27 18:25:15 kind of Jun 27 18:25:22 it works very wrong in 4.4 Jun 27 18:25:27 and yes, the diagnostics of overlays are really awesome :P Jun 27 18:25:28 but it does do stuff Jun 27 18:25:59 in 4.9 I'm currently in "white screen indicating that the driver loaded successfully" mode Jun 27 18:26:27 ok, maybe regardless of your preferences try the latest lxqt image from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian Jun 27 18:26:43 if that works, then you have a point for comparison Jun 27 18:27:17 I know it works with the BBGW base image, but I'm trying to create it "normally" through the netinstall path Jun 27 18:27:38 the question is why it won't load with the overlay package installed Jun 27 18:28:19 the most obvious possibilities are: different version of overlay files, different kernel Jun 27 18:29:06 also, depending on how recent that BBGW base image is, it might be using "u-boot overlays" rather than a runtime overlay Jun 27 18:29:26 hm, okay.... any logging anywhere I can try and root cause/feel like a more competent sleuth on this issue? Jun 27 18:29:44 do you have a serial debug cable? Jun 27 18:29:48 yup Jun 27 18:30:29 actually, not sure yet if/how that would help right now Jun 27 18:30:34 hahaha Jun 27 18:30:58 I'd really consider starting with examining a working setup and comparing that with the non-working one Jun 27 18:31:31 what would you "compare" in this context? Jun 27 18:31:51 I have a working and non-working setup, but without a logging path it's hard for me to know what's wrong Jun 27 18:32:54 I'm afraid I first need to do some shopping, I'll be back later Jun 27 18:33:34 okay Jun 27 18:35:00 and to put the quality of your question in perspective.... https://pastebin.com/raw/k53GnrnZ :P Jun 27 18:46:01 ok I seem to be failing to get myself out the door anyway... I guess shopping isn't that important :P Jun 27 18:46:07 hahaha Jun 27 18:46:29 (I blame insufficient caffeine consumption) Jun 27 18:46:58 I just noticed in the github issue that rcn says u-boot overlays should be enabled Jun 27 18:47:14 I turned them on, just that none of it was successful Jun 27 18:47:48 can you pastebin the output you're getting from u-boot via the debug console? Jun 27 18:48:16 (disclaimer: I don't use u-boot overlays myself and know very little about them) Jun 27 18:48:18 the extent of the relevant output was what I posted (as far as I can tell) Jun 27 18:48:33 bone_capemgr bone_capemgr: loader: failed to load slot-3 BB-CAPE-DISP-CT4:00A0 (prio 0) Jun 27 18:48:40 but I'll try again and see what it says Jun 27 18:48:44 that sounds like kernel output to me, not u-boot output Jun 27 18:49:40 the u-boot version might also be useful to know Jun 27 18:49:59 ah, that's true, but I didn't notice anything in the uboot output which seemed applicable. I'll confirm that though Jun 27 18:50:16 and like I said, using a separate FAT boot partition is also very unusual nowadays, I wonder if that might be messing with things Jun 27 18:51:02 where is the uboot info normally contained without the boot partition? Jun 27 18:51:06 presumably for u-boot overlays to work it needs to fetch overlay files from /lib/firmware ... I wonder if that's going wrong (e.g. it tries to fetch them from the FAT16 partition) Jun 27 18:51:07 i8n the ext4? Jun 27 18:51:29 u-boot itself is at a fixed offset, before the root partition Jun 27 18:51:34 its config is on the root partition Jun 27 18:52:00 ....which sounds like a boot partition to me, how is it labeled on the disk? Jun 27 18:52:26 there's only one partition, the ext4 root partition Jun 27 18:53:21 okay, I get what you;re saying now Jun 27 18:53:54 where is your boot partition mounted? what's its contents? Jun 27 18:55:06 it's not actually a boot partition during setup, which is why I said I'm not sure what it was Jun 27 18:55:20 but btrfs doesn' Jun 27 18:55:24 *doesn't appear to work Jun 27 18:55:33 you mentioned FAT16 Jun 27 18:55:49 it's just a fat16 partition, not labeled as used during the netinstall process Jun 27 18:55:54 150MB Jun 27 18:56:04 which is what the auto-partitioner setup Jun 27 18:56:12 there's nothing on it? Jun 27 18:56:22 I was just trying to avoid additional variables while setting it up Jun 27 18:56:24 I'll go look Jun 27 19:00:50 https://pastebin.com/eb7A7Vu7 Jun 27 19:01:37 ancient u-boot, probably doesn't even support u-boot overlays Jun 27 19:01:51 How do I update uboot? Jun 27 19:02:18 Also: /dev/mmcblk0p1 on /boot/uboot type vfat (rw,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro) Jun 27 19:04:52 I'm not even sure if current u-boot builds work when installed on a FAT16 partition Jun 27 19:06:38 I would assume so, it's a pretty common paradigm, and it's not like fat16 is a terribly complex protocol Jun 27 19:08:04 I'll be more specific: the MLO (intermediate bootloader) needs a special header when installed at a fixed offset on mmc/sd, and I'm not sure the ROM bootloader tolerates that header on an MLO installed on a FAT partition Jun 27 19:09:01 I also don't know whether the boot script of the latest u-boot builds still take the possibility that a separate boot partition is being used into consideration Jun 27 19:09:39 as I mentioned earlier, for u-boot overlays it will unavoidably need to load files from /lib/firmware, which is located on the root partition, not your boot partition Jun 27 19:10:22 https://github.com/RobertCNelson/netinstall/blob/00474eb6412094ad082b3f752e347d38f2f67a81/mk_mmc.sh#L1632 Jun 27 19:10:39 Maybe the right thing is to attempt another install with the "beta" bootloader Jun 27 19:12:18 I have no idea, the lack of a separate boot partition is definitely not remotely a new thing Jun 27 19:12:54 but I don't know how netinstall works, so I can't give much useful advice here Jun 27 19:13:27 https://github.com/RobertCNelson/netinstall/blob/00474eb6412094ad082b3f752e347d38f2f67a81/mk_mmc.sh#L1632 Jun 27 19:13:42 ack Jun 27 19:13:47 https://github.com/RobertCNelson/netinstall/blob/00474eb6412094ad082b3f752e347d38f2f67a81/mk_mmc.sh#L1002 Jun 27 19:14:52 which would you recommend? fatfs? spl? Jun 27 19:15:00 what a strange case statement Jun 27 19:15:41 dd_spl_uboot_boot Jun 27 19:15:52 okay Jun 27 19:15:54 I don't really understand why dd_uboot_boot is even an option Jun 27 19:15:57 it can't work Jun 27 19:16:45 or well, I guess it might on some arm-based embedded systems... this script may be suffering from excessive generality Jun 27 19:17:33 yarp, it's for friggin' everything Jun 27 19:17:47 even things like the bananapi M2 shenanigans Jun 27 19:22:42 latest release-version u-boot seems to be v2017.05-r13 Jun 27 19:23:20 It may be that I need to follow-up on the netinstall script for using a version of uboot which is too old Jun 27 19:23:38 you can find the u-boot.img and MLO files in https://rcn-ee.com/repos/bootloader/am335x_boneblack/ Jun 27 19:27:37 there's probably some official way to update u-boot, or you can use this script -> https://pastebin.com/ynz0Sv1k Jun 27 19:27:39 there are issues with u-boot and ext4 filesystems created with some fancy new features (default in debian stretch) Jun 27 19:27:53 vagrantc: iirc that has been fixed Jun 27 19:27:59 oh, that would be nice. Jun 27 19:28:34 in rcn's u-boot, or mainline? Jun 27 19:28:41 both I think Jun 27 19:28:55 * vagrantc got weary with troubleshooting it and hasn't tested for a while Jun 27 19:29:18 https://lists.denx.de/pipermail/u-boot/2016-September/266857.html Jun 27 19:32:26 * vagrantc should test it some more Jun 27 19:36:21 i'm having some trouble flashing my BBB with a new image. I've copied the image to a 16GB micro SD card formatted with a FAT32 partition, but when I insert it and then power up the beagle with the boot button held, nothing happens. The lights never turn on. Any ideas? Jun 27 19:37:11 spuz: how did you write the image to the card? Jun 27 19:37:14 the image should be written directly to the card itself, not to a file on the card Jun 27 19:37:33 you can use e.g. https://etcher.io/ Jun 27 19:37:35 there are exact steps for doing that Jun 27 19:40:52 zmatt tbr: I used the xzcat command, I specified the disk i.e. /dev/mmcblk0p1 as the target rather than a particular mountpoint Jun 27 19:41:07 partition is *wrong* Jun 27 19:41:15 you must write to the raw device Jun 27 19:41:27 what do you mean? Jun 27 19:41:47 /dev/mmcblk0p1 ← "p1" aka "first partition Jun 27 19:41:57 you should write to "/dev/mmcblk0" Jun 27 19:42:33 in case of "scsi" mountpoint, something like /dev/sdx Jun 27 19:43:27 (after checking three times that it's the right one) Jun 27 19:43:37 tbr: ah yeah I see, thanks I'll try that Jun 27 19:44:33 yeah, nothing like overwriting a disk with vital data :D Jun 27 19:45:14 which is why I actually added an udev rule that makes raw access to sd cards unprivileged Jun 27 19:57:15 okay, attempting with this block uncommented: https://github.com/RobertCNelson/netinstall/blob/00474eb6412094ad082b3f752e347d38f2f67a81/hwpack/am335x-boneblack.conf#L15-L30 Jun 27 19:57:34 (and with the other block at the top commented) Jun 27 19:58:19 hmmm Jun 27 19:58:27 maybe I should just do the spl one? Jun 27 19:58:56 honestly not too sure if they're both meant to be commented in at the same time Jun 27 19:59:27 probably not Jun 27 19:59:30 but whatever Jun 27 19:59:37 hopefully it won't break anything Jun 27 20:06:40 ooh, lights are firing now. progress :) Jun 27 20:08:53 it's doing the knightrider pattern which is always a good sign Jun 27 22:19:05 zmatt: are you busy? Jun 27 22:25:29 Hello friends. Looking for some general pointers from fellow SoC fanatics concerning uBoot. I'm trying to use the 'gpio' command in uBoot to toggle a UART_TX pin. However, when I issue 'gpio toggle ##', it reports 'value is 0' and then immediately 'Warning: value of pin is still 1' Jun 27 22:25:49 I'm wondering if I don't need to feed uBoot the DTB somehow or some other voodoo? Jun 27 22:25:56 Any questions or suggestions appreciated. Jun 27 22:26:52 Mocking will be accepted but not encouraged. Jun 27 22:27:28 fwiw, my processor is an iMx6 on a Wandboard rev C module. Jun 27 22:27:42 :D Jun 27 22:27:43 iMx6Solo* Jun 27 22:28:11 Shhhh, they're thinking ver|laptop, don't distract them. Jun 27 23:05:33 majuk: sounds like the pin might not be configured as output Jun 27 23:05:48 or perhaps not even configured as gpio Jun 27 23:06:04 (I don't really know anything about pinmux on the imx) Jun 27 23:06:15 ver|laptop: not particularly Jun 27 23:06:32 just arrived at work Jun 27 23:07:42 majuk: gpio set/clear/toggle do attempt to configure the pin as output though Jun 27 23:08:17 so probably, since you referred to the pin as UART_TX, it as configured as uart pin instead of as gpio Jun 27 23:08:24 *it is Jun 27 23:09:54 can we now commence mocking you for asking questions about an iMX SoC in an irc channel dedicated to boards based on TI SoCs ? Jun 27 23:09:57 :) Jun 27 23:10:09 zmatt: Seems reasonable. :D Jun 27 23:10:21 Thanks for your input though, that's good stuff. Jun 27 23:10:50 on a beaglebone I could tell you "poke this value into that memory mapped register and voila" Jun 27 23:11:22 I'm over here editing memory registers right now trying to get around gpio Jun 27 23:11:41 It's working, but not giving me the result I expect. Jun 27 23:11:47 As per usual. Jun 27 23:11:53 so the thing you're *probably* looking for is chip-level pinmux Jun 27 23:13:00 I just edited that pin to be GPIO via the pinmux register, then tried to manipulate it, no joy Jun 27 23:13:16 Then tied the RX line high and read the memory value, still reports low. Jun 27 23:13:17 SO Jun 27 23:13:54 try reading the gpio controller's registers directly? Jun 27 23:14:13 ...I *think* that's what I'm doing, using the command md Jun 27 23:14:24 then you're probably doing it wrong Jun 27 23:14:25 :D Jun 27 23:14:43 Well, I confirmed reading some known values Jun 27 23:16:08 Understand that this UART trace ends on a custom carrier board. My next step is to repeat all this on the off-the-shelf Wandboard carrier and see if it plays nice. Jun 27 23:16:21 So maybe that will be enlighting. Jun 27 23:16:43 Because it's entirely possible my PCB skills are shitty. Jun 27 23:17:10 I mean, ethernet works, so I had hope. But that hope is fleeting./ Jun 27 23:19:34 if your pcb skills were shitty, you probably would never even have arrived in u-boot Jun 27 23:21:37 ...are you hitting on me? Jun 27 23:21:38 :P Jun 27 23:22:05 hehe Jun 27 23:54:29 Welp, tomorrow is another day. Thanks for your input zmatt. Jun 27 23:54:33 Have a good one. Jun 27 23:54:40 you can't know that for sure Jun 27 23:55:18 S'true, that's why I'm leaving work to get drunk and try to sucker some girl into sleeping with me. Jun 27 23:55:33 Priorities. Jun 27 23:55:46 YES ON A TUESDAY. **** ENDING LOGGING AT Wed Jun 28 03:00:04 2017