ftg has quit [Read error: Connection reset by peer]
montjoie_ has joined #linux-sunxi
montjoie has quit [Ping timeout: 480 seconds]
Daanct12 has quit [Quit: WeeChat 4.3.0]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
hexdump01 has quit [Ping timeout: 480 seconds]
fxqd has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
swiftgeek has quit [Ping timeout: 480 seconds]
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
gsz has joined #linux-sunxi
swiftgeek has joined #linux-sunxi
<loki666>
tokyovigilante I'll try a simpler buildroot image, but batocera boot but crash in the init
<loki666>
Is cpufreq supposed to works?
apritzel has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
apritzel has quit [Ping timeout: 480 seconds]
wingrime-ww has quit [Quit: WeeChat 4.2.2]
wingrime-ww has joined #linux-sunxi
<tokyovigilante>
loki666: in theory yes, in practice not currently included in my device trees or kernel tree as the upstream driver has not yet been committed, there are still a couple of queries on the mailing list, and I can only get 1.4GHz with the current opp table
<tokyovigilante>
the vendor BSP can achieve 1.5GHz@1.6v so I'm sure we can get there, just hasn't been highest priority
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
fxqd_ has joined #linux-sunxi
<tokyovigilante>
ok, v2 of the RG35XX display panel is on the list :)
fxqd has quit [Ping timeout: 480 seconds]
fxqd has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
fxqd_ has quit [Ping timeout: 480 seconds]
fxqd has quit []
<Jookia>
tokyovigilante: congratulations! seems like you'll have to port garlicOS or release an image for people to use now
apritzel has joined #linux-sunxi
pg12_ has joined #linux-sunxi
pg12 has quit [Ping timeout: 480 seconds]
pg12_ is now known as pg12
colinsane1 has joined #linux-sunxi
colinsane has quit [Ping timeout: 480 seconds]
Robot_ has joined #linux-sunxi
<apritzel>
tokyovigilante: loki666: H616 cpufreq support is merged, into v6.10-rc1, released last Sunday
<apritzel>
since we are doing upstream development here, you should rebase your branches on top of v6.10-rc1, and be it to improve the testing coverage on the new kernel
<apritzel>
and indeed at the moment we are limited to 1.4 GHz, whereas the vendor image goes up to 1.5GHz. But reportedly this isn't stable with mainline, for some odd and unknown reason
kikuchan has joined #linux-sunxi
diego71 has quit [Ping timeout: 480 seconds]
<kikuchan>
Jookia: apritzel: About PWM for kernel, do you think there is anything we can do towards the mainline for now?
<apritzel>
I saw the thread, but haven't looked into it in detail. But will do and reply there
<apritzel>
I was wondering if we really need all this complexity. For instance can't we just deny request for linked channels if they conflict?
<Jookia>
kikuchan: i'm honestly not sure what the solution is. i think getting the current PWM driver in would be best and then we can improve it later
<Jookia>
maybe get some feedback from real world use cases
<apritzel>
I mean the pairs are meant to be used for generating those complementary outputs. If you just need single PWMs, you could just choose different 1, 2, 4, for instance
<kikuchan>
Thanks. hmm...
<apritzel>
kikuchan: in general I feel Aleksandr's driver is the base to work on for now
<apritzel>
either we fix things that are wrong right now, or you make a patch on top of that to bring it to the state you have, if that has advantages
<kikuchan>
Oh, can I post modified version based on his driver to fix?
<Jookia>
yep :D it's open source
<kikuchan>
oh ok. I'll compose something.
<kikuchan>
how to label it btw? v10? RFC?
diego71 has joined #linux-sunxi
wingrime1 has joined #linux-sunxi
wingrime1 has quit []
wingrime1 has joined #linux-sunxi
<Jookia>
hmm. i think you could make it additional patches on top of the PWM driver, not copy the patchset entirely
<Jookia>
so like regular PATCH v1 but say it requires the PWM v10 patches
wingrime-ww has quit [Ping timeout: 480 seconds]
<kikuchan>
ok thanks!
Schimsalabim has quit [Read error: No route to host]
Schimsalabim has joined #linux-sunxi
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
dsimic is now known as Guest8051
dsimic has joined #linux-sunxi
Guest8051 has quit [Ping timeout: 480 seconds]
wingrime-ww has joined #linux-sunxi
wingrime1 has quit [Ping timeout: 480 seconds]
<apritzel>
yes, that would be the plan: post some improvement patches
<apritzel>
if they are considered good, we might either squash them or at least merge them back to back
<apritzel>
kikuchan: but you would need some rationale for the improvements
<wingrime-ww>
tokyovigilante: maybe you know why RG35xx plus don't have proper deep sleep mode?
<vaughngx4>
Trying to add support for this device: https://ibb.co/album/208yPZ labeled T199 v2.0 designed by EASiTEK ... It does not appear to be documented. Is magic.bin the same as script.bin? magic.bin (text) taken from nanda.img: https://pastebin.com/TJVdfiK1 FEL mode does not load boot1 AFAIK (bulk send error received when trying to read it) and UART appears to be disabled in the firmware (anywhere that appears to be missing a resistor reads the same
<vaughngx4>
voltage on either end). I used the DirtyCOW exploit to get temp root and dump partitions. sunxi_meminfo failed with permission denied and I ended up soft-bricking the device after flashing a magisk patched boot image (v22.1) out of frustration (trying to get proper root, I'm dumb). No idea how to get back into fastboot to flash the stock boot.img without physical buttons (aside from a "UBOOT RECOVER" button for FEL mode. Was booting into fastboot
<vaughngx4>
using ADB. So AFAIK I'm stuck with FEL mode for now. However, I do have dumps of all "by-name" partitions and whatever nand partitions I could read with temp root (nanda through nandn excluding nande). Struggling at this point. Great with Linux, first time doing low level stuff. SPECS: Allwinner H2+ SoC, 512MB GCAI RAM, 8GB Sandisk eMMC, XR819 WiFi chip, ethernet, HDMI, AV, IR and physical FEL mode button. Is there any conceivable way to force
<vaughngx4>
the device into fastboot mode? Failing which, where to from here? There is an address I found in env.img that may be helpful with forcing fastboot. recovery default.prop: https://pastebin.com/3v4qHN97 | strings env.img https://pastebin.com/5DjTn5Ru . Apologies for the lengthy message(s).
warpme has joined #linux-sunxi
JohnDoe_71Rus has joined #linux-sunxi
<wingrime-ww>
vanghngx4: first step usualy get UART
<wingrime-ww>
vanghngx4: and seems yours don't have any microsd card in it
<wingrime-ww>
vanghngx4: don't see any good options besides send uboot over uart and boot using ehernet
aggi has joined #linux-sunxi
vaughngx4 has quit [Quit: Client terminated!]
<wingrime-ww>
vanghngx4: or try solder usb adapter directly to emmc
<Jookia>
kikuchan: FWIW i think your solution of defining divisors in the DT is the best approach.
Schimsalabim has quit [Ping timeout: 480 seconds]
Schimsalabim has joined #linux-sunxi
vaughngx4 has joined #linux-sunxi
<vaughngx4>
wingrime-ww: Yes unforunately no MicroSD
<vaughngx4>
wingrime-ww: I'm having trouble getting UART but I'll try again tomorrow
<vaughngx4>
wingrime-ww: Can you elaborate on boot using ethernet? Was not aware that these devices could "netboot"
<vaughngx4>
At the bottom of the strings from env.img (string linked above) there are these two lines - "fastboot_key_value_min=0x2" and "fastboot_key_value_max=0x8". Could these be IR codes?
<vaughngx4>
vendor.img also defines some keys, maybe I can boot fastboot using a keyboard? strings vendor.img: https://pastebin.com/twqkKh62
Robot_ has joined #linux-sunxi
<wingrime-ww>
vaighngx4: I don't think thats IR codes. I Think it just button via lradc
<wingrime-ww>
vaighngx4: boot via ethernet is possble but you need uboot on emmc for it
<wingrime-ww>
vaighngx4: H2+ has good support for mainline linux/uboot, and you have good chances to boot from mmc card if you desolder emmc and solder some adatpter
<buZz>
H3 used to have good support too
<buZz>
oh
<wingrime-ww>
vaighngx4: Second option solder usb gadget cable and use fel-usb boot
<wingrime-ww>
buZz: H2+ and H3 almost same chip as I remembert
<buZz>
oldstuff nowadays, its not even ARMv8 :)
<buZz>
my old 3dprinter got a H3 (nanopi M1) cemented inside by me ages ago :D
<buZz>
still working well
wingrime-ww has quit [Quit: WeeChat 4.2.2]
wingrime-ww has joined #linux-sunxi
<vaughngx4>
I can access FEL via USB already. sunxi-fel ver returns "AWUSBFEX soc=00001680(H3) 00000001 ver=0001 44 08 scratchpad=00007e00 00000000 00000000". New to building uboot so I can't seem to create/find a working config to build uboot for this board
wingrime-ww has quit []
<Jookia>
vaughngx4: if you have a boot.img you could dump the device tree and use that to build u-boot and figure out what's missing
wingrime-ww has joined #linux-sunxi
<wingrime-ww>
vaughngx4: try find any device with H3 in uboot sources
<wingrime-ww>
vaughngx4: or H2+
<wingrime-ww>
vaughngx4: than boot uboot via usb-fel using wiki guide
<vaughngx4>
wingrime-ww: I've tried building uboot using a few different H3/H2+ configs but there's no way for me to see what's happening when I FEL/USBBoot because I don't have UART :-( Guessing I need to try a full image so I get output on HDMI if it works?
<vaughngx4>
Jookia: I do have a boot.img. How would I go about dumping the device tree? Been reading through the wiki quite a bit but I'm still struggling.
<vaughngx4>
Jookia: Thank you! I will get on this ASAP
<Jookia>
awesome :)
<vaughngx4>
Thanks everyone. Have to go now but I will take all advice given and update later or tomorrow.
<wingrime-ww>
vaughngx4: your uart connector are in a right conner nearby with emmc
<wingrime-ww>
vaughngx4: see GND TX RX markings? you just need usb adapter
<vaughngx4>
wingrime-ww: yeah I soldered that on myself. TX doesn't send any data :(
<wingrime-ww>
vaughngx4: thats can be normal
<wingrime-ww>
vaughngx4:you can upload uboot image via usb and see output
<wingrime-ww>
vaughngx4: SoC have many uarts and you just need select right in uboot config
<vaughngx4>
wingrime-ww: Oh? I was not aware. I'll leave it connected when I'm tinkering and see if I get anything thanks!
vaughngx4 has quit [Quit: Client terminated!]
<Jookia>
also make sure to connect RX on the connector to TX on the board and vice versa, and try baud 9600 and 115200
<wingrime-ww>
yeah best so test uart via loopback)
wingrime-ww has quit [Quit: WeeChat 4.2.2]
<Jookia>
no, i mean your USB connector has pins labeled TX and RX, and the board has a TX and RX. if you connect TX to TX it might be wrong and need swapping
wingrime-ww has joined #linux-sunxi
wingrime-ww has quit []
wingrime-ww has joined #linux-sunxi
Robot_ has quit [Ping timeout: 480 seconds]
warpme has quit []
hexdump0815 has quit [Quit: WeeChat 3.8]
hexdump0815 has joined #linux-sunxi
vaughngx4 has joined #linux-sunxi
<vaughngx4>
Jookia: I did see "ttyS0, 115200" somewhere in the strings. Also tested TX with a mutlimeter got 0.00V. Yes I have TX -> RX and RX -> TX. Definitely no output.
<Jookia>
hmm yeah it might be that it isn't the uart the boot rom uses
apritzel has quit [Ping timeout: 480 seconds]
vaughngx4 has quit [Quit: Client terminated!]
<wingrime-ww>
vaughngx4: try test usb uart dongle, connect TX to RX pins, and launch picoterm or miniterm, when TX-RX connected you will see what you type
<wingrime-ww>
vaughngx4: multimeter not usable for such fast changing signals, osciloscope needed
<Jookia>
$8 sigrok logic analyzer would work for this
<wingrime-ww>
Jookia: good option
vaughngx4 has joined #linux-sunxi
<vaughngx4>
wingrime-ww: Yeah I did that as a sanity check the other, key presses are indeed printed. Alos tested with another device I have (Tanix tx6) and I got kernel logs so the USB adapter is working fine. No need for a logic analyser, the UART output is definitely blank. Even if baudrate was wrong it would output gibberish but I'm getting nothing at all in picocom
Schimsalabim has quit [Read error: Connection reset by peer]
Schimsalabim has joined #linux-sunxi
Robot_ has quit [Ping timeout: 480 seconds]
wingrime1 has joined #linux-sunxi
wingrime-ww has quit [Ping timeout: 480 seconds]
vagrantc has joined #linux-sunxi
gsz has quit [Ping timeout: 480 seconds]
<tokyovigilante>
Jookia: I'm working with the muOS chaps, we have bodged the kernel into Batocera and it works with GPU which is great, I'm working on a minimal Alpine image as a base but harder than I thought to convert the miniroot fs to a functional userspace, so might try just putting the installer image on another SD partition and doing it that way. Very educational trip through the bowels of the system
<tokyovigilante>
apritzel: thanks, I did note that, will make a cpufreq patch for the RG35XX DTS. Will do some more testing and try to get the 1.5Ghz bin working too
<tokyovigilante>
wingrime1: I don't entirely myself but understand there is extra firmware (crust) which would generally run on a separate RISC-V core in most Allwinner chips, but not in the H616 series, which stays powered up during sleep to handle interrupts. We would have to more or less bodge this on the H616, keeping a single ARM core running. I think there was some discussion a day two ago with comment
<Jookia>
isn't there a suspend to ram or something where you save the current registers, then next boot you reload them
<apritzel>
Jookia: suspend-to-RAM means you turn off as many devices as you can, but keep the RAM alive, then go into the deepest sleep you can
<apritzel>
there is also suspend-to-disk, where you save the content of the RAM into the swapfile, then turn the system off
<apritzel>
on the next boot you restore that and continue operation
<apritzel>
I don't know if the latter is too useful, though it typically is easier to implement, as it's mostly a kernel thing, with little to no firmware or hardware assistance
<apritzel>
for suspend-to-RAM you want to set the DRAM controller to self-refresh, then you can turn off a lot of devices, including most clocks
<apritzel>
but in general "suspend" is not the problem, it's (successful) "resume" that is tricky ;-)
<apritzel>
the cute thing about the ARISC equipped SoCs is that those management cores run mostly in a separate power and clock domain, so you can turn the real power guzzlers off, and just run on fumes
<apritzel>
whereas on the H616 you have to carefully select all the clocks and buses that we need for wakeup and DRAM refresh, and try to turn the rest off
<apritzel>
which is doable, but requires quite some research and experimentation, plus we need some software framework to pull this off. Not sure if crust can run AArch64 code in 32K of SRAM, for a start
<apritzel>
so if someone is bored and is looking for a challenge, that's doable, I think, but tricky
loki666 has quit [Quit: Ping timeout (120 seconds)]
loki666 has joined #linux-sunxi
vaughngx4 has joined #linux-sunxi
<tokyovigilante>
realistically for the use cases I have just saving a userspace application state (ie game save-states in libretro) is sufficient, then I am happy to just power off. My other use case is basically an iPod, so music player with the ability to disable the buttons and turn screen off, so I wouldn't want the device to suspend in that case. But I'm sure plenty of others would like some sort of
<tokyovigilante>
suspend. I'm not 100% sure how the vendor BSP is doing it but I'm sure we can look at some discovery between us.
<apritzel>
yeah, I was wondering how much use suspend-to-RAM is when you can boot quickly enough in some gaming system
<apritzel>
at least it might not be worth the trouble for this use case
<apritzel>
though people expect some quick suspend/resume functionality from modern mobile devices nowadays
<apritzel>
tokyovigilante: and indeed we can start easy: let the kernel power off most devices (panel, DE, GPU, USB), turn all but one core off, and send the last one into WFI
<apritzel>
but not sure how long the battery lasts in this setup
<apritzel>
I am not really experienced in this field, but my understanding is that this should work already, since it's generic Linux and PSCI functionality
vagrantc has quit [Quit: leaving]
<apritzel>
tokyovigilante: do you have some devices using the IOMMU working? Either DE or the video engine?
ftg has quit [Read error: Connection reset by peer]
<tokyovigilante>
apritzel: no, well I have the IOMMU patches from Jernej for the VE, but having that enabled (with or without the 4GB patch) causes display corruption on the LCD
<tokyovigilante>
I don't need it for basic LCD support, so my plan was to get the LCD upstreamed +/- GPU in whatever fashion, then get the VE and HDMI (since they are complementary for HW-accelerated video) on as RFC patches
<tokyovigilante>
Realistically the DE33 probably needs to be RFC first too
<apritzel>
tokyovigilante: I sent some IOMMU patches, based on jernej's patch, but with more prose in the commit messages and in proper shape otherwise
<apritzel>
would be great if you could test this, if you have some setup that uses the IOMMU
<vaughngx4>
So I looked up how to get the device tree from boot.img or recovery.img and I don't seem to have one. Tried a script that separates an appended dtb from the kernel as well but it can't find anything either. Did the devs really put the dtb on it's own partition? Or am I missing something?
<apritzel>
vaughngx4: you can use binwalk to search for the DTB magic in any image file
<vaughngx4>
apritzel: I installed binwalk. Apologies if this is a silly question, I'm new to this. What is this DTB magic you speak of?
<apritzel>
vaughngx4: the magic bytes at the beginning of each DTB. binwalk looks for those clues to find any kind of structured data in a binary image
<apritzel>
so you just let it run on your image file, and it will identify kernels, DTBs, gzip'ed files, you name it
<vaughngx4>
apritzel: Ah okay I thought I had to specifiy the magic. That makes sense thank you! I'll write a quick bash loop to test all my dumped images now.
<apritzel>
vaughngx4: binwalk can be pretty verbose, and it leaves you still with the task of extracting the DTB