01:33 <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

03:19 <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

03:24 <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

03:30 <set_> Hello...I do not know much about uboot but I saw a digikey setup of building uboot.

03:31 <set_> Let me see if I can get the link. This may be useful or not. Please hold.

03:32 <zmatt> hays: I mean, this isn't really the best place for asking about some random board based on some undocumented Marvell SoC no

03:32 <vagrantc> hays: there are often different channels for different board communities ... i'd guess that to be #marvell(if it exists)

03:32 <zmatt> vagrantc: lol, doubtful

03:32 <set_> Here: https://forum.digikey.com/t/debian-getting-started-with-the-beaglebone-black/12967#bootloader-u-boot-5 <<< it is older but can be useful?

03:32 <set_> BBB!

03:33 <zmatt> hays: have you checked http://wiki.espressobin.net/tiki-index.php?page=Build+From+Source+-+Bootloader

03:33 <set_> Oh. It is for another board.

03:33 <set_> Sorry.

03:35 <hays> zmatt: yeah, that's what im working from.

03:36 <zmatt> hays: it looks like atf-ntim.txt is an intermediate build output

03:36 <zmatt> hays: you can see it in the build directory listing they're showing on that page

03:37 <hays> yeah, but for some reason its not being created

03:38 <zmatt> hays: try their forums? http://espressobin.net/forums/

03:38 <hays> https://github.com/globalscaletechnologies/A3700-utils-marvell/blob/A3700_utils-armada-18.12.0-gti/script/buildtim.sh this is the build script i believe

03:39 <hays> thanks for looking at it. was hopihg it might be something obvious to someone with more experience

03:39 <zmatt> I'm not familiar with ATF no

03:40 <vagrantc> hays: i'm more familiar, but marvell's build process is ... painful.

03:40 <zmatt> and atf-ntim.txt appears specific to marvell armada

03:41 <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

03:42 <hays> heh. yeah let me keep grepping.. i've been grepping

03:42 <hays> ill get more fancy with it

03:45 <zmatt> I mean, it's in the top-level makefile of the atf-marvell source tree

04:53 <hays> zmatt: yep i found it and fixed it

04:53 <hays> thanks for the help

10:17 <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?

10:26 <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?

11:23 <zmatt> what receiver? (part number)

11:24 <set_> OrangeRX R820X V2

11:25 <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!

11:32 <zmatt> cppm or sbus version?

11:32 <set_> No clue. It does not say.

11:39 <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 ...

11:39 <zmatt> ...the blue

11:40 <set_> I just killed off two BBBlue boards. Dang it.

11:41 <zmatt> maybe you should stop doing that

11:42 <set_> Right!

11:43 <set_> WHelp, time to reflash.

11:44 <set_> Who knows? It could be something faulty. Maybe they are not fried yet.

11:54 <set_> Anyway...

11:54 <set_> @zmatt: Thank you for the R110XL mention. I will look into it.

11:56 <set_> WHelp, new image and no power. This cannot be good.

11:57 <zmatt> what did you do?

11:58 <set_> I plugged in the BBBlue into the USB port on the host.

11:58 <zmatt> I mean, what did you do to fry it?

11:58 <set_> It showed no power. I reflashed and then...oh.

11:58 <zmatt> how did you reflash it if it "showed no power" ?

11:59 <set_> I plugged in the PRU to Signal on the Receiver.

11:59 <set_> No LEDs lit up at all on one board. The second board is powered now via usb. phew.

11:59 <zmatt> please say words that actually describe what you did

11:59 <zmatt> you can't plug anything into "PRU", you can only plug things into connectors that exist on the bbblue

12:00 <set_> I made a cable.

12:00 <zmatt> and the receiver has a whole bunch of possible of connections

12:00 <zmatt> from what to what?

12:01 <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.

12:02 <set_> It fits on the Eight Pin header on the Receiver, i.e. Signal.

12:02 <set_> I think that the Eight Pin Header on the Receiver is signal but at 5v.

12:09 <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)

12:09 <zmatt> but yes, if that's a 5v signal (which you should have checked) then it's quite likely you fried the beaglebone

12:10 <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.

12:11 <zmatt> lol

12:11 <set_> I know. he must have powers on the forums.

12:11 <set_> Blah.

12:12 <zmatt> not everything is going to have the level of patience with you that I often show you

12:12 <zmatt> *not everyone

12:12 <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.

12:13 <set_> I understand you have patience w/ technical stuff. I am thankful.

12:13 <set_> Two years and two posts and I am spam. That is garbage.

12:14 <set_> And...

