00:15 <apritzel> thanks!

03:42 <tokyovigilante> macromorgan: there is also a interrupt-parent = <&r_intc>; /* test */

03:42 <tokyovigilante> in the axp717 define which is defined for other SoCs (up to the H6) but not for the H616

07:37 <Jookia> time for some late night review >:D

08:00 <Jookia> ok, done

08:38 <tokyovigilante> nice Jookia!

08:38 <tokyovigilante> Have just sent my first go at the RG35XX DTS - https://lore.kernel.org/linux-sunxi/20240414083347.131724-2-ryan@testtoast.com/T/#t

08:46 <Jookia> tokyovigilante: awesome work!

09:31 <gamiee> hi apritzel , please, did you had a chance to look on my sunxi-tools sid-write pr? Thanks

10:53 <warpme> apritzel : many thx!. This helps :-) Now i'm not sure what: kernel cmd. line should i use to get kernel to use such to ram loaded initrd image with ext2 fs?

11:03 <Jookia> tokyovigilante: are you using b4 to handle patches?

11:06 <apritzel> warpme: so initrd these days really means "initramfs", so it's a tmpfs filesystem in RAM. So it's a RAM disk with a builtin filesystem, if you like

11:07 <tokyovigilante> just git send-email currently

11:07 <tokyovigilante> b4 for downstreaming

11:07 <apritzel> warpme: I don't think it makes much sense to use a separate filesystem in a RAM block device

11:08 <apritzel> warpme: and you should be able to use the eMMC on the TX1, and you can copy a rootfs image over via USB stick

11:09 <Jookia> tokyovigilante: i would highly suggest using b4 for patches, it handles versioning, CCing, and helping you write a cover letter and send-email

11:10 <tokyovigilante> ok will give it a go

11:10 <apritzel> Jookia: though I only use git send-email as well, and for low volume patches it's totally fine, I think

11:10 <Jookia> tokyovigilante: i noticed some of your patches have a 'From:' in the body, so you might want to check your patch From: and email From: are the same. not sure

11:10 <Jookia> apritzel: yeah i kind of just struggle with git send-email and manually versioning, it just throws my anxiety through the roof

11:11 <Jookia> just some suggestions :)

11:11 <apritzel> "git format-patch -v2 --cover-letter ..." also gives you a cover letter template and versioned patches

11:11 <apritzel> and I *always* send a patch series to myself first, to see what git send-email makes of it

11:11 <Jookia> yeah

11:11 <Jookia> b4 automates a lot of that

11:13 <apritzel> b4 probably helps with individual per-patch recipients, but I don't need that very often

11:13 <Jookia> ah ok

11:14 <apritzel> Jookia: but if you are happy with b4, that's great, keep using that

11:14 <Jookia> yeah! :D

11:15 <tokyovigilante> Just nosing through the b4 docs, thanks both. Managed to muddle through send-mail ok but b4 does look nice for when I become a fulltime kernel developer ;)

11:16 <apritzel> warpme: which DT did you use for the TX1? Did you see my post from like two weeks ago? https://lore.kernel.org/linux-sunxi/20240330013243.17943-1-andre.przywara@arm.com/T/#u

11:16 <apritzel> warpme: if that works for you, can you please reply to the list, which would help that getting merged?

11:19 <warpme> apritzel : "can copy a rootfs image over via USB stick" - this is one from options i'm considering. My idea is following: 1)boot kernel via sunxi-fel with boor.scr having kernel cmd.line having "root=/dev/sda2 rw rootwait"; 2)when kernel boots, remove USB cable used for sunxi-fel and plug USB key with rootfs (part2); 3)i hope kernel will continue booting using plugged usb as rootfs so i will get finally cmd.prompt; 4)copy bootloader

11:19 <warpme> + rootfs from usb to emmc; 5)box should boot from emmc. What you think?

11:20 <Jookia> warpme: have you considered using nfs root + usb ethernet gadget

11:22 <apritzel> warpme: is that just for you to get something on the board, or is more a recipe for MiniMyth users?

11:22 <warpme> yeah - that was my idea as well but idk how to get usb eth gadget hw? I have usb-eth dongle (asix based)

11:23 <warpme> apritzel : this is by minimyth2 user request (he donated me hw) - so i'm playing a bit now :-)

11:24 <Jookia> warpme: no, as in g_ether in kernel- then you boot using fel, then upload kernel using fastboot, then run rootfs using nfs. but if that's too complicated, usb rootfs might work

11:24 <apritzel> tokyovigilante: the structure of your post and the commit messages look really neat, especially for a first time post. I will dive into the details later today - the sun just came out ;-)

11:25 <apritzel> warpme: did you know that you can upload a bootscript via FEL, and U-Boot automatically executes that?

11:26 <apritzel> so you should be able to issue to commands to expose the eMMC as a block device on your host PC, which then would allow people to just "dd" an image, or even fdisk & mount partitions

