<DC-IRC> <Tonymac32> I think the only functional line here is the delay between setting the PLL and taking it out of reset (line 342-3). Shortening the delay on checking if you have lock/timing out sooner shouldn't be doing anything at all
<DC-IRC> <Tonymac32> I would suspect there should be some sort of status bit you can watch for this, but given the typical Amlogic situation with clocks in general who knows
<DC-IRC> <Tonymac32> I wish I had access to any documentation, PLL's don't just "turn on", which is why I think the delay is the key, but that only makes sense if the PLL being released from reset is just gating, and the clock was "running" as soon as the enable bit was flipped. Gating it out before it's ready might cause it to be unstable. I'm not 100% sure on the role of meson_clk_pll_wait_lock(), but that check might need to go before releasing the
_whitelogger has joined #armbian-amlogic
<DC-IRC> <Spectrefield> Can I share the log here ?
<DC-IRC> <Tenkawa> @Spectrefield use https://paste.armbian.com
<DC-IRC> <Spectrefield> I have copied the execution start to the compilation and the end
<DC-IRC> <Spectrefield> I'm not able to upload all the log due to an error "something went wrong"
<DC-IRC> <Tenkawa> Were you using the updated builder options or were these ones you've used in the past?
<DC-IRC> <Spectrefield> Shall I choose the good github branch or commit or the kernel version edge instead of current ? and Linux version ?
<DC-IRC> <Tenkawa> I ask because the builder has changed dramaticly in the laat few weeks
<DC-IRC> <Spectrefield> Repeat build: ./compile.sh build BOARD=radxa-zero BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=no BUILD_ONLY=kernel EXPERT=yes RELEASE=jammy
<DC-IRC> <Tenkawa> the build options/syntax has changed
<DC-IRC> <Tenkawa> so if you were using something you had used in the past it may not work as is
<DC-IRC> <Spectrefield> ah ok, no its the first to me 🙂
<DC-IRC> <Spectrefield> ah ok, no its the first forme 🙂
<DC-IRC> <Tenkawa> ok.. good to know
<DC-IRC> <Spectrefield> ah ok, no its the first time for me 🙂
<DC-IRC> <Tenkawa> I think @rpardini is going to have to look at that output to say more...
<DC-IRC> <Spectrefield> ok thanks for all 🙏
<DC-IRC> <Spectrefield> I will tried with past tag for now
<DC-IRC> <Spectrefield> and with edge version
<DC-IRC> <Tenkawa> my radxa zero wont even run anymore
<DC-IRC> <Tenkawa> no matter what I try to install on it
<DC-IRC> <Tenkawa> heh
<DC-IRC> <rpardini> Hey Spectrefield, build with `SHARE_LOG=yes` please and share the url here
<DC-IRC> <rpardini> Hey @Spectrefield, build with `SHARE_LOG=yes` please and share the url here
<DC-IRC> <rpardini> But yeah you've got a `vmlinuz-6.1.27-rt8-meson64` which is not expected by the build system
<DC-IRC> <rpardini> did you patch?
<DC-IRC> <rpardini> You can patch no problem, but don't force the version, and it should work.
<DC-IRC> <rpardini> @Tenkawa Thanks for helping out, but please, in the future, instruct people to use `SHARE_LOG=yes` instead of pasting manually, it almost always results in a garbled log....
<DC-IRC> <Tenkawa> @rpardini SHARE_LOG is new to me
<DC-IRC> <Tenkawa> I only use the tools I know
<DC-IRC> <Tenkawa> and I don't see it on https://docs.armbian.com/Developer-Guide_Build-Options/
<DC-IRC> <Tenkawa> So the docs need to be updated.
<DC-IRC> <c0rnelius> That's because Radxa had a meeting after the 1.4 was released titled "How can we make this worse?" and followed through with the suggestions.
<DC-IRC> <Tenkawa> haahaaa
<DC-IRC> <Tenkawa> sounds like it
<DC-IRC> <c0rnelius> @rpardini What is stopping Armbian from making all these VARIABLES you need to add after ./compile.sh 'lets call it a user profile?' that can be sourced to cut down the need to write all that out every time?
<DC-IRC> <c0rnelius> Best use case could be apart of the profile and the `compile.sh` script could create it before moving forward. After which a user could, make slight adjustments to his/her profile and just run `./compile.sh`
<DC-IRC> <c0rnelius> after which, of course.
<DC-IRC> <rpardini> Well you definitely can. Write all your options to `userpatches/config-c0rnelius.conf` (it's just bash/sourced). Then run with `./compile.sh c0rnelius`
<DC-IRC> <rpardini> Yeah, this is new since January I think. Every build reminds you of that in the last few lines.
<DC-IRC> <rpardini> Yeah, this is new since January I think. Every build reminds you of it in the last few lines. (unless you use it!)
<DC-IRC> <c0rnelius> Is there a template for this?
<DC-IRC> <c0rnelius> Meaning does the user base of armbian know? and why not just make that the default?
<DC-IRC> <rpardini> I guess there is, but you don't really need it. Just write the VARIABLE=values there, one per line.
<DC-IRC> <rpardini> I dunno, config files existed before I existed, lol. I just kept what was in there.
<DC-IRC> <c0rnelius> userpatches seems like a strange place to put a general build option for the builder.
<DC-IRC> <rpardini> oh _tell me about it_
<DC-IRC> <rpardini> we've tried to change a few years ago, which lead to a generalized meltdown. people really love their way of working.
<DC-IRC> <rpardini> we've tried to change a few years ago, which led to a generalized meltdown. people really love their way of working.
<DC-IRC> <rpardini> but yeah if you read "userpatches" as "user_stuff"... makes more sense
<DC-IRC> <c0rnelius> i get it
<DC-IRC> <c0rnelius> i think patches and my mind goes to kernel or u-boot.
<DC-IRC> <rpardini> yeah, you're absolutely right.
<DC-IRC> <c0rnelius> Not my personal preferred builder choices.
<DC-IRC> <rpardini> If we can manage to get a release out eventually....
<DC-IRC> <rpardini> next cycle I'd do more general reorg, including getting rid of "./compile.sh" and "userpatches"
<DC-IRC> <rpardini> "compile"? most times the stuff is all prebuilt in caches already and there's 0 compilation happening
<DC-IRC> <c0rnelius> I agreed
<DC-IRC> <c0rnelius> I agree
<DC-IRC> <Spectrefield> Ok I have compiled successfully an image without any patch and I have started one now with the preempt_rt patch. It is correctly applied and the option is available in the kernel settings. Waiting for a results...
<DC-IRC> <Spectrefield> it is ko
<DC-IRC> <Spectrefield> it is ko but the only one change is the preempt_rt patch
<DC-IRC> <Spectrefield> at line 175 it seems an error in the patch application, but why ? the version patch-6.2-rt3 seems the good one for the edge branch that follows the kernel.
<DC-IRC> <Tenkawa> @Spectrefield remember... these are not mainline kernels
<DC-IRC> <Tenkawa> These are vendor kernels so many of them have patches/changes in them
<DC-IRC> <Spectrefield> exact this could be fatal
<DC-IRC> <Tenkawa> Some devices run mainline... however it appears you are building for the Rock64 and I don't think that one has made it yet.. (don't quote me though)...
<DC-IRC> <Tenkawa> hmmm it might be
<DC-IRC> <Spectrefield> it is for a Radxa Zero, but it's true that I missed that the kernels can be adapted to the target
<DC-IRC> <Tenkawa> ahh yeah you did say the zero
<DC-IRC> <Spectrefield> it looks bad with previous release too...
<DC-IRC> <Tenkawa> In another project I work on we have hundreds of patches to offset this conundrem
<DC-IRC> <Tenkawa> (granted thats to handle all sbcs we support..)
<DC-IRC> <Spectrefield> This seems not easy to resolve
<DC-IRC> <Tenkawa> It gets easier the more you do it
<DC-IRC> <Spectrefield> With the repo Build, is it possible to make image with the kernel branch current ?
<DC-IRC> <Tenkawa> Gotta run afk... door ..
<DC-IRC> <rpardini> Okie. I'm not familiar with the RT patches.
<DC-IRC> <rpardini> Seems they force a certain `-rtX` suffix in the version, and Armbian gags.
<DC-IRC> <rpardini> could you detail which patches you're applying?
<DC-IRC> <rpardini> (and where to get them)
<DC-IRC> <rpardini> also, any `.config` changes?
<DC-IRC> <rpardini> cos if you avoid the version change, all should work.
<DC-IRC> <rpardini> the version impacts all the paths of modules/dtbs and thus the bootloader phase, etc.
<DC-IRC> <Spectrefield> Thanks for reply, the patches come from https://cdn.kernel.org/pub/linux/kernel/projects/rt/ and I chose the 6.2 subfolder according to the target kernel release of the armbian branch edge.
<DC-IRC> <Spectrefield> The only one .config changes I applied is the line CONFIG_PREEMPT_RT_FULL=y
<DC-IRC> <Spectrefield> exactly this one. except the format because I chose the xz extension.
<DC-IRC> <Spectrefield> Exactly this one. Except the format because I chose the xz extension.
<DC-IRC> <rpardini> No matter the compression, right? You decompress the patch.
<DC-IRC> <Spectrefield> yes
<DC-IRC> <rpardini> so looky there
<DC-IRC> <rpardini> ```patch
<DC-IRC> <rpardini> diff --git a/localversion-rt b/localversion-rt
<DC-IRC> <rpardini> new file mode 100644
<DC-IRC> <rpardini> index 0000000000000..1445cd65885cd
<DC-IRC> <rpardini> --- /dev/null
<DC-IRC> <rpardini> +++ b/localversion-rt
<DC-IRC> <rpardini> @@ -0,0 +1 @@
<DC-IRC> <rpardini> +-rt3
<DC-IRC> <rpardini> ```
<DC-IRC> <Spectrefield> and install it in userpatches/kernel/meson64-edge
<DC-IRC> <rpardini> around line 4790
<DC-IRC> <rpardini> you could try and remove lines 4790-4796
<DC-IRC> <Spectrefield> I found these, removed now
<DC-IRC> <rpardini> that might prevent the localversion from changing, and thus allow the packaging to work
<DC-IRC> <rpardini> try it out, if it does help, I could handle that removal in the core, even, so future users succeed without it.
<DC-IRC> <rpardini> I'm not clear how that `localversion-rt` is handled and by what, though.
<DC-IRC> <Spectrefield> it is started
<DC-IRC> <rpardini> Oh -- it's right there... https://github.com/torvalds/linux/blob/master/init/Kconfig#L183-L191
<DC-IRC> <rpardini> > [appended...] after the contents of any files with a filename matching `localversion*` in your [...] source tree
<DC-IRC> <rpardini> Guess it's a gross failure of Armbian to not honor those correctly.
<DC-IRC> <rpardini> If you open an Issue on `armbian/build` repo I'd be compelled to (eventually) fix it to support those.
<DC-IRC> <Spectrefield> I have a new log here https://paste.next.armbian.com/tajatafegu
<DC-IRC> <Spectrefield> what do you want as data in this issue ? I can create it yes
<DC-IRC> <rpardini> patch is failing to apply...
<DC-IRC> <Spectrefield> yes in kernel/panic.c 👍
<DC-IRC> <rpardini> yep, that's the only patch touching `panic.c`
<DC-IRC> <c0rnelius> It is a problem because ur applying a RT patch against a kernel that is already being heavily patched. On top of it probs not being the exact revision, which is not something Armbian does. The kernel last time I checked is dictated by Armbian and not the user.
<DC-IRC> <rpardini> Yeah in this case, it's not Armbian patches; no other Armbian patches touch `kernel/panic.c`.
<DC-IRC> <rpardini> Armbian's pulling branch `linux-6.2.y` though, so you're getting 6.2.14, and the RT patches might not work on that.
<DC-IRC> <c0rnelius> Basically you would need to fit the RT patch around what Armbian has to deliver.
<DC-IRC> <rpardini> Or: you can hack `KERNELBRANCH=` in meson64_common to point to `tag:v6.2` and see what happens 😉
<DC-IRC> <rpardini> I've no idea about those RT patches, I suppose they patch against 6.2.0 final?
<DC-IRC> <Tenkawa> is that mainline 6.2.y or vendor kernel?
<DC-IRC> <rpardini> mainline. there's no amlogic 6.2 vendor.
<DC-IRC> <c0rnelius> The mainline RT patches are specific to revs. Last I checked.
<DC-IRC> <c0rnelius> So 6.2.13 or whatever... When ever they last released one.
<DC-IRC> <rpardini> oh so that also works, `KERNELBRANCH=commit:<sha1>` I think.
<DC-IRC> <rpardini> Unfortunately we can't pass KERNELBRANCH on the command line _yet_ (tsk tsk, dont ask), you have to hack it in the family common file.
<DC-IRC> <rpardini> or yeah, `tag:v6.2.13`. It definitely should be easier to change that.
<DC-IRC> <rpardini> (the only clean way today is to use a hook, which is overkill for most users, who don't even have a config file).
<DC-IRC> <rpardini> either way, I like this.
<DC-IRC> <rpardini> 👉 TIL: `localversion-*` is added to `CONFIG_LOCALVERSION`
<DC-IRC> <c0rnelius> So like when it comes to Pi's, people usually stick with the Pi commit that relates to the mainline RT patch kind of deal. So generally unless some crazy patching is going on it should apply.
<DC-IRC> <rpardini> Interesting. I had heard of ppl using it. Seems like ppl really wanna do stuff better done in a dedicated microcontroller in Linux. 😄
<DC-IRC> <c0rnelius> Timing is everything... That and satellites. Anything where the math has to be spot on or it breaks.
<DC-IRC> <rpardini> fascinating.
<DC-IRC> <c0rnelius> Think like old QNX OS.
<DC-IRC> <c0rnelius> But people do it with Linux now
<DC-IRC> <c0rnelius> When they can
<DC-IRC> <rpardini> I had no idea, I thought all serious RT stuff was in FreeRTOS.
<DC-IRC> <rpardini> Cool stuff. I'd say `-rtX` should be welcome in Armbian and all.
<DC-IRC> <rpardini> but for now, really gotta remove that `localversion`, set KERNELBRANCH=tag:v6.2 or such to match the patch, and it should work.
<DC-IRC> <Spectrefield> for now I have tested v6.2.13 - 12 - 11 - 10 - 9 - 8 and no one works 🙂
<DC-IRC> <Spectrefield> I also have another build on v6.1 and the corresponding patch works well. It's compiling. I will go to sleep and check in morning.
<DC-IRC> <Spectrefield> Thanks for all 🙂
<DC-IRC> <rpardini> 🖖
<DC-IRC> <Spectrefield> 7 is ko too 🤭
<DC-IRC> <Spectrefield> 🖖
<DC-IRC> <rpardini> (heh. try `6.2.0`)
<DC-IRC> <Spectrefield> [🐳|💥] error! [ Failed to fetch SHA1 of 'git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git' 'tag' 'v6.2.0' - make sure it's correct ]
<DC-IRC> <Spectrefield> ahah well well well 🙂
<DC-IRC> <rpardini> `v6.2` is the tag for `6.2.0` (don't ask)
<DC-IRC> <Spectrefield> it's applied successfully !!! 🥳
<DC-IRC> <Spectrefield> then two images in compilation 🤟 (6.1.y and 6.2)
<DC-IRC> <c0rnelius> what did 6.2 have to offer that 6.1 does not/
<DC-IRC> <c0rnelius> what did 6.2 have to offer that 6.1 does not?
<DC-IRC> <Spectrefield> I don’t know 👌
<DC-IRC> <c0rnelius> Just curious. I can't imagine there would be a need to push updates to a RT kernel after the fact unless there was a bug that wasn't noticed before deployment.
<DC-IRC> <c0rnelius> Features I guess. Come to mind.