12:14 <zmatt> I mean, it depends a bit on what you posted :P

12:14 <set_> They stopped servicing the BBBlue. I mean, they will not have support for it any longer.

12:15 <set_> They are heading towards STm chips for people to make their own distros of ArduPilo.

12:17 <zmatt> https://ardupilot.org/rover/docs/common-autopilots.html#common-autopilots

12:17 <zmatt> number two in the list

12:18 <zmatt> same for copter: https://ardupilot.org/copter/docs/common-autopilots.html#common-autopilots

12:18 <set_> I see it. If you scroll down on that link and click a link, you end up here: https://discuss.ardupilot.org/t/beaglebone-blue-released-linux-enabled-autopilot-for-80/15772

12:18 <set_> Let me get the link real quickly that states what I am discussing.

12:21 <set_> Hmm. See. He removed his posts that were against me and my wants involving the Build on the BBBlue and blah, blah, blah.

12:21 <set_> Now, I am making things up. Argh!

12:25 <set_> Anyway, I tried w/ ardupilot. Chatted w/ a bunch of "people" and got nowhere.

12:25 <set_> It was a time. The time was interrupted by things not working well for me.

12:26 <set_> The only time ardupilot worked for me was when I pushed the mode button on the BBBlue and had librobotcontrol work!

12:29 <set_> and ... : https://discuss.ardupilot.org/c/hardware-discussion/linux-autopilots/111 seems a bit absent.

12:31 <set_> @zmatt: Anyway, let me get ready for this glorious day. I get to play in dirt again! Yay and yah!

12:32 <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.

12:32 <set_> no sleep and ramshaft dirt work here I come!

13:47 <Guest95> hi

13:47 <Guest95> i have problem

13:47 <Guest95> i set setenv serverip 192.168.27.1

13:48 <Guest95> and setenv ipaddr 192.168.27.2

13:48 <Guest95> i can ping the server from u-boot

13:48 <Guest95> but the server can't ping beaglebone

13:49 <Guest95> so what should i do

13:49 <Guest95> ?

13:49 <Guest95> ?

13:49 <Guest95> ?

13:49 <Guest95> ?

13:59 <Guest95> ?

14:38 <hnv>  what commands are you using? at both ends

15:20 <zmatt> I don't think u-boot is pingable

15:20 <zmatt> I don't think it even acquire an ip address until it actually attempts to do the tftp boot

15:22 <zmatt> I could be wrong

15:26 <zmatt> hmm, maybe I spoke too soon, looks like it ought to be pingable once network is up

15:26 <zmatt> oh he left anyway

19:26 <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

19:28 <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

20:23 <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

20:24 <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

20:24 <nmingotti> ok forget the string "pwersaving.service" this is just a string that remained there

20:25 <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

20:26 <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

20:27 <zmatt> hmm, looks like the device doesn't get tagged by default, so a bit of udev will be needed regardless

20:29 <zmatt> hold on, let me test something

20:30 <nmingotti> okis ! thanks zmatt

20:43 <zmatt> nmingotti: https://pastebin.com/byzebjj6

20:44 <zmatt> nmingotti: this makes each pwm visible as a systemd unit, e.g. "dev-pwm-ehrpwm1a.device", on which you can add a dependency

20:45 <nmingotti> cool ! thank you again, let me study it and make some test :)

20:45 <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

20:47 <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

20:50 <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"

20:52 <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

20:53 <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

20:54 <zmatt> that's not *that* magical I think

20:56 <zmatt> or at least, it's exactly the right amount of magical to make device units actually useful ;)

21:06 <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

21:06 <nmingotti> declarative configurations. well ... it works well, so i will not complain much ;)

21:19 <zmatt> I honestly didn't find the old pile of shell scripts much clearer

21:21 <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

21:22 <zmatt> it's also kinda like a makefile

21:23 <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

21:25 <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

21:27 <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,

21:27 <nmingotti> i don't dislike the new system.

21:27 <nmingotti> config the boot process, of course

21:28 <nmingotti> and it was working mostly cross platform, i remember we had serveral Debian, ScientificLinux, FreeBSD and OpenBSD

21:29 <nmingotti> ok, i will look into che kernel parameter for systemd log details, seems interesting

21:41 <zmatt> systemd.log_level=debug

21:42 <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

21:43 <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

21:45 <zmatt> e.g. sudo kill -RTMIN+22 1

21:49 <hnv> those udev rules show up doing systemd-analyze?

21:49 <zmatt> all units show up in systemd-analyze

23:37 <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

23:39 <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)