<shadows>
bjdooks: maybe it is not aligned properly or has been overwritten by devicetree
shoragan has joined #riscv
<shadows>
risc-v architecture description in Documentation/ (Linux kernel) does not explicitly say it, but you will find that it follows similar alignment requirements as 64-bit arm
<shadows>
something like 2M alignment
jacklsw has quit [Read error: Connection reset by peer]
indy has joined #riscv
prabhakalad has quit [Ping timeout: 260 seconds]
prabhakalad has joined #riscv
coldfeet has joined #riscv
<xypron>
shadows: The alignment requirement for the device-tree is 8 byte as specified by the device-tree specification. RISC-V does not share the restrictions of ARM for the initrd. MIN_KIMG_ALIGN SZ_2M is arm64 specific and I guess only required for the kernel itself. Kernel and initrd having to be within 1 GiB is also arm64 only, see efi_get_max_initrd_addr().
<bjdooks>
shadows: this is inbuilt into the kernel, either it is getting corrupted by uboot or some other weirdness is going wrong (can't get crc32 to match from kernel / build)
coldfeet has quit [Ping timeout: 252 seconds]
bsFFFFFF has quit [Ping timeout: 244 seconds]
bsFFFFFF has joined #riscv
jacklsw has joined #riscv
coldfeet has joined #riscv
bsFFFFFF has quit [Ping timeout: 276 seconds]
bsFFFFFF has joined #riscv
coldfeet has quit [Ping timeout: 260 seconds]
clemens3 has quit [Ping timeout: 252 seconds]
<bjdooks>
ok, so early in setup_kernel the crc32 of the initrd data matches when it starts the decompress
<bjdooks>
not sure if a 16MiB initrd is just bad, or there's something weird going on with uboot
Armand|X13s has joined #riscv
Armand|X13s has quit [Remote host closed the connection]
Armand|X13s has joined #riscv
jacklsw has quit [Ping timeout: 260 seconds]
Armand|X13s has quit [Quit: Leaving]
dramforever[m]1 has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #riscv
r6fej has joined #riscv
_catircservices has quit [Quit: Bridge terminating on SIGTERM]
_catircservices has joined #riscv
<bjdooks>
trying 6.16-rc5
lemojan has joined #riscv
r6fej has quit [Quit: Leaving]
r6fej has joined #riscv
agentcasey has joined #riscv
ruidx has joined #riscv
Abstract-Mage has joined #riscv
<Abstract-Mage>
hi
<shadows>
some of my first messages to u-boot mailing list are very similar topic, why is corruption happening? and I iterated to find that 2M alignment was required
<shadows>
this might not match what is written in documentation but it is what actually is real life ;)
<Abstract-Mage>
i wonder wether well ever get close to a point where os's can ship a "generic" risc-v image instead of every board shipping its own customized version of linux
<dramforever[m]1>
the main thing will always be drivers
<shadows>
not exactly your question, but it is a generic-ish network based installer and you just load it from whatever bootloader
<Abstract-Mage>
why network based?
<shadows>
also the JH7110 CPU boards all share the same "firmware" (U-Boot) build and devicetree is runtime-selected
<dramforever[m]1>
please do correct me if i'm wrong but i am fairly sure e.g. intel and amd ship their drivers out to linux first and then give you hardware
<shadows>
Abstract-Mage: oh, actually the full dvd-1 image does also work but loading it is annoying because of the size
<dramforever[m]1>
it helps that they have like generations of chips behind them instead of literally just being the first chip of the company to use these peripherals
<dramforever[m]1>
i suppose another thing is if you can get vendors to ship everything through pci then you can do it through acpi
<Abstract-Mage>
understandable
<Abstract-Mage>
its just kind of annoying for operating systems which arent linux
<Abstract-Mage>
also a cpu shouldnt need drivers should it?
<dramforever[m]1>
it never is a cpu these days
<dramforever[m]1>
it's a "system on chip" (SoC)
<shadows>
Abstract-Mage: i.e. JH7110 CPU includes the USB controller and network stuff
<dramforever[m]1>
like, maybe this isn't the best analogy
<dramforever[m]1>
but if you get a new hardware that doesn't have (mainline) linux support
<Abstract-Mage>
i know what an soc is
<dramforever[m]1>
yeah i was leading up to my horrible analogy
<Abstract-Mage>
im rather annoyed that everything seems to become an soc but still
<dramforever[m]1>
if you get a new hardware that doesn't have (mainline) linux support, it just ... doesn't have mainline linux support
<Abstract-Mage>
can one not boot up the cpu cores without drivers? but then again to actually get in and output youd need usb and atleast something like a display driver
<Abstract-Mage>
which is annoying
<dramforever[m]1>
the situation with these soc stuff is partly that, and partly some basic things being handled within e.g. linux instead of being in ACPI
<dramforever[m]1>
oh you can boot up the cpu cores without special drivers
<dramforever[m]1>
you can even try to use the SBI console for input and output
<Abstract-Mage>
im mostly here as im thinking about learning c and wanting to port openbsd to more risc-v boards
<dramforever[m]1>
that absolutely works
<shadows>
Abstract-Mage: nothing stops you from doing that but yourself at this time :)
<Abstract-Mage>
oh im getting the c book for my birthday soon so im on it
<dramforever[m]1>
i do not jest, this is how things were towards the beginning of everyone trying out spacemit k1
<Abstract-Mage>
also have some extremely basic os dev experience from writing a small kernel in rust
<dramforever[m]1>
because it has all these newfangled extensions like zicond and uh ... and such
<dramforever[m]1>
but you need a new kernel if you want to try out hwprobe
<dramforever[m]1>
i think zicond and sstc? i can't remember much else that's exciting
<Abstract-Mage>
arent alot of the chips very nonstandart in their extensions?
<Abstract-Mage>
cough cough ghostwrite
<shadows>
I suggest StarFive JH7110 CPU for this; there's a variety of available hardware in-stock from multiple vendors and upstream has been there for 1+ year, even there is Rust lang implementation from Daniel as oreboot.
<dramforever[m]1>
if that was a question you're going to be more specific than that
<Abstract-Mage>
no no my question has been answered
<dramforever[m]1>
*going to need to be
<dramforever[m]1>
yeah jh7110 is probably the most well supported by "standard" software now
<dramforever[m]1>
it still doesn't have hdmi out in mainline
<Abstract-Mage>
shadows, openbsd and freebsd already support the jh7110
<dramforever[m]1>
linux, i mean
<Abstract-Mage>
im dont much care for linux
<shadows>
Abstract-Mage: yes, so it should be easier for you?
<dramforever[m]1>
well i meant i think there's hdmi support in mainline uboot? might have imagined that
<Abstract-Mage>
ahhh
<Abstract-Mage>
but yea so far i have dealt with x86_64 hardware directly once and tbh i hated it
<dramforever[m]1>
okay i think i imagined that
<Abstract-Mage>
yea
<Abstract-Mage>
one of those things quiet close to a real life lovecraftian horror
<dramforever[m]1>
here's hoping market forces drive out the nonstandard stuff
<Abstract-Mage>
i hope so as well
<Abstract-Mage>
i also hope for socketed risc-v cpu's. although i know it to be unlikely
<dramforever[m]1>
like the reason everyone cares so much about the ghostwrite stuff is that the sg2042 with 64 core c910/c920 is still the fastest generally available riscv you can get
<dramforever[m]1>
i forgot if the p550 stuff beat c920 in single core
<Abstract-Mage>
oh yeah that one is the board i drooled over back then
<Abstract-Mage>
yea the p550 is iirc a rather high performance core
<dramforever[m]1>
there's some frankly lackluster effort trying to mainline sg2042 stuff
<Abstract-Mage>
shadows, thanks
<Abstract-Mage>
i dont recall much, is the ghostwrite exploit possible without direct hardware acces?
<dramforever[m]1>
what do you mean by "direct"
<Abstract-Mage>
physical acces to the hardware
<shadows>
should work seamlessly with StarFive VisionFive2, Pine64 Star64, and Milk-V Mars; I'm in-progress on upstreaming Milk-V Mars CM (and CM Lite) but I am a ski instructor not any kind of programmer so I just am taking forever to do this
<dramforever[m]1>
no you can do that as long as you can run arbitrary instructions
<dramforever[m]1>
and as long as V isn't disabled
<Abstract-Mage>
ah damnit that is a big holw indeed
<Abstract-Mage>
v is the custom extension correct?
<shadows>
V is vector
maylay has quit [Quit: Pipe Terminated]
<shadows>
you don't worry about that with JH7110 it doesn't have it
<Abstract-Mage>
indeed but i am curious
jacklsw has joined #riscv
<dramforever[m]1>
V on c920v1 is custom :P
<dramforever[m]1>
like it might as well have been
<Abstract-Mage>
so i was correct
<dramforever[m]1>
sure, this is what happens when you let anyone make riscv hardware
itrsea has quit [Remote host closed the connection]
itrsea has joined #riscv
<Abstract-Wizard>
like 128 bit computers are just kind of cool
<Abstract-Wizard>
i just cant think of any good use for it, i mean the added register length might speed up some calculations but those numbers arent that normal iirc