<dwfreed>
because every kernel build changes that hash
<Habbie>
oh, bet i need install -a after update -a
<Habbie>
or make clean?
<Habbie>
we'll see
<Habbie>
build completed in any case
<Habbie>
cause: 40008008 pc: 81bab408
<Habbie>
ffffffff81bab3c4 T prom_init
<Habbie>
* The bootloader passes a pointer to the boot descriptor in
<Habbie>
does it though!
<Habbie>
dwfreed, no joy from earlyprintk
<Habbie>
it doesn't help that i barely have a clue what i'm doing :)
<dwfreed>
heh
<Habbie>
the uboot mailinglist archives have fun quotes like "cavium never upstreamed their work so we cannot answer questions"
<Habbie>
however! even though i haven't gotten any text out yet, today's lesson is that the exception happens in some semi-plausible place
<Habbie>
so my kernel is loaded. it is started. no code signing shenanigans have prevented this.
<Habbie>
it's not a terrible outcome
<dwfreed>
yeah
<Habbie>
i can just edit the extracted kernel sources and hit 'make', right?
<Habbie>
here's a 3 line horror story
<Habbie>
prom_init();
<Habbie>
setup_early_fdc_console();
<Habbie>
#ifdef CONFIG_EARLY_PRINTK
<Habbie>
dwfreed, thanks, btw :)
<dwfreed>
hah
<dwfreed>
need earlyearlyprintk
<Habbie>
:D
Mangix has joined #openwrt-devel
<Habbie>
using (llvm-)objdump on build_dir/target-mips64_octeonplus_64_musl/linux-octeon_generic/linux-6.1.69/vmlinux at least gets me symbols right in the output
<Habbie>
the one in bin/ is stripped, even though i set sstrip to none
<dwfreed>
kernel and/or buildsystem tries extra hard to strip kernel debug info
<dwfreed>
because the whole image needs to be loaded into RAM, and will live there forever, so debug info is just wasting RAM
<Habbie>
ack
<Habbie>
haha, target/linux/*/config-6.1 has CONFIG_DEBUG_INFO=y .. except for one target
<Habbie>
if that doesn't work, i'm going to have to wolf fence debug into some register that linux doesn't care about but uboot exceptions do print ;)
<dwfreed>
or just figure out which register is in use for the failing code?
shibboleth has quit [Quit: shibboleth]
<Habbie>
from my notes
<Habbie>
ffffffff81bab408: dc 62 01 88 ld $2, 392($3)
<Habbie>
so some operation on `392($3)`. The register value that seems closest to `badvaddr: c30dee50` is `v1: c30decc8` and indeed, their difference is 392.
<Habbie>
is how far i am
<Habbie>
with some code digging i can likely figure out what struct has something at 392
<Habbie>
i don't know enough to be confident but it almost looks like openwrt is just not setting kernel .config right
<dwfreed>
guarantee you it's that cvmx_desc_addr load
<dwfreed>
because cvmx_desc_addr is at the very end of its rather large struct
<Habbie>
vaddr?
<dwfreed>
err, yes
<Habbie>
ack
<Habbie>
oh, i in fact have some register dumps where pc is the same but badvaddr, and the related register (sometimes v0, sometimes v1), vary together
<Habbie>
so definitely garbage from uboot
<Habbie>
which i can't immediately blame - i just tell it to run an ELF file
<Habbie>
well, ELF image
* dwfreed
closes the tabs before you nerdsnipe me any more