linkliu59 has quit [Remote host closed the connection]
linkliu59 has joined #beagle
set_ has quit [Quit: I thought I saw a puddy-cat...]
argonautx has joined #beagle
charlie5 has quit [Read error: Connection reset by peer]
charlie5 has joined #beagle
set_ has joined #beagle
charlie5 has quit [Quit: Leaving.]
<jduchniewicz>
what are you trying to do set_ ?
<set_>
Update my computer...
<set_>
Oh. You mean w/ the reading and writing files?
<set_>
I was going to update the cloud9-examples list of source files.
<set_>
But...I was advised against it.
javaJake_ has joined #beagle
javaJake has quit [Ping timeout: 250 seconds]
javaJake_ is now known as javaJake
<jduchniewicz>
why would want to update them?
<jduchniewicz>
making them work (with more recent language version) is a good idea
<jduchniewicz>
but I am no expert on js :)
<jduchniewicz>
with C++ I usually try to keep the SW up-to-date with the newest standard
<jduchniewicz>
I judge that with js not many things get obsoleted
florian has joined #beagle
<set_>
Oh.
<set_>
I am not a good worker w/ .js files either.
<set_>
I am just learnin' again.
<set_>
I am spending time learning about music and then learning js to update the older scripts.
<set_>
But...
<set_>
I guess people are updating them constantly.
javaJake_ has joined #beagle
javaJake has quit [Ping timeout: 252 seconds]
javaJake_ is now known as javaJake
LetoThe2nd has joined #beagle
charlie5 has joined #beagle
Guest3553 has quit [Quit: Client closed]
zmatt has quit [Ping timeout: 240 seconds]
zmatt has joined #beagle
Shadyman has quit [Quit: Leaving.]
Guest3553 has joined #beagle
LetoThe2nd has quit [Quit: Connection closed for inactivity]
buckket has quit [Quit: buckket]
buckket has joined #beagle
rob_w has quit [Quit: Leaving]
Guest355358 has joined #beagle
Guest3553 has quit [Ping timeout: 246 seconds]
buzzmarshall has joined #beagle
Guest355358 has quit [Quit: Client closed]
argonautx has quit [Quit: Leaving]
ikarso has joined #beagle
florian has quit [Quit: Ex-Chat]
samael has quit [Ping timeout: 258 seconds]
mattb0ne has joined #beagle
mattb0ne has quit [Ping timeout: 250 seconds]
bradfa has quit []
mattb0ne has joined #beagle
mastermind_ has joined #beagle
mastermind_ is now known as mabb0ne
starblue has quit [Ping timeout: 258 seconds]
starblue has joined #beagle
LetoThe2nd has joined #beagle
Gigi95 has joined #beagle
<Gigi95>
Hello, I have a question. where can I buy a JTAG adapter or header piece for my beagleBone Black?
Gigi95 has quit [Ping timeout: 246 seconds]
Gigi95 has joined #beagle
Gigi95 has quit [Ping timeout: 246 seconds]
GenTooMan has quit [Ping timeout: 252 seconds]
GenTooMan has joined #beagle
<buzzmarshall>
i found a pin header at digikey what you can solder to the bbb vacant pads to create the connection on the board. FTR-110-03-G-D-06 was the digikey part number
<buzzmarshall>
or you can just solder your own pins depending on what you want to do
thinkfat has joined #beagle
thinkfat has quit [Ping timeout: 258 seconds]
<zmatt>
a better question would be why they'd want to
ikarso has quit [Quit: Connection closed for inactivity]
vagrantc has joined #beagle
<mabb0ne>
for debuggin the pru
<mabb0ne>
maybe
<mabb0ne>
i saw some product that did that
<mabb0ne>
jtag or something
<zmatt>
it's kind of absurd that TI hasn't made a debugserver for pru that runs on linux... like, it really wouldn't be particularly hard. debugging PRU is done via memory-mapped registers, instead of accessing those registers via JTAG they could just forward those accesses via a TCP socket to a process on the target system that performs those same accesses on the debugger's behalf
<zmatt>
there's absolutely no reason to use JTAG for this
<zmatt>
I wonder how hard it would be to make such a daemon that supports the gdb remote protocol
LetoThe2nd has quit [Quit: Connection closed for inactivity]
yCrazyEdd has quit [Ping timeout: 240 seconds]
yCrazyEdd has joined #beagle
mattb0ne has quit [Quit: Leaving]
akaWolf has quit [Ping timeout: 240 seconds]
<buzzmarshall>
jtag something most around here wouldnt use, but if one really wants to work with the onboard hardware at register level and core level jtag is a good method
<buzzmarshall>
or if someones trying to hack proprietary stuff of the board boundary scan is just easier to snoop on things
<buzzmarshall>
example would be the other typical amlogic, rockchip and others that don't release much in the way of bsp sources and info
<buzzmarshall>
you can build your own soc model and use something like jtag to take better quesses at missing information
<buzzmarshall>
or keys
<buzzmarshall>
or in some cases bypass the trusted platform code
<buzzmarshall>
i do wafer inspection and reverse engineering of some things mostly now as a hobby but jtag is a good tool
<buzzmarshall>
the other day i seen someone here that was a avr guy asking bout jtag and bbb and not get anywhere as like i said most here its not something typical to the beagles at this level for hobbiest
<buzzmarshall>
but cause he came from a avr based where working in assembly and using things like jtag are the real support originally offered by atmel back then
<buzzmarshall>
thats probably why he was taking it for granted it was a thing here as well
<buzzmarshall>
even now tho most avr'ers stick with the higher level dev tools and get lost with working at register level
<zmatt>
what do you mean by "hack proprietary stuff of the board" ?
<zmatt>
like, using boundary scan seems the slowest and most inconvenient way available to control pins :P (and probably the most hazardous)
<buzzmarshall>
say i wanted to figure out something not published like the proprieatary gpu's
<zmatt>
then boundary scan would be absolutely useless
<buzzmarshall>
which is still a big issue with most of these socs tho open source is getting better
<zmatt>
since the "boundary" it scans is the SoC boundary
<buzzmarshall>
it checks any of the nets in the design
<zmatt>
no it doesn't
<buzzmarshall>
being everything is mostly cores these days
<zmatt>
there are internal boundary scan chains, but the mechanism to access those is unknown and undocumented, and may not even be usable in production parts
<buzzmarshall>
if you can scan the nets to see how things move it makes it easier to guess where something sit
<buzzmarshall>
not true
<zmatt>
the normal boundary scan chain available is just the external SoC pins
<buzzmarshall>
it just means you need to do alot of research into what your playing with
<zmatt>
go check the bsdl file
<buzzmarshall>
boundaryscan will scan whatever your software is built to do as long as theres a net some place
<buzzmarshall>
even internal to the soc they exist , it just means you might need to decap something and look at it under a scope
<zmatt>
... that's not exactly boundary scan anymore :P
<buzzmarshall>
ya its more then just that your right
<zmatt>
boundary scan, via jtag, using the documented jtag boundary scan commands, will not get you anything of the internals on these SoCs
<zmatt>
there's like a few dozen undocumented bits in the scan chain
<buzzmarshall>
but for the sake of here with that atmel guy thats probaly why he askes as for a low level programmer on the avr stuff it was easier to create precise timing for something because you can verify and adjust the code almost live
<zmatt>
?
<buzzmarshall>
alot of people have come to depend on the higher level ide's using things like c or python which is cool
akaWolf has joined #beagle
<buzzmarshall>
but if i needed a almost exactly timed loop i wouldn't use any of that as i would write them in assembly to elimanate any latency's in the higher level routines
<buzzmarshall>
having jtag running lets me work at register level
<zmatt>
on the cortex-a8 you'll have a very hard time writing any exactly timed loop, even in assembly
<buzzmarshall>
one of the biggest advantages of the original avr's over most other back then was its predictable instruction set with most taking 1 clock
<zmatt>
that's exactly why PRU is awesome
<buzzmarshall>
where as a princeton or some other chip takes a much wider range which makes it hard to make precise timed things
<buzzmarshall>
yea i agree
<zmatt>
you sure btw? iirc at least indirect branches are 2 cycles
<zmatt>
on avr
<buzzmarshall>
actually your right its mostly 2 with a few at 4
<buzzmarshall>
i migrated to avrs years ago when atmel brought them out as they made great cores to build a glitcher around
<zmatt>
like iirc there's still 2 pipeline stages in avr, which shows itself when doing an unpredictable branch (e.g. an indirect branch) ... being truly unpipelined like PRU (whose indirect and conditional branches are genuinely just 1 cycle) is very rare
<buzzmarshall>
glitchers require very controlled output on a couple of things and the atmel was good for that
<zmatt>
anyway, back to topic, if someone answers they intend to try doing baremetal development on a beaglebone then sure that's a perfectly valid reason to want to get JTAG working
<buzzmarshall>
normally the only single one i ever came across was doing something in your own cpld or fpga
<buzzmarshall>
i would agree thats kinda why i said i dont really see it being used around here on the beagles
<zmatt>
hence why, when someone asks about JTAG, I'd ask why they're asking since the probability that they're confused about what they want is bigger than the probability they actually need it for what they intend to do
<buzzmarshall>
with all the existing support for here theres really no need for it
<buzzmarshall>
i agree i think he was just new to the bbb and thinking in terms of avr
<buzzmarshall>
which i can see as the bbb software trys to make the bbb act like a duino
<buzzmarshall>
lol
<buzzmarshall>
thats why i removed all that stuff
<buzzmarshall>
jtag nowadays isnt really used that much unless its needed as support for what most people are trying to do with most of these embedded devices is mostly pretty good
<zmatt>
oh it totally was the same person to whom I talked 3 days ago