brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
akaWolf has quit [Ping timeout: 264 seconds]
akaWolf has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
xet7 has quit [Remote host closed the connection]
brook has quit [Remote host closed the connection]
PhotoJim has quit [Ping timeout: 248 seconds]
Guest42 has joined #beagle
otisolsen70 has joined #beagle
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
<zmatt>
you can use whatever size SD card you want
GenTooMan has quit [Ping timeout: 244 seconds]
GenTooMan has joined #beagle
Guest42 has quit [Ping timeout: 252 seconds]
Shadyman has quit [Quit: Leaving.]
mattb00ne has quit [Remote host closed the connection]
mattb0ne has quit [Remote host closed the connection]
ikarso has joined #beagle
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #beagle
Guest79 has joined #beagle
<Guest79>
Hello There. I ordered the Beaglebone AI-64 from Farnell and they can not ship it from UK to Germany, how I was explained, due to some documents missing from BeagleBone creators side.
<Guest79>
Anybody here from the creators?
Guest79 has quit [Quit: Client closed]
<zmatt>
jkridner: ping? sounds like whatever issue mouser is having also affects farnell
GenTooMan has quit [Remote host closed the connection]
GenTooMan has joined #beagle
brook has joined #beagle
<rcn-ee>
zmatt: really surprised , they should be able to self-certify.. that's how we sold everything in the first week..
PhotoJim has joined #beagle
brook_ has joined #beagle
brook has quit [Ping timeout: 244 seconds]
brook_ has quit [Ping timeout: 240 seconds]
<zmatt>
what exactly is the problem?
set_ has quit [Remote host closed the connection]
<rcn-ee>
US export codes.. they have the base CCAT, but they need to do the paperwork...
agrue has joined #beagle
brook has joined #beagle
GenTooMan has quit [Ping timeout: 244 seconds]
buzzmarshall has joined #beagle
GenTooMan has joined #beagle
Guest42 has joined #beagle
<Guest42>
So I am coming completely from a software world and don't know crap about hardware but am trying to pick it up. These Sitara processors, I have never heard of them before. But they seem to just be ARM-based. Could I feel confident I can get tensorlite and such working on say the AI-64 pretty easily or does stuff not compile straight-forward?
<zmatt>
Guest42: I mean, any software that can run on Linux on an ARMv8 processor (specifically ARM Cortex-A72) will obviously work
<zmatt>
though a lot of computational power on the AI-64 is in its other cores, such as the DSPs
<zmatt>
unfortunately I'm not (yet) particularly familiar with the AI-64's capabilities nor the tools available to harness them
<Guest42>
tyvm. yeah I have never encountered anything like PRU's before and hard to find documentation about use-cases people have succeeded with
<Guest42>
Just makes the imagination of what to do with the board a bit more opaque is all, not sure what can be done with the PRUs.
<Guest42>
Just a learning curve
<zmatt>
PRUs are really cool, though not really as a computational resource but rather for things like real-time I/O
<zmatt>
thanks to their deterministic instruction timing and low latency gpio which are tied directly into registers
<Guest42>
There doesn't really seem to be anything as open as beagleboard and I've looked extensively
<zmatt>
a relatively simple example use-case of PRU on the BeagleBone Black is "BeagleLogic", which turns a BBB into a 100 Msps 12-channel logic analyzer (with one PRU core sampling the inputs every other cycle and using the remaining cycles to offload the data to the other PRU core, which is responsible for writing it out to memory)
<Guest42>
I was interested in pine64 but read they shut down their california offices to go to Hong Kong and avoid the "legal mafia" per the words of their owner. Moving HQ china to escape regulation seems sketch as hell
<Guest42>
Interesting thanks zmatt
<zmatt>
we use PRU to accurately timestamp the transfer of audio data, because the timestamps provided by ALSA were just too terrible and jittery to be of any use
<zmatt>
PRU is also commonly used to bit-bang custom protocols, such as the weird protocol used for WS2812 leds
<zmatt>
on the BeagleBone Blue one of the PRU cores is commonly used as an extra quadrature decoder, to supplement the three hardware-implemented quadrature decoders
<Guest42>
Ahh interesting
<Guest42>
I was thinking they could be used for servos and such
<zmatt>
yep
<Guest42>
I'm coming from a Jetson Nano world, definitely feel some convenient APIs are lost here but on the flip-side you are not as beholden to nvidia releasing software to keep the product going
<Guest42>
Getting into hardware has been difficult for me but slowly picking it up
<zmatt>
also, nvidia's developer license is insane
<zmatt>
that's the big advantage of TI... you can just go to their site and download detailed SoC documentation without even any sort of registration or whatever
<agrue>
Heh - I'm testing out the ai64 because nvidia isn't providing updates for the (relatively recent) nano anymore
<Guest42>
i have to admit I have never used a TI product besides the ti-86. I had no idea TI was even making SBCs until I found this project
<agrue>
Shame, the gst plugins from nv on jetson are nice
<zmatt>
TI nowadays mainly targets industrial and automotive markets rather than consumer devices, so products tend to be well-supported and available for a long time
<zmatt>
which I personally find more valuable than having the hottest new CPU core or whatever
<Guest42>
argue that is one of the main reasons I want to hop ship from the jetson nano
<Guest42>
I am very annoyed they stopped releasing updates as regular packages and now everything is a separate docker container that dusty-nv hosts on his personal website. Not sure if you ran into that
<agrue>
Oh I had been using yocto for a year so I might have missed it
<Guest42>
yeah all of the latest updates have been ad-hoc on one employee's personal webpages and github
<Guest42>
but then you are stuck making docker containers talk to each other instead of just using native packages and going with it
<Guest42>
because as much work to keep up with nvidia as it was to just develop what you want
<Guest42>
became as much work*
<agrue>
I'm hoping to try out the ti gst elements this week, been a bit swamped since the thing was delivered
<Guest42>
they will be good for enterprise where you are a business and want to offload liability and support to another company. I think for individual devs they arent interested in really keeping up a community
<Guest42>
the nano has very much become just a test platform to see if you want to jump into their more expensive boards, i dont think they really want people staying on the nano and living there
<Guest42>
anyway my rant over
<Guest42>
i was an open source fanatic earlier in my life so beagle calls to me, seems to have an honorable mission lmao
<zmatt>
this documentation is specifically about TI's own SDK, I have no idea whether of all this is already working on the debian images for the AI-64
<Guest42>
if it is in the debian repo for ARM is it safe to assume it will work on a beagle
<Guest42>
or not always
<Guest42>
well of course not always, but more often than not
<zmatt>
unless there's something intrinsically hardware-specific about a package
<zmatt>
normally whenever anything is packaged by debian, it's supported on all architectures that have official debian support, including armhf and arm64
<Guest42>
Got it, that is great to hear. It's really just some of the TI-specific stuff on the board I am really uncertain about but I guess I should probably just dive in. For example, even interfacing with the PRUs...I'm assuming in the end it's going to be a few API calls or something not that bad but just havent looked into it yet
agrue has quit [Ping timeout: 252 seconds]
<Guest42>
Thank you for all the great info, a lot to learn here
<zmatt>
PRUs are best viewed as standalone microcontrollers embedded inside the SoC... you just write separate programs for them
<zmatt>
(typically in assembly if you care about performance or deterministic timing)
<Guest42>
Hm ok I actually dont know assembly so that's going to be interesting. C an option or not so much
agrue has joined #beagle
<Guest42>
I guess a better question to ask is where are you finding the documentation for this stuff xD I am googling but just finding youtube videos that arent totally relevant
<zmatt>
there is a C/C++ compiler for PRU, but of course you lose the benefits granted by the deterministic instruction timing, and the code output of the compiler is pretty bad, in part because PRU's instruction set was designed for manually writing code in assembly and is quite poorly suited for targeted by a C compiler
<zmatt>
I'm not sure what the best way is to get into all this stuff, since I've been involved with this stuff for so many years that I have no idea anymore where I picked up what info
<agrue>
I actually stumbled on some docs the other day....
<Guest42>
yeah i hear you man, everything is being rolled into higher- and higher-level apis that its becoming difficult to go back and pick up the low-level stuff sometimes
<Guest42>
just hard to find documentation and discussion around it some day s
<zmatt>
I know PRU quite well, I've actually made a python library that can interact with PRU (including loading code, mapping shared memory, and even debugging the PRU core)
<zmatt>
Guest42: yeah the AI stuff (e.g. TIDL) seems to be layers upon layers upon layers, and annoyingly there doesn't even seem to be low-level documentation available for the C7x DSP
<agrue>
sorry if I'm misinterpreting - does BB refer to them as PRU and TI refer to them as MCU?
<zmatt>
agrue: TI refers to the PRU as PRU
<zmatt>
the only context in which I've seen TI use "MCU" is the MCU island of the TDA4VM and various other SoCs, which is a section of the SoC that can be isolated from the rest of the SoC for safety-critical applications
<zmatt>
the PRUSS instances are not part of that island on the TDA4VM
<agrue>
Oh thanks, I'm not super familiar with this and was just trying to reconcile the ai64's feature list with the TDA4VM's page
<zmatt>
the TDA4VM MCU island uses a dual-core ARM Cortex-R5F processor
<Guest42>
is there any sort of roadmap of how long some of the beagleboards plan to be supported
<zmatt>
Guest42: generally speaking, for as long as the components are available
<Guest42>
I think it is a very interesting project with some noble goals, I feel technology is becoming too commoditized and hidden behind APIs but a project like this tries to bring that tech back to people in its entirety. I respect that a lot and it makes me want to participate. Not going to lie though I feel there is more of a learning curve with these
<Guest42>
boards than some other SBCs (admittedly the other SBCs contain less functionality which keeps them more simple). Debating if I am brave enough to jump in lol
<zmatt>
there's no doubt a bigger learning curve.. and unfortunately beagleboard.org doesn't have the sort of resources that e.g. the raspberry pi foundation has to put into educational resources
<zmatt>
otoh, I would never want to embed an rpi into a product, or any other board that uses a SoC that you can't buy, has no substantial public documentation, and doesn't even have a product page on the manufacturer's website :P
<Guest42>
yeah that is how I feel about rpi
<Guest42>
they are shockingly less open than I initially thought.
<Guest42>
a big motivation for me right now is I am trying to pick up tech I can transfer the skills over to my kid and help him have some projects to learn from. there is no sense in teaching him proprietary packages that no knowledge can transfer over to another stack. this new generation is really gifted in some aspects of technology but other
<Guest42>
foundational stuff is so obfuscated they never get exposure
<zmatt>
you know what I also find a good indicator? how easy it is to find the errata of a chip, since you know any chip of this complexity has plenty of 'em... for the rpi stuff, I think there's some collected on a wiki page by volunteers. For TI, it's the second prominent link on the product page, immediately below the datasheet link: https://www.ti.com/product/TDA4VM
vagrantc has joined #beagle
<zmatt>
I think PRU is a very nice processor for learning assembly btw... it's a very clean 32-bit RISC architecture, the instruction set is small and simple enough to easily fit in one's head
<Guest42>
I have never tried to learn assembly. Always figured it was too low level for me so never gave it a chance
<Guest42>
the servos I have used so far have been things like Dynamixel if you are familiar with them, they are pretty low-power/low-torque but they come with a very easy to use API to control the server
<Guest42>
servo*
<Guest42>
Im taking a look at the beagleboard projects on adafruit now some are decent but none really seem to touch on the PRU
<zmatt>
Guest42: and my py-uio library (not supported on the AI-64 yet) allows one to directly fiddle with the PRU and see what it's doing, even interactively using the python REPL. for example this bit of python code sets register r0 to 123, then runs this program on the PRU core https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/test.pasm which just adds 1 to r0 and then halts, so the python ...
<zmatt>
...script will show "r0 = 124" after the core has halted
<Guest42>
zmatt just curious are you a lead on the project or just community member? seem to have a lot of knowledge about the boards
<Guest42>
i hope you can port it to AI-64 >_>
<Guest42>
lmao
<zmatt>
I expect porting it to the AI-64 should be somewhere betweene easy and trivial
<zmatt>
but I don't have an AI-64 to test on yet
<zmatt>
like, I suspect the uio-pruss driver and py-uio will work just fine on the TDA4VM, with all that's needed is a small device-tree fragment
<zmatt>
(alternatively, the uio-pdrv-genirq driver could be used but that would require some changes in py-uio to support interrupt handling)
<zmatt>
rcn-ee: does the kernel for the ai64 include uio-pruss and/or uio-pdrv-genirq currently?
<zmatt>
Guest42: also, no I'm not part of beagleboard.org, I'm just a community member
<rcn-ee>
zmatt: uio on the ai64... i guess we can try patch... ;)
<Guest42>
Well zmatt youre super helpful in either case so tyvm
<rcn-ee>
try that patch...
<zmatt>
rcn-ee: imho it's still the superior way of using PRU... fuck remoteproc and especially rpmsg :D
<Guest42>
if any other noobs come in, this webpage has been helpful in understanding what others are doing and what's possible just fyi https://beagleboard.org/p?sort=published
<rcn-ee>
zmatt: well the uio patch is enabled...
<zmatt>
nice, I'll take a look at the DT side
<rcn-ee>
and set CONFIG_UIO=m CONFIG_UIO_PDRV_GENIRQ=m
<zmatt>
honestly, the driver is so simple and stupid... unless there's some weird prcm-detail that gets in the way, I suspect it'll work just fine
<zmatt>
except for external memory access by pru, like I said, since config is needed to translate from PRU's 32-bit address space to the external 48-bit address space
<zmatt>
but that's py-uio's problem to deal with
agrue has quit [Ping timeout: 252 seconds]
waldo323 has joined #beagle
agrue has joined #beagle
<Guest42>
any rumors on beagleboard risc-v anytime soon
<Guest42>
so the hardware will be completely open aside from the cpu?
<rcn-ee>
Guest42: 'aside from the cpu' ? huh...
<zmatt>
FSF loves to complain, but blobs for hardware peripherals are not that problematic anyway.. especially if you consider that FSF apparently doesn't have a problem when that blob is hardcoded into the peripheral device, even though the overall result is the same except now you can't fix bugs :P
<rcn-ee>
most of FSF's complaints have been updated in the last 5 years..
<rcn-ee>
'have not been'....
<Guest42>
arm isnt open is what i mean
<rcn-ee>
Guest42: well if 'arm' isn't open, nothing is open on this board...
<rcn-ee>
Guest42: if you want open, grab and fpga and do a 'risc-v' that's 'open'...
<rcn-ee>
Guest42: what do you mean by 'open'... everything has source, everything can be built, there is no 'blob' that stops you..
<Guest42>
i just mean the arm license
<zmatt>
Guest42: are you planning on making your own SoCs? :P
<rcn-ee>
Guest42: TI still paid a license for the SGX, and everything else... 'arm license' ... nothing is free..
<Guest42>
ahahah not at all but it would be neat to see a risc-v variant out. the problem is it will be much slower but for a hobby it would be cool
<Guest42>
true
<rcn-ee>
Guest42: why would it be slower? just pay more for 5nm process.. ;)
<rcn-ee>
slower = how much $ your willing to put behind it..
<zmatt>
as neat as a fully open SoC design would be, I don't see much practical benefit given the enormous costs involved with making use of the rights such a design would theoretically give you
<rcn-ee>
and... arm has 20 years of software 'hacks' / optimizations... it'll take risc-v a few years to catch up to those man hours..
<zmatt>
I don't quite get where it's coming from... the test you did shows it's not the result of accessing the ddr memory from python... it does make sense for pru to crash, but then how on earth would that cause a bus error on the python side
<zmatt>
mysterious
<zmatt>
anyway, pretty cool that apart from ddr access it Just Works
<rcn-ee>
yeah, it's really cool!
<rcn-ee>
also added py-uio to the default install on arm64..
<rcn-ee>
: /opt/source/py-uio/
Guest78 has joined #beagle
<zmatt>
sweet
<zmatt>
I wonder if it's coincidence that uio-pruss allocated ram at a physical address below 4G (i.e. one that fits in 32 bits) or if that's guaranteed due to the way it allocates it
<zmatt>
if it's something I can rely on then I can just setup RAT to be a flat mapping for the low 4G of physical address space
lucas_ has joined #beagle
lucascastro has quit [Read error: Connection reset by peer]
<zmatt>
hmm, it seems RAT defaults to a flat mapping... so I guess whatever is the problem is not that simple
lucas_ is now known as lucascastro
lucascastro has quit [Quit: Leaving]
lucascastro has joined #beagle
lucascastro has quit [Remote host closed the connection]
Guest78 has quit [Quit: Client closed]
otisolsen70 has quit [Quit: Leaving]
agrue has quit [Quit: Client closed]
demirok has quit [Ping timeout: 240 seconds]
otisolsen70 has joined #beagle
Guest42 has quit [Quit: Client closed]
mattb0ne has joined #beagle
mattb00ne has joined #beagle
otisolsen70 has quit [Quit: Leaving]
amir36 has joined #beagle
<amir36>
Hi friends, first question, is there a way to see the chat history when we log in every time? is it possible to create an account ? Sometimes I get disconnected and lose everything. I'm new so please guide me.
<amir36>
the second question, has anyone done RTOS or NO RTOS (bare-metal) programming on BBAI ? have you used CCS from TI? if anyone has experience with this, I'll appreciate it if they can offer some guidance or if we can chat offline if you prefer. I'm working on a cool project and for the first part, I need to be able to do bare-metal programming on
<amir36>
am5729 (BBAI). I think if you have experience with a different TI chip that still could apply. Let me know if you're interested in collaborating with me and we can get connected.
<amir36>
thanks zmatt
<zmatt>
also, if you use a proper irc client instead of the web client, it should reconnect automatically and also keep your scrollback so you'd only miss messages during the brief window of time it's reconnecting
<zmatt>
I've done a little baremetal experimentation on the BBB, not the BBAI though
<amir36>
did you use TI CCS ? or their sdk (pdk) ?
<zmatt>
no
<zmatt>
TI's "SDK" for baremetal dev on the AM335x (called "StarterWare") is a steaming pile of pig manure
<amir36>
why ? is that provided by beagle board or ti ?
<jkridner>
StarterWare was provided by TI originally, but they dropped it.
<zmatt>
I mean, it's still on their site
<amir36>
does anyone have experience with am572x sdk ?
<jkridner>
zmatt: what do you recommend for bare metal programming? personally, I point people to u-boot SPL.
<zmatt>
jkridner: on the am335x? dunno, my own experimentation was purely with my own code, in part based on my previous experience with the dm814x
<amir36>
u-boot is too complicated isn't it ? it's kinda of a kernel itself
<jkridner>
kinda, but much easier to grok than linux.
<zmatt>
it's not a kernel, but it's definitely very bloated
<jkridner>
stays single threaded.
<jkridner>
you can build a small thing though and only pay attention to a small number of files.
<jkridner>
I kinda wish someone did a Zephyr target.
<jkridner>
anyway, not as simple as a entry vector into libc main. I'd be interested if someone did that.
<jkridner>
getting the linker flags right is big.
<amir36>
we need more people do bare-metal
<amir36>
tired of linux on every SBC, oh buy this then run linux out of the box now you're a programmer.
<zmatt>
maybe I should look into making the baremetal C++ codebase I have for the AM335x public, but I'm not sure how useful it would be
<amir36>
that's definitely useful. I purchased a evm based on am335 today we can collaborate if you want.
<amir36>
do you have device driver for all peripherals ?
<zmatt>
definite no
<jkridner>
minix is also an interesting code base for AM335x.
<zmatt>
what I have is _very_ basic, it's really just some small tests and primarily as a learning project
<amir36>
what's minix ? jkridner
<zmatt>
basic setup of the cortex-A8 (incl MMU and caches), some PLL/clock configuration, uart console, interrupt/fault handling, i2c, gpio
<zmatt>
I also have some ugly unfinished emmc code (performs initialization and reads the ECSD), and unfinished EMIF initialization code
<zmatt>
so yeah, rather minimal
<amir36>
I think it'd be great if you could release your code with some basic documentation.
<amir36>
I'm honestly amazed why no one has used TI SDK to write some bare metal on a custom board (and not documented) it.
<zmatt>
it's also written in a fairly eccentric style of C++, you can see that style in this codebase: https://github.com/dutchanddutch/jbang .. the headers in include/ in that project are actually from my baremetal codebase
<zmatt>
(and it doesn't link to any libc hence doesn't use dynamic memory allocation)
amir36 has quit [Quit: Client closed]
brook has quit [Remote host closed the connection]
amir36 has joined #beagle
<amir36>
is there a way to get connected to people who designed BBAI ? both hardware and their version of linux ?
<amir36>
do you think it's done on Beagle board or is it more internal to TI ? because they seem to have connections.
<zmatt>
?
<amir36>
I mean people who have written drivers for linux certainly know bare-metal
ikarso has quit [Quit: Connection closed for inactivity]
<amir36>
I don't know if beagle board as an organization does the design/programming or is the design done in texas instrument
<zmatt>
rcn-ee: found the cause of the bus error: all of the memory regions are mapped as device memory, and apparently on arm64 doing memset() on device memory will crash
<Guest42>
are any beagleboards not manufactured by seeeed by any chance