IRC channel logs

<solid_black>well hello friends :)

<sneek>solid_black, you have 2 messages!

<sneek>solid_black, azert says: that I made substantial advances toward enabling IRQs and I figured out that kalloc has some serious bug

<sneek>solid_black, azert says: please consider reviewing and applying this patch, https://paste.debian.net/1314115/ , for me it makes little sense to work on this more until we fix kalloc, since results are quite unpredictable

<solid_black>if (gic->srcs != 256) <--- what?

<solid_black>did you mean nsrcs? is that your kalloc bug?

<azert>solid_black: that’s a tentative workaround

<solid_black>no, look closely

<solid_black>srcs is a pointer

<solid_black>nsrcs is the size, which could be 256

<azert>I had to use static allocation otherwise the content of the srcs[] array is inconsistent

<solid_black>inconsistent how?

<azert>It returns memory that doesn’t exist

<azert>You write in it and it is ignored

<azert>Same issue as the ev table

<solid_black>interesting

<azert>Try testing with 1gb vm

<solid_black>are we doing something wrong with the RAM vs vm_page?

<solid_black>I am testing with 1GB VM yes

<solid_black>with the memory starting at 1GB address too

<solid_black>so same as yours

<azert>Do we use a linear mapping?

<azert>For the kernel?

<solid_black>I mean, our handling of available RAM is certainly not in any way robust, but I wouldn't expect us to straight out hand out nonexistent memory

<solid_black>also, if you write to bad memory I'd expect it to raise an exception or something

<solid_black>part of it is a linear mapping, but we also just map individual pages

<azert>Then im not sure what is happening

<azert>Where is the ram detected? Might be an issue with the detection

<solid_black>did your attempts to connect GDB go anywhere?

<azert>The jtag connectionof my board is used for the smart card

<solid_black>pmap_discover_physical_memory

<azert>So I cannot

<solid_black>and it kind of continues in pmap_bootstrap and pmap_bootstrap_misc

<azert>It’s probably trivial to enable the inkernel debugger

<solid_black>but we don't support it yet

<solid_black>since I haven't quite figured out how it works

<solid_black>maybe that's what I should invest time into

<azert>Check also the netbsd port

<solid_black>(or, maybe I could annoy youpi until he explains it to me :D)

<solid_black>the netbsd port?

<solid_black>you mean they have ported Mach's debugger?

<azert>Yes

<azert>We use the same kernel debugger

<solid_black>do you know how to use kdb as a user?

<azert>No but I can learn

<azert>Where would you add some messages about memory ranges detected?

<solid_black>you could log it inside pmap_discover_physical_memory if you want to, but be aware that this runs before we turn on the MMU so you need to use the UART's address without the highmem 0xffff thing

<solid_black>I don't think there's anything too broken about that logic though

<solid_black>maybe you could try to add some tracing to whatever code allocates physical pages / kalloc

<azert>Could you add that it would be useful for me

<solid_black>what you could certainly do (do you do that already?) is add tracing to pmap_enter

<solid_black>so you see what physical address is that problematic virtual address mapped to, at least as far as Mach itself is aware

<azert>Im not sure im confident enough in that part

<azert>Ok, I suspect I found the buf

<azert>bug

<solid_black>what is it?

<azert>No device of type memory on my device tree

<solid_black>oh

<solid_black>could you post the device tree again?

<solid_black>but I can't imaigne how that could work, under any kernel

<azert> https://paste.debian.net/1314143/

<azert>There might be other ways to discover the memory on such chips

<solid_black>could it just be named something else in the device tree?

<solid_black>is dram-controller@1c62000 it for example?

<solid_black>dma-ranges = <0x00 0x40000000 0xc0000000> that looks like your ram, no?

<solid_black> https://www.kernel.org/doc/Documentation/devicetree/bindings/arm/sunxi/allwinner%2Csun4i-a10-mbus.yaml well, no, this speaks of a memory bus and not ram

<solid_black> https://devicetree-specification.readthedocs.io/en/latest/chapter3-devicenodes.html this is pretty clear in requiring the /memory node

