nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
vagrantc has quit [Quit: leaving]
argonautx has quit [Quit: Leaving]
vagrantc has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
<zmatt> ok, good to know... if hdmi is enabled on the bbb (which is the factory default) but no hdmi is attached then the lcdc pins remain in lcdc's reset state, which is: P8.27 driven high, P8.28-30 driven low, P8.31-46 high-impedance
hays has joined #beagle
<hays> hey is there any channel good to ask about more general stuff, say the espressobin ultra? Im having a really vexing problem building u-boot
<hays> atf-ntim.txt is some file that's missing. anyways i know im off topic but just trying to get a decent lead on this
<set_> Hello...I do not know much about uboot but I saw a digikey setup of building uboot.
<set_> Let me see if I can get the link. This may be useful or not. Please hold.
<zmatt> hays: I mean, this isn't really the best place for asking about some random board based on some undocumented Marvell SoC no
<vagrantc> hays: there are often different channels for different board communities ... i'd guess that to be #marvell(if it exists)
<zmatt> vagrantc: lol, doubtful
<set_> BBB!
<set_> Oh. It is for another board.
<set_> Sorry.
<hays> zmatt: yeah, that's what im working from.
<zmatt> hays: it looks like atf-ntim.txt is an intermediate build output
<zmatt> hays: you can see it in the build directory listing they're showing on that page
<hays> yeah, but for some reason its not being created
<zmatt> hays: try their forums?
<hays> thanks for looking at it. was hopihg it might be something obvious to someone with more experience
<zmatt> I'm not familiar with ATF no
<vagrantc> hays: i'm more familiar, but marvell's build process is ... painful.
<zmatt> and atf-ntim.txt appears specific to marvell armada
<zmatt> hays: I suggest grepping the source tree to find the makefile that is supposed to produce it, and from there try to figure out why it isn't doing so
<hays> heh. yeah let me keep grepping.. i've been grepping
<hays> ill get more fancy with it
<zmatt> I mean, it's in the top-level makefile of the atf-marvell source tree
_outrageous has joined #beagle
outrageous has quit [Ping timeout: 256 seconds]
<hays> zmatt: yep i found it and fixed it
<hays> thanks for the help
_outrageous has quit [Ping timeout: 240 seconds]
outrageous has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
vagrantc has quit [Ping timeout: 240 seconds]
starblue has joined #beagle
CrazyEddy has quit [Ping timeout: 240 seconds]
CrazyEddy has joined #beagle
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #beagle
starblue has quit [Ping timeout: 256 seconds]
vigneshr has quit [Quit: Connection closed for inactivity]
starblue has joined #beagle
starblue has quit [Ping timeout: 256 seconds]
<set_> Is anyone using the librobotcontrol library currently (or w/ past knowledge) w/ making the BBBlue fly? Where does the receiver fit in w/ PRU attachment? Where does the UART/DSM port on the BBBlue go into on the receiver?
<set_> This darn receiver is a "DSM" receiver and has the JST-ZH, three-pin connectors on it. Does anything, anything, from the BBBlue get attached to the receiver in the form of JST-ZH connections?
<zmatt> what receiver? (part number)
<set_> OrangeRX R820X V2
<set_> Forget it. Something is wrong w/ the BBBlue now. It will not boot when I put USB to the computer from the BBBlue. Boo!
<zmatt> cppm or sbus version?
<set_> No clue. It does not say.
<zmatt> it looks like it doesn't output the protocol for which the dsm2 connector is intended... basically, this thing both receives the signal and converts/splits it, while the dsm2 connector is for simpler devices that merely receive the signal (e.g. OrangeRx R110XL)... such receivers can also plug into the "sat 1"/"sat 2" ports of your R820X, which is why those are the same connectors as the dsm2 port on ...
<zmatt> ...the blue
<set_> I just killed off two BBBlue boards. Dang it.
<zmatt> maybe you should stop doing that
<set_> Right!
<set_> WHelp, time to reflash.
<set_> Who knows? It could be something faulty. Maybe they are not fried yet.
<set_> Anyway...
<set_> @zmatt: Thank you for the R110XL mention. I will look into it.
<set_> WHelp, new image and no power. This cannot be good.
<zmatt> what did you do?
<set_> I plugged in the BBBlue into the USB port on the host.
<zmatt> I mean, what did you do to fry it?
<set_> It showed no power. I reflashed and then...oh.
<zmatt> how did you reflash it if it "showed no power" ?
<set_> I plugged in the PRU to Signal on the Receiver.
<set_> No LEDs lit up at all on one board. The second board is powered now via usb. phew.
<zmatt> please say words that actually describe what you did
<zmatt> you can't plug anything into "PRU", you can only plug things into connectors that exist on the bbblue
<set_> I made a cable.
<zmatt> and the receiver has a whole bunch of possible of connections
<zmatt> from what to what?
<set_> JST-SH (pru BBBlue) to single wire to female connector for Receiver. The female connector was a single wire w/ a female end on it.
<set_> It fits on the Eight Pin header on the Receiver, i.e. Signal.
<set_> I think that the Eight Pin Header on the Receiver is signal but at 5v.
<zmatt> I also don't understand why you were doing that in the first place, since librobotcontrol doesn't seem to have support for that protocol (unlike ardupilot)
<zmatt> but yes, if that's a 5v signal (which you should have checked) then it's quite likely you fried the beaglebone
<set_> I tried ardupilot. I got upset three years ago w/out support. When I asked for support, one "head honcho" stated they would flag me as SPAM. I grew furious. I just moved on.
<zmatt> lol
<set_> I know. he must have powers on the forums.
<set_> Blah.
<zmatt> not everything is going to have the level of patience with you that I often show you
<zmatt> *not everyone
<set_> Everyone/Everything...Blah. I did not post for two years and then I came back made two posts. SPAM is set_. Ya, ya. All day. Blah.
<set_> I understand you have patience w/ technical stuff. I am thankful.
<set_> Two years and two posts and I am spam. That is garbage.
<set_> And...
<zmatt> I mean, it depends a bit on what you posted :P
<set_> They stopped servicing the BBBlue. I mean, they will not have support for it any longer.
<set_> They are heading towards STm chips for people to make their own distros of ArduPilo.
<zmatt> number two in the list
<set_> I see it. If you scroll down on that link and click a link, you end up here:
<set_> Let me get the link real quickly that states what I am discussing.
ark has joined #beagle
<set_> Hmm. See. He removed his posts that were against me and my wants involving the Build on the BBBlue and blah, blah, blah.
<set_> Now, I am making things up. Argh!
<set_> Anyway, I tried w/ ardupilot. Chatted w/ a bunch of "people" and got nowhere.
<set_> It was a time. The time was interrupted by things not working well for me.
<set_> The only time ardupilot worked for me was when I pushed the mode button on the BBBlue and had librobotcontrol work!
<set_> @zmatt: Anyway, let me get ready for this glorious day. I get to play in dirt again! Yay and yah!
<set_> So, dumbing it down is what I do. You are patient w/ this fact but I have to play this way or I get ramshafted into doing less than dirt work, i.e. if that is possible.
<set_> no sleep and ramshaft dirt work here I come!
set_ has quit [Remote host closed the connection]
Guest95 has joined #beagle
<Guest95> hi
<Guest95> i have problem
<Guest95> i set setenv serverip
<Guest95> and setenv ipaddr
<Guest95> i can ping the server from u-boot
<Guest95> but the server can't ping beaglebone
<Guest95> so what should i do
<Guest95> ?
<Guest95> ?
<Guest95> ?
<Guest95> ?
ark has quit [Ping timeout: 256 seconds]
<Guest95> ?
<hnv>  what commands are you using? at both ends
Guest95 has quit [Ping timeout: 256 seconds]
hnv has quit [Quit: Client closed]
<zmatt> I don't think u-boot is pingable
<zmatt> I don't think it even acquire an ip address until it actually attempts to do the tftp boot
<zmatt> I could be wrong
ikarso has joined #beagle
hnv has joined #beagle
<zmatt> hmm, maybe I spoke too soon, looks like it ought to be pingable once network is up
<zmatt> oh he left anyway
Guest95 has joined #beagle
CrazyEddy has quit [Ping timeout: 240 seconds]
Guest95 has quit [Quit: Client closed]
lucascastro has quit [Ping timeout: 240 seconds]
hnv has quit [Quit: Client closed]
hnv has joined #beagle
lucascastro has joined #beagle
russ has quit [Ping timeout: 250 seconds]
starblue has joined #beagle
russ has joined #beagle
rcn-ee has quit [Quit: Leaving]
<zmatt> you know, when a feature is added to a peripheral or subsystem I think you can usually take a decent guess why it was deemed a useful thing to add
<zmatt> ... but I'm really having a lot of trouble with coming up with any ideas why on earth in PRUSS IEP (a timer/capture peripheral or sorts) they added a read-only view to the capture timestamp registers which... bit-reverses every byte
rcn-ee has joined #beagle
hnv has quit [Quit: Client closed]
hnv has joined #beagle
nmingotti has joined #beagle
lucascastro has quit [Ping timeout: 256 seconds]
vagrantc has joined #beagle
<nmingotti> hi guys, quick question, i would like one of my systemd service not to start untill /dev/pwm/ehrpwm1a is present. I pretty sure the way to do it is ENV{SYSTEMD_WANTS}="powersaving.service" in udev, but i don't know in which file i do need to uperate. any suggestion
<nmingotti> i am running in BB-AI, pwm is loaded by this in uEnv: uboot_overlay_addr1=/boot/dtbs/4.19.94-ti-r70/overlays/BONE-PWM2.dtbo
<nmingotti> ok forget the string "pwersaving.service" this is just a string that remained there
<zmatt> there are two ways to do that actually, you can indeed have an udev rule request your system service to be started, or alternative you can add a dependency on the device in your system service file
<nmingotti> better the second, so i keep the config in just one file. Let me see googling .... because i think i tried that another time and it did not work
<zmatt> hmm, looks like the device doesn't get tagged by default, so a bit of udev will be needed regardless
<zmatt> hold on, let me test something
ikarso has quit [Quit: Connection closed for inactivity]
<nmingotti> okis ! thanks zmatt
<zmatt> nmingotti: this makes each pwm visible as a systemd unit, e.g. "dev-pwm-ehrpwm1a.device", on which you can add a dependency
<nmingotti> cool ! thank you again, let me study it and make some test :)
<zmatt> I don't quite know how systemd handles that, since it can't know in advance that such a device will even appear, but iirc it does in fact work... hopefully I don't misremember
<nmingotti> systemd for me is black magic, i never had time to dig into how it works. it is very useful, i use it, but really: blackbox
<zmatt> yeah, this is the magic: "devices are exposed in systemd as .device units. They exist primarily to order stuff properly at boot, for example so that we can fsck/mount a block device only after it has shown up. As such device units are primarily useful as a synchronization concept: you enqueue a job for a device which isn't around yet, and the job will succeed as soon as it shows up"
<zmatt> so adding Wants=dev-pwm-ehrpwm1a.device and After=dev-pwm-ehrpwm1a.device will create a start-job for dev-pwm-ehrpwm1a.device (unless one is already in progress) and orders the start of your service after it
<zmatt> even though systemd doesn't know anything about that device yet, it allows this anyway and the job will sit in the queue until either 1. udev discovers the device and tells systemd to create the actual device unit (which completes the start job) or 2. the start job times out
<zmatt> that's not *that* magical I think
<zmatt> or at least, it's exactly the right amount of magical to make device units actually useful ;)
<nmingotti> thank you for the description ;) I mean when i was using cron, rc.local and init scripts it was all much easier to understand. Now it is more powerful, but also considerably more complex. And the feeling, to be honest, at time, is that i don't have full control of the machine. Since once I had to write code, to write the logic, not i have to write
<nmingotti> declarative configurations. well ... it works well, so i will not complain much ;)
<zmatt> I honestly didn't find the old pile of shell scripts much clearer
<zmatt> I mean, I don't see the distinction you're making... even sysv init scripts had some declarative syntax for the purpose of declaring dependencies, it was just really crude
<zmatt> it's also kinda like a makefile
<zmatt> though it does have a rather large amount of options, which is great if you need those specific pieces of functionality, but it can definitely be overwhelming
<zmatt> btw, if you ever get confused by what's happening, don't forget you can change the log level of systemd on the fly (and also at boot time using a kernel cmdline parameter) to see in more detail what it's doing e.g. with job management
<nmingotti> about 15 years ago we were using mostly rc.local to config servers, it was really easy and we knew for sure the order in which things will happen. Of course, this was useful for servers since the bootup time is mostly irrelevant. But for a phone or a multimeter the bootup phase must be quick, so, our simple approach is really unfit. But as i said,
<nmingotti> i don't dislike the new system.
<nmingotti> config the boot process, of course
<nmingotti> and it was working mostly cross platform, i remember we had serveral Debian, ScientificLinux, FreeBSD and OpenBSD
<nmingotti> ok, i will look into che kernel parameter for systemd log details, seems interesting
nmingotti has quit [Quit: Client closed]
<zmatt> systemd.log_level=debug
<zmatt> hmm, current systemd also has "systemctl log-level" to get/set systemd's loglevel, but it appears the systemd on debian buster is too old to have that
<zmatt> but you can send systemd SIGRTMIN+22 to change its loglevel to debug and SIGRTMIN+23 to restore the loglevel to its configured value
<zmatt> e.g. sudo kill -RTMIN+22 1
<hnv> those udev rules show up doing systemd-analyze?
<zmatt> all units show up in systemd-analyze
lucascastro has joined #beagle
CrazyEddy has joined #beagle
nmingotti has joined #beagle
<nmingotti> hey zmatt, i got it working, finally the fan cape turn on only when temperature is > 75 and shuts down most of the time. The service start happily at boot with systemd, so finally my problem with the FanCape is solved :) without your assistance this would have been impossible, thanks again
<nmingotti> the BB-AI is now silent, i can happily work near it and i don't risk it shuts down for overheating (it was happening often)