00:00 <Guest89> wassup?

00:13 <set_> I think I ruined my webinar chances. I did something...

00:14 <set_> The BBAI-64 webinar starts at 8:00 CST. Okay, I got it. I started it too early and it shutdown itself.

00:16 <set_> Luckily, I kept the email. I would have been w/out BBAI-64 intel!

00:16 <set_> I am excited.

00:19 <set_> I flossed. My darn green teeth, wishing I could say tooth, are flourishing. Do I have to show myself? Should I get a suit?

00:20 <set_> and a fedora? Ha. Maybe just the suit and a nice buckle?

00:27 <set_> Anyway, all dress up aside, I received a Relay Cape. It has black relays on it and not blue relays like the other one I purchased...

00:28 <set_> Is this a thing b/c of the shortage and, what people in the oilfield call a bust, chip disparities?

00:31 <set_> My first one, before the bust, had blue relays from GoodSky and this one has TE relays.

01:53 <set_> Dang it. I cannot find my mic. The show begins soon!

03:11 <set_> Dang cameras. Nice articulation of ideas...I could not find the darn cam to save my life. Blah.

08:18 <SINGARAVELAN> BeagleBone® AI Board, indian dealers list?

16:12 <Guest4494> What controls which gpios get created automatically under /sys/class/gpio/ ?

16:13 <Guest4494> I know I can create additional directories/gpios myself after the fact, but I'm asking about what mechanism creates the ones that are already there.

17:27 <zmatt> Guest4494: gpios can be configured and exported via device-tree (by creating a gpio-of-helper device). cape-universal (if enabled, which it is by default) does this for all gpios

17:27 <zmatt> all gpios corresponding to P9/P8 expansion header pins that is

17:35 <Guest4494> zmatt, that seems more complicated than making gpio settings in uEnv.txt.  Or am I misunderstanding?

17:37 <zmatt> I don't know what you mean by that

17:39 <zmatt> there's no way to "make gpio settings in uEnv.txt"

17:41 <zmatt> gpios can either be configured at runtime (which is what most people do), or they can be given a default config via device-tree

18:36 <Guest4494> (Sorry, got pulled away.) I just meant that one can, say, set a gpio to output using u-boot's 'gpio set' command and placed in uEnv.txt.

18:53 <Guest4494> (Sorry, got pulled away.) I just meant that one can, say, set a gpio to output using u-boot's 'gpio set' command and placed in uEnv.txt.

19:53 <jkridner> you can add that sort if thing to the uenvcmd variable, if still there.

19:58 <MAri> HI!   How can I contact your sales team?

20:04 <Guest65> hi am using beagle bone xm its a old board lying with me can anyone help me with putting os in sdcard where to download and flash with etcher and start using the board

21:17 <jfsimon1981> Hi, I believe this is a community channel instead MAri

21:18 <jfsimon1981> Slaes at the beaglebone site porobably if you need contact

21:29 <rah> I'm trying to create a bootable disk image for a beagleboard x-15; I've compiled u-boot and dd'd MLO and u-boot.img to an sd card but it's not booting

21:30 <rah> to compile, I did "make CROSS_COMPILE=arm-linux-gnueabihf- am57xx_evm_defconfig" followed by "make CROSS_COMPILE=arm-linux-gnueabihf- -j20"

21:33 <rah> to dd, I did "sudo dd if=MLO of=/dev/sde conv=notrunc count=2 seek=1 bs=128k" followed by "sudo dd if=u-boot.img of=/dev/sde conv=notrunc count=4 seek=1 bs=384k"

21:33 <rah> any ideas why it might not be working?

21:37 <rah> nevermind, I've seen the problem: the u-boot.img is bigger than (count=)4 * (bs=)384k

21:50 <rah> thank you, cardboard developer

21:59 <zmatt> Guest4494: oh, that's what you meant... ew? are you using some kind of ancient image? I feel like I haven't seen u-boot commands in an uEnv.txt the last decade or so :P anything you do to gpios in u-boot would normally be undone by the kernel if the gpios are exported by DT, which on current images by default happens to all pins

22:01 <zmatt> so I'm guessing you're either using an image that predates cape-universal or you've explicitly disabled it

22:02 <zmatt> (in retrospect I should have guessed that from your question about automatically exporting gpios)

22:17 <rah> hmm, when I zero the first 10M of the SD card and write MLO/u-boot.img, the card boots fine; when I have a partition table and root FS and write ML/u-boot.img, the card does not boot; any ideas why?

22:32 <zmatt> rah: can you hexdump the first 257 sectors of the non-working case? i.e. dd if=DEVICE count=257 status=none | hexdump -C

22:33 <zmatt> btw you can just omit the count= argument to dd to avoid the problem you had earlier

22:34 <zmatt> also instead of messing with the blocksize I'd just specify a proper seek value, i.e. "seek=256" instead of "seek=1 bs=128k" and "seek=768" instead of "seek=1 bs=384k"

22:35 <zmatt> or if you really want to write in 128k blocks then at least "seek=3 bs=128k" instead for the u-boot.img ... using a blocksize of 384k is just kinda gross :P

22:36 <zmatt> anyway, the only thing I can think of is... if there's crud in the initial bytes of sector 0 (the space for the MBR) then maybe bootrom mistakenly thinks it's an MLO and tried to load and execute it

22:38 <zmatt> this is what it should preferably look like: https://pastebin.com/8F0a3yiR

22:44 <rah> zmatt: here's my image: https://pastebin.com/YCvBVm8C

22:45 <zmatt> yep, exactly what I guessed

22:47 <zmatt> pretty sure that's an x86 MBR

22:50 <zmatt> presumably whatever tool you used to create the partition table thought that was a good idea... fdisk doesn't do that

22:56 <zmatt> you can clean this up e.g. with head -c $((0x1b0)) /dev/zero 1<>FILENAME