buckket has quit [*.net *.split]
willow has quit [*.net *.split]
starblue has quit [*.net *.split]
Epakai has quit [*.net *.split]
SJFriedl has quit [*.net *.split]
vigneshr has quit [*.net *.split]
starblue has joined #beagle
vigneshr has joined #beagle
buckket has joined #beagle
Epakai has joined #beagle
SJFriedl has joined #beagle
willow has joined #beagle
GenTooMan has quit [Ping timeout: 272 seconds]
GenTooMan has joined #beagle
<set_> Hot!
<set_> Does the BBAI fanCape work for the BBAI-64?
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 264 seconds]
starblue has quit [Ping timeout: 255 seconds]
<set_> Chuggin' ahead!
starblue has joined #beagle
<set_> GenTooMan: The train almost hit me the other day. Damn workers forgot to set their down flags on the tracks. It was about 25' from me.
<set_> I would have finally made the news!
<set_> Ha.
<set_> Anyway...back to the BBAI-64! armnn is not going to build itself...
Shadyman has joined #beagle
<rcn-ee> zmatt: ignoring all the bigger ARCH/etc changes on the bbai64, boot "order" is similar to BBB...eMMC first, unless you hold the boot button then microSD... device id is opposite... microSD = mmcblk1, eMMC = mmcblk0
<rcn-ee> unlike the "BBB" if you really want the R5 to load from microSD at all cost.. i recommend users hold both teh reset and boot buttons... insert power.. let off reset (still holding on boot), wait till led, then let off boot.. that'll guarntee the R5 doesn't sneak the bin from eMMC... ;)
brook has joined #beagle
<zmatt> or wipe eMMC presumably
<zmatt> that's a curious sequence though... is the boot button supposed to be sampled on power-on or on reset?
<zmatt> hmm, "These pins must be properly set up before power ramp"
<zmatt> ah the ai64 reset button performs a power-on reset rather than a warm-reset
<set_> Aw...that is news.
* GenTooMan quietly breaks
<GenTooMan> hmm well that's useful when all else fails
<zmatt> rcn-ee: any idea why the reset button asserts MCU_POR (power-on reset) rather than MCU_RESETz (warm reset) ? I don't see any relevant errata that could explain it
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook_ has joined #beagle
brook has quit [Read error: Connection reset by peer]
<set_> Damn same issues...arm nn is not available for the build in ARM 64 b/c of the fact that bazel is not available in ARM 64 repos.
<rcn-ee> for eMMC, you just need to wipe boot0... that's all the bbai64 bootrom looks for.. there doesn't seem to be any legacy boot modes for eMMC.. (classic fs vs raw..) compared with microSD, in which case its' setup for 'fs' mode... our factory u-boot had a quick macro to erase boot0... https://git.beagleboard.org/beagleboard/u-boot/-/blob/v2021.01-ti-
<rcn-ee> we'd have to ask @jkridner about the reset, it might have been a copy of the TI evk module..
<rcn-ee> whereas am335x/am57xx support fs and raw mode out of the box... the bbai64 requires a sysboot pin to define "fs" or "raw" mode for the microSD...
<zmatt> the reset button behaviour is definitely a change from the BBB where pressing the reset button doesn't re-sample the boot mode button (which has proven useful sometimes)
<zmatt> rcn-ee: TRM doesn't seem very clear what the fs/raw setting is for eMMC and SD as backup boot mode, I presume raw
<zmatt> so if I understand correctly the default is { eMMC(raw), SD(raw) } and the boot button changes that to { SD(fs), SD(raw) }
<zmatt> I wonder if having the boot button arrange for { USB, SD{raw) } would be more useful, to potentially allow for reflashing via usb... SD(fs) seems of marginal interest especially since such an image wouldn't work on eMMC
<zmatt> ugh, the TRM could definitely use some improvement here
<zmatt> it would have been nice if it has the ability to just read a table of boot methods to try from an i2c eeprom or something
brook_ has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 272 seconds]
GenTooMan has quit [Ping timeout: 264 seconds]
GenTooMan has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
<set_> This lib. may never be built. Nothing that they are saying is correct.
samnob has quit [Ping timeout: 240 seconds]
nparafe has quit [Ping timeout: 246 seconds]
nparafe has joined #beagle
<set_> It is like someone on some computer somewhere is saying, "Gotcha loser!"
<set_> Argh...
Shadyman has quit [Quit: Leaving.]
akaWolf has quit [Ping timeout: 246 seconds]
akaWolf has joined #beagle
akaWolf has quit [Ping timeout: 272 seconds]
<set_> Well. armnn may have beat me this time!
<set_> I shall be back...
<set_> The protobuf, framebuffer, and other libs. are all out of order. I have been cyclicly, might be a word, repeating the same task but w/ the updated libs. over and over.
<set_> They distinctly said 1.13.1. Nope. It does not work that way. So, I have to try another and then another...
<set_> I wonder...
<set_> Will I ever get it to comprehend my commands?
<set_> and then compiling tensorflow has no memory of itself being compiled. Blah. So, starting that from scratch again...AW!
<set_> There is one thing I can say. It almost worked once.
akaWolf has joined #beagle
<set_> I am in the make command now under armnn. I made it! Is it done...no. But...I am two steps closer!
<set_> This BBAI-64 can take the pain!
<zmatt> lol wtf, for some reason mouser's AI-64 page claims that "Due to government regulations, Mouser is unable to sell this product in your country." ...
<set_> Hmm.
<set_> I just got one from Mouser.
<set_> In the USA?
<set_> Illegal Beagle!
<zmatt> no I'm not in the US, but I'm also not exactly expecting export restrictions to the Netherlands :P
<set_> Hmm.
<set_> Odd.
<set_> Now, mouser has exactly 0 for selling.
<set_> They just had 85 like two days ago.
<zmatt> yeah it's probably just a mouser issue
<set_> Probably.
<set_> I am on 35% on building armnn now. I recorded the build instructions too!
<set_> This BBAI-64 is going to compute if I have something to do w/ it.
<set_> Now, if I can only figure out this EVE and how to use it to my advantage.
<zmatt> AI-64 has no EVE
<set_> I looked at digikey first. They were out.
<set_> Oh?
<set_> Let me double check.
<set_> Yep.
<set_> You are right. I got what happened now.
<set_> The banner said this while the instructions below were for the AI.
<set_> Blah.
<set_> DSP, though!
<set_> @zmatt: What is a R5?
<set_> That is new to me.
<zmatt> sorry, busy
<set_> There is so much to do!
<set_> Oh.
<set_> Okay.
<set_> WHelp, back to watching my "successful" building!
<set_> What is the deal w/ the extra couple of header(s)?
M-blaise has joined #beagle
<set_> Whelp...
<set_> I am reading about the cortex-a5 and it is similar to M4 chips w/ the NVIC, SP, PC, and so on...
<set_> Sorry. cortex-r5.
<set_> There are many rules, i.e. my "strong" suit. Ha. I am going to finish this building and then go to the r5 for modeling.
<set_> I found a fellow online. Anyway, this "fellow" works for UT and got wrapped up in TI and the university.
<set_> He created a bunch of books and online learning ideas. It is about the cortex-m. So, not too relevant but the info. is similar.
<set_> 63% and still going strong!
<set_> How would one read individual registers on the cortex-r5 on the BBAI-64?
<set_> I mean...I see in the TRM how to do so. But...I just do not think it is that "easy."
<set_> So, would I write an assembly solution for this effort or is there a command on the terminal that can be used?
<set_> That is what I am getting at right now.
<set_> nasm?
<set_> WHelp. Somehow, somewhere. Yep. I messed it up.
<set_> Blah.
<set_> 65% to notta and all in one build.
akaWolf has quit [Ping timeout: 240 seconds]
<set_> I reach for the stars and I end up grabbing worms.
<set_> Argh...
<set_> I am going to do it again!
akaWolf has joined #beagle
<rcn-ee> zmatt: we had to self certify, one reason we ran out so fast... they should also be up on ti.com now too.. Mouser just needs to do the paper work..
<rcn-ee> for the TRM, the bbai64 boot rom is more simple when compared to the am335x/am57xx, it will only do what the 'sysboot' pins tell it.. So the pcb is only setup for "FS" mode on the microSD (you need to move a resistor to enable "RAW" mode.... Where as the eMMC only supports "boot0" mode, then when the R5 runs that first blob, we load everything thru u-boot in "FS" mode... For something like USB or NVME, i haven't looked at it too
<rcn-ee> much... I'm thinking we will reliy on "boot0" on the eMMC and there for u-boot to scan usb and nvme...
<rcn-ee> but a pure blank eMMC/microSD case, i have no idea how we'd do usb or nvme boot..
<rcn-ee> For end users today, we can easily dd between eMMC -> microSD (just change fstab) and things will work fine.. the only setting for eMMC is to dd the R5 blob..
M-blaise has quit [Read error: Connection reset by peer]
<set_> To anyone here, what exact arm64 type is the arch. on the BBAI-64, i.e. -8a or another variation?
<aussetg> set_: ARMv8-A ? It’s just a plain A72 afaik
brook has joined #beagle
<set_> Oh.
<set_> Okay.
<set_> Dang it. I messed up again.
<set_> aussetg: The reason I ask is this...I am building a "few" libs. now and things got "complicated." Anyway, the ComputeLibrary I am building now asked in output for a arch= and I picked -8a b/c I was unaware of the type of processor arch.
<set_> So, is this a arm64-7 arch then?
<set_> The reason is this: My only options are these processor arch on this build.
<set_> 'arm64-v8a', 'arm64-v8.2-a', 'arm64-v8.2-a-sve', 'arm64-v8.2-a-sve2'
GenTooMan has quit [Ping timeout: 260 seconds]
GenTooMan has joined #beagle
SJFriedl has quit [Quit: Leaving]
brook has quit [Read error: Connection reset by peer]
brook has joined #beagle
akaWolf has quit [Ping timeout: 276 seconds]
akaWolf has joined #beagle
lucascastro has joined #beagle
vagrantc has joined #beagle
<set_> Has anyone figured out which one of the above four is the architecture on the BBAI-64?
<set_> I cannot figure it out.
<vagrantc> joined too late
<vagrantc> what were the four choices?
<set_> 'arm64-v8a', 'arm64-v8.2-a', 'arm64-v8.2-a-sve', 'arm64-v8.2-a-sve2'
<vagrantc> none of the above
<set_> I was going to build some libs. and make this hootin-shootin...dang it.
<vagrantc> or wait, the bbai-64 is a thing?
<set_> Yep!
<set_> They made it!
<set_> Tariff and all!
<set_> I know. I got one or one. Yep. It works. I got one.
<vagrantc> or did you get one?
<set_> The processor is auto grade. I got one.
<set_> It can handle the heat!
<rcn-ee> vagrantc: do you need one? ;)
<set_> I put a fan on it anyway. It seems to like it better when it is cooler.
<vagrantc> so you want to know the architecture of the hardware, or the operating system?
<rcn-ee> arm64
<set_> Hardware.
<rcn-ee> k3
<vagrantc> rcn-ee: considering how not far i got with the BBAI ... not sure.
<set_> I got nowhere w/ the AI. I am bummed out.
<set_> Hey you guys...
<set_> arm64, right. But...what is the extra bits and pieces of the arch. for the arm64?
<set_> This lib acts like it knows everything.
<rcn-ee> vagrantc: for you, the biggest issue right now is the fork of ATF, optee, and u-boot: https://git.beagleboard.org/beagleboard/repos-arm64/-/blob/main/bb-u-boot-beagleboneai64/suite/bullseye/debian/rules#L25-36
<set_> Someone, I think aussetg, listed a link. I read it.
<set_> Blah.
<set_> Never fret. I will keep researching.
<rcn-ee> this patchset should 'clean' things up... https://lore.kernel.org/all/20220615064804.29553-1-n-francis@ti.com/T/
<vagrantc> presuming you mean debian's arm64 ... https://wiki.debian.org/Arm64Port
<rcn-ee> correct.
<rcn-ee> we shipped Debian Bulleseye ARM64 with our overlay.,.. https://debian.beagle.cc/arm64/ (kernel u-boot, and other random stuff for ti edge demos..) with network-systemd enabled as default..
<vagrantc> set_: the operating system defines the baseline architecture, although the hardware may support additional features on top of that ... but depending on how you write the software, you might have to recompile the whole os ... more ideally, use runtime detection to use features above the baseline
<rcn-ee> i mirrored what debian did for the RPI... special fat partition mounted at /boot/firmware/
<rcn-ee> we should be able to do the "cat" dd images..
<vagrantc> yeah, how to support platforms that have stuff not in debian is a tricky proposition :)
<vagrantc> especially if they're things that can't officially end up in debian main
<vagrantc> e.g. the rpi bits
<rcn-ee> so, it's a dual partition, fat + ext4... Debian needs to enable k3...
<rcn-ee> k3 arch in linux kenrel..
<vagrantc> happy to merge pull requests or update the debian kernel packaging to add it
<vagrantc> bbai-64 doesn't have much in the way of disk i/o though?
<vagrantc> emmc or usb-c ?
<rcn-ee> we also use extlinux.conf by default.. ;)
<rcn-ee> baseline... eMMC and microSD..
<rcn-ee> type-c is avaiable, some issues users are facing right now..
<vagrantc> ah, but you coudl maybe wire some disk into the m.2 slot ... pcie or something?
<rcn-ee> pci-e -> type - e to normal nvme key is needed... untested..
<rcn-ee> exactly with a type-e adapter..
<vagrantc> nice full-board heatsink, looks like :)
<rcn-ee> that's from teh bbai, we won't overheat at all cost..
<rcn-ee> at full load it sits at 65C (no cpufreq yet..)
<rcn-ee> mainline works nice... video bits just got enabled..
<rcn-ee> (using our v5.10.x dtb on v5.19.x kernel)..
<vagrantc> not sure i have a use for it ... just got a honeycomb lx2 ... 16 cores, 64GB of ram :)
<rcn-ee> yeah, i agress the honeycome is nice..
<vagrantc> my crazy build zoo is likely going to loose some diversity
<rcn-ee> and we only have 4gb of ram..
<vagrantc> we still have a few ~4gb boards ... but if i got a couple honeycombs it might make sense to retire them
<rcn-ee> wish we had a rfc for 5.10.x but we are too late now.. main thing in debian, enable K3 arch..
<rcn-ee> (5.20.x)
<vagrantc> haven't done anything clever with boards really, still mostly just using them as part of a build farm ... but i have plenty of way at the back burnered projects to tackle someday...
<vagrantc> would like to use some relays to divert excess solar power to useful things and whatnot
<rcn-ee> no worries, you know us, the goal is once we release something, it should be around for 10 years. ;)
<vagrantc> yeah, can't say the same for most boards
<vagrantc> the risc-v stuff didn't quite get there?
<vagrantc> most of the things i could use beagleboard stuff for i can probably just use a microcontroller that supports micropython, though ... my interests seem to leap straight from microcontroller to build machines, with not a lot in-between, other than maybe a daily use laptop
<vagrantc> but i'm guessing beagleboard isn't too interested in handhelds or phones or laptops and all the mess that comes with
lucascastro has quit [Ping timeout: 255 seconds]
<vagrantc> the mnt/reform folks are doing some interesting work that seems somewhere in-between ... bulky laptops and handhelds made to have replaceable parts, and DIY modifications and whatnot
<set_> speaking of .dtb...
<set_> I saw the AI-64 had a robotcontrol.dtb. I forgot to look at it.
<set_> Dang it!
akaWolf has quit [Ping timeout: 260 seconds]
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
Shadyman has joined #beagle
brook_ has quit [Read error: Connection reset by peer]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
akaWolf has joined #beagle
brook_ has quit [Read error: Connection reset by peer]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook_ has joined #beagle
agrue has quit [Quit: Client closed]