**** BEGIN LOGGING AT Thu Mar 17 02:59:56 2022 Mar 17 03:17:21 mixotricha: ubuntu is not officially supported (even though unofficial images do exist), the recommended images are Debian Mar 17 03:17:46 and the IoT images include the toolchain for pru Mar 17 03:19:50 there's basically two ways to write code for pru: the original way was using the pru assembler (pasm), loaded onto pruss using the uio-pruss driver and libprussdrv. later TI made a C compiler (even though the instruction set was designed for assembly programming and really not for being targeted by a C compiler) Mar 17 03:20:27 that C compiler peoduces ELF executables which can't be loaded by libprussdrv, the new mechanism is the remoteproc-pru driver where the kernel handles the loading instead of userspace Mar 17 03:21:40 alternatively I've made a python library, py-uio, which uses the uio-pruss driver and is able to load both raw binaries as produced by pasm and elf executables produced by clpru (the c compiler) Mar 17 03:22:13 (and py-uio also makes it easy to directly inspect and interact with the pru subsystem and its two pru cores) Mar 17 03:27:51 Thanks. I have Debian on it now. I have a bit of assembly written for the PRU that I would like to play with. It apparently does SPI over the PRU. What would be the best way to move that over to the C. I am quite comfortable in the C but a bit more of a learning curve when it comes to the assembly. Mar 17 03:28:30 "does SPI" in what sense? if it's bit-banging then it's probably too timing sensitive to do in C Mar 17 03:29:41 one of the big benefits of PRU is that its simple and deterministic instruction timing and dedicated gpio hooked into registers makes it easy to implement custom protocols in software Mar 17 03:30:07 but writing in C obliterates that Mar 17 04:00:08 Ah mainly I was just going to port it over to C to fit in to some of the gcc-pru examples I have looked at written in C. Mar 17 04:00:18 oh right, gcc-pru exists too Mar 17 04:00:25 I didn't know anyone actually used it Mar 17 04:01:00 I just figured since I am comfortable with C. The SPI example I was looking at is here. Mar 17 04:01:01 https://github.com/kiorpesc/BBB-PRU-SPI Mar 17 04:01:48 its elf executables don't actually comply with the pru abi so I don't think py-uio can even load them, though I think they did patch the linux driver to understand what pru-gcc produces Mar 17 04:01:56 I have a need to do fast SPI to a bus for a bit of vintage S-100 hardware. Just seeing how far I can go with this. The standard GPIO isn't fast enough and we don't think the SPI is quite fast enough on its own to get us up to the 10MHz bus speed we would like. Mar 17 04:02:26 the SPI controllers support up to 48 MHz Mar 17 04:03:06 Will they really do that though given latency in kernel and such like. See the S-100 bus is very time sensitive. Mar 17 04:03:41 which timings exactly? Mar 17 04:03:58 ( this debate has been going back and fourth in the S-100 group about if the SPI will be fast enough. I say the way to solve that is to bit bang it with the pru ) .. Mar 17 04:04:14 do you have details of what exactly you're trying to do? Mar 17 04:04:36 ah, this? https://en.wikipedia.org/wiki/S-100_bus Mar 17 04:05:38 We are putting a beagle bone black on the S-100 bus. Asking for the S-100 bus timing is like asking for the whole IEEE-696 standard. It is a whole bloated manual of timing signals. Mar 17 04:05:54 okay so you're not actually trying to do spi Mar 17 04:06:40 Well the SPI is a nice way to handle all of the pins involved and the GPIO on its own is what 3MHz ? Mar 17 04:07:17 The GPIO on its own isn't fast enough. Stage of level shifting and multiplexing out to a 16 bit SPI chip seems a clean way to go off the S-100 bus. Mar 17 04:07:19 if you're going to be accessed by a remote bus master then of course the question is also how you're going to service the requests... like, will the remote bus master just access some piece of memory in pruss or what? Mar 17 04:07:26 If the SPI is fast enough on its own this is easy ... Mar 17 04:07:36 ehh, that would just make things slower Mar 17 04:08:20 I thought the non PRU GPIO topped out at about 3MHz max? Mar 17 04:08:22 like, pru is the fastest thing pru can do, it can read its gpio inputs or modify its gpio outputs in a single clock cycle Mar 17 04:09:00 Oh I forgot to say the other reason for the SPI was because it is a nice way to multiplex down all the pins. Mar 17 04:09:00 non-pru gpio doesn't have guaranteed deterministic timing so it's presumably not useful here Mar 17 04:09:27 yeah hence go to the PRU and bit bang some SPI ...   because you get what 24 pins? Mar 17 04:09:36 IS it 24 pins? ... but you get two don't you ? Mar 17 04:10:14 S-100 bus is also lots of pins. 100 of em. Organic evolved legacy mess. Mar 17 04:10:20 ew Mar 17 04:10:33 And capacitance terminated old school Mar 17 04:10:46 not modern path termination though somebody has done a backplane that is modern terminated Mar 17 04:11:16 https://pastebin.com/zK85mXex Mar 17 04:11:31 Somebody has done a PDP project using a Beagle Bone but the difference is that it isn't synchronous. Mar 17 04:11:39 So the timing is not really an issue. Mar 17 04:12:02 I know someone implemented some microprocessor bus using pru that was timing sensitive Mar 17 04:12:25 I think he used some parallel latch or whatever to get around not having enough pins Mar 17 04:12:55 But really I came here just more for pointers about tools. Like should I used Debian. Should I use the gcc-pru. Are people still using pasm? Mar 17 04:13:08 doing 100 pins serially via spi would be suuuper slow, you kinda want to use as many pins in parallel as feasible Mar 17 04:13:09 What is the best way to go about setting up a tool chain to use the pru. Mar 17 04:13:24 I wouldn't use gcc-pru Mar 17 04:13:33 Okay. So the pasm? Mar 17 04:13:48 since you're in need of both max performance and critical timing you'll definitely want to write in asm Mar 17 04:14:29 you can either use pasm or the assembler from the new toolchain.... both have pros and cons Mar 17 04:17:49 pasm has some nice features that pru-cgt's assembler doesn't, like being able to scoped variables (e.g. you can declare a scope that declares certain names variables to have certain types and be bound to certain registers, and then in your main code you can tell the computer when you enter/exit that scope and all variables declared in that scope and then available, and iirc pasm also checks that you ... Mar 17 04:17:55 ...don't enter two scopes with overlapping register uses) Mar 17 04:18:19 This bit of asm that does the big banging of SPI over the PRU was done using pasm. Mar 17 04:18:39 pasm was designed for humans writing assembly, pru-cgt is centered mainly around the C compiler hence its assembler is mainly designed to consume machine-generated asm Mar 17 04:22:03 note that the spi code you're looking at is an spi master Mar 17 04:22:15 that's not really what you're after, you're not the one creating the timing Mar 17 04:23:27 I had pondered that. The thinking was since that thing is so much faster than the 10MHz the s-100 bus can do Mar 17 04:23:38 it could master the whole thing quite comfortably. Mar 17 04:24:00 But how the hardware is done is next problem ....  first problem was just toolpath Mar 17 04:24:13 I think I will go look at the pru-cgt thing thanks Mar 17 04:24:26 being a master is generally much easier than being a slave, since if you're the clock master then you can typically just go slower when needed since other devices and using your clock Mar 17 04:24:30 why? Mar 17 04:24:43 I'd suggest pasm Mar 17 04:26:17 the main reason to use ti-cgt's assembler would be if you want to use the remoteproc-pru driver instead of uio-pruss, but remoteproc-pru is overall more limited and especially poorly equipped for high performance data exchange Mar 17 04:28:52 and whether it can do 10 MHz depends on how much work there is to do per clock cycle Mar 17 04:29:51 if you're going to need to read inputs and/or update outputs in multiple steps using external muxes/latches/shift registers due to insufficient pins then you can still easily run out of time Mar 17 04:30:27 I think I would be more comfortable with the pasm actually as well Mar 17 04:31:01 And I would rather be able to just compile the pru stuff on the device Mar 17 04:31:19 you can compile on the bbb regardless of what you use Mar 17 04:32:03 my python library ( https://github.com/mvduin/py-uio ) includes both pasm examples and clpru examples (though mostly pasm) Mar 17 04:32:31 (since it can load executables from both toolchains) Mar 17 09:25:35 We using Beagle bone Black version C and looking for 3D step file. Can you help us with that? Mar 17 12:51:26 rcn-ee: whatever is going on with 5.10 wasn't a problem with my kernel build, 5.10.100-ti-r40 is also broken on my bbx15 Mar 17 12:52:10 like, shortly after boot something goes horribly wrong... and usually it spontanously reboots, though it seems for some reason it doesn't this time Mar 17 12:52:45 right now if I try to access any file (even in proc or sys) the process hangs (but killable with ctrl-C) Mar 17 12:52:58 ah, and it rebooted Mar 17 12:56:09 5.4 works fine though Mar 17 13:02:41 rcn-ee: and I've tested that uio-pruss also works on the bbx15, in 5.4.106-ti-r40 Mar 17 13:02:52 sweet.. Mar 17 13:05:04 rcn-ee: using e.g. https://pastebin.com/raw/Va6SMSjC Mar 17 13:05:30 sweet i'll add that.. Mar 17 13:07:14 hehe, for some reason I'm now feeling the urge again to see if I could make a working uio-eve ... fortunately I don't have the time Mar 17 15:41:23 thanks zmatt, added as https://github.com/beagleboard/BeagleBoard-DeviceTrees/commit/9f571b111577901f20f538f5bdf18cd53f45bd00 had to add the interrupt-parent to keep DTC happy.. Mar 17 15:51:54 ehhh what Mar 17 15:51:59 no that interrupt-parent doesn't make any sense Mar 17 15:52:09 that can't possibly work Mar 17 15:55:20 without a value we get: src/arm/overlays/AM57XX-PRU-UIO-00A0.dts:25.9-38.3: Warning (interrupts_property): /fragment@2/__overlay__: Missing interrupt-parent Mar 17 15:56:03 that's just an incorrect warning caused by dtc ignoring that it's an overlay and not a complete dts Mar 17 15:56:57 that warning (and a bunch of other ones) should just be suppressed when compiling overlays, or a bug filed against dtc Mar 17 15:59:41 it's also just straight up the wrong interrupt-parent, the correct one is inherited from an ancestor node Mar 17 16:01:16 (looks like it's inheriting interrupt-parent = <&crossbar_mpu> from the root node) Mar 17 16:05:39 Hi guys! I have some questions related to a PRU unit of BBB. Have anyone worked on that before? Mar 17 16:06:07 no, you're the very first person :P Mar 17 16:06:36 Haha sadge Mar 17 16:08:32 so what are the questions? Mar 17 16:11:36 I do some experiment with PRU and the data is saved in a PRU register. Can I get the value outside the linux enviroment some how? Mar 17 16:13:06 my py-uio python library allows easy direct access to the registers of a pru core whenever it is halted, for example: https://github.com/mvduin/py-uio/blob/master/pru-examples/basic-test.py Mar 17 16:14:00 (that's setting a register, then running a program that increments the register https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/test.pasm and then once the core has halted prints the new value of the register) Mar 17 16:16:10 I cannot access the register in real time? Halted Cause I did some processing there, it's mean nothing if it's stop Mar 17 16:16:35 when the core is running, its registers are private to the core Mar 17 16:16:53 if you want to share data between pru and arm while pru is running, use shared memory Mar 17 16:22:38 rcn-ee: for completeness, here's the version for 4.14/4.19: https://pastebin.com/raw/bftdgnE7 Mar 17 16:36:02 rcn-ee: so is 5.10-ti actually working for you on am572x ? on my bbx15 it consistently hangs soon after boot (and then gets reset, presumably by the watchdog), with nothing logged by the kernel Mar 17 16:36:33 wonder, what version of u-boot is on your board? Mar 17 16:36:54 but yeah, it booted fine yesterday.. Mar 17 16:37:01 hah, I was *right now* thinking "hmm, maybe I should try updating u-boot" Mar 17 16:37:06 probably ancient Mar 17 16:37:15 pre-overlays Mar 17 16:37:16 still up.. .https://gist.github.com/RobertCNelson/0c0d85dc3281f87bf9834256da5fc9cf Mar 17 16:37:42 There is a package.. and script: /opt/u-boot/bb-u-boot-am57xx-evm/install.sh Mar 17 16:38:00 2017.01-00468-g506adcc7f880 Mar 17 16:38:11 apt package: bb-u-boot-am57xx-evm Mar 17 16:38:25 oh wait, it's actually custom-built I realize Mar 17 16:38:38 2017.01 vs 2021.04... smells like something ti or watchdog would change/break.. Mar 17 16:39:10 well the watchdog is working fine, the kernel is somehow borking (first sign is that filesystem access hangs) Mar 17 16:39:23 this is the tree... https://github.com/beagleboard/u-boot/commits/v2021.04-bbb.io-am57xx Mar 17 16:39:39 thinks maybe the mmc number changed? Mar 17 16:40:21 no I mean, it boots normally but then within a few seconds to a few minutes all file access (including virtual, like proc) starts to hang Mar 17 16:40:32 really bizarre Mar 17 16:50:28 rcn-ee: hmm, looks like this u-boot version still configures nonsense pinmux (intended for the full EVM instead of the bbx15), preventing that was actually the main reason for custom-building u-boot Mar 17 16:50:38 but, let's see if it fixes the 5.10 issue Mar 17 16:50:47 yeah, we still need to setup a better default.. Mar 17 16:51:31 btw don't forget to remove the interrupt-parent Mar 17 16:52:15 (it definitely won't work with interrupt-parent misconfigured) Mar 17 16:53:42 So how can I get the shared memory out of PRU? zmatt Mar 17 16:54:45 rcn-ee: it actually looks like updating u-boot fixed the problem... that's... fascinating Mar 17 16:54:54 never mind Mar 17 16:54:57 I spoke too soon Mar 17 16:57:45 Guest1: using py-uio you mean? the way to use shared memory depends a bit on what tools/environment you're using (on both sides) Mar 17 16:58:13 py-uio has a few examples that use shared memory Mar 17 17:03:00 libprussdrv also supports shared memory.... dunno if remoteproc-pru finally supports shared memory or if people still work around that Mar 17 17:04:38 Thank man! I still a little confuse but I try to look at that :) Mar 17 17:05:46 also, the only piece of actual documentation I've written for py-uio so far (sorry) is about using shared memory, although it's not exactly a tutorial and more reference documentation: https://github.com/mvduin/py-uio/wiki/Memory-access Mar 17 17:06:24 but like I said, it depends on what you're using (or planning to use), and you haven't really mentioned anything on that topic yet Mar 17 17:06:46 (I'm obviously most familiar with py-uio... since I wrote it :P ) Mar 17 17:08:52 pru-examples/ddr-ping.py is an extremely basic example using shared memory in ddr3 and a pru program in assembly: https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/ping.pasm Mar 17 17:09:26 pru-examples/elf-test.py also uses shared memory in a very simple way, this time using pru firmware written in C: https://github.com/mvduin/py-uio/blob/master/pru-examples/fw-c/test.c Mar 17 17:11:20 stream.py and stream-c.py are more complicated examples that use a ringbuffer in shared memory to send a continuous stream of messages from pru to python (stream uses pru firmware written in asm, stream-c uses pru firmware written in C) Mar 17 17:21:10 Thank a lot! In this ddr-ping.py example, How can I take the value 0x1234 out to linux enviroment example? Mar 17 17:21:48 ? Mar 17 17:22:55 how much background in programming do you have exactly? Mar 17 17:26:44 Not much! and i am also see on assembly for my example so it's confusing for me Mar 17 17:29:23 yeah, pru is not the easiest environment to write software for, it may not be the best idea to start out with that if you have very little experience with programming Mar 17 17:29:26 what do you want to do with it? Mar 17 17:37:36 yeah. I know but I still have to do it! The task is: I have 16 bits value from the shared memory example. The task is I need to read it in Linux environment. Is this making sense? Mar 17 17:38:17 not really no Mar 17 17:38:39 like, it's vague to the point of being meaningless Mar 17 17:39:33 and you also haven't answered what you're trying to do with pru in the first place Mar 17 17:40:13 https://keeni.notion.site/RX-a73d3e8f39f24a29baf62d576855c344. I have the code here Mar 17 17:40:59 The task is get the r3 value out Mar 17 17:44:03 I don't understand, this is some existing code which has already been designed with a particular shared memory protocol, which moreover has already been implemented in a driver https://github.com/openvlc/OpenVLC#design-of-openvlc Mar 17 17:46:33 yes, it is! They didn't provide the output of the r3 value in the end. So I need to extract this value outside Mar 17 17:46:39 like, whatever it is you're trying to do, it is clear you're seriously out of your depth... Mar 17 17:46:58 Okey! Thank for your help Mar 17 17:47:21 what do you even mean "the r3 value" ? r3 is just a register used here Mar 17 17:47:45 and it's clearly storing the received data into shared memory Mar 17 17:49:06 like, I really don't know how to help you since you don't even have enough background to be able to communicate what you're trying to achieve Mar 17 17:51:13 this is just not very beginner-friendly stuff Mar 17 17:51:46 Yes I see, the data storage in r3 is what I need. maybe I don't explain it well enough Mar 17 17:53:40 yes I see it's using r3 to accumulate the received data, and then it writes that into a shared memory buffer Mar 17 17:54:38 the diagram at the top also shows that this buffer is in fact shared between the two pru cores, and the second pru receives this data, processes it in some way, and finally writes it to a buffer that's read by the linux driver Mar 17 17:55:32 like, your claim that it "doesn't output" this value is bizarre, since transferring this data to linux is the entire purpose of this code Mar 17 17:55:46 so you're probably just severely misunderstanding things Mar 17 17:59:26 So the value already goes into the Linux environment. So maybe I only need to look for it on the driver's side of it Mar 17 18:02:00 Thank you a lot for clearing the misunderstanding! Have a great day Mar 17 18:05:48 Good evening, do you know how to change default resolution ? hdmi renders at 1280x800 Mar 17 18:06:12 it seems this needs to be set suring boot, i think a kernel or uEnv setting Mar 17 18:06:25 i'd like to lower a bit the resolution for performance Mar 17 18:06:30 thanks Mar 17 18:08:32 by default it'll pick what it thinks is a sensible resolution, which can then later be changed by whichever process becomes the master of the display device (e.g. X11, Wayland, or an application that directly renders fullscreen to the display) Mar 17 18:09:01 ah Mar 17 18:09:04 the initial resolution can also be overridden using a kernel parameter Mar 17 18:09:09 i'll check it Mar 17 18:10:15 but typically applications that use the modern kernel graphics api (direct rendering manager) will set the resolution themselves anyway, so the kernel parameter is then not very relevant since it would only apply during boot Mar 17 18:10:50 it seems i only see available a set of 1280 with different bpp, no other resolution listed Mar 17 18:10:59 how are you looking? Mar 17 18:11:00 i don't quite understand yet Mar 17 18:11:14 through lxde parameters Mar 17 18:11:30 i also listed them through sfml videomode inquiry Mar 17 18:12:09 what video driver does x11 use? Mar 17 18:12:25 how can i check this ? Mar 17 18:12:31 good question Mar 17 18:12:53 also, using x11 will obviously degrade performance compared to rendering directly to the display Mar 17 18:13:07 ah Mar 17 18:13:35 it's not quite fast, kind of works Mar 17 18:14:29 since this app is 2d only i have'nt installed the sgx driver, although in the future i probably run it through opengl via sgx acceleration somehow Mar 17 18:14:42 at the moment it pins a bit the processor. Mar 17 18:15:03 this at least shows which video drivers are installed: dpkg --list 'xserver-xorg-video-*' | grep ^ii Mar 17 18:17:06 is there really no better way to check which one is used than grepping the x11 server's log? :/ Mar 17 18:20:05 thank you Mar 17 18:21:08 thant's the output : https://pastebin.com/hEE5ZwpY Mar 17 18:22:24 yeah all are installed Mar 17 18:22:35 also looks like basic drivers aren't packaged separately anyway Mar 17 18:23:01 are you using hdmi too ? Mar 17 18:23:30 i don't think 2d is nor can be accelerated, bad luck Mar 17 18:23:33 never heard of this sfml before... it sounds a bit like sdl ? Mar 17 18:24:17 no, but obviously how you render graphics can have significant impact Mar 17 18:24:17 well it's using the back end, x11 don't know exactly, but it's an interface, very good library Mar 17 18:25:43 it can work with opengl too although i'll develop that part a bit later Mar 17 18:26:07 that will probably be slower, unless you want to do actual 3d rendering Mar 17 18:26:36 looks like sdl nowadays supports rendering directly using drm/kms rather than x11 Mar 17 18:27:07 i did some tests about 3/4 years ago and it's much much faster to render in 3D through sgx integrated graphic card, than even simple 2D animations running through the cpu Mar 17 18:27:23 ok Mar 17 18:27:34 well, it'll depend on how you're doing the rendering obviously Mar 17 18:27:46 but maybe you're right, maybe I'm a bit too pessimistic about the gpu Mar 17 18:28:08 I know qt5 was slower with gpu than without it, but maybe it was just doing stupid things Mar 17 18:28:25 or maybe we were, dunno, it was a while ago Mar 17 18:29:20 hmm, libsfml depends on libgl1 (opengl) Mar 17 18:30:20 ah Mar 17 18:31:09 i used to run a small 3D animation with stuff for x-plane, it rendered very good, and i think Qt might need 2D acceleration though i'm not an expert at all with this Mar 17 18:31:42 no I was using qt with eglfs backend, which uses OpenGL ES 2.0 Mar 17 18:31:57 indeed sfml runs opengl and a few other libraries, it should be lightweight. Mar 17 18:32:08 opengl is not lightweight Mar 17 18:32:10 ok strange Mar 17 18:32:24 then it worked on the gpu Mar 17 18:32:24 (and opengl (not-ES) also can't be gpu-accelerated on the bbb) Mar 17 18:32:44 yes i mean opengles Mar 17 18:32:57 sfml depends on gl though, not gles Mar 17 18:33:12 i worked a bit with it and pvr tools, they're quite interesting Mar 17 18:33:59 rights, i don't think i used sfml with opengles ever, not checked it Mar 17 18:38:47 Can i ask, do you see multiple resolutions available on the screen setup ? Mar 17 18:42:11 I'm not using graphics on any beaglebone here, and even when I did do something with graphics I didn't use x11 Mar 17 18:43:06 a while back I made a little utility that dumps information about a drm device (/dev/dri/card*): https://liktaanjeneus.nl/drm-dump.tar.gz Mar 17 18:43:15 which includes all supported video modes Mar 17 18:44:57 it's possible your x11 is using the fbdev driver, which uses the legacy fbdev interface and doesn't have the ability to change resolution Mar 17 18:46:44 indeed i see all video modes there Mar 17 18:47:01 from 720x400 to 1280x800 Mar 17 18:47:34 and i see "fb" with only one, 1280x800 16 bits Mar 17 18:47:53 that's the framebuffer allocated for the legacy fbdev Mar 17 18:48:36 ok Mar 17 18:48:51 (also used for things like the console / VTs) Mar 17 18:50:20 a bit too complex yet to grasp, i'll experiment with it Mar 17 18:50:45 yeah this is just a raw information dump Mar 17 18:51:28 if x11 is indeed using the fbdev driver then using the modesetting driver instead should allow runtime changes to the resolution Mar 17 18:51:45 or, like I said, you can force a different initial resolution using a kernel parameter, configured in /boot/uEnv.txt Mar 17 18:51:51 i mean about the driver stuff, it seems i should change driver to get the right res Mar 17 18:52:35 that's the simpler solution Mar 17 18:52:58 or, y'know, ditch x11 :) Mar 17 18:53:46 (if appropriate) Mar 17 18:54:26 don't know, i'll check the uEnv, i'm doing it now Mar 17 19:01:35 thnks Matt, work a charm Mar 17 19:02:26 added in uEnv.txt => optargs=video=HDMI-A-1:640x480 Mar 17 19:02:47 optargs? wtf is that, I've never seen that Mar 17 19:03:36 no idea, that's how they recommend to do it, it passes a kernel instruction Mar 17 19:04:01 normally there's a cmdline= variable to which you can append custom kernel parameters (such as video=HDMI-A-1:640x480), and an example for that in the comments Mar 17 19:05:34 hm, it looks like u-boot indeed also accepts kernel parameters in an optargs variable, in addition to the cmdline parameter that's normally used Mar 17 19:05:40 ok, it works though Mar 17 19:05:44 I've never seen or heard of it before though Mar 17 19:06:37 it's probably some backwards-compatibility thing Mar 17 19:06:50 ok Mar 17 19:07:01 also I think you omit the name of the video output, e.g. video=640x480 Mar 17 19:07:01 can't tell Mar 17 19:07:23 well normally /boot/uEnv.txt explains which variables are available for use in its comments Mar 17 19:07:26 and it doesn't mention optargs Mar 17 19:09:23 i think it's an old thing Mar 17 19:09:25 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/580352/am4378-issue-with-hdmi-resolution-of-1280x720 Mar 17 19:09:42 though i really don't know Mar 17 19:11:18 just add your video= option to the cmdline variable that's already there instead Mar 17 19:12:22 it works well Mar 17 19:12:37 going to test a bit the perf at this resolution Mar 17 20:24:58 thnks a lot Mat for your advices, it helps a lot Mar 17 20:25:26 display runs smooth, got the resolution scaled a bit lower **** ENDING LOGGING AT Fri Mar 18 02:59:56 2022