ChanServ changed the topic of #linux-sunxi to: Allwinner/sunxi development - Did you try looking at our wiki? https://linux-sunxi.org - Don't ask to ask. Just ask and wait for an answer! - This channel is logged at https://oftc.irclog.whitequark.org/linux-sunxi
MoeIcenowy has quit [Read error: Connection reset by peer]
Moe_Icenowy has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
MoeIcenowy has joined #linux-sunxi
Moe_Icenowy has quit [Ping timeout: 480 seconds]
Moe_Icenowy has joined #linux-sunxi
MoeIcenowy has quit [Read error: Connection reset by peer]
vagrantc has quit [Quit: leaving]
hexdump01 has joined #linux-sunxi
hexdump0815 has quit [Ping timeout: 480 seconds]
cnxsoft has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
hlauer has joined #linux-sunxi
JohnDoe_71Rus has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
aggi has quit [Quit: connection closed.]
hlauer has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen_ has joined #linux-sunxi
apritzel has joined #linux-sunxi
moteen_ has quit [Remote host closed the connection]
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
moteen_ has joined #linux-sunxi
moteen_ has quit [Remote host closed the connection]
moteen_ has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
apritzel has quit [Ping timeout: 480 seconds]
hentai has joined #linux-sunxi
moteen_ has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
gsz has joined #linux-sunxi
paulk has joined #linux-sunxi
paulk-ter has quit [Ping timeout: 480 seconds]
<swiftgeek> how can I check state of HHPD from linux?
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
<swiftgeek> I guess /sys/class/drm/card1-HDMI-A-1/status should reflect it, and it at least follows connector being plugged in
<swiftgeek> /sys/class/i2c-adapter/i2c-1/1-0050/eeprom has EDID contents but /sys/class/drm/card1-HDMI-A-1/edid does not
ftg has joined #linux-sunxi
<swiftgeek> can HDMI i2c speed be adjusted? (H3)
<swiftgeek> i see DDC_Clock in A20 user manual
vagrantc has joined #linux-sunxi
rm_ has joined #linux-sunxi
<rm_> hello
<rm_> I tried to boot an old Mele A2000G with mainline u-boot and modern kernel
<rm_> Mele M5 boots fine in a similar setup
<rm_> but for the A2000G I use the "Mele A1000" dtb in uboot and kernel
<rm_> aaaand it hangs at "Starting kernel..." in u-boot
<rm_> I wonder if those need to be ported over and a separate DTS needs to be created for the G version
<rm_> or any other ideas? thanks
apritzel has joined #linux-sunxi
gsz has quit [Quit: leaving]
<rm_> ...actually it might be that the LPAE kernel is not suitable for the A10 chip
<gamiee> Hi, bit general question, is I2C bit banging bad idea from Linux userspace?
<jakllsch> probably
<jakllsch> would be better to have a kernel driver do it, if you must bitbang
<jakllsch> although TBH, timing usually isn't a problem
<jakllsch> as you get to drive the clock line yourself
moteen has joined #linux-sunxi
<apritzel> rm_: yes, running an LPAE kernel on an Cortex-A8 will stop early before enabling the MMU, and you probably won't see output, unless you have the proper earlyprintk options configured
cnxsoft has quit []
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
<apritzel> rm_: (the M5 looks like having an A20, which is Cortex-A7, which is LPAE capable)
<rm_> right, I was reusing the rootfs from M5, that's how I ended up trying the LPAE kernel :)
<rm_> now figuring out how to install a non-LPAE one into the rootfs, operating on an x86 machine
<apritzel> rm_: do you know what the difference between 1000 and 2000 is?
<rm_> all the sources say only cosmetic (casing)
<gamiee> jakllsch: yeah, need secondary I2C and board have exposed only one :/ Thanks!
<apritzel> rm_: yeah, that's what I found as well
<apritzel> rm_: is your rootfs something special / custom-made? Otherwise (off-the-shelf distro) you might just pick a different kernel
<rm_> no, it is a debian rootfs
<rm_> how do you install a different kernel into an armhf roots, while on x86?
<rm_> and have it generate an initrd.img?
<apritzel> yeah, generating the initrd on a different machine is a bit tricky
<rm_> at first I tried to forego the install part, just unpacked the kernel from a .deb into the rootfs
<rm_> but then faced that there's no initrd that way
<apritzel> but you could try booting in QEMU?
<rm_> yes, that could work
<apritzel> otherwise the installer kernels are a good choice, they should boot on everything, and have lots of modules in their initrd
moteen has joined #linux-sunxi
<apritzel> rm_: https://d-i.debian.org/daily-images/armhf/daily/ has kernel and installer initrd images, maybe you can boot, quit the installer, and chroot into your existing rootfs?
<jernej> gamiee: if I'm not mistaken, there is already support for bitbanged i2c in kernel
<jernej> you just have to specificy pins
<jernej> I used that long time ago when hacking routers with self build openwrt
<jernej> so it probably possible to do that via DT now
<apritzel> Documentation/devicetree/bindings/i2c/i2c-gpio.yaml
<gamiee> jernej: any ideas how the kernel module is named? Can't find it
<jernej> apritzel just mentioned :)
<gamiee> apritzel , jernej : oh great! Just was digging in the kernel to find it :D thanks!
<jernej> note, it's possible that preemption must be enabled
<jernej> at least SW CEC implementation wants it, it would probably be wise for this too
<jernej> eh, now I remember, I used it for LED display on Tanix TX6 :)
<apritzel> jernej: I think I saw you using it in a DT to drive those sketchy TV box displays
<apritzel> jernej: exactly ;-)
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
chewitt has joined #linux-sunxi
<rm_> apritzel, thanks, the QEMU approach worked, also used the howto at https://wp.dejvino.com/2020/07/orange-pi-zero-running-in-qemu/
<hramrach> there is also the option to run mkinitrd in qemu-user-static or what is the package that has the userspace emulation
<hramrach> you copy the qemu binary into the rootfs and chroot
<hramrach> but it's not ideal for mkinitrd becaue if it does some hardware detection you have completely different hardware
<rm_> hramrach, I tried that, but I believe I didn't have 'binfmt' set up for automatic invocation of qemu-user-static while in chroot
<rm_> so it had to be prepended to running anything
<rm_> manually
<rm_> and aside from that, yes, the h/w detection, so didn't dig deeper into figuring out to fix this
<hramrach> the binfmt detection is typically packaged somewhere as well
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
moteen has quit [Remote host closed the connection]
<smaeul> Moe_Icenowy: the diagram in section 3.3.2 seems to explain how the RISC-V IOMMU is connected. it appears to only affect DRAM access, not MMIO
moteen has joined #linux-sunxi
chewitt has quit [Ping timeout: 480 seconds]
moteen has quit [Remote host closed the connection]
moteen has joined #linux-sunxi
chewitt has joined #linux-sunxi
<smaeul> the GPADC now has a GPIO controller inside it. must really have been short on pins :)
chewitt has quit [Ping timeout: 480 seconds]
<gamiee> smaeul: now just hopefully someone will sell the board with V853
moteen has quit [Remote host closed the connection]
<smaeul> the RTC module now adds hardware on/off/suspend/resume power sequencing, wakeup source control, and power button support
<gamiee> oh nice!
<gamiee> btw smaeul, please, I'm looking for an register (H3), which will stay persistent after reboot (run recovery mode after reboot), is there any register for this? I remember there might be something in watchdog ip core.
<smaeul> yes, the RTC general purpose registers
<smaeul> this was discussed a couple of weeks ago here and on the U-Boot ML, here's an explanation of how to implement it: https://lore.kernel.org/u-boot/87596dac-6072-b0fc-65bf-b3f342b551e0@sholland.org/
<smaeul> and in fact NVMEM core was merged to U-Boot just a few days ago, so that can be used
moteen has joined #linux-sunxi
<gamiee> smaeul: oh, thanks! so NVMEM is just watchdog general purpose registers, right? Also secondly, the patch you sent me is about ability to run (in case of AW SoC) FEL mode after reboot, do I understand it correctly?
<jernej> smaeul: would you mind uploading that manual to wiki? I can't download it, it fails after a couple of minutes.
<smaeul> gamiee: RTC, not watchdog
<gamiee> smaeul: oops, yeah, meant RTC
<smaeul> NVMEM is the Linux/U-Boot/DT API for accessing non-volatile memory, and that includes "battery-backed RAM" like in the RTC
<smaeul> gamiee: yes, the example there is for FEL mode, but recovery mode is similar. dm_reboot_mode_update() sets an environment variable that you can use from your boot script
JohnDoe_71Rus has quit []
<gamiee> smaeul: ahh makes sense! So only thing left to do is implement reboot-mode for sunxi platform
<smaeul> jernej: while I figure out how to shrink the file enough for the wiki, https://distfiles.smaeul.xyz/distfiles/tmp/v853-amp-v853s_datasheet_v1.1.pdf
sunshavi has joined #linux-sunxi
<hramrach> right, it's the same patch as on the mailing list
<hramrach> this is example in p-boot https://megous.com/git/p-boot/tree/src/start32.c which uses different value for another mode
<hramrach> not sure if it's recovery or something else
<hramrach> gamiee: ^
chewitt has joined #linux-sunxi
<jernej> smaeul: thanks!
<gamiee> hramrach: thanks! According to p-boot source code ( https://github.com/davidwed/p-boot/blob/36b1dd4f8472c0abe23358776de97c1f18b067b2/src/start32.S#L12 ) the second mode is "make BROM boot from eMMC!
<gamiee> Since A64 firstly boot from SD, this mode is to reboot into the OS in eMMC
<gamiee> This eventually could be "treated" as recovery mode
hlauer has joined #linux-sunxi
chewitt has quit [Quit: Zzz..]
<smaeul> well the register values are entirely arbitrary, as long as the OS and the bootloader agree on their interpretation. so it is better to choose a value specifically for recovery mode
<gamiee> smaeul: true. Also, from your response to hramrach: "Allwinner platforms would need to add a nvmem-reboot-mode node, and a bit more driver infrastructure"
<gamiee> In my case (just setting the RTC value to env variable), I just need to add "reboot-mode-rtc" node to my device tree, isn't it ?
<smaeul> no, reboot-mode-rtc is some u-boot-ism.
<smaeul> you need a driver for nvmem-reboot-mode, because that is what will go in the upstream DT
<smaeul> (sure, reboot-mode-rtc will work for downstream use. it's just unfortunate when U-Boot ignores already-existing bindings)
moteen has quit [Remote host closed the connection]
<gamiee> ahh, so reboot-mode-rtc is u-boot specific, damn.
<gamiee> hmm, I don't see nvmem-reboot-mode used in any device tree in Linux :(
moteen has joined #linux-sunxi
<hramrach> how would you create the nvmem? as some kind of child node for the rtc?
moteen has quit [Remote host closed the connection]
<smaeul> hramrach: the RTC node itself is the NVMEM provider
<hramrach> how does it provide nvmem?
<smaeul> here's the DT changes corresponding to the p-boot usage: https://github.com/megous/linux/commit/820cc9e4bdff43f5107bd6e4ade13ef4d9f00d4f
<smaeul> I may have misinterpreted what you were asking. if you mean the nvmem cell, then yes, that is a child node of the RTC
<hramrach> thanks, that's a great example
moteen has joined #linux-sunxi
moteen has quit [Ping timeout: 480 seconds]
moteen has joined #linux-sunxi
<swiftgeek> lol EDID was corrupted and that was one part of the issue
moteen has quit [Ping timeout: 480 seconds]
ftg has quit [Ping timeout: 480 seconds]
hlauer has quit [Ping timeout: 480 seconds]
<swiftgeek> how can I debug HPD/EDID issues in uboot?
<swiftgeek> i spotted `i2c edid 50` but it doesn't seem to work
apritzel has quit [Ping timeout: 480 seconds]
<swiftgeek> i don't see anything in dm tree so i guess DE2 is not hooked up to that?
<swiftgeek> i guess i can define debug in sunxi_de2.c and edid.c