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