11:27 <apritzel> I mean using U-Boot's "ums" command, via USB-OTG, so it's the same setup as you are using for FEL

11:29 <apritzel> so the users would issue the sunxi-fel command, with just the U-Boot image uploaded, and a few seconds later a new /dev/sdX would appear on the host PC

11:30 <apritzel> which is unfortunately somewhat theoretical atm, as eMMC access from U-Boot on the H616 is broken for some odd reason

11:31 <apritzel> but it works in Linux, so you could do the same scheme, just a bit more complicated via the kernel and some initramfs

11:32 <apritzel> and btw: this also means that loading the kernel from the eMMC does not work atm, which spoils more use cases atm, especially for the TX1 having no SD card

11:33 <apritzel> gamiee: I had a look, just no real idea what's best, though qianfan's suggestion doesn't sound too bad

12:15 <warpme> apritzel: "did you know that you can upload a bootscript via FEL, and U-Boot automatically executes that?" - yes. it works for me perfectly. WIth boot.scr having "booti 0x40200000 - 0x4fa00000" i'm getting nicely loaded and booted kernel to stage where it awaits for rootfs.

12:18 <warpme> apritzel: "so you should be able to issue to commands to expose the eMMC as a block device on your host PC" - i was not aware that such thing it possible in sunxi-fel? This will be probably best solutin for ppl trying to get mainline (i.e. archlinux by miniarch) distro on tx1

12:20 <warpme> apritzel: "eMMC access from U-Boot on the H616 is broken for some odd reason" - i got it working so all my h313/h616/h618 currently are booted/working from emmc (can save sd cards in my home uLab)

12:47 <gamiee> apritzel : thanks for answer. Qianfan's answer is indeed not bad, but I do not know how to solve the endianess, as that seems to be important for keys and stuff. Anyway, we can still have both of them. Also, raw sid write is useful for SoCs, which does not have implemented SID fields table in sunxi-fel tool.

13:24 <apritzel> gamiee: that is part of why I like that idea: it would make it less error prone. And if you have an unlisted SoC, you can always add that section that you want to write to.

13:26 <apritzel> gamiee: eMMC access in U-Boot: "i got it working": care to share? Didn't find any patch in your minimyth2 repo

13:26 <apritzel> nope, that ^^^^ was for warpme

16:17 <macromorgan> tokyovigilante: let me know if you need help cleaning up that tree.

16:18 <macromorgan> One of the first things you should do before you submit is to run `make dtbs_check` FYI

16:18 <macromorgan> I find it helps to run make dtbs_check first, ignore all the output, do a `touch arch/arm64/boot/dts/my-devicetree.dts`, then run make dtbs_check again so you only see the output for your new trees

16:21 <macromorgan> and also any time you modify a *.yaml file you should do a `yamllint Documentation/devicetree/bindings/my_updated_file.yaml` followed by a `make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/my_updated_file.yaml`

16:29 <apritzel> macromorgan: tokyovigilante: "make W=2 CHECK_DTBS=y allwinner/sun50i-xxx.dtb" is the explicit shortcut for that "just check a single DTB" operation

16:30 <apritzel> or use the raw form directly: dt-validate -m -u /src/linux/Documentation/devicetree/bindings -s /src/linux/Documentation/devicetree/bindings your.dtb

16:30 <macromorgan> I guess that could work too :-)

16:31 <macromorgan> I kind of wanted to finish testing each of the regulators before we pushed upstream, and fix the NMI thingimabob

16:31 <apritzel> yeah, dunno about you, but on my box "make dtbs_check" takes ages

16:32 <macromorgan> make dtbs_check -j32 takes about a minute

16:32 <macromorgan> helps with a 16 core Ryzen and enough RAM to fit the entire build tree into cache though

16:33 <apritzel> macromorgan: so did changing the regmap_range fix the interrupt issue?

16:42 <macromorgan> let me check, I honestly didn't try that yet

16:43 <macromorgan> yeah, I see it now... the range doesn't include where I can write to disable the IRQ

16:43 <macromorgan> err, ack the IRQ I mean

16:44 <apritzel> exactly, would perfectly explain what you see

16:47 <macromorgan> okay, added a range and that fixed the problem

16:47 <macromorgan> no more errors, power button works

16:48 <apritzel> \o/

16:48 <macromorgan> I added another range instead of expanding the existing one because the IRQ enable stops at 0x44 and the IRQ status starts at 0x48

16:48 <macromorgan> but yeah, simple fix and now we've got interrupts from the PMIC!

16:49 <macromorgan> I'll push an upstream patch enabling the NMI on the 616 if anyone else is available to test it that would be great

16:49 <warpme> apritzel : I wax not aware that sunxi-fel is able to issue to commands to expose the eMMC as a block device on your host PC. Looking on sunxi-fel help i can't find relevant command...

16:50 <warpme> wax->was

16:54 <apritzel> warpme: sunxif-fel does not support this, but U-Boot does, with its "ums" command. So all you need to do is to upload and start U-Boot, then trigger the mass storage export: ums 0 mmc [devno:part]

16:54 <warpme> apritzel : re: your Q about DT im using in uboot for TX1 - yes - i'm using your code deom ML (many thx). And when i'll get it all working - for sure i'll drop comment (and kudos) on ML!

16:55 <apritzel> for ums you need to enable CONFIG_CMD_USB_MASS_STORAGE in U-Boot, and maybe something else

16:56 <warpme> apritzel : when you saying "trigger the mass storage export: ums 0 mmc [devno:part]" - do you meant issuing this command on uboot console (via uart) - or i can do this "remotely" from Linux PC?

16:56 <warpme> asking as i'm trying to find solution not requiring any soldering....

16:56 <apritzel> on the U-Boot console, so either explicitly via the UART, or via the boot script

16:57 <warpme> ah - indeed - i can do this via boot.scr upload in sunxi-fel

16:57 <apritzel> the boot script method should work without any UART

16:57 <warpme> ideed. qll. let me try this

16:58 <apritzel> people would still need a non-standard USB-A <-> USB-A cable, though

16:58 <apritzel> due to the lack of an SD card slot this device is an interesting challenge, for the casual user

17:00 <apritzel> one comfortable method would be to install an SSH server on the vendor Android, but not sure the "su" to get root works on this level

17:00 <apritzel> (it certainly does on the UART prompt, and I could dd something from a USB stick to the eMMC)

17:01 <apritzel> but that requires opening the device, soldering something to the UART pins and then connecting a serial adaptor, which is not very end user friendly

17:06 <macromorgan> NMI patch series: https://lore.kernel.org/linux-sunxi/20240414170424.614921-1-macroalpha82@gmail.com/

17:07 <macromorgan> so this plus the regmap_range fix gets you a working power button on the AXP717/H700 series

17:08 <warpme> so now i see chicken-and-egg problem: to map emmc as mass storage i need to provide: [devno:part]. But vanilla device has android partitions layout (15 or so partitions) - while my distros are operating on 2 partitions.... Ideally will be to have possibility to do: dd of sd card image file to emmc (i'm doing this in my distros when user wants to install on system on box internal emmc)

17:09 <apritzel> warpme: if you leave out the :partition number, you get the whole block device

17:10 <warpme> ah qll!

17:10 <apritzel> IIRC on this device the big data partition was not ext4?

17:11 <apritzel> I typically just untar a rootfs to this partition, which does not affect any of the Android data in there (non-overlapping directory names), so you can keep the vendor firmware, but still use a proper Linux rootfs and a mainline kernel

17:19 <warpme> hmm: i'm getting "=> ums 0 mmc Unknown command 'ums' - try 'help'" Time to add CONFIG_CMD_USB_MASS_STORAGE=y and CONFIG_USB_USB_GADGET and CONFIG_BLK in defconfig?

17:23 <apritzel> yes, the ums command is not enabled by default for sunxi

17:43 <warpme> apritzel : issue => ums 0 mmc 1 gives on uart "UMS: LUN 0, dev mmc 1, hwpart 0, sector 0x0, count 0x1d1f000" and hell of "|/-\|/-\/-" is this ok? If so - i can't find new mass storage dev on linux host....

17:54 <apritzel> yes, this is the expected response on the UART, though of course there should be a mass storage device. Do other USB gadget commands (dfu, fastboot, Ethernet) work?

17:58 <warpme> hmm - there is no /dev/sdb device and in dmesg i see: https://gist.github.com/warpme/56b3a97c267b00a39c88f6130b8942d2

18:02 <warpme> maybe i need to reuse my "windows expertize": just reboot and pray?

20:42 <tokyovigilante> apritzel: macromorgan: thanks for the review, I did know about make dtb_check and then forgot to actually run it, like a rookie. Have started work on v2.

20:42 <tokyovigilante> macromorgan: great work regarding the NMI patches too, all coming together nicely

20:43 <tokyovigilante> SD2 card slot working with the extra regulators too which is nice, at least the card-detect.

20:52 <tokyovigilante> Just for clarity, is the DTS standard 4-space tabs? All the docs say 8 spaces, but all the committed files have 4-space tabs.

20:55 <macromorgan> it's a tab character

20:55 <macromorgan> so no spaces

20:55 <macromorgan> ./scripts/checkpatch.pl should yell at you if you try to use spaces I think

20:56 <macromorgan> also one other thing... hold off on the LEDs if you can, I'd like to define them as PWMs but I have to get that working first...

21:00 <tokyovigilante> ta, will add that to the list of checks

21:01 <tokyovigilante> that's cool, I haven't done anything with them myself. I'll try and get this done, then sound, and perhaps leave you the backlight, and Jookia has a T113 RGB implementation that he will hopefully share at some point