00:30 <macromorgan> okay cool. I just had some folks ask if I could make an image of a debian bookworm system for them (it's what I use for dev work) and I wanted to start with all the correct patches. I'm still actually using an A-TF branch that can't control the PMIC currently...

00:54 <tokyovigilante> apritzel: agreed, they are more or less arrived-at by trial and error currently, and probably not quite right given the odd detection failure at bootup.

07:31 <tokyovigilante> outstanding, got the kernel booting over tftp

08:56 <tokyovigilante> Do I still need initramfs support if I'm building a minimal kernel without modules? have disabled initramfs and loadable module support so the tftp-ed image is standalone, but my wifi/bt firmware won't load, even with the drivers built-in

09:15 <tokyovigilante> ah, seems a driver can't load firmware from filesystem if the filesystem's not mounted yet...

09:26 <tokyovigilante> well, that's the evening... got a fully-scripted tftp-boot going though with a minimal kernel config, so that's ideal. Will get into the u-boot effort next. Shall I just throw the DRAM patches out first for comment? That will be the most controversial I think, as they're all basically either magic numbers or guesses

09:35 <apritzel> tokyovigilante: please try to avoid too custom or minimal kernels, that just limits what people can do with that

09:36 <apritzel> actually people should not bake their own kernels, rather leaving that to the distributions

09:36 <apritzel> if you *need* a custom kernel, base that on something public, like a distro kernel, and use that config

09:37 <apritzel> or use mainline and defconfig, and just *add* the options you need

09:38 <Jookia> yeah, make a distro kernel and add patches to it if you can

09:39 <tokyovigilante> Oh this is literally just to make it easier for me to write the sound driver, I'm not intending this for any distribution

09:39 <tokyovigilante> just neat to have it all working together

09:39 <tokyovigilante> Ideally we will just get everything mainlined and people can just run a distribution or buildroot away

09:40 <Jookia> ah ok

09:40 <tokyovigilante> plus I am learning everything I never wanted to know (or even knew existed) about the kernel

09:40 <Jookia> Were you in to embedded Linux before this, or are you now down the rabbit hole? :)

09:40 <tokyovigilante> have got my EDR cycle down to about a minute and one command (and one USB unplug-replug), which makes it pretty painless

09:40 <tokyovigilante> no not at all

09:41 <apritzel> tokyovigilante: if in doubt, just leave an option in. Otherwise this just comes and bites you later, when you suddenly need a feature or want to try something

09:42 <tokyovigilante> apritzel: sure. this is just a good experiment. now I know how to do it I can roll back to the full config

09:42 <apritzel> tokyovigilante: for development I'd just go with defconfig plus the required sunxi drivers compiled in

09:42 <apritzel> this simplifies updating the config over various kernel versions

09:43 <apritzel> I have my .config under git version control (in a separate build directory), so I can switch between kernel versions, and also you can have branches for things like "tiny config"

09:44 <apritzel> this also prevents you losing a once working config accidentally

09:47 <tokyovigilante> sounds good, will give it a go

09:47 <tokyovigilante> the more I think about it, am I gaining anything using the USB gadget over FEL-boot and just uploading the kernel?

09:47 <tokyovigilante> *gadget ethernet I mean

09:49 <apritzel> the Ethernet gadget is much faster. But if you do FEL booting anyway, it's actually simpler to upload all in one go, via FEL

09:50 <tokyovigilante> seem to have so much flux in both u-boot and kernel, makes sense to have both over FEL and just use the SD card image for userspace

09:50 <apritzel> a 20MB kernel (Image.gz) takes about 80 seconds via FEL, with gadget Ethernet it's more like 5 seconds

09:50 <tokyovigilante> although either way I'd need to build an initramfs for modules and firmware I assume?

09:50 <tokyovigilante> ah yup

09:51 <tokyovigilante> ok, will stick with my frankensetup for now then

09:52 <apritzel> for kernel development I'd go with either userland on a proper SD partition, or a fixed initramfs, on the SD card as well. The latter is better if you crash the kernel often

09:52 <apritzel> not sure how many userland tools you need for audio testing, might be easier to use a proper distro for that

09:53 <tokyovigilante> still using my fedora image with the ALSA user tools and pipewire

