<Guest27>
Are there any F36/F37 RISC-V images? There are images built in July of 2022 but those are still F33. Where can I get a F36/F37/rawhide image?
<Guest27>
Umm... hello?
<davidlt[m]>
Morning
<davidlt[m]>
The image is not exactly F33 (it's F33 + with some things backported from the Rawhide).
<davidlt[m]>
F37 and F38 is still cooking
<Guest27>
Thanks for replying davidlt
<Guest27>
Are the images packages and images built natively or with QEMU?
esv has quit [Remote host closed the connection]
<davidlt[m]>
The F37 and F38 so far all packages are natively built
<davidlt[m]>
Anything before that a mix of QEMU + native
<Guest27>
Okay
<Guest27>
Not to be entitled/impatient, but how long until a F37/F38 image is ready? (Sorry, I'm new to the Fedora ecosystem and don't know how to navigate around in Koji to see the progress myself)
<Guest27>
Also, like Debian's FTBFS (failed to build from source), does Fedora have a similar "status page", or is that what I'm already getting from Koji?
<davidlt[m]>
FTBFS exist, but not for Fedora/RISCV.
<Guest27>
Okay
<davidlt[m]>
Typically in Fedora upstream build infra those are filled in bugzilla for the specific package IIRC.
<davidlt[m]>
F37 and Rawhide depends, most likely 1-2 months away.
<Guest27>
So around the time when VisionFive V2 gets in my hands :D
<davidlt[m]>
There are good days and some bad days so it's hard to tell exactly when it happens.
<Guest27>
That's understandable
<davidlt[m]>
Majority of VisionFive V2s will be available in Feb 2023.
<davidlt[m]>
There will be some in November IIRC.
<davidlt[m]>
But it most likely take quite some time for kernel and u-boot patches to be upstreamed.
<davidlt[m]>
Probably sometime in 2023.
<Guest27>
Asked these question since I am unaware of how development works in the RHEL ecosystem... stuff like Fedora's release cadence, Koji, Mock, etc... Hope that was okay and I didn't appear as a jerk :)
<Guest27>
4GB are set to shipped in Nov 2022
<davidlt[m]>
Yeah, but those have one of Ethernet ports not capable of doing 10/100Mbit mode IIRC. Which is only fixed in Feb 2023 batch.
<davidlt[m]>
I think November is "Super Early" batch.
<davidlt[m]>
Not sure when PINE64 ships their Star64 with the same JH7110 SoC.
<davidlt[m]>
This is a different chip.
<davidlt[m]>
It never really got an upstream support.
<davidlt[m]>
This basic support can boot IIRC, but not into the userspace.
<davidlt[m]>
JH7100 had an L2 bug and a bunch of stuff was connected to a wrong port to U74-MC thus cache coherence was a problem
<davidlt[m]>
JH7100 is a dead as a test chip
<davidlt[m]>
JH7110 is a true proper chip, but it's completely different
<Guest27>
About the Nov + mixed eth ports: There are two tiers shipping in Nov. 'Super early bird' and 'Early bird', the latter has a higher price but _does_ ship in Nov '22.
<davidlt[m]>
Even U74-MC are not the same. It's a newer release with a lot of bug fixes and new IP blocks too
<Guest27>
Understood (about the JH7100 and JH7110)
<davidlt[m]>
We will probably need to cook a custom image, but it will take a lot of time to upstream this chip
<Guest27>
Ah, okay
esv has joined #fedora-riscv
<davidlt[m]>
So far StarFive Tech didn't post any patches. The last time they depended on the community to do most of the upstreaming work too.
<Guest27>
They said Ubuntu, Debian and Fedora will be vendor provided. I assume they will be using F33, right?
<davidlt[m]>
F36
<Guest27>
Like Pine64... :(
<davidlt[m]>
Yeah, it's a lot like PINE64.
<davidlt[m]>
But StarFive Tech has collab with Canonical thus their engineers probably will be helping out to refine, cleanup and upstream.
<davidlt[m]>
JH7110 doesn't have the same issues as JH7100 thus to get it booted should be relative low amount of patches.
<Guest27>
F36? Sorry, I don't follow... I assume this F36 image will be done by the vendor (because I can't find it...)
<davidlt[m]>
It exist, but in a different Koji instance.
<Guest27>
Yeah, Ubuntu is the only OS which "officially" supports RISC-V in their LTS release
<davidlt[m]>
There is another one in China.
<Guest27>
Ahh, gotcha
<davidlt[m]>
Yeah, but "officially" support might mean they have a bunch of non-upstream patches from the vendor.
<davidlt[m]>
But it's up to Canonical folks to maintain them until it get upstreamed.
<Guest27>
Yeah... That's why I'm staying away from Ubuntu for now
<Guest27>
They did the same for Raspbery Pi too... Albeit that was by themselves, taking the rpi-kernel and building on top of it.
<davidlt[m]>
Oh, they did that for the ARM64 server platform too :)
<davidlt[m]>
That was fun.
<Guest27>
:P
<davidlt[m]>
Get a server for 150K USD the only distro that works on it is Ubuntu :)
<davidlt[m]>
Old days :)
<Guest27>
I love the package build policy of Debian and Fedora (and by extension RHEL) that there must be no downstream patches (*coughs* grub *coughs*) in official packages :D
<davidlt[m]>
:)
<davidlt[m]>
Well, I use all the distributions and engineers are great in all the distros!
<davidlt[m]>
But I do prefer Fedora as it's faster moving one.
<davidlt[m]>
Debian usually too slow and too old for me.
<Guest27>
On the topic of grub, is a switch to systemd-boot possible? My distro (Pop!_OS) on desktop uses it and it hasn't had any problems (at least not for me). But grub might still win because of it's backlog of forum documentation in form of QnA.
<davidlt[m]>
It works on Fedora in general, but not sure on riscv64. I think it's supported, but no one attempted.
<Guest27>
I recently switched my Pi to Fedora so can't comment on it, but I do love it for other reasons. SELinux and Podman (especiall rootless) are a godsend.
<davidlt[m]>
We don't use GRUB2 yet. LoadFile2 and boot hard id UEFI protocol is not yet implemented upstream.
<davidlt[m]>
Podman rootless is a king :)
<davidlt[m]>
Half of stuff on my system run in toolbox and podman rootless.
<Guest27>
Have you looked at how Debian recommends building a "barebones" image? They don't use grub afaik... they use u-boot and it provides a menu like grub to choose kernels/envs.
<Guest27>
That looks very minimal and could be easily changed to either grub/systemd-boot based on how fedora on x86 goes
Guest27 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
Guest27 has joined #fedora-riscv
jcajka has joined #fedora-riscv
<davidlt[m]>
Yeah, so the plan is to use UEFI and GRUB2 because that's how majority of arches work on Fedora. We don't want to have something radically different. Other options like systemd-boot is fine, but they wont be default. Also someone has to maintain that.
<davidlt[m]>
I know (because I looked into it) that systemd-boot works in Fedora as an option and there instructions (relatively easy) to switch from GRUB2.
<Guest27>
Oh okay, I can chip in for systemd-boot (once I get my board)
<davidlt[m]>
Tianocore EDK2 has been working on SiFive HiFive Unleashed for years now too (minimal support).
<davidlt[m]>
You might notice that some companies are working on Tianocore UEFI proper implementation in general.
<Guest27>
Yeah, HPE is one of them
<davidlt[m]>
The RISC-V Platforms specifications requires UEFI too.
<Guest27>
But I don't expect EDK2 to work on VisionFive OOTB
<davidlt[m]>
All the current boards are "e-waste" because none of them support the RISC-V standards that are still being written.
<Guest27>
Maybe uboot for now and we can let go of uboot once EDK2 is there
<Guest27>
:)
<davidlt[m]>
RISC-V Profiles, RISC-V Platforms, OS-A SSE, etc.
<Guest27>
Are these mandatory?
<davidlt[m]>
It will be for compliance.
<davidlt[m]>
Basically this will define for software how to handle the hardware.
<davidlt[m]>
We will have a single disk image that just works on any hardware that is compliant.
<davidlt[m]>
Sadly specifications efforts are bit slow right now thus we have wild wild ARMv7-ARMv8 world with a lot non-compliant boards.
<davidlt[m]>
The next major ISA baseline most likely will be RVA23U64 too.
<davidlt[m]>
RVA22U64 should be ratified (my hopes) late this year, but it will lack things like various vector extensions.
<davidlt[m]>
The current "RV64GC" aka RVA20U64 is not on what RISC-V future will be built for high performance SoC/CPUs.
<davidlt[m]>
Heck, we don't even have ratified psABI document yet ;)
<davidlt[m]>
But once psABI and RISC-V Profiles are ratified we at least know that your shipped binaries should be OK.
<davidlt[m]>
No, the kernel should be able to handle things at the run-time
<davidlt[m]>
But in general disributions and some components might expect HW and FW to work in compliant way especially if hardware has the sticker.
<davidlt[m]>
I am not a fan of D1 and what T-HEAD did. It does have the upstream support now IIRC, but it has some bits that aren't RISC-V spec compliant.
<davidlt[m]>
They kind mask it these days by using errata framework.
<javierm>
davidlt[m]: yeah, I understand that enterprise distros/companies won't support it. Just like they expect SystemReady-SR hw for aarch64 servers, etc
<javierm>
davidlt[m]: but wondered how far was from the spec to even be something that could be made to work upstream
<davidlt[m]>
As I said D1 is even worse because it brakes RISC-V standard :) Not even the future not yet ratified standards :)
<davidlt[m]>
Well D1 gets it's support because of wide availability, otherwise it would not have happened (personal opinion).
<javierm>
davidlt[m]: got it. So even the RISCV ISA standard, not just the enterprise nice to have stuff like EFI, ACPI, etc
<javierm>
davidlt[m]: well, that was the case of the rpi as well :)
<davidlt[m]>
Realistically if no mistakes were done (TBD) JH7110 based SBCs will be good enough. Up to 1.5X performance compared to FU740 in Unmatched for <100 USD price point.
<javierm>
davidlt[m]: cool
<davidlt[m]>
But remember that StarFive Tech most likely will heavily depend on the community for upstreaming effort.
<davidlt[m]>
Again, personal opinion.
<davidlt[m]>
What will make it popular and last for some time is PINE64.
<davidlt[m]>
A lot of communities are familiar with PINE64 and there in general exist some trust based on experience.
<davidlt[m]>
There are more boards coming up (more T-HEAD stuff, SiFive/Intel, BeagleBoards, etc.)
<davidlt[m]>
BeagleBoards sadly got delayed (those would have been popular too).
<davidlt[m]>
So JH7110 based boards take the premium spot if PINE64, StarFive Tech can release them fast enough.
<javierm>
davidlt[m]: yup. the D1 was the first cheap one I could buy here in Spain
<davidlt[m]>
Especially before SiFive/Intel board arrives.
<davidlt[m]>
I don't even have a D1 (Lithuania, EU).
<davidlt[m]>
Most of that is available via China shops and price point isn't that great comparing to JH7110.
<davidlt[m]>
JH7110 continues to have U74 core complex from SiFive.
<davidlt[m]>
SiFive/Intel stuff is based on a newer (somewhat old) P550 (the first OoO core) based on Intel 4 (7nm).
<Guest27>
davidlt I assume my question can be answered with "let's see what way we diver to". But let me ask it anyways. The developments that you talked about (RVA22U64), once adopted, will they break support for the current RISC-V SoCs?
<davidlt[m]>
Combine OoO with 7nm process and that alone is huge performance improvement (assuming no major erratas).
<javierm>
davidlt[m]: thanks for all the info
<javierm>
something I liked about the D1 though was the form factor, specially for someone who already has too many boards in a cabinet :)
<davidlt[m]>
Guest27: at some point future Fedora disk images (out of the box) might run on the current hardware. Might have board specific adjustments (like it's done now).
<davidlt[m]>
In general it might not boot too.
<davidlt[m]>
If all standards land at RVA23 (expect next major RISC-V ISA baseline) timeframe that's what distro will use by default.
<davidlt[m]>
That's a lot of new instruction extensions in RVA23 that today don't exist in SoCs.
<davidlt[m]>
javierm: yeah, I really stopped buying ARM based SBCs because they lack standards and compatibility.
<davidlt[m]>
It was all fun 10+ years ago boostrapping and working on aarch64. Had great hope at Linaro and 96Boards, standards, etc. but that didn't really happen. We didn't manage to fully fix "armv7l" madness.
<davidlt[m]>
So aarch64 works in the server land, but not in the SBCs.
<davidlt[m]>
A few years a new project happen to somehow make Raspberry Pi compliant :)
<javierm>
davidlt[m]: yeah, well nowadays is much better with SystemReady IR and SystemReady IR-ish boards that at least allow to do EFI boot using u-boot
<davidlt[m]>
Somehow to pull RPi to get it compliant.
<javierm>
davidlt[m]: yes, ironically rpi4 is the most standard aarch64 SBC thanks to that edk2 port
<Guest27>
Oh okay, thanks davidIt
<Guest27>
Is that an 'L' or an 'i' in your username?
<Guest27>
I've tried PFTF's port of EDK2 for the Pi. Not the most stable thing imo XD
<davidlt[m]>
lt -> LT. Yes I am lazy. I am "David" and I am from Lithuania (LT) thus David +LT :)
<Guest27>
RHEL's ISO boots, installs and then doesn't boot after a 3rd or 4th reboot lol, very weird. And no, I didn't install any updates. Only registered my system and rebooted.
<Guest27>
Ah okay davidlt
<javierm>
davidlt[m]: you mentioned pine64, I've a rockpro64 and pinephone pro. For both I've a u-boot in the SPI flash and then can use standard EFI fedora images
<javierm>
davidlt[m]: so yeah, it's not EFI + ACPI but better than what it was with armv7 SBCs
<davidlt[m]>
Yeah, I have PineBook Pro :)
<davidlt[m]>
2-3 years and I still don't have WiFi :)
<davidlt[m]>
Because doing a proper thing to get it working takes so long :)
<Guest27>
lmao, good thing I didn't get one
<javierm>
davidlt[m]: my question for D1 was in that vein, if would mean not EFI + ACPI, or really just a custom ISA not supported by GCC, kernel, etc
<javierm>
davidlt[m]: but now I understand that will be supported with some erratas
<Guest27>
Apparently there was a huge controversy with Pine64's decision by choosing Manjaro as the official distro
<davidlt[m]>
I bought PineBook Pro because I wanted aarch64 laptop. That was the best option to have. I have trust in PINE64 and TL Lim.
<javierm>
and probably at some point it could be a EFI+DTB
<Guest27>
TL Lim?
<javierm>
davidlt[m]: I think the problem is what you said, relying on the community to give proper SW
<davidlt[m]>
I think he is the founder of PINE64.
<davidlt[m]>
So far only SiFive have provided majority of vendor support to their SoCs.
<Guest27>
Oh okay
<davidlt[m]>
Actually FU740/Unmatched support was posted for upstream support before product went to hands. That was cool!
<Guest27>
VisionFive V2's marketing says it's "mainlined" and 5.10 and 5.15 has support for it
<davidlt[m]>
Depends. U74 is supported, but not their SoC.
<davidlt[m]>
Or all the new features in U74.
<Guest27>
Let's see what happens this Nov :)
<davidlt[m]>
They have significantly newer U74 cores. Some erratas don't apply to their U74 cores.
<Guest27>
If it gets into the hands of actual developers, I assume it will be supported by the "larger launch" of Feb '23
<davidlt[m]>
There potentially is new IP blocks (mainly L2 prefetcher) that probably does not have a driver in Linux (might not even need one).
<davidlt[m]>
Basic boot (boot + uart and networking) should happen soonish.
<Guest27>
Yeah, let's see how it turns out
<davidlt[m]>
All the fancy things like GPU, video/image processing, etc. might take significant time.
<davidlt[m]>
GPU might even take years.
<Guest27>
That depends on Immagination and our imagination :p
<davidlt[m]>
Imagination just recently started working on it. I think it's mostly Mesa work for now (?). Not following closely.
<Guest27>
Me neither
<Guest27>
Btw, when are you getting your board?
<davidlt[m]>
That's constantly changing.
<Guest27>
Which board are you talking about tho?
<davidlt[m]>
VisionFive V2
<Guest27>
Doesn't that have a set window of Nov-Feb?
<davidlt[m]>
Current I expect to get one sooner
<Guest27>
Oh, a dev special?
<davidlt[m]>
Some developer tend to get boards sooner, even PINE64 Star64 is already in some hangs.
<Guest27>
Nice!
<davidlt[m]>
s/hangs/hands/
<Guest27>
ack
<davidlt[m]>
Typically boards might be available (early engineering samples) many months before it gets into hands of most folks.
<Guest27>
gotcha
<rwmjones>
morning
<davidlt[m]>
For example SiFive HiFive Unmatched boards for developers are Rev 3A0, not 3B0.
<davidlt[m]>
PINE64 is well known to send out the hardware to developers, find bugs, get feedback, improve, etc.
<davidlt[m]>
The early VisionFive V2 in November also has an issue with one of Ethernet ports (cannot do 10/100 Mbit).
<davidlt[m]>
The one in Feb doesn't have it. So it's a different revision.
<Guest27>
Oh no, the 10/100 Mbit is a cheaper option
<Guest27>
You can still get a 4GB board with dual-1-Gig eth in Nov
<Guest27>
That's what I'm getting
<Guest27>
The one in Feb is for 8GB dual-1-Gig eth variants
<davidlt[m]>
All ports are 1G, but one cannot do 10/100 Mbit IIRC
<davidlt[m]>
No that anyone runs stuff on 10/100Mbit these days :)
<Guest27>
That's a cheap option
<davidlt[m]>
Ah
<davidlt[m]>
Wrong.
<davidlt[m]>
One is 10/100Mbit, another is 1G only :)
<davidlt[m]>
So both ports aren't 10/100/1G capable until Feb boards.
<Guest27>
wait
<davidlt[m]>
Quote: Super Early Bird is a special version, which has different Ethernet ports, one support 10/100Mbps speed, other is 1000Mbps only. But other features same as normal version.
<davidlt[m]>
If you want I can respin with parallel build disabled
<rwmjones>
let me look at this one, I'll see what's going on
<davidlt[m]>
Okay :)
<rwmjones>
oh that was actually a build of ocaml itself
<davidlt[m]>
Yes
<davidlt[m]>
I was hoping to do ocaml + all ocaml-* packages today
<rwmjones>
just doing a local build to see if it's reproducible
<somlo>
davidlt[m]: I dug through the logs and figured out that I need to extract u-boot.itb and u-boot.spl.bin from uboot-images-riscv64-...noarch.rpm :) But what's the difference between qemu-riscv64, qemu-riscv64_smode, and qemu-riscv64_spl?
<davidlt[m]>
different machine support
<davidlt[m]>
different configs and boot order and other u-boot environment variables
<davidlt[m]>
You can look into U-Boot files to find config files and config headers for each machine
<somlo>
well, it's somewhat simplified by the fact that only qemu-riscv_spl has uboot-spl.bin :) so if I cargo-cult the bread crumbs from the July 15, 2022 chat logs, that's the one I want
<davidlt[m]>
uboot-spl is just a very minimal u-boot which inits DDR and looks for u-boot ITB (which is DTB) and loads the correct thing
<somlo>
also (and correct me if I'm wrong) rwmjones on Jul. 15 2022 was talking of running qemu/kvm on actual rv64gc[+] hardware, so there may be extra quirks that I'm either missing or don't apply to me, for added fun and games :D
<somlo>
and got opensbi displaying a bunch of stuff in my terminal, then getting stuck there (ctrl-a c did *not* get me out, I had to kill the terminal itself :) )
<somlo>
nvm, forgot the backslash after stdio :)
zsun has joined #fedora-riscv
zsun has quit [Remote host closed the connection]
<somlo>
now I'm in an endless loop of trying to uncompress the kernel, then getting an unhandled exception: https://pastebin.com/QwpPGrBR
zsun has joined #fedora-riscv
zsun has quit [Remote host closed the connection]
<davidlt[m]>
somlo: at least you got it to work :)
<davidlt[m]>
Hmm... Could it be that some process damaged memory?
<davidlt[m]>
That used to happen before in some cases.
zsun has joined #fedora-riscv
zsun has quit [Client Quit]
<somlo>
davidlt[m]: so then, the new official qemu instructions are: 1. unpack uboot-images-riscv64-*.noarch.rpm; 2. use command line above (incuding the missing '\') -- nice and easy, I'll write that down!
<somlo>
only trouble is the weird crash -- you mention "some process damaged memory" -- how would that even happen?
<somlo>
and, more importantly, how did you fix it when you saw it happen before?
<javierm>
somlo: yeah, because is the bootloader (or firmware) that should decompress
<davidlt[m]>
somlo: try loading everything manually instead of extlinux to check if all looks OK
<somlo>
you mean, use -kernel and -initrd to bypass u-boot?
<davidlt[m]>
No, get into u-boot prompt
<davidlt[m]>
Load dtb, kernel, initramfs and call booti
<davidlt[m]>
That's what extlinux basically does
<davidlt[m]>
You can adjust things as needed to explore if anything changes
<somlo>
so I'm at the '=>' u-boot prompt, trying to figure out how to load things manually (don't have a lot of prior exposure to u-boot, so I'm a bit slow, sorry :)
<davidlt[m]>
If you could runt it at 1.5GHz, recompile Fedora with bitmanip and tune L2 prefetch for good enough operation it should quite faster. Probably no more than 1.5X of default FU740.
<davidlt[m]>
somlo: that's just a copy from extlinux.conf
<somlo>
and I need to figure out what value of UUID to use for root on my own image -- assuming the exact initrd and vmlinuz file names didn't match up, this was a different (earlier) build than the latest nightly (from july 22) that I'm working with
<davidlt[m]>
No, you don't need to use UUID
<davidlt[m]>
This is for the systemd because it can do that
<davidlt[m]>
You can directly tell /dev/something
<somlo>
so in my case it'd be what, `/dev/virtio1p2`, or what's the naming convention?
<somlo>
or /dev/vda2
Guest27 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<davidlt[m]>
probably vdaX
<davidlt[m]>
I used to have root=/dev/vda1 according to my notes
<somlo>
but /dev/vda1 is 'virtio 0:1' and therefore what's mounted as '/boot', no?
<somlo>
so it'd have to be /dev/vda2 then
<davidlt[m]>
this is before we had /boot I think
<davidlt[m]>
So yes,
<somlo>
can I `cat` the contents of a file on virtio 0:1 from the uboot command lie ? :)
<somlo>
*line
<davidlt[m]>
You should be able too
<davidlt[m]>
Not sure if now or in the future U-Boot releases :)
<davidlt[m]>
There is xxd command proposed to hexdump the content of the file
<somlo>
hmmm, no `xxd` in the current fedora-riscv64 version
<somlo>
I was going to cut'n'paste the UUID, but screw it, I'm going with /dev/vda2 :)
<somlo>
after executing `booti ${kernel_addr_r} ${ramdisk_addr_r}:${initramfs_size} ${fdt_addr_r}`, I get "Bad Linux RISCV Image magic!" and kicked back to the u-boot prompt
<somlo>
here's all my manual loading commands to uboot:
<davidlt[m]>
(and yet I am trying to bootstrap Perl)
<somlo>
guess I'll wait for an updated `uboot-images-riscv64-*.riscv64.fc33.noarch.rpm` to show up, then try again the "normie user" (as opposed to the "u-boot ninha") way :D
<somlo>
*ninja
<somlo>
my shitty keyboard is spoiling my lame attempts at making jokes :)
<davidlt[m]>
These images are up to date, almost latest versions
<somlo>
well yeah, but rwmjones found the bug, so it's going to the builder, presumably, and might take a while (hours? days?) to become available *with* the fix ?
<davidlt[m]>
No, that's ocaml. Doesn't affect U-Boot or OpenSBI.
<somlo>
oh, that's a different bug and I just got confused by the cross talk
<davidlt[m]>
So it should work out of the box, it's just that someone (i.e. me) needs to sit down and try it to write instructions.
<somlo>
so we have a bug in u-boot, that's crashing while unpacking the kernel, that we don't yet have a fix for
<davidlt[m]>
No
<davidlt[m]>
That's not a bug, that's me not having low brain utilization this evening :)
<somlo>
oh, ok, I'll back off then, live to pester you another day :D
<davidlt[m]>
The thing is that we gave a garbage to load.
<davidlt[m]>
Because we mixed the variables.
<davidlt[m]>
The kernel must be loaded into kernel_addr_r
<davidlt[m]>
Also try: fdt addr ${fdtcontroladdr};
<davidlt[m]>
My want to experiment with: setenv fdt_addr ${fdtcontroladdr};
<davidlt[m]>
fdt_addr is typically were DTB is loaded. fdtcontroladdr is DTB that is embedded part of U-Boot for this particular device (aka the one in the firmware).
<davidlt[m]>
We don't modify ramdisk_addr_r and kernel_addr_r and etc. because we want to test the defaults that are builtin.
<somlo>
ok, how do I make sure FDT from QEMU "is present" ? I have `dtb-5.18.8-200.0.riscv64.fc33.riscv64` on `virtio 0:1`, should I load it explicitly, and if so, where (fdtcontroladdr, fdt_addr_r, something else)?
<davidlt[m]>
No
<davidlt[m]>
QEMU will provide the DTB
<davidlt[m]>
(you can actually dump it and use like on any device)
<somlo>
ok, so with or without `fdt addr ${fdtcontrolladr}` in the instructions you provided, after I issue `booti` command it goes back to the infinite loop of crashing and restarting just as before
<davidlt[m]>
I might try it tomorrow, don't want to start hacking on it before hitting the bed