<solid_black>I'm honestly surprised that anything has worked for you at all w/o physical memory

<solid_black>does Linux boot on your board using UEFI and not DT?

<azert>It’s booted using the device tree

<azert>On Linux, on netbsd

<solid_black>can you see (and maybe post) logs of Linux bootup? does it discover memory?

<azert>I cannot find how netbsd finds the physical memory otherwise I’d tell you

<azert>I’d prefer not to look at Linux, i would rather check netbsd

<azert>Their kernel is based on Mach too, although much more advanced

<solid_black>I don't think it's exactly based on Mach

<solid_black>Mach is/was based on BSD code base

<azert>They claim they ported ghe

<solid_black>and the BSDs have imported back the vm subsystem

<solid_black>ghe?

<azert>the Mach vm to the bsd kernel

<solid_black>the vm subsystem, yes

<azert>That’s their claim

<anatoly>was it like big single unix process for everything unix on earlier versions of mach?

<azert>The vm subsystem evolved considerably

<solid_black>anatoly: early versions of Mach (pre 3.0) were colocated with BSD

<solid_black>basically Mach was developed inside of a BSD kernel

<azert>anatoly that was cales BSD Lite

<solid_black>to already have a working system, and add to it

<anatoly>yep, that was the reason

<solid_black>this is coincidentally (not) what NeXT did with their system

<solid_black>they pretty much took Mach 2 / BSD, and based their system on that

<solid_black>then in Mach 3, they (Mach developers) were finally able to more BSD from kernel space to userland, as one giant server ("Lites"), yes

<azert>But XNU is more like Next

<solid_black>XNU is exactly continuation of NeXTSTEP, yes

<solid_black>they ported to Mach 3 later, but retained the in-kernel BSD design

<solid_black>they also had a third component, the Driver Kit

<solid_black>which was a framework for writing device drivers, inside the kernel, in objective-C

<solid_black>instead of the dated Mach/BSD device abstractions

<anatoly>but the time to rewrite all of that in rust has come :-D

<solid_black>yes, I've long wanted somebody to made gnumach-rs :D

<solid_black>could even make it a drop-in replacement, keeping ABI

<azert>netbsd is much more simple, but they took a lot from Mach. I’m not sure stating that they just ported the vm is accurate. Although it’s hard to say what went in which directions for me, since I don’t know the pre mach bsd enough

<anatoly>I was thinking about mig as a possible exercise to learn that part

<solid_black>which part?

<azert>The similarities in the code base are quite clear

<solid_black>(that was a q to anatoly)

<anatoly>^^^ thanks :-D

<anatoly>solid_black: mig compiler, sorry

<anatoly>but I guess there's not much in it to benefit from such rewrite

<solid_black>ah, you mean rewriting MIG in Rust?

<azert>MIG is pure yacc and bison, you might as well write a better idl compiler instead of rewriting MIG

<solid_black>azert: the device tree spec really requires a /memory node as you can see

<solid_black>so I'm inclined to say that this is a bug in your device tree

<solid_black>that you could report to... whatever the source of that is, Linux probably

<solid_black>but in the mean time, you could try adding a /memory node from U-Boot?

<azert>solid_black I don’t think I’m going anywhere with this

<anatoly>btw, I liked to read this book: https://www.cs.princeton.edu/~bwk/memoir.html

<solid_black>adding a node from U-Boot should be reasonably easy

<azert>if that node is not there it means surely something

<solid_black>it would be best to research how others deal with it, sure

<azert>I’ll add this node from u-boot, it should be easy. But others deals with it for sure

<azert>Let me just add the node. There are more pressing things to fix

<azert>Could you copy paste here the one from qemu?

<anatoly>azert: that's what I think as well, not so much there beside yacc

<solid_black>sure, memory@40000000 { reg = <0x00 0x40000000 0x00 0x40000000>; device_type = "memory"; }

<solid_black>but this is for address-cells = 2

<anatoly>Oh! What's the state of rust on hurd? Patches were submitted, right?

