I like the healthy dose of scepticism about marketing claims that meeting people in person at conferences provides :)

@monsieuricon @wagi Look how far north Ireland is, but the gulf stream does us serious favours :)

@kernellogger I know little about building kernels for commodity hardware, but for my boxes I build deb-pkg by setting LOCALVERSION on the command line when calling make. Just makes me curious if the wacky looking sed command could be avoided.

@kernellogger out of curiosity reading through, what's the difference between setting "EXTRAVERSION" as opposed to "LOCALVERSION"?

@ljs On Windows in Chrome it works automagically for lore, google search etc (iirc if you use system theme), but not for more complex sites. There's a flag that can be set in the browser that forces dark mode everywhere, but it makes very poor colour choices. I look at lore a good bit in the dark and yeah - similar eye burning affect there!

@ljs Ah cool. Usually my browser coverts stuff (like lore) automagically to dark mode, but not for elixir. Thanks!

@ljs How did you get darkmode on elixir?

re: https://social.kernel.org/notice/AS3DZjXqKnHXtM8ZEG

Problem 1:
Nick fixed about a year ago, and to quote his commit message
```
In case the DTB provided by the bootloader/BootROM is before the kernel
image or outside /memory, we won't be able to access it through the
linear mapping, and get a segfault on setup_arch(). Currently OpenSBI
relocates DTB but that's not always the case (e.g. if FW_JUMP_FDT_ADDR
is not specified), and it's also not the most portable approach since
the default FW_JUMP_FDT_ADDR of the generic platform relocates the DTB
at a specific offset that may not be available. To avoid this situation
copy DTB so that it's visible through the linear mapping.
```

Problem 2:
I fixed a few months ago. The reserved memory scanning takes place too early
during init, before paging has been enabled. As a result, once paging *is*
enabled & the tlb flushed, trying to read the label names of reserved memory
regions causes a kernel panic. Apparently we were just the first ones to try
to write a remoteproc driver for RISC-V!
The solution was moving the call to early_init_fdt_scan_reserved_mem() after
the dtb was properly mapped.

Problem 3:
If the dtb is located outside of memory regions that the kernel is aware of, it
gets remapped into a region that the kernel *is* aware of.
However, this is done before we check for any reserved memories etc. If there
happened to be a section of unusable memory in the DT, that was then carved
out using a reserved memory region with a "no-map" property, it is entirely
possible that the DT would end up there.
This was introduced by Nick's fix for problem 1 & I've been avoiding it by just
putting the dtb somewhere that I know will be accessible to the kernel, and thus
avoiding the remapping.

Problem 4:
Introduced by my fix for problem 2. RISC-V uses the top-down method for looking
up memblocks for reserved memory regions. In a sparse configuration, if there
was to be an upper-most range, all of which was intended to be used as a DMA
region, memory allocated at some point in paging_init() would consume very small
sections of this upper DMA region. This can be observed on some configurations
on PolarFire SoC, and was easy to spot with memblock debug enabled.
These small allocations mean that when, in early_init_fdt_scan_reserved_mem(),
we look up the reserved memory node that is intended to consume the whole memory
region there is no longer enough space for this mapping.
This is worse if the memory region is non-coherent as the system will then
immediately crash.

Problem 4 can be fixed by using bottom-up searching for memblocks. This may also
fix problem 3 too, I just haven't tested it.
I'm super unsure as to whether switching the search order has some consequences
that I am just not aware of, but I probably won't be any the wiser until I send
a patch!

Found another reserved memory related problem in RISC-V's early init code today. This one appears to actually have been caused by my last fix, but that makes for 4 problems in the same but of code.

I have a fix for it, but it's either adding yet another band-aid, introducing a behaviour change or trying to find the time to do significant overhaul and hope not to make it worse!

@monsieuricon I gave it 24h then reported with the original post of this thread. I figured that was sufficient and then didn't want to be pushy!

@monsieuricon I do not use an app, just the website. Going to https://social.kernel.org/main/friends produces nothing other than 500 errors for me. Notifications works though!

@monsieuricon you know, it's kinda nice to have a website be (give or take) non-functional yet not feel aggrieved.
A symptom of knowing who is running it versus it being a faceless corporation.

@dwagenk or device tree & it's variants too...

https://www.devicetree.org/

Devicetree devicetree DeviceTree

How am I suppose to know when the organisation itself doesn't!

@monsieuricon Ah I see. Thanks!

@monsieuricon been getting an error 500 accessing my "home timeline" on the social.kernel.org website. "Public timeline" works though. Any idea what may be the cause?

Back working this morning. DDR/DDR training issues perhaps?

Welp, my visionfive v2 might be a little on the kaput side?

Been running the same boot process since I got my board.
tftp a fitImage w/ initramfs and then boot w/ bootm as might be expected.

First time I powered it on today, it bootlooped once but then worked properly.
Rebooted it and since then it's been bootlooping in U-Boot non stop.
`bootm ramdisk` or `bootm loados` tend to be where it dies.

Randomly had it start working again just now, while manually entering the commands for a couple boots in a row.
Allowing autoboot, which runs the same commands, didn't.

Back to not working at all again now.

🤔

I hate outlook & I hate automatic replies.

https://social.kernel.org/notice/ARVWmKdhWckD0iaCWm

Looked at this again today, having fixed some build issues in the pinctrl driver. Looks like the patches posted to the ML do the right thing after all, woops!

I had been trying the "upstream" branch in their GitHub repo, so that I didn't have to fix the pinctrl driver in order to try the board out.
The branch is older than I thought it was, so perhaps it was not a good idea to do that & I came a cropper as a result.

I feel terrible about this sort of thing, I hope I didn't waste too much of their time.