I upgraded arcload on my Indigo2 a few weeks back when the ebuild was updated from 0.50-r1. Since it was a new version of the bootloader, I decided to install /usr/lib/arcload/sashARCS to my volume header - and neglected to backup the old one :( Now I get a PANIC whenever I try to boot. Same kernel, arc.cf are used. I can still boot the kernel directly using the Command Monitor, but it would be nice to use arcload again. Reproducible: Always Steps to Reproduce: 1. Install sys-boot/arcload-0.50-r2 on IP22 2. Reboot 3. no step 3 Actual Results: Boot failure Expected Results: Boot success
Created attachment 399338 [details] serial boot log
A lot of the fixes were just basic compile fixes only. Though, the sashARCS binary is unique in that it is in ECOFF format (converted by the wreckoff tool during the build), and that's simply done as a legacy fix for super old Indy's and Indigo2's. The fix there was to account for the new .MIPS.abiflags section added in ELF binaries now by GCC. I borrowed existing code in wreckoff to simply copy that section over from the ELF to the ECOFF, but that might not have been the correct thing to do. If you want, intercept the build and grab the sashARCS binary out before wreckoff converts it. It would be interesting to see if the ELF variant of sashARCS boots or not. My Indy hasn't been operational for 6+ years now, so it's not something I can easily test right now. I'll see about restoring the -r1 release back into the tree as a temp workaround as well.
I tried using the pre-wreckoff binary, but it seems to fail quicker now (note no msgs about grub filesystem, etc): Starting up the system... To perform system maintenance instead, press <Esc> Exception: <vector=UTLB Miss> Status register: 0x30004803<CU1,CU0,IM7,IM4,IPL=???,MODE=KERNEL,EXL,IE> Cause register: 0x30008008<CE=3,IP8,EXC=RMISS> Exception PC: 0x9fc371a4, Exception RA: 0x9fc3717c exception, bad address: 0x8 Local I/O interrupt register 2: 0xc0 <SLOT0,SLOT1> Saved user regs in hex (&gpda 0xa8740e48, &_regs 0xa8741048): arg: a8740000 0 beefed 887fec08 tmp: a8740000 a8747c10 887fec68 1 10000000 0 ffffffff 4 sve: a8740000 c12dc13a 0 c0f9138a 0 c0edd9c9 0 bf077b8a t8 a8740000 t9 c0dcea58 at 0 v0 c0f9138a v1 0 k1 0 gp a8740000 fp ffffffff sp ffffffff ra ffffffff PANIC: Unexpected exception [Press reset or ENTER to restart.]
I added -r1 back into the tree last night. Give that one a spin with the same compiler/toolchain and let me know how it works. I want to eliminate the compiler as the source of the problem. You'll have to use the pre-wreckoff version, because if you're using modern GCC, you'll get a failure on wreckoff when it encounters the .MIPS.abiflags section in the ELF binary.
I can't build -r1 anymore, it fails trying to patch the sources. Instead, I modified the r2 ebuild to only apply the patches r1 does, along with the wreckoff fixes and... it boots! After trying the other patches one at a time, it appears that the deb-elf64-on-m32.patch is causing the problem. (I'm running in an o32 profile if that's relevant)
I removed -r2 and added -r3, which comments out the 'deb-elf64-on-m32' patch. Please re-open if the problem still persists. Thanks!