<solid_black>since you have it set to 1 as I can see, drop both 0x0-s

<solid_black>anatoly: I think they were all even merged into upstream Rust

<solid_black>so, I'd say, it's waiting for Debian to build Rust packages

<solid_black>but youpi would know more

<anatoly>solid_black: yep, wasn't sure about the merge part

<azert>Adding the memory node doesn’t help

<azert74>GNU Mach 1.8

<azert74>Kernel command line: foo=bar

<azert74>Booting in EL1

<azert74>vm_page: page table size: 262144 entries (20480k)

<azert74>vm_page: DMA: pages: 262144 (1024M), free: 213940 (835M)

<azert74>vm_page: DMA: min:13107 low:15728 high:26214

<azert74>Model name: Olimex A64-Olinuxino

<azert74>timer: found armv8 compatible timer, clock-frequency=24000000

<azert74>gicv2: found gic-v2 compatible interrupt controller at distributor=ffff000001c81000(size=00001000), cpu=ffff000001c82000(size=00002000)

<azert74>gicv2: prop name interrupts, length 48

<azert74>gicv2: isppi, irq, flags = 0x00000001, 0x0000001d, 0x00000f04; nsrcs = 0

<azert74>../aarch64/arm/gic-v2.c:170: gic_v2_add_src: Assertion `gic->srcs[irq - 16] == NULL' failed.panic ../kern/debug.c:107: Debugger: Debugger invoked, but there isn't one!

<azert74>the latest assertion happens just because the kalloced memory doesn't work

<azert74>I reverted the static allocation of srcs

<azert74>since the kalloc bug is worse than anything

<azert74>why such an assertion there?

<solid_black>azert: the assertion is there because we don't support two devices sharing the same irq

<solid_black>so when setting an irq handler, we want to make sure nothing else uses the same irq

<solid_black>otherwise we'd be overwriting its handler

<solid_black>this same assertion also fails for me on qemu after reboot (but not on initial boot)

<solid_black>which might indicate that we don't always zero out memory properly, or something like that

<azert>That’s not the case over here, nsrcs was zero

<azert>The assertion fails because kalloc provides something unreliable

<solid_black>I surely have a memset there

<azert>Yes

<solid_black>so this must be that special kind of memory that ignores writes and always reads 0xff?

<azert>Apparently

<solid_black>can you print the address you got from kalloc, and also trace pmap_enter's?

<azert>Yes, ok

<dsmith>(Still reading through the backlog) Often on uboot/linux, uboot probes memory and updates the device tree. Maybe that's why you are not seeing it in there.

<solid_black>oh, that would make sense indeed

<solid_black>axert: are you loading the dtb as an opaque just a blob?

<solid_black>just an opaque blob*?

<Pellescours>hi

<azert>I don’t think uboot does any magic with the device tree

<solid_black>from looking at u-boot source, it does, but this depends on the board for some reason, and also on the command

<azert>I just load it from disk, modify it transparently in memory

<solid_black>bootm seems to do more changes than booti

<azert>Ok I didn’t know

<azert>This is the chip memory map https://linux-sunxi.org/A64/Memory_map

<azert>Yes, I confirm , u-boot fixes this

<azert>Why opaque blob? I open this in u-boot to add the module infos

<Pellescours>sneek: later tell almuhs I was able to compile rumpkernel with netbsd10, only 1 file was missing "opt_ahcisata.h"

<sneek>Will do.

<Pellescours>When trying to compile rumpdisk with my new rumpkernel libraries (netbsd10), I have these undefined reference "rumpns_bus_dmatag_subregion" called from the function "rumpns_ehci_init"

<AlmuHS>hi

<sneek>Welcome back AlmuHS, you have 1 message!

<sneek>AlmuHS, Pellescours says: I was able to compile rumpkernel with netbsd10, only 1 file was missing "opt_ahcisata.h"

<AlmuHS>Pellescours: could you explain me, step-by-step, how did you download and compile the rumpdisk sources?

IRC channel logs

2024-04-15.log