<jkridner>
hi all. I'm working on a TDA4VM-based BeagleBone AI variant. might as well tap into the community. I'm a couple weeks late from finalizing the header pin choices, but I'm going cross-eyed staring at it. I'm hacking using the spreadsheet linked at https://github.com/beagleboard/capes README. <-- zmatt
<jkridner>
at this moment, I'm spending a bit more time cleaning up the pin list which didn't import cleanly.
<jkridner>
so many things are driving me nuts.
<jkridner>
like having the PCIx_CLKREQ# lines on the I3C pins. :-(
<jkridner>
NishanthMenon: spent any time with TDA4VM pinmuxing?
<NishanthMenon>
jkridner, meaning what specifically? I had been helping architect the SoC :D
* jkridner
wishes the AM3358 pinmux was looked.
<NishanthMenon>
jkridner, did you mean in terms of mux option selections? or pinmux registers and organization, perse?
<NishanthMenon>
jkridner, i helped define the part two to prevent a repeat of iodelay. but not been involved in mux options per pin.. that was package and apps team driven
<jkridner>
It looks like the only place to grab the I3C signals is the same place to grap the PCIx_CLKREQ signals, so I can't have I3C and PCIe.
<jkridner>
trying to make some pins that gave the same options would have been nice.
<NishanthMenon>
aah.. mux option.. sorry, have'nt been involved there. yeah - i3c has been hotly debated as no one seems to know of anyway to use them
<jkridner>
I keep running into situations where I cannot get functions out because of conflicts.
<NishanthMenon>
jkridner, aah.
<jkridner>
I've been pulling my hair for 4 straight days without sleeping.
<NishanthMenon>
jkridner, i assume you've spoken to some TI folks on it?
<jkridner>
It has caused me to miss my schedule and could make everything slip. :-(
<NishanthMenon>
sure eidk board has had the same challenge
<jkridner>
I don't know who to ask about it outside of you. I don't think Paul, etc. would give me much time on it.
<NishanthMenon>
jkridner, let me check internally.. I think Mike Erdhal will be a great help..
<NishanthMenon>
uggh.. wrong bu.. robert eschler or brian brenner i think
<jkridner>
oh, good call.
<jkridner>
I can ping Brian.
<NishanthMenon>
jkridner, yup. let me know if you dont get a response.. i can always walk over to his cube and provide some glare to complement :P
<jkridner>
Brian is really responsive to me. I just text him.
<jkridner>
you back in the office then?
<NishanthMenon>
jkridner, yep - texas is open for business.. it getting crowded in dallas office now :D
<NishanthMenon>
jkridner, btw on the i3c stuff -> we did get cdns to get the driver in upstream. unfortunately, we in linux team have'nt enabled it tda4/j721e since we cant seem to find any reasonable way to test it..
<NishanthMenon>
so no dts node :(
<jkridner>
well, I'd try to make hardware it can be reached on, but I think it is impossible if you want to have PCIe at the same time..... PCIe wins.
<NishanthMenon>
yep - sounds like a sane option.. at least optionally, put a couple of test points if someone wants to drop pcie and monkey with i3c :D
<NishanthMenon>
not sure how that works with highspeed signalling :(
* jkridner
isn't familiar with how CLKREQ# is used on PCIe.
<jkridner>
I just know it is on the connector.
* NishanthMenon
ducks
<zmatt>
jkridner: clkreq is not a high-speed signal at least, it's basically just an async request to wake up the refclk in low power modes
<jkridner>
yeah, kinda what I figured, so I can't figure out why anyone would decide to make the *ONLY* pins that can expose it to be the same only pins as for I3C.
<zmatt>
yeah a bit odd that both have only a single pinmux option
<NishanthMenon>
zmatt, overall the story inside j721e kind of devices is that it is massive. and n * m mux options challenges are extreme. most places unless the business teams come up with strong rationale, the alternate mux options tend to get challenged to reduce area
<zmatt>
NishanthMenon: I don't see why iodelay is inherently bad, it seemed like a very flexible solution to line signals up at the chip boundary (albeit presumably a bit heavy on silicon real-estate)... the problem was that its implementation sucked
<NishanthMenon>
zmatt, yeah - layout constraints and glitchless muxes (as sensible as possible) have been a guidance principle on all k3 SoCs
_whitelogger has joined #beagle
<zmatt>
jkridner: to be fair, four pcie subsystems seems a bit excessive, is it an option to just not support pcie 0 and 1 (or at least not support hardware-managed link power management on these) ?
rob_w has joined #beagle
<zmatt>
or use the i3c interfaces in the mcu domain?
M-blaise has joined #beagle
<jkridner>
good point, looking at conflicts for PCIe2 or PCIe3.... 2 --> QEP strobe, so maybe that one. 3 --> MMC1 card detect.... I need to see if that is the one I'm using for the microSD.
<zmatt>
(assuming those are accessible from main domain by default if no explicit isolation has been setup)
<zmatt>
mmc card detect can use any gpio
<zmatt>
iirc
<jkridner>
I'm planning a small extra ribbon-cable connection to expose a mikroBUS connection for the MCU.
M-blaise has quit [Client Quit]
<jkridner>
yeah, I think the kernel can work with any GPIO, rather than the one assigned by the peripheral. so, I think that'll be the one.
<jkridner>
lack of sleep causes obvious solutions to go unnoticed.... thus crowd-sourcing. :-)
M-blaise has joined #beagle
<zmatt>
I'd assume (but have not checked!) that mcu domain is not isolated from main domain by default, but that that requires setting up firewalling
<NishanthMenon>
interesting j721e evm - J721E_IOPAD(0x258, PIN_INPUT, 0) /* (P23) MMC1_SDCD */ -> but I think it should work with gpio as an option too..
M-blaise has quit [Client Quit]
<zmatt>
hmm maybe I assumed wrong
<zmatt>
I might need to read up more on the global memory map and interconnects
<NishanthMenon>
zmatt, yes - this is a basic difference between the j721e arch and am64 arch -> mcu domain is integral and primary on j721e arch in am64 arch, mcu arch is an addon -> so you can optionally firewall it off entirely.
<NishanthMenon>
additionally there are power domain controls to isolate further the two domains in am64 arch. in j7 arch, mcu domain is a lot more fundamental to operation.
<NishanthMenon>
zmatt, in both cases - unless you are dealing with what we call as a HS_SE device, the firewalls are default always open. on HS_SE device firewalls are locked down by default, and bootloader needs to initiate opening things up
<zmatt>
I see main domain and mcu domain addresses overlapping though, which makes it not immediately clear whether all mcu domain resources are accessible at all from main domain
<NishanthMenon>
zmatt, overall all peripherals are reachable. there is a global address map
<NishanthMenon>
but from routing perspective (intererupts , dma etc) -> there are always constraints as to what can be enabled simultaneously across the domain.. that is the real bottleneck
M-blaise has joined #beagle
<NishanthMenon>
soc design philosophy assumes the mcu peripherals are meant for mcu domain firmware as primary usecase and main domain as an optional usecase.. many reasons why.. safety s/w and all that stuff comes into play..
<zmatt>
fair
<NishanthMenon>
zmatt, jkridner does it help if we organize some sort of a talk thingy about j721e.. that is a monster to understand from trm alone.. not entirely sure about the feasibility etc..
<NishanthMenon>
maybe a bit premature..
vigneshr has joined #beagle
<NishanthMenon>
zmatt, vigneshr will be a good guy to poke as well :D
<zmatt>
I was somewhat surprised to learn a j721-based beagle was being explored, being the first keystone SoC for which this is done... it's such a ridiculously huge SoC. like, I already called the dra7xx/am572x "the monster" when I first started reading about it, but it's made to look tame and modest in comparison to j721e lol
<NishanthMenon>
zmatt, yep... am65 is a uC compared to j721e.. but.. believe me when i say this.. j721e is a uC compared to what we are going to throw out there ... :D
<zmatt>
a μC ? I'm sure baremetal programming this thing would be great fun ;-)
<NishanthMenon>
ROFL
<zmatt>
I've done baremetal on the dm814x and a little on the am335x, but going beyond those starts to look a bit intimidating to me
<NishanthMenon>
zmatt, yeah - i was in the firmware team on k3 for a few years.. it is not easy.. i will definitely confirm that.
<NishanthMenon>
but, at least there are libraries in what we call PDK out there.. not my fav way of organizing stuff, but there is bunch of libraries to use from.. so building on top should'nt be as tough as when we started on FPGA
<zmatt>
for am335x I browsed StarterWare but it was.... really bad
<jkridner>
NishanthMenon: always interested in whatever you have to teach.
<NishanthMenon>
yeah - hoping we learnt a few lessons along the way, but yeah - early days of PDK - it is going to be interesting to see where that can be improved..
<jkridner>
I found u-boot to be a better starting point for "bare metal" programming.
<zmatt>
NishanthMenon: dunno if it's been fixed since, but the am335x uart driver caused random data corruption and the uart echo example compiled to a deadloop if any optimization was enabled
<zmatt>
in starterware
<NishanthMenon>
zmatt, uggh..
<zmatt>
like, it looked like it was written by people who do not have an adequate mental model on how to deal with interrupts, hence should not be allowed to touch driver code with a ten foot pole
<NishanthMenon>
jkridner, zmatt, in this journey, i would really be interested in ways we can improve our pdk offering.. i believe in heterogenous systems working like how the uServices work in cloud world and there will be smaller firmwares that help make the overall solution effective.. will be interested in knowing how to improve that..
<NishanthMenon>
jkridner, on the "teaching" side.. sure.. lets find some topics to walk through and I will try to find the teachers this side of the shop who are probably better than me
<zmatt>
I have negligible experience with any TI PDK though, on the dm814x (where we never went beyond an early prototype) I've only done baremetal, on the am335x I just use debian
<zmatt>
my limited experience with the am572x has likewise only been using debian so far
<NishanthMenon>
zmatt, hmmm.. sounds like i might know just the person to introduce PDK :)
<NishanthMenon>
i mean, i dont deal with PDK personally myself.. my solution for PDK is -> send the firmware to linux-firmware.. :D
<zmatt>
(I also don't know if I actually have spare braincells to dive deep into the j721e right now, even if it sounds fun)
<NishanthMenon>
zmatt, yup..
<zmatt>
especially given that the j721e is not exactly a light snack
<NishanthMenon>
do have a pepto-bismol handy when you start :P
<zmatt>
so what happened to the broadmarket version, am752x ? the download link on the product page still calls the trm the "DRA829/TDA4VM/AM752x Technical Reference Manual" but in the PDF itself the /AM752x has been removed from the title in revision B
<NishanthMenon>
zmatt, actually, i dont know... good question.. I can ask.. i think the answer is going to be simplify the offering and use TDA4 brand or something.. I have no idea
<zmatt>
sounds reasonable, it has always been annoying that essentially the same soc (but with different features efused out) has multiple totally different part numbers
M-blaise has quit [Quit: WeeChat 2.8]
M-blaise has joined #beagle
<NishanthMenon>
heh.. mktg folks and their alphabet soup... that is also why i stick only to the first part number mentally it is still hard for me to digest TD4 as J721e ...
<zmatt>
(while at the same time having very similar-looking part numbers for totally different SoCs... *cough* dra78x *cough*)
<NishanthMenon>
lol
<zmatt>
I actually prefer using the codenames for the SoC(-family) whenever they're known to me, since those tend to be much more memorable and distinguishable than a pile of letters and digits, e.g. using "subarctic" instead of "am335x" completely avoids any risk of confusion with the totally unrelated "am35xx"
<NishanthMenon>
yup. we do have codenames, but we also put in place a gag order from using the codenames in public :(
<NishanthMenon>
supposedly many customers got confused looking for codenames in trm and such..
<NishanthMenon>
so now everyone internally started using the same alphabet soups ..
<zmatt>
/o\
<NishanthMenon>
yup
<zmatt>
the solution would have been to just explicitly mention the codename in the TRM
<NishanthMenon>
zmatt, i am not entirely sure of all the rationalization they might have had when gag order came down.. yeah, personally, i might have gone a different road.. but good thing I am not involved in mktg :D
<NishanthMenon>
at least given the confusion it creates from time to time.. I am sure industrial espionage is at least that little harder :P
<zmatt>
yeah I'm not a fan of part numbers being decided by marketing instead of being based on technical relatedness
<NishanthMenon>
+1....
<zmatt>
especially if you want to deal with entire families
<NishanthMenon>
aye
<zmatt>
like, "am57xx/tda2/dra7xx except dra78x" is a rather annoying SoC family name
<NishanthMenon>
zmatt, we can always use the JTAG_ID to refer to parts.. but i think it might be a mouthfull :D
<zmatt>
heh
* NishanthMenon
back ltr.. meeting fun theme..
<zmatt>
maybe some sort of hash function from jtag id to a sequence of english words... the "correct horse battery staple" SoC ;-)
<jkridner>
anyone know enough about google sheets to find string matches between two CSV delimited cells?
<zmatt>
"CSV delimited cells" ?
M-blaise has quit [Quit: WeeChat 2.8]
M-blaise has joined #beagle
<jkridner>
yeah, cells where I used =JOIN(",",range)
<jkridner>
I think I figured it out.
rob_w has quit [Quit: Leaving]
<zmatt>
I can't say I've ever had an urge to deliberately put CSV into spreadsheet cells... I think the moment you start effectively trying to use nested columns is the moment maybe spreadsheets aren't the best tool for the job anymore :P
<zmatt>
yay, logging is up
<zmatt>
oh nice the live updates are quite low latency
<NishanthMenon>
zmatt, yeah - btw, if you can update the topic, it will help remind all where the logs are..
starblue1 has quit [Quit: Leaving.]
<NishanthMenon>
zmatt, internal response on AM75x -> as I guessed.. TDA4VM is meant for both industrial and automotive. AM752x is in the middle of being cleanedup by tech docs team..
<zmatt>
topic should be fine, once we're actually migrating the links in http://bbb.io/chat will be updated to point the webchat and logs to here
<NishanthMenon>
zmatt, cool..
<zmatt>
jkridner: should we wait for the matrix bridge? I don't really know much about matrix but I did get the impression that it was/is used by some people on the current freenode channel
<jkridner>
hmmmm...... I feel like that'll sink about 2 hours of time. Not sure I have it right now.
<zmatt>
well the matrix bridge isn't going to be available in 2 hours yet anyway ;)
<zmatt>
I've heard someone say they hope to have it up by friday but dunno how reliable that hearsay is
<jkridner>
oh, the one by matrix.org..... I was thinking of the one I have up on beagleboard.org that isn't working because of being blocked by freenode.net
<jkridner>
then again, I could never even fully get it working between matrix.beagleboard.org and irc.beagleboard.org :-(
<zmatt>
yeah I wouldn't suggest trying to set up your own integration with any existing irc network, that's just a bad idea
<zmatt>
without explicit support from the irc network it would presumably just look like a whole bunch of normal connections coming from the same IP, which indeed is liable to look like abuse and get banned
<NishanthMenon>
russ, fun stuff.. jkridner and team are working on a j721e bbai variant.. so your wisdom will be valuable :D
<NishanthMenon>
russ, otherwise meetings as usual :D
<russ>
does it have some sort of deep learning coprocessor?
noahm has quit [Changing host]
noahm has joined #beagle
<NishanthMenon>
yeah - that tiny little c7x stuff we put in there.. :D
<russ>
ah, so using DSP instructions
<NishanthMenon>
i think there are all model abstractions to get to the mma stuff..
<russ>
I've really just been sitting back enjoying the first year with my new son, I'd be nice to get back into things part time and help out though
<NishanthMenon>
russ, congrats btw.. yeah bb.org has some cool new boards - beagle-v stuff now these new ai engines... just too much to play with and not enough weekend hours for me :(
shoragan[m] has joined #beagle
<russ>
it does look like a fun little board, pretty cool they packed it in there considering the size of the evms
<NishanthMenon>
yeah
shoragan[m] has quit [Quit: node-irc says goodbye]
shoragan[m] has joined #beagle
vagrantc has joined #beagle
<jkridner>
NishanthMenon, russ : does it matter which UART I put on the console header?
<NishanthMenon>
jkridner, yes
<NishanthMenon>
jkridner, there are two key firmware that is involved - TIFS and DM -> those two use wkup usart0 and mcu_usart0 respectively.
<jkridner>
please do tell.
<NishanthMenon>
those logs are super critical if something hanky panky goes on in the firmware - they control security and power/resource management respectively
<jkridner>
u-boot, linux can use wkup_uart0?
<NishanthMenon>
there are alternative ways to pick the logs -> like using itm or a limited internal circular buffer, but those tend to be useful (when linux has'nt crashed) if the failure is catastropic -> e.g. freeRTOS died or something..
<jkridner>
currently, McASP changes have me a bit wrapped around the header axle. There's no more AHCLKX.... I'm assuming all of the ACLKX are "high-speed"
<NishanthMenon>
u-boot linux default is main_usart0
<jkridner>
I'm trying to figure out if BeagleBone Black daughterboards ended up using both ACLKX and AHCLKX.
<jkridner>
k.. J29 and J28 tied for console connector. :-D
<NishanthMenon>
jkridner, i thought you were going rpi header
<jkridner>
not for this board..... I'm doing a robotics daughterboard and need all the EQEP, EHRPWM, etc.
<jkridner>
also, didn't want to do the secondary Pi header for this one either....
<NishanthMenon>
on flip side (on usart) - j721e - we f**d up a bit.. default the main_usart0 is not clocked by ROM. wkup_usart is. so very early R5 u-boot logs are hard to get with mcu_usart or main usart
<jkridner>
maybe too crazy, but trying to provide cape compatibility to give cape users a roadmap.
<NishanthMenon>
that oversight was fixed on all follow on chips.. but anyways..
<NishanthMenon>
jkridner, hmm.. cape ecosystem - for some reason i thought we left them behind to rpi hat ecosystem..
<NishanthMenon>
jkridner, what ever you do.. please no more emmc board revisions please. put in a eeprom.. please
<jkridner>
nope..... more often than not, people use them more like a COM connector.... big board they drop a Beagle into....
<jkridner>
but, still, trying to continue to support the cape ecosystem.
<jkridner>
TI is likely to start low-cost EVMs.... I gave advice internally that low-cost EVMs should use the Pi-headers.
<NishanthMenon>
jkridner, yeah - it is all PI header.. in exact physical dimensions :D
<jkridner>
I've yet to see a really low-cost EVM from TI, but that was the idea I pushed before leaving.
<NishanthMenon>
only flip side... we ended up with two pi header modes - one which is rotated 180 degrees for pin1 to be compatible with some jet board :P
<jkridner>
for Beagle, I think we have to care about an installed base, where it isn't the same with sporadic TI EVMs.
<jkridner>
For BeagleV, it is a fresh start with a Pi header.
<jkridner>
along with the work Bootlin is doing in upstream u-boot, there are attempts (stealing much thoughts from zmatt) to make cape overlays that are compatible across various SoCs.... as long as they have the right peripherals.
<jkridner>
similar could be applied to the Pi header, there just isn't as much to work with there.
<jkridner>
QEPs, EHRPWMs, eCAPs, etc...... if you guys would stop monkeying with how they are pinmuxed!!!
_whitelogger has joined #beagle
<jkridner>
anyone know why AM3358 has both ACLKX and AHCLKX and both are enabled on the HDMI?
<zmatt>
(this just explains it from a hardware point of view though, the linux driver does not necesssarily support all of these options, and the DT configuration regarding audio can be obtuse)