Shadyman has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
<set_> Hey! I think I figured out why my RepliCape was not working years ago.
<set_> Yay! yay! yay!
<set_> If you guys do not know, inductive sensors handle magnetic fields from metals, i.e. preferably iron or steel.
<set_> I have a heated bed over my steel plate. Ha! Burn.
<set_> Oops.
<set_> Can one man feel less adequate than me?
<set_> My z-axis kept saying ___________. Nothing. Just errors galore was on the output.
<set_> Silly me. I feel less credible now. B/c! You guessed it. I am less credible now. Hard knott life!
<set_> Ha.
<set_> That was a Buildroot, Poky joke.
<set_> I picked up ardupilot b/c of the sensor issues. Anyway...back to the ole post.
<set_> If anyone gets a chuckle, please send kudos.
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #beagle
vagrantc has quit [Quit: leaving]
<set_> Not one single person laughed or chuckled a bit? Sheesh, tough crowd.
troth has quit [Ping timeout: 256 seconds]
troth has joined #beagle
renrelkha has quit [Quit: bye]
renrelkha has joined #beagle
Posterdati has quit [Ping timeout: 250 seconds]
Posterdati has joined #beagle
Shadyman has quit [Remote host closed the connection]
bradfa has quit [Ping timeout: 256 seconds]
bradfa has joined #beagle
crazymax has quit [Quit: Bye!]
xet7 has quit [Quit: Leaving]
Jacmet has joined #beagle
<Jacmet> where can I find the description of the identification eeprom content on beaglebone-ai? The original patches and my board has name=BBBBAI__, but what got applied to mainline uboot uses name=BBONE-AI?
<rcn-ee> Jacmet, there is no eeprom, it's in the first sector of the boot0
<rcn-ee> Grab's new bbai, lets' see what it should be..
<rcn-ee> 00000000 AA 55 33 EE 42 42 4F 4E 45 2D 41 49 30 30 41 31 .U3.BBONE-AI00A1
<rcn-ee> 00000010 31 39 33 33 45 4D 41 49 30 30 31 36 32 34 FF FF 1933EMAI001624..
<rcn-ee> in: /dev/mmcblk1boot1
<Jacmet> rcn-ee: didn't the a2 revision add an eeprom?
<rcn-ee> i don't believe A2 shipped to market yet..
<rcn-ee> ping @jkridner ^
<Jacmet> ahh, I don't see any clear revision markings on the baord
<Jacmet> root@beaglebone:~# hexdump -C /dev/mmcblk1boot1
<Jacmet> *
<Jacmet> 00400000
<Jacmet> 00000000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
<rcn-ee> Jacmet, A1 does have a label between heatsink and Kingston eMMC.
<rcn-ee> BeagleBone AI Rev A1
<Jacmet> rcn-ee: mine doesn't even have a heatsink
<Jacmet> so it gets pretty toasty
<Jacmet> rcn-ee: I believe it was an early board Jason sent me
<rcn-ee> ah, yeah... A2's eeprom needs ot be sent to u-boot, i haven't done that yet.. the eth mac needs to be figured out too..
<rcn-ee> ps get a heatsink on there asap.. here's the dimennsions (same one used on the x15)
<Jacmet> rcn-ee: I will
<Jacmet> rcn-ee: We've used the initial patches in Buildroot since I added the board, and I wanted to migrate to mainline u-boot/Linux now, but noticed that u-boot doesn't detect it as a bb-ai
<Jacmet> rcn-ee: but I don't quite get it then. This is on top of u-boot 2019.04, so without the workaround to read board id from the emmc (commit d6eaaae3d3)
<rcn-ee> Jacmet, i'm currently shipping this branch for
<rcn-ee> it doesn't include A2, but it's much closer to mainline..
<rcn-ee> if (rc)
<rcn-ee> printf("ti_i2c_eeprom_init failed %d\n", rc);
<rcn-ee> };
<rcn-ee> if (rc) {
<rcn-ee> ti_i2c_eeprom_am_set("BBONE-AI", "A");
<Jacmet> ahh
<rcn-ee> v2021.07 should get built-in extension support the team at bootlin did for
<Jacmet> and in the 2019.04 patch it was ti_i2c_eeprom_am_set("BBBBAI__", "A");
<rcn-ee> there we go! nuke change that to my fix...
<Jacmet> that kind of explains why I had issues getting 2021.10 booting without hardcoding bbai detection
jfsimon1981 has quit [Remote host closed the connection]
<rcn-ee> Jacmet, ps, can you do a dump of the eeprom? Ps feel free to add the value to mainline u-boot... At some point the A2 should become the default..
<Jacmet> rcn-ee: ok, so either hardcode bbone-ai if it failed to read the eeprom or stick eeprom data in the emmc boot partition?
<Jacmet> rcn-ee: I guess I don't have an eeprom after all, just the fallback code to ti_i2c_eeprom_am_set("BBBBAI__", "A");
<rcn-ee> Correct, on the AI, we should read eMMC, if fail read eeprom, if fail just default to the BBAI for us..
<rcn-ee> the bbai is the only am57xx from us or TI without eeprom, so it's safe to assume..
<Jacmet> rcn-ee: ok, good. Sorry, got confused by seeing (broken) bbai support in mainline
<rcn-ee> 3rd party did the bbai, we didn't catch the eeprom miss till it was way way too late..
<rcn-ee> (pcb)
vagrantc has joined #beagle
mattb0n has joined #beagle
mattb0n has quit [Remote host closed the connection]
mattb00ne has joined #beagle
zjason` has joined #beagle
zjason has quit [Ping timeout: 268 seconds]
russ has quit [Ping timeout: 268 seconds]
ikarso has joined #beagle
russ has joined #beagle
set_ has quit [Ping timeout: 268 seconds]
xet7 has joined #beagle
mewt has joined #beagle
<mewt> This seems like a more promising spot to ask... I have a Beaglebone Black that gives a 100% consistent error found here on boot: (this is just grepping CPSW from the journal after pulling the card out)
<mewt> This is with the latest archlinux-arm image
<mewt> Said SD card works fine, seemingly, in my other BBB
<mewt> both are rev B6
<mewt> Is this confirmed hw failure? is there anything else to do?
<mewt> Note that this is not the blah blah blah nothing at MDIO addr 0 *finds something at 2* error, but I don't know if the kernel would print it the same way anymore so maybe it -is- that reset bug
<mewt> ...That wording is confusing, all I mean to say is the error message is different from reports of that I've seen
nslu2-log has quit [Ping timeout: 240 seconds]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Client Quit]
jfsimon1981 has joined #beagle
<jfsimon1981> Hi, good evening,although not directly related to the beagleboard, i'm trying to get a modbus communication running through rs485 module attached to a bb black. I was struggling to get it working (no feed back from attached device, but was reading my own echo).
<jfsimon1981> After some investigations, I realized the half duplex rs485 line was not managed by the converter attached to bbb. Itself is communicationg through uart2 ttyS1.
<jfsimon1981> Finally I understand the RTS signal should be wired to the module enabling RX, disabling TX, and only during short periods data are sent does RTS get to 1 and reverse TX/TR (enable tx, disable rx).
<jfsimon1981> I'm still testing and modifying the module firmware to make that possible and will get 1 or 2 more GPIO from the BBB.
<jfsimon1981> Has someone experience with this, and can confirm or clarify how half duplex RS485 is to be properly handled ?
<jfsimon1981> Thankx
ikarso has quit [Quit: Connection closed for inactivity]
Shadyman has joined #beagle
xet7 has quit [Quit: Leaving]