ArmbianHelper changed the topic of #armbian to: armbian - Linux for ARM development boards | www.armbian.com | Github: github.com/armbian | Commits: #armbian-commits | Developer talk: #armbian-devel | Forum feed: #armbian-rss | Off-Topic: #armbian-offtopic | Logs: -> irc.armbian.com
shoragan has quit [Read error: Connection reset by peer]
shoragan has joined #armbian
shoragan has quit [Quit: quit]
shoragan has joined #armbian
califax has quit [Remote host closed the connection]
califax has joined #armbian
DC-IRC has quit [Remote host closed the connection]
DC-IRC has joined #armbian
DarkL0rd has quit [Remote host closed the connection]
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 252 seconds]
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 240 seconds]
lyri has quit [Remote host closed the connection]
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 255 seconds]
archetech has quit [Quit: Konversation terminated!]
archetech has joined #armbian
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 252 seconds]
buzzmarshall has quit [Quit: Konversation terminated!]
marco44 has quit [Quit: ZNC 1.8.2+deb3.1 - https://znc.in]
marco44 has joined #armbian
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 264 seconds]
xispita has joined #armbian
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 246 seconds]
danilogondolfo has joined #armbian
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 260 seconds]
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 268 seconds]
vpeter has quit [Ping timeout: 256 seconds]
zeemate has joined #armbian
vpeter has joined #armbian
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 256 seconds]
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 272 seconds]
Manneveru has joined #armbian
<Manneveru> Good morning, Armbian ;-) Anyone well versed in RPi's DT overlays here?
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 264 seconds]
DarkL0rd has joined #armbian
LanDi has joined #armbian
DarkL0rd has quit [Remote host closed the connection]
LanDi1 has joined #armbian
LanDi has quit [Ping timeout: 260 seconds]
LanDi1 has quit [Ping timeout: 256 seconds]
LanDi has joined #armbian
DarkL0rd has joined #armbian
DarkL0rd has quit [Ping timeout: 272 seconds]
DarkL0rd has joined #armbian
laz0r has quit [Quit: ZNC 1.8.2+deb2+b1 - https://znc.in]
laz0r has joined #armbian
LanDi has quit [Quit: LanDi]
LanDi has joined #armbian
LanDi has quit [Ping timeout: 240 seconds]
<Manneveru> From another angle: has anyone managed to enable I²C on Raspberry Pi 5 on Armbian?
<c0rnelius> Manneveru: `sudo modprobe i2c-dev` you see the `ls /dev/i2c*` now?
<Manneveru> c0rnelius: yes, but only 1, 11 and 12. How to make this persistent on boot and how to enable 4 & 6 (cameras)?
<c0rnelius> Manneveru: add `i2c-dev` to /etc/modules
<c0rnelius> I thought cams were autodetected now? I know the old school way is to enable in the config.txt `start_x=1` and `gpu_mem=128` the new way which I never use is `camera_auto_detect=1`
<Manneveru> Camera autodetect is not going to work for my as I have _in-house_ camera with my own driver. I need to enable I²C as I can on Raspberry Pi OS, `dtparam=i2c_arm=on` in /boot/firmware/config.txt` was doing the job there.
<Manneveru> s/for my/for me/
<ArmbianHelper> Manneveru meant to say: Camera autodetect is not going to work for me as I have _in-house_ camera with my own driver. I need to enable I²C as I can on Raspberry Pi OS, `dtparam=i2c_arm=on` in /boot/firmware/config.txt` was doing the job there.
<Manneveru> The other part is that `dtoverlay` is not working for me as it wants to prefix each DTBO filename with `0_`...
<c0rnelius> armbian is using `/boot/firmware/overlays` to store the overlays correct?
<Manneveru> There are 2 copies for increased confusion
<Manneveru> Files are there, but they don't have prefix...
<Manneveru> Not sure how to tell `dtoverlay` to not prefix them on attempt to load
<c0rnelius> Not sure what you mean by the prefix? The boot firmware as far as I know is just looking for that directory `overlays`.
<c0rnelius> hmmm. well that could be the issue if armbian is using ubuntu bits to put its pi img together.
<Manneveru> sudo dtoverlay i2c6
<Manneveru> DTOVERLAY[warn]: no matching platform found
<Manneveru> * Failed to apply overlay '0_i2c6' (kernel)
<Manneveru> dmesg:
<Manneveru> [14625.703153] OF: resolver: node label 'i2c6_pins' not found in live devicetree symbols table
<Manneveru> [14625.711568] OF: resolver: overlay phandle fixup failed: -22
<c0rnelius> and that works on raspios?
<Manneveru> Yep
<Manneveru> Actually... that's lie
<c0rnelius> :)
<c0rnelius> is there custom overlays you created?
<Manneveru> I don't have to do that for I²C on Raspberry Pi OS as the `dtparam=i2c_arm=on` enables all I²C I need, them I can `dtoverlay` my driver.
Smedles has quit [Quit: No Ping reply in 180 seconds.]
<Manneveru> My overlay don't work as my driver cannot identify the device connected as there's no /dev/i2c-4 in the system
Smedles has joined #armbian
<c0rnelius> well even on my own custom img i only see the three when I enable the i2c. in a normal case the i2c nodes created in /dev are only done so because they are in the DTB or the DTBO. The system can't create something it doesn't know about.
<Manneveru> Right. Thing is overlays doesn't seem to work on Armbian
<c0rnelius> Where are you putting ur custom overlays?
<Manneveru> But dmesg says it's loaded (I'm doing it at runtime), so my driver is probed.
<Manneveru> But I can't enable right overlays for I²C at boot.
<Manneveru> s/I²C/right I²C/
<ArmbianHelper> Manneveru meant to say: But I can't enable right overlays for right I²C at boot.
<Manneveru> Hmm... worth giving a shot. Let me try.
<Manneveru> No change. I don't have serial cable to see what errors firmware may spit at me :-(
<c0rnelius> I'm just gonna guess here as I feel like ur not giving me all the info; the overlays aren't being found by the config.txt so they aren't getting loaded.
<Manneveru> The DTBOs aren't for right platform, hence the `no matching platform found` warning on manual attempt. Firmware cannot load them even with the flag enabled in `config.txt`.
<Manneveru> I wonder what would happen if I copied DTBOs from the SD card with Raspberry Pi OS?
<Manneveru> dtc -I dtb /boot/firmware/overlays/i2c4.dtbo
<Manneveru> compatible = "brcm,bcm2711";
<Manneveru> it needs `bcm2712`
<c0rnelius> are you using a pi5?
<Manneveru> yep
<c0rnelius> yeah
<Manneveru> and image from Armbian download from RPi5 section
<c0rnelius> or "brcm,bcm2711", "brcm,bcm2712"; so it works on both.
<Manneveru> you're right. Whatever, it's now broken.
<Manneveru> Question why and how to quickly fix it?
* Manneveru is thinking...
<c0rnelius> either decompile and recompile or edit the original overlay dts file and compile it.
<Manneveru> The layout of I²C muxer is different on RPi5... DT needs to be different.
<Manneveru> Is repo with original Raspberry Pi DTS open to public?
<c0rnelius> of course
<c0rnelius> may just be what you are looking for is on a diff i2c on the pi5 `i2c1-pi5-overlay.dts i2c2-pi5-overlay.dts i2c3-pi5-overlay.dts`
<c0rnelius> i2c11 and 12 I believe are baked into the DTS file.
<Manneveru> They're called `i2c_csi_dsi*` on RPi5 and are related to RP1 and they don't have own overlays (at least one I can find)
<c0rnelius> k
<c0rnelius> clever: might have some thoughts on the matter?
<Manneveru> There's something that makes them work on Raspbian, but not on Armbian
arch3r has quit [Read error: Connection reset by peer]
arch3r has joined #armbian
archetech has quit [Quit: Leaving]
LanDi has joined #armbian
LanDi has quit [Ping timeout: 268 seconds]
<clever> c0rnelius: do you also have the overlay map?
<c0rnelius> clever: i know nothing more than what Manneveru has said.
<clever> c0rnelius: this tells the firmware, that if you try to load disable-wifi on a pi5, it should instead load disable-wifi-pi5
<clever> that gives some flexibility in what its loading
<c0rnelius> ah gotcha. never even seen that file :)
<clever> that dts gets compiled to a dtb like the rest, and dropped in the fat partition
<clever> and if its missing, then all of that magic goes away
<clever> what was the root problem?
<c0rnelius> I have it in my personal build. not sure if armbians img does. I would assume it does?
<clever> something with the i2c6 overlay?
<c0rnelius> yeah he is trying to load i2c6 which is not available on a pi5 it seems. though he says it works using raspios.
<clever> the map file says that is pi4 only
<clever> checking the rp1 datasheet, it does have an i2c6, at 0x40088000
<c0rnelius> looks to me that what he is trying to do is not compat with the pi5 and needs to be reworked. but i also don't believe all the info has been expressed.
<clever> arch/arm/boot/dts/broadcom/rp1.dtsi: reg = <0xc0 0x40088000 0x0 0x1000>;
<clever> which is referenced in the dts
<c0rnelius> well if he comes back online maybe you can help him?
<Manneveru> clever: for starter in short `dtparam=i2c_arm=on` in `config.txt` works on RPi OS, but not on Armbian
<Manneveru> so some puzzle is missing and I don't get I²C devices
<clever> arch/arm/boot/dts/broadcom/bcm2712-rpi.dtsi:i2c_arm: &i2c1 {
<clever> that flips on a thing here i think
<clever> ah no, thats just a label
<clever> there it is, i think `dtparam=i2c_arm=on` just flips the status of the earlier one
<clever> Manneveru: it may help to compare the final dts, one min
<clever> something like `dtc -O dts /proc/device-tree -s -o out` will convert the final dts (after all overlays are applied) back into a dts file
<clever> if you run that under both Armbian and RPi OS, and diff the files, you can see why linux is behaving differently
lyri has joined #armbian
<Manneveru> It's going to take time as I have one RPi only and need to reboot from different SD Card.
<Manneveru> clever: major differences seem to be clocks
<Manneveru> a lot of phandles differ
<clever> phandles differing is normal
<clever> thats just how one node points to another
<clever> i need to go grab lunch, then i can debug it more
tomaw has quit [Remote host closed the connection]
tomaw_ has joined #armbian
tomaw_ is now known as tomaw
alekksander has joined #armbian
<clever> Manneveru: oh, and are you using dtoverlay= or the userland dtoverlay?
LanDi has joined #armbian
LanDi1 has joined #armbian
LanDi has quit [Ping timeout: 264 seconds]
LanDi1 is now known as LanDi
mighty-bob has joined #armbian
LanDi1 has joined #armbian
LanDi has quit [Quit: LanDi]
LanDi1 is now known as LanDi
LanDi1 has joined #armbian
LanDi has quit [Ping timeout: 255 seconds]
LanDi1 is now known as LanDi
zeemate has quit [Ping timeout: 256 seconds]
LanDi has quit [Read error: Connection reset by peer]
LanDi has joined #armbian
LanDi has quit [Remote host closed the connection]
<Manneveru> clever: in reality both, in userland I use it to load my own driver with my own overlay file (which works on Raspbian OS on RPi 5, because I²Cs are active in DT).
<clever> Manneveru: i'm more familiar with the config.txt method, can you try loading all of the overlays like that, convert /proc/device-tree to dts, and then pastebin the dts?
<Manneveru> Give me few seconds
<Manneveru> Interesting observation: i2c@80000 status okay on armbian, disabled on raspberryos, same i2c@88000
<Manneveru> Armbian on RPi5 with `dtparam=i2c_arm=on` in `config.txt`: https://pastebin.com/Tcc8Wmnm
<Manneveru> Raspberry Pi OS on RPi5 with `dtparam=i2c_arm=on` in `config.txt`: https://pastebin.com/9dJiLvrb
<Manneveru> clever: both have `camera_auto_detect=1` commented out
<Manneveru> i2c@7d508200 enabled on RPi OS, disabled on Armbian, same i2c@7d508280
<clever> Manneveru: i2c@80000 is i2c6, so if the status is disabled, then you never enabled it
<Manneveru> interrupt-controller@7c502000 and interrupt-controller@7d510600 and moplet@7c501000 same
<Manneveru> but the config.txt says the same and my overlay is not loaded yet
<clever> dtparam=i2c_arm=on doesnt turn on i2c6
<clever> it turns on i2c1
<clever> if you want to use i2c6, you must dtoverlay=i2c6
<Manneveru> it's not going to work and i2c6 compatible= is set to bcm2712 only... I've checked
<Manneveru> s/bcm2712/bcm2711/
<ArmbianHelper> Manneveru meant to say: it's not going to work and i2c6 compatible= is set to bcm2711 only... I've checked
<clever> Manneveru: ah, then we need a new and custom overlay, one minute
<Manneveru> Then why I'd have to do it on Armbian and I don't have to on RPi OS?
<Manneveru> RPi OS seem to enable all of them
<clever> where do you see it enabled? https://pastebin.com/9dJiLvrb says i2c6 is disabled
<Manneveru> did I pasted right file?
<Manneveru> I look at both in Meld
<clever> the one you claim came from armbian, has i2c6 enabled!
<clever> while the raspi-os one has it disabled
<Manneveru> https://pastebin.com/kAbPHmGq 7d508200 & 7d508280 enabled
<clever> those are internal to the soc and dont matter
<clever> anything starting with 7e or 7d is part of the SoC and not exposed on the gpio header
<clever> i also just noticed, i2c6 only has device-tree listing pins 38/39
<clever> you simply cant use i2c6, its not exposed on any pins
<clever> why did you want to use i2c6?
<Manneveru> i2c4 and i2c6 are buses on CSI ports (camera interfaces)
<Manneveru> what confuses me if DT shows i2c4 and i2c6 status = "okay" why they're not in /dev?
<Manneveru> actually why there's no I²C device in `/dev` after boot on it
<clever> root@raspberrypi:~# ls -l /sys/bus/i2c/devices/
<clever> because i2c is weird
<clever> you must `modprobe i2c-dev` for the char devices in /dev/ to show up
<clever> the character devices are a completely optional part
<clever> what does this ls command return?
<Manneveru> ? I don't have to on Raspberry Pi OS...
<Manneveru> booting Armbiab
<Manneveru> booting Armbian
<clever> root@raspberrypi:~# cat /etc/modules
<clever> i2c-dev
<clever> Manneveru: because this line exists in the default install
<Manneveru> :-/
<clever> line 38: "CD0_SDA" unused input active-high
<clever> line 39: "CD0_SCL" unused input active-high
<clever> and yeah, i can confirm, 38/39 is the camera/display port
<Manneveru> lrwxrwxrwx 1 root root 0 May 7 17:28 i2c-1 -> ../../../devices/platform/axi/1000120000.pcie/1f00074000.i2c/i2c-1
<Manneveru> lrwxrwxrwx 1 root root 0 May 7 17:28 i2c-4 -> ../../../devices/platform/axi/1000120000.pcie/1f00080000.i2c/i2c-4
<Manneveru> lrwxrwxrwx 1 root root 0 May 7 17:28 i2c-6 -> ../../../devices/platform/axi/1000120000.pcie/1f00088000.i2c/i2c-6
<Manneveru> let's try my overlay again
<clever> yep, i2c-6 is loaded, and once you load i2c-dev, it should show up
<clever> what was the end goal?
<Manneveru> OK, now after `modprobe i2c-dev` these two didn't appear so I couldn't do `i2c-detect` on them
<Manneveru> now my overlay uses wrong I²C despite using `cam0` param
<clever> how does your overlay reference the i2c port?
<Manneveru> and this is interesting? reversed aliases? on RPi OS I use `cam0` param to the dtoverlay, which is supposed to tie my driver to i2c_csi_dsi0 and it's i2c6 there, but if I use `cam0` on Armbian I end up with reference to i2c4 instead... it loads OK if I don't use param and `target = <&i2c_csi_dsi1>;` remains in force (I derived my DTS from imx219 one).
<Manneveru> Looks like userspace `dtoverlay` on Armbian doesn't deal well with params
<Manneveru> I have to manually change fields for overlay to work
<clever> Manneveru: why not just use only config.txt ?
<Manneveru> our driver is in development, so we load and unload it sometimes... but soon we should have `.deb` with it, so it should land in `config.txt` then
<Manneveru> Thanks for help - very valuable!
<Manneveru> I have the driver loaded and libcamera sees it
<clever> you can load and unload just the .ko
<clever> and leave the overlay in place all of the time
<clever> thats how i did my RP1 pio drivers
<clever> my .ko wasnt in /lib/modules, so on boot, linux/modprobe just fails to find it, and basically ignores the overlay
<Manneveru> hmm... I tried and something about rp1_cfe was causing troubles
<clever> when i modprobe the .ko, it springs to life
<clever> and as long as i dont OOPS or panic, i can unload and reload the module as much as i want
<Manneveru> hmm... on Raspberry OS I didn't have to add it to `/etc/modules` to work...
<Manneveru> only launch `depmod` after copying the driver `.ko` over
<clever> i try to avoid making auto-load works
<clever> because if you mess up the init function and it panics the kernel, how do you fix it?
<Manneveru> remove SD card, mount on PC, remove the .ko and overlay and reboot
<clever> yep, but thats a lot of hassle
<clever> i found it far simpler if you just require a manual `insmod` on boot
<Manneveru> my probe is stable, so I can leave with it ;-)
<clever> if you mess up, just cycle the power, and it wont load again
<Manneveru> OK, that's why I stick with dtoverlay reload
<Manneveru> worked so far... trouble started on Armbian
<Manneveru> we need Jammy because of ROS2
<Manneveru> alternative was Docker on RPi OS with Jammy and Humble on it
<Manneveru> but that's a lot of hassle to make cameras work inside container
<clever> speaking of ROS, would a 200mhz cortex-m3 help out any?
<clever> there is one hidden in the corner of the pi5
<clever> it has low-latency access to gpio as well
<Manneveru> ATM we wouldn't make use of it... however, good to know. Is it accessible to flash from the main one and what bus can be used to communicate with it?
<Manneveru> As this may be valuable for drone builders
<clever> it has no flash
<clever> let me get the info
<Manneveru> hmm... no flash? how it runs any software? shared mem?
<clever> Manneveru: page 7, you can see all of the peripherals in the RP1, and a pair of M3 cores, and 64kb of shared ram
<clever> that shared ram is directly accessible over pcie, as is the MMIO for resetting the M3 cores
<clever> core0 is managing the fan tach signal, and some unknown pcie things
<Manneveru> RP1... doesn't RP1_CFE use it when cameras are in play?
<clever> core1 is unused
<clever> damn near everything on the pi5 goes thru the RP1
<Manneveru> ROTFL
<clever> the csi/dsi ports, all of the gpio, the ethernet, the usb
<Manneveru> weird, I thought BCM2712 would be rich enough in peripherals
<clever> i think half the reason behind this choice, is future plans
<clever> if you slap an RP1 onto any pcie capable SoC, it will have 90% of the features of an rpi5
<clever> is there any reason to stay with broadcom now?
<Manneveru> if you put it this way...
<clever> and even if you do stay with broadcom, the user facing peripherals wont change when you upgrade to the next SoC
<clever> with the core1_test program, you can shove a binary into the upper half of the shared sram, and force core1 to begin executing it
<clever> and rp1-lk is a port of little-kernel, giving you a full command prompt and some basic drivers
<Manneveru> awesome
<clever> Manneveru: https://i.imgur.com/EHLTTqA.jpeg i also have the PIO working, and its clocked at 200mhz
<clever> so i can take a bit stream, and then replay it out any gpio pin, at 200mhz
<Manneveru> os this chip some form of FPGA with M3 Cores?
<clever> its the ancestor of the rp2040
<clever> not an fpga, but just regular old hard silicon
<Manneveru> I don't know any Cortex MCU with full PCI-E bus
<clever> its rigged up as a pcie slave
<Manneveru> so, they designed one for their needs... interesting
<clever> yep
<clever> do you see the address translation block in the top-right of page 7?
<Manneveru> how did you learn about it? inside knowledge from Raspberry?
<clever> mostly from working on the open firmware for past models, and bumping into 2 other guys who where RE'ing things
<clever> the pi5 VPU firmware is largely structured the same way as the pi4 firmware, which ive spent years RE'ing
<clever> so it was fairly easy to find the part where the VPU boot-straps the RP1
<clever> root@raspberrypi:~# gpioinfo | grep RP1
<clever> line 0: "RP1_SDA" unused input active-high
<clever> line 1: "RP1_SCL" unused input active-high
<clever> line 2: "RP1_RUN" "RP1 RUN pin" output active-high [used]
<clever> those are 3 gpio on the 2712, that are used to bootstrap the RP1
<clever> RP1_RUN is used to just hard-reset the entire RP1, and then a simple protocol is used over i2c, to push a ~21kb firmware blob over
<clever> and the pcie link doesnt work until that blob is executed
<clever> but my pi5 hadnt arrived at this point in the story, so i was working entirely in software
zeemate has joined #armbian
<clever> https://github.com/G33KatWork/RP1-Reverse-Engineering this guy got a pi5 first, and experimented with ways to reboot the RP1 after linux has booted
<clever> and working with him, we got a dump of the boot rom for the RP1
<clever> then later i worked with https://github.com/MichaelBell/rp1-hacking, he found a `while(true){ ...}` in the 21kb blob, and by patching it at runtime, he can temporarily borrow core0 and get core1 started
<clever> the biggest problem with G33KatWork's initial solution, is that you have to hard reset the RP1 after booting
<clever> and the linux drivers get really really upset when you hot-unplug the RP1
<clever> `rmmod` is also enough to panic certain drivers
<clever> so you need to use a config.txt dtoverlay to just ban linux from touching the RP1 in the first place (no ethernet or usb on boot)
<clever> then hard reset it, and sideload your firmware
<clever> then use the userland dtoverlay to enable the RP1
<clever> then reboot the whole system if you want to do it again
<clever> MichaelBell's trick allowed you to gain control of core1 without a reboot, and i just refined things, using the reset block and getting LK ported
laz0r_ has joined #armbian
laz0r has quit [Ping timeout: 246 seconds]
laz0r_ is now known as laz0r
mighty-bob has quit [Ping timeout: 264 seconds]
alekksander has quit [Remote host closed the connection]
TheCoffeMaker has quit [Ping timeout: 246 seconds]
TheCoffeMaker has joined #armbian
buzzmarshall has joined #armbian
jantones has quit [Ping timeout: 260 seconds]
jantones has joined #armbian
* flyback should blow the dust off his orane pi lite soon
<DC-IRC> [Discord] <nexusxe> hey, trying to build armbian for my lichee rv nezha board with the build tool's mangopi-mq config, but am getting errors building u-boot due to missing opensbi. anyone have any ideas? I can get opensbi cross-compiled locally just fine, but the build tool doesn't seem to be able to do it
<Manneveru> clever: sounds tough. Too bad RPi1 firmware is not open-source, so it could sideload the RPi1 before the kernel is loaded (similar like Xilinx does on Zynq and others)
<clever> Manneveru: i have been working on making open firmware for the rpi line of boards
<clever> Manneveru: currently, it can boot linux on a pi2 and pi3
califax_ has joined #armbian
califax has quit [Remote host closed the connection]
califax_ is now known as califax
califax has quit [Remote host closed the connection]
califax has joined #armbian
archetech has joined #armbian
zeemate has quit [Ping timeout: 255 seconds]
Perflosopher has quit [Quit: The Lounge - https://thelounge.chat]
jantones has quit [Ping timeout: 260 seconds]