I've updated the patch, addressing kan's comments. I'll send out a separate review for enabling bus pass on MIPS (together with enabling it for the mips_pic (intr.c) tomorrow. I'll also update the bus_space_fdt removal patch tomorrow.

I do not see mips_pic.c in this patch, which is supposed to the the generic MIPS32 intr controller and is the place where cpu_establish_hard_intr for INTRNG is implemented. If you do not need rest of the mips_pic.c, consider moving these into an independent implementation file (mips/mips/intr.c?). You will need to export the root PIC pointer from MI intr code for that and that is the reason why I kept function in the file that implements root PIC on my SOC.

I will fix this in LLDB. Thanks Warner!

In D5171#110109, @imp wrote:

Also, the LLVM parser is wrong.

case llvm::ELF::EF_MIPS_ARCH_3:
case llvm::ELF::EF_MIPS_ARCH_4:
case llvm::ELF::EF_MIPS_ARCH_5:
case llvm::ELF::EF_MIPS_ARCH_64:
    return (endian == ELFDATA2LSB) ? ArchSpec::eMIPSSubType_mips64el : ArchSpec::eMIPSSubType_mips64;

This is incorrect. These arch (at least the first two) are both 32-bit and 64-bit. You know what arch you are executing based on the e_ident[EI_CLASS} telling you 32 vs 64 bit.

32-bit mips FreeBSD binaries are MIPS-3. And that's correct. And LLVM doesn't grok that. So the LLVM parser also needs work.

In D5171#110106, @imp wrote:

I don't like this interface. The CPU specific eflags aren't a property of the CPU, but rather are a property of how the binary was compiled. These should be in the header for the binary being executed, which is completely ignored. On arm, there's at least two flavors we support executing today. On mips we support 3 different binary ABIs. And we wish to support more flavors of those ABIs (soft-float, hard-float, cheri) and you can't know based on the kernel which one of these you are running.

Also, the LLVM parser is wrong.

I don't like this interface. The CPU specific eflags aren't a property of the CPU, but rather are a property of how the binary was compiled. These should be in the header for the binary being executed, which is completely ignored. On arm, there's at least two flavors we support executing today. On mips we support 3 different binary ABIs. And we wish to support more flavors of those ABIs (soft-float, hard-float, cheri) and you can't know based on the kernel which one of these you are running.

I meant to talk to you about possibly moving the Atheros SoCs to MIPS24K, but then got distracted with other things :-)
Yeah, I guess we can move the SoCs later. I did that for the Ralink SoCs in sys/mips/ralink for now, will be using the new cpu options with the Ralink/Mediatek FDT stuff too.

This fine by me; it reminds me that we never started using the mips24k pieces for those atheros SoC cores (all the ar71xx, ar91xx, ar933x, etc) that are actually mips24k. They're mips4k.

After discussion with imp@, removed the CPU_MIPS24KE option, as 24KE is not really different than 24K, apart from having DSP ASE, which can be detected dynamically via Config3 register.

After discussion with imp@, removed the CPU_MIPS24KE option, as 24KE is not really different than 24K, apart from having DSP ASE, which can be detected dynamically via Config3 register.

After discussion with imp@, removed the CPU_MIPS24KE option, as 24KE is not really different than 24K, apart from having DSP ASE, which can be detected dynamically via Config3 register.

Backed out the sys/mips/include/asm.h change as it is probably too risky at the moment.

Abandon in favor of fix in qemu. Changing ABI is too heavy-handed.

Updates diff to remove hdwr value fixup

Fine with me, make sure to include Relnotes: YES and comment on ABI concerns in the commit message.

This fixes my ability to use unmodified qemu-user code to build mips/mips64 packages.

The alternative approach of fixing sysarch(GET/SET_TLS) in qemu-bsd-user might be called for, pending confirmation from sbruno.
Our kernel does unnatural things in rdhwr emulation codem qemu-user might have to follow.

Committed at svn r286040

Regenerating diff from top of /usr/src. Sorry for the noise.

Ok, I had no interest in the function just ran into the build error while investigating unrelated problems on a device. Removed per review.

The changes to pads() for 64-bit processors aren't quite right. In particular, the second access to segtab[] isn't correct. The changes should look more like what you see in the DDB function just above pads().

Trying to incorporate feedback. I don't understand the pads changes, nor am I sure if all the ifdef I added is necessary.

How about I don't put the rest of my tree in this review.

Drop casts to (void *)

Note that the warning says "argument 3", which is the pv_va parameter, not "argument 2", which is the pmap parameter. Remove the (void *) from before the pmap parameter.

In D3206#64342, @alc wrote:

That's a different problem. If you're going to fix the printf()s, then remove the silly casting of the variable "pmap".

That's a different problem. If you're going to fix the printf()s, then remove the silly casting of the variable "pmap".

Please give this a once over. I've testbuilt this for the RSPRO(mips32) and MALTA64(mips64) kernels.

Let me do a thing to update this change so that it builds for mips/mips64 debug kernels.

Hrm, since this is used for MIPS64, I did a test build and it fails.

The change is correct. Commit it.

This also matches the pmap_pvdump() function in arm/arm/pmap-v6-new.c