- User Since
- Jun 6 2018, 11:31 PM (66 w, 4 d)
Sat, Sep 14
Tue, Sep 10
Mon, Sep 9
Sat, Sep 7
Fri, Sep 6
Hmm, calculations on powerpc64 seem to be offset incorrectly in both cases with the patched lld. Gonna meditate on a disassembly for a bit.
Sun, Sep 1
Interesting thought. That seems to me like it should also help a lot with the logic in ld.bfd as well.
Fri, Aug 30
Sat, Aug 17
The new KERNBASE allows my RB800 to boot without having to modify it, so that's a definite improvement there.
Will check for regression on G4 / G5 / POWER9 (and maybe test the X5000, if I can finally get uboot loader set up on it so I don't have to futz with mkimg to build test kernels) tomorrow.
on MPC85XXSPE build:
Aug 17 2019
Aug 8 2019
removing belt&suspenders bit.
Aug 7 2019
Jul 26 2019
ELFv1 and ELFv2 buildworld worked fine.
Boots on ELFv1 and ELFv2. Doing a buildworld to excercise it a bit.
Jul 25 2019
That's up to jhibbits.
Jul 24 2019
My patch seemed to fix things. I was able to buildworld and installworld (after rolling base back to a non crashy version).
Jul 23 2019
I'm going to try this and see if it works:
Actually, we might be able to determine what format the aux vector is by heuristics.
OK, with OLD_AT_COUNT dropped down to 27, it continues working (whether or not I use 32 or 27 in exec_copyout_strings(), so it looks like it will continue to work even if the normal AT_COUNT is incremented in the future.)
Jul 22 2019
Yep, that did it. exec_copyout_strings() needs to use the correct size for the aux vector or it will screw things up somehow.
I built a test program to examine auxv (or at least libc's idea of it): http://drop.rtk0.net/auxv.c
Yeah, I had bumped both of the sys/sys/param.h lines to 1300037.
Yeah, I had. Bumped both in sys/sys/param.h. Getting back into the machine to double check that I didn't do something silly with that now.
Jul 20 2019
Hmm, additionally, it looks like AT_EXECPATH is damaged, because I can't use /rescue/sh either, it just comes up with the usage.
elfv1, new kernel, old userland:
Jul 13 2019
Jul 7 2019
Makes sense to me. That's the same sort of thing that chrp_mem_regions() is doing to determine it for its own purposes.
Jul 1 2019
Not 100% sure, but I think you should skip the logic if either _NO_INCLUDE_COMPILERMK or _NO_INCLUDE_LINKERMK is defined. That appears to be what controls the variables not being defined.
Jun 28 2019
Looks like r344264 and r344798 have fixed this independently.
Jun 27 2019
Maybe move the EM_PPC: case down to right before the edesc = powerpc_eflags_desc; line and explicitly fall through there so that the e_flags code only runs on ppc64 and not ppc32, but both of them do the edesc?
Jun 25 2019
Will address comments and catch up with the latest API changes soon. Poking at it this evening.
Jun 24 2019
Current version tested on iBook G4, still works.
Current version also tested on rb800 (powerpcspe), works as well.
Jun 14 2019
I like the idea, it beats having to compile a custom kernel. This is also relevant on some of my macintoshes, where the keyboard works in OFW but not in the kernel debugger when I have an early crash.
Jun 13 2019
Over in powerpc land, we've been chasing crashes with dpcpu and vnet as well. Our current prospective fix is https://reviews.freebsd.org/D20461 but we don't understand why it seems to fix it.
Jun 12 2019
needs reroll, the backport of most of this landed with r349004.
Jun 11 2019
fix style(9) issue.
Jun 2 2019
May 27 2019
May 26 2019
May 23 2019
fix my diff config, context was missing
May 22 2019
This is the root cause of all the ctfmerge oddness on powerpc64.
Fix backwards logic.
Of course I was getting the first part backwards. The point stands that the support was missing.
May 21 2019
Remove DMAP_ZERO bits -- since we're in real mode while in the trap area, we can reach the magic trap address as TRAP_GENTRAP(0).
May 20 2019
May 18 2019
Loader comes up fine and loads kernel on my iMac G3 using the same cd. (Ctrl-c'd it at that point since the ppc64 kernel won't run on g3)
regenerated hfs stats:
May 15 2019
This one is not tested properly yet but I wanted to bounce the idea off jhibbits.
May 1 2019
Yeah I meant bits, not bytes. 64 bits. 8 bytes.
Apr 7 2019
Going to work on some issues I noticed with the power_save_sequence.
@luporl Feel free to commandeer this back again. Please do a test of the updated trap code with clang8/lld8. I have sucessfully booted this with my base/gcc 8.2.0.
marking done on addressed comments.
Rewrote trap code to not waste valuable trap space for addresses that are easily calculatable.
Tighten up the reset vector by one instruction.
Commandeering this to post updated trap code.
Apr 6 2019
Yep, there is indeed an 8-byte alignment restriction on .toc.
Also the section being subsumed into .got might throw off the linker as well.
Well, it's probably from the alignment being off. Ensuring alignment there makes sense to me imo. Checking what the actual requirements are...
Mar 29 2019
The TOC_REF bits have landed separately as rS345676.
Mar 26 2019
Note: The LINKS= line breaks installkernel on systems where /boot is a msdos filesystem (currently needed on some petitboot systems on powerpc64 -- Talos II in particular, due to lack of UFS support in the default PNOR builds)
Looks good here. It has the bugs fixed that I had in the original. +1
Mar 17 2019
Some parts of this will land separately. The ldscript chanages are split off to D19574 as more cases have been discovered where kernels were built with multiple PT_LOAD sections, even on ELFv1, and it should probably go in first.
Mar 16 2019
ELFv1 test went fine too on the G5.
Mar 15 2019
This is functionally identical to what I've been running locally since last October for my ELFv2 kernel builds.
Mar 12 2019
Feb 26 2019
Feb 25 2019
Regarding the sys/conf/Makefile.powerpc, sys/conf/kern.pre.mk and
sys/powerpc/include/vparam.h changes that you left out, leaving them out is correct -- they were POWER9BSD and/or local hacks that are unrelated.
Feb 22 2019
Feb 18 2019
Yeah, that's better.
Feb 14 2019
Jan 31 2019
Jan 15 2019
32 bit version works fine on G4.
Jan 10 2019
C question: Would a cast through void* be a better workaround for this specific issue by the way?
Abandoning in favor of the D18808 solution.
OK, I'm fine with this solution.