09:53 <apritzel> for my basic kernel testing I have a ~3 MB initrd, with the basic tools I need, that's quick to load, even via FEL

10:22 <tokyovigilante> am just testing out the clock calibration patch from the list also, and it seems the H616 structs aren't actually in the mainline kernel?

10:22 <tokyovigilante> maybe in clk-next actually

10:33 <tokyovigilante> hmm, in fact it seems https://lore.kernel.org/linux-rtc/20210802003952.19942-8-andre.przywara@arm.com/ never actually got merged

10:35 <apritzel> it somewhat did, but not in this form

10:35 <apritzel> don't remember the details, but I think we figured the actual RTC *clock* bits are the same as for the H6, hence don't need a separate structure?

10:41 <apritzel> ah no, scratch that, commit 8a93720329d4d2 gives a hint: the H616 RTC clock parts are now in drivers/clk/sunxi-ng/ccu-sun6i-rtc.c. Check the git log for that file ...

10:41 <apritzel> tokyovigilante: but good find, that means that this patch is based on some bogus tree?

10:42 <tokyovigilante> yeah by the looks

10:43 <tokyovigilante> was just digging through the archives and see there was a v3 then v4 patch (yours) which split up the implementation

10:45 <tokyovigilante> sorry a v9 then v10

10:45 <tokyovigilante> so in theory the H6 changes should be enough for the H616

10:47 <apritzel> there was a revert from jernej a while ago: initially both the H6 and H616 RTC clocks were handled in the new driver, but the H6 got moved back: 60d9f050da63b71

10:56 <tokyovigilante> that revert doesn't seem to touch the h616 struct though, it looks like it never made it in.

10:58 <tokyovigilante> the rest of the patch applies and the h616 is listed as compatible, so will give it a quick test and reply to Alois

10:58 <tokyovigilante> interested to see if it helps with the bluetooth out-of-order packet issues I've been seeing

10:58 <apritzel> tokyovigilante: so thanks for the heads up, replying as well

10:59 <apritzel> but I don't think this patch will work in this form, the H616 *clock* is only handled in the new driver

10:59 <tokyovigilante> np, ah right. I will leave you to respond then

11:00 <apritzel> (note the confusing subtleties between the clock parts and the RTC parts: there is no CLK_OF_DECLARE_DRIVER line for the H616 in rtc-sun6i.c)

11:01 <apritzel> please feel free to respond anyway, I will CC: you on my response anyways

11:02 <tokyovigilante> have done. So you don't think just enabling the bits is sufficient?

11:14 <apritzel> the patch would need to be ported to ccu-sun6i-rtc.c. Conceptually it's still the same, but the structs are different

18:29 <macromorgan> tokyovigilante: are you still booting from FEL? I'm using your branch for U-boot and think I'm back to square 1 with U-Boot.

19:21 <Raqbit> I just spent a long time trying to figure out why TF-A was only partially compiling (and not giving a build artifact) - turns out it doesn't compile bl31 if you have the $BL31 env variable set

19:45 <Jookia> that kind of makes sense

20:05 <tokyovigilante> macromorgan: the rg35xx-upstream branch i posted a day or two ago should work, its what i'm using currently. also works fine written to a card, although i need to formally test apritzel's 256k offset patch

20:05 <tokyovigilante> what trouble are having?

20:06 <tokyovigilante> Raqbit: that story sums up most of my devwlopment efforts ;) I see my first kernel patch has had its first correction...

20:06 <tokyovigilante> exit

20:16 <macromorgan> what offset do you write it to (without the 256k patch)?

20:16 <macromorgan> that could be my issue

20:16 <macromorgan> I've been using 8k

20:16 <macromorgan> I honestly don't remember how I got it to work last time, I think my offsets were off maybe

20:29 <Raqbit> tokyovigilante: With the rg35xx-upstream u-boot branch & the TF-A PMIC patch sets I get as far as I did previously - nothing from the UART after "Trying to boot from FEL", and no fel communication is possible after

20:39 <macromorgan> dammit, I think this is the memory issue that I had and fixed before, but since forgot (and accidentally deleted my defconfig too)

20:58 <macromorgan> nope... back to square one where a `make mrproper` and then a `make anbernic_rg35xxh_defconfig` doesn't get me booting. Darn.

20:58 <macromorgan> will have to troubleshoot more