<tuxd3v>
diego71, yes, but in the meantime between ntp updates the time will slide since you don't have a rtc 32768 clock
<tuxd3v>
the idea is, between updates to maintain the hw clock more or less acurate :)
ftg has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
ftg has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
cnxsoft has quit [Remote host closed the connection]
cnxsoft has joined #linux-sunxi
<diego71>
in the worst case ntp is updated every about 15min, and rtc is usually read only at boot
JohnDoe_71Rus has quit []
cnxsoft has quit []
apritzel has quit [Ping timeout: 480 seconds]
apritzel has joined #linux-sunxi
tnovotny has joined #linux-sunxi
prefixcactus has joined #linux-sunxi
cnxsoft has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
warpme___ has joined #linux-sunxi
hlauer has joined #linux-sunxi
JoaoSchim has quit [Remote host closed the connection]
JoaoSchim has joined #linux-sunxi
joaoSchim_ has joined #linux-sunxi
JoaoSchim has quit [Ping timeout: 480 seconds]
hlauer has quit [Read error: Connection reset by peer]
hlauer has joined #linux-sunxi
apritzel has joined #linux-sunxi
apritzel_ has joined #linux-sunxi
<apritzel>
tuxd3v: at kernel runtime the current time is kept via the arch timer, driven by the 24 MHz oscillator
<apritzel>
tuxd3v: The RTC is typically only read at boot and written at shutdown, to bridge the period the arch timer is not running
<apritzel>
and typically RTCs are considered inaccurate these days, at least when compared to other time sources, like NTP
<apritzel>
they are mostly good for putting you in the right century, so that your certificate checks don't fail ;-)
apritzel_ has quit [Ping timeout: 480 seconds]
JohnDoe_71Rus has joined #linux-sunxi
<valdikss>
Oh, you didn't see my messages
<valdikss>
Hello everyone, I'm trying to activate USB OTG in u-boot (mass storage gadget) on an unsupported board, and all it says is "A charger is plugged into the OTG: Port not available.". I assume the issue is in device tree, but I don't understand how to fix it. Can anyone help me?
<valdikss>
The device is SUN50I (r18/a64), I took olinuxino-a64 dts as a base and modify it. Basically everything works except OTG. USB Host works fine.
<valdikss>
And there's another issue: when loading legacy sunxi kernel 3.10 with modern u-boot and with stock dtb, it doesn't work properly. The kernel can't find some regulators, emmc does not work. Does u-boot somehow modify the dtb when booting with booti and does not keep it intact?
<apritzel>
valdikss: you cannot boot 64-bit BSP kernels with mainline U-Boot
<apritzel>
valdikss: does OTG work in the kernel?
<valdikss>
apritzel: really? But it boots just fine
<valdikss>
I mean I have the console and all
<valdikss>
>does OTG work in the kernel? < Yes
<apritzel>
valdikss: I think I used OTG an some A64 board in U-Boot, at least a few weeks/months ago
<valdikss>
I have zero experience with device tree, that's why I assume I've edited olinuxino's incorrectly and messed the pins or something.
<apritzel>
valdikss: did you use latest U-Boot
<valdikss>
Yes, latest master of yesterday commit.
<apritzel>
good!
<apritzel>
(read: thanks for testing!)
<valdikss>
is that related to 64 bit legacy kernel?
<apritzel>
valdikss: do me one favour: write "Allwinner BSP 3.10 kernel" on a piece of paper, then burn it. Never think about it again. It's a relief, believe me ;-)
<apritzel>
valdikss: as you mentioned: some things are broken, the DT is completely different, the way they handle regulators, and so on
<valdikss>
https://pastebin.com/nsD9euBv < boot the same kernel from legacy u-boot (which is on emmc). As you can see, in 'sunxi-mmc 1c11000.sdmmc: sdc set ios' vdd and numbers are different.
<apritzel>
the whole firmware and boot process is so backwards that we decided to do it properly instead
<valdikss>
apritzel: What I did on modern u-boot: loaded kernel, initramfs and dtb with sunxi-fel, then jumped with booti.
<valdikss>
I expected that u-boot would not touch dtb in this case, but apparently it does? Or it just I don't understand how it should work?
<valdikss>
The dtb is stock, not my olinuxino modification.
<apritzel>
valdikss: U-Boot changes some bits in the DT, for instance to memory node and the MAC address(es)
<valdikss>
I assume that in booti cycle, u-boot takes current (embedded) dtb and appends(?) loaded dtb to it
<apritzel>
valdikss: U-Boot gives the DTB that you tell it to use, with the third parameters to booti
<valdikss>
Why doesn't it work then?
<valdikss>
The kernel logs are clearly different, while I'm sure this is the same dtb.
<apritzel>
valdikss: what doesn't work? booting BSP kernel with mainline? Or USB-OTG in U-Boot?
<valdikss>
I'm trying to boot legacy sunxi kernel 3.10 with dtb, over fel, with mainine u-boot. It boots, but dtb seems to be different from the kernel standpoint, and emmc does not work. However, the same set of kernel+dtb boots and works fine when booted with legacy u-boot (which was on this device' emmc already).
<apritzel>
the Allwinner BSP provided DTB and mainline DTB are vastly different and not compatible at all
<apritzel>
and so are the drivers, plus the whole firmware boot flow
<valdikss>
I understand. I want to use mainline DTB only for mainline u-boot, and boot legacy kernel + legacy dtb from it. Is that possible?
<apritzel>
short answer: no. We don't support booting 64 bit BSP kernels on mainline U-Boot
<valdikss>
Or could the difference be in pre-u-boot partitions like spl, which are different in mainline u-boot?
<valdikss>
Because another difference I've spotted is psci version detected by the kernel. With legacy on-flash u-boot it says "PSCIv0.2 detected in firmware.", and with mainline u-boot: "PSCIv1.1 detected in firmware."
<apritzel>
if you want to boot a BSP kernel, use a BSP U-Boot
<apritzel>
as I said: the whole U-Boot and Trusted Firmware is completely different between BSP and mainline
<apritzel>
and the Allwinner version is broken beyond repair
<valdikss>
palmer: all right, that's unsupported, I got it. Do you have any idea what could be wrong with USB OTG in the mainline u-boot than?
<valdikss>
then*
<valdikss>
Here's the original dtb from stock 3.10 kernel: https://litter.catbox.moe/mk4hh0.bin < do I need to modify any nodes in my custom dts to make usb0 otg work on this device? If yes, how should I do that?
<valdikss>
I assume usb0_vbus_det-gpios should be modified?
<valdikss>
in usbphy
<apritzel>
U-Boot is typically not so sensitive about USB-OTG DT properties, for instance I believe it ignores any GPIOs and power bits
<apritzel>
if that works in the mainline kernel, then it's probably correct
<valdikss>
As you can see here https://pastebin.com/cN5FDHS7 < "Bus usb@1c19000: A charger is plugged into the OTG: Port not available."
<valdikss>
I haven't checked mainline kernel, I have only stock legacy kernel on this device.
<apritzel>
U-Boot's OTG support is somewhat special, and we had some changes lately, so it might be broken
<valdikss>
Should I try release version of u-boot?
<apritzel>
yeah, try v2021.07, I believe that's the version I last tested with OTG
<valdikss>
And all the tests I made were without 5V connected to the laptop from the device. Is that fine?
<apritzel>
I can test this later tonight on master
<valdikss>
However, it works in legacy kernel just fine.
<valdikss>
Oh by the way, musb dma support is broken, it does not compile.
<valdikss>
Had to use pio.
<apritzel>
in U-Boot?
<valdikss>
Yes
<apritzel>
well, it's not supported, isn't it?
<valdikss>
I don't know
<valdikss>
DMA_TO_DEVICE and DMA_FROM_DEVICE are not defined
<apritzel>
IIRC the MUSB driver was once copied from Linux, but many parts in it are somewhat disabled in U-Boot
<valdikss>
I mean, DMA mode is the default in menuconfig u-boot
<apritzel>
valdikss: is it? I see USB_MUSB_PIO_ONLY being default y if ARCH_SUNXI
<apritzel>
valdikss: in general U-Boot menuconfig is quite fragile, and it's easy to create non-working configs
<valdikss>
And it does not compile. Had to check CONFIG_USB_MUSB_PIO_ONLY
<apritzel>
yes, because it's not supported
apritzel_ has joined #linux-sunxi
<apritzel>
admittedly the Kconfig should be stricter here, I guess
<apritzel>
I would just add CONFIG_USB_MUSB_GADGET=y to the defconfig and don't touch anything else
<apritzel>
you can use menuconfig to add commands and such, but even that is not guaranteed to work
<valdikss>
apritzel: what's interesting, if only gadget is enabled (and not CONFIG_USB_MUSB_HOST), u-boot does not print anything regarding otg, and it still doesn't work.
<valdikss>
It prints log as if host mode is enabled, not gadget.
<valdikss>
only ohci/ehci devices are detected, but no 1c19000, while you may expect completely opposite result.
<apritzel>
valdikss: look at the bananapi_m64, I believe OTG works there
<apritzel>
both defconfig and DT
<apritzel>
valdikss: what did you do to test this? I believe U-Boot doesn't touch OTG unless you explicitly tell it so via some command
<apritzel>
do you have some other A64 board to compare this against?
<apritzel>
valdikss: did you try to chase down the error message, in board/sunxi/board.c?
<apritzel>
I guess you alreday disabled usb0_vbus_det-gpios because of this?
<valdikss>
apritzel: I've tried to configure ums.
<valdikss>
I've tried to hack up vbus detection function. It stopped printing this message but started to print that OTG is not ready or something.
<valdikss>
My dts is very similar to bananapi-m64, but there are some difference. I'll try to run modified dts close to bananapi's and report back in ~1 hour. Would you still be here?
<apritzel>
try to disable EHCI0 and OHCI0 in the DT
<apritzel>
valdikss: I will be around for a while, but even if not I read the logs
tnovotny has quit [Quit: Leaving]
<valdikss>
apritzel: aaand it works! It still spams "a charger is plugged into the OTG", but ums now works.
<valdikss>
apritzel: I suppose the dts change did a trick.
<valdikss>
apritzel: I still need proper usb0_vbus_det-gpios I guess
<valdikss>
apritzel: in my stock dtb, usb_det_vbus_gpio = "axp_ctrl"; What should I set in mine?
<valdikss>
apritzel: for some reason, it works only when ethernet gadget is compiled in
<valdikss>
[15:29] <valdikss> apritzel: aaand it works! It still spams "a charger is plugged into the OTG", but ums now works.
<valdikss>
[15:30] <valdikss> apritzel: I suppose the dts change did a trick.
<valdikss>
[15:30] <valdikss> apritzel: I still need proper usb0_vbus_det-gpios I guess
<valdikss>
[15:35] <valdikss> apritzel: in my stock dtb, usb_det_vbus_gpio = "axp_ctrl"; What should I set in mine?
<valdikss>
[15:47] <valdikss> apritzel: for some reason, it works only when ethernet gadget is compiled in
gsz has joined #linux-sunxi
<apritzel>
valdikss: I don't think you *need* VBUS detect, it should work without it
<valdikss>
apritzel: it apams the message, but I've commented it. Works fine now with one minor bug: if USB transfer is very heavy (raw copy/write), it doesn't have time to update watchdog timer, so I had to disable it.
<valdikss>
Thank you! Btw, it still doesn't work without ethernet gadget, apparently it initializes something.
<apritzel>
valdikss: was that with latest U-Boot?
<valdikss>
Yes, yesterdays git master
<apritzel>
we just enabled the watchdog one week ago
<apritzel>
so happy to hear about this
<apritzel>
I think longer running operations are supposed to update the watchdog, and we might never done this in some parts Allwinner USB code
<apritzel>
valdikss: is it that Yandex smart speaker device?
<valdikss>
Yes, the first one (Яндекс Станция)
<apritzel>
понятно
<apritzel>
does it have a micro-USB-B connector?
<valdikss>
No, it doesn't have anything. I had to solder to the test point, which I found by desoldering the CPU
<apritzel>
desoldering the CPU? As one does ... ;-)
<wart_>
hi folks. i'm on a pinephone with the allwinner chip. I'm curious if there is a way to wakeup from CRUST through something other than an sms or incoming call, sort of like wake on LAN.
<wart_>
working on a script that will wake up the phone if it is in CRUST and perform an action from the phone. Right now I send an e-mail to my carrier +MYPHONE@tmomail.com and use that to trigger a wakeup, but thought I'd ask if there was a better way via the CRUST system itself.
veremitz has joined #linux-sunxi
wart_ has quit [Remote host closed the connection]
wart_ has joined #linux-sunxi
gsz has quit [Quit: leaving]
<gnarface>
hey wart_ did you try asking this in #pinephone on irc.pine64.org?