<somlo>
davidlt[m]: with all of the above CONFIG_* options turned off, I am no longer getting the store/AMO crash during early boot
<somlo>
so, good news is I *think* I can get a fedora(-ish) system to boot on LiteX :)
<davidlt[m]>
Which ones? Matrix doesn't show anything above (sometimes it doesn't sync well with IRC)
<somlo>
mediocre news is that now I have to narrow down just which one of those CONFIG_* options is the *actual* culprit, and what the implications of that will turn out to be :)
<somlo>
hang on, I'm going to cut'n'paste them again
<davidlt[m]>
Ah, one of those above from "$ grep ^+ /tmp/defconfig.diff | grep y$" ?
<somlo>
yeah
<davidlt[m]>
Ah, ok, that's too long list.
<somlo>
I went and turned just those off and rebuilt the kernel, and now it finished building and doesn't crash
<somlo>
and I have no real prime suspects -- that's why I said "mediocre" :P
<davidlt[m]>
Hmm...
<davidlt[m]>
+CONFIG_SOC_STARFIVE=y
<davidlt[m]>
+CONFIG_KEXEC_FILE=y
<davidlt[m]>
+CONFIG_ERRATA_THEAD=y
<davidlt[m]>
Those would be interesting.
<somlo>
I figured I'll do a bisect-like thing where I turn half of them off, see what happens, and go from there -- I'll make sure these are in the first half :)
<davidlt[m]>
ERRATA_THEAD should do nothing on your CPU, kexec support was added just recently IIRC, starfive stuff should do nothing too on your CPU.
<davidlt[m]>
Yeah, bisection is the best here.
<davidlt[m]>
somlo: once you get the CONFIG_* option that's causing it could you do a full bisection to figure out which commit causes that option to act like that?
<somlo>
I'll burn that bridge when I get to it -- optimistically, knowing the actual option might tell us if it's a Rocket-chip vs. some physical taped-out ASIC behavioral discrepancy, or something along those lines
<somlo>
but it all depends on what the option actually turns out to be...
<somlo>
ok, building with just your three commented out, we'll hopefully know if it's one of those by tomorrow :)