Remove mips 32bit atomic_load/store_64.

In D13586#284245, @jhb wrote:

Yes, let's kill these and fix DDB instead.

Yes, let's kill these and fix DDB instead.

In D13586#284229, @jhb wrote:

BTW, I looked and the only place atomic_load_64 and atomic_store_64 are used in sys/mips is for DDB (db_read_bytes and db_write_bytes in sys/mips/mips/db_interface.c). It is not clear to me that this actually needs to be near this fancy. Most architectures just do a simple byte loop. Only 32-bit arm, mips, and powerpc attempt to handle accesses for exact word-size specially. arm doesn't try to handle 64-bit accesses with this kind of magic. powerpc just uses a 'uint64_t' load and store via C the same as it does for other word sizes. I suspect the db_read/write_bytes can just be simplified to match what powerpc does and and use simple C load/store and then these functions can be removed.

BTW, I looked and the only place atomic_load_64 and atomic_store_64 are used in sys/mips is for DDB (db_read_bytes and db_write_bytes in sys/mips/mips/db_interface.c). It is not clear to me that this actually needs to be near this fancy. Most architectures just do a simple byte loop. Only 32-bit arm, mips, and powerpc attempt to handle accesses for exact word-size specially. arm doesn't try to handle 64-bit accesses with this kind of magic. powerpc just uses a 'uint64_t' load and store via C the same as it does for other word sizes. I suspect the db_read/write_bytes can just be simplified to match what powerpc does and and use simple C load/store and then these functions can be removed.

looks good and useful. thanks!

thanks

Cleanup on error path during attach.

I just can say that I saw some problem in that area configuring MMC device for X1000 processor a month ago and was thinking about similar change.

• Remove unused parameters in jzsmb_reset_locked
• Replace timeval usage with timespec

looks good then!

Seems this patch is a lot more "clang friendly" as the MIPS64 clang compiled kernel can now at least *get* to trying to start init:

In D2535#163954, @adrian wrote:

I committed the pagemask enumeration/printing logic to -head a while ago. We should gather some dmesg's from various embedded MIPS boards.

IIRC, some of the mips24kc parts were only doing 4k pages.. :(

I committed the pagemask enumeration/printing logic to -head a while ago. We should gather some dmesg's from various embedded MIPS boards.

Copy/paste a couple of quick functions from pmap.c to pmap_mips64.c
and now the new option compiles and boots under MALTA64

Fix mips32 build.

Pull in CHERI change to fix compile time errors. Update and compile
tested world/kernel via mips64 target and MALTA64 under qemu.

Ah, I need to steal from a Brooks commit over in CHERI:

Currently fails to buildworld due to changes to pte.h:

Update review to head.

Going to update this to be applicable to HEAD after some build test. Some of this review has been committed by various folks.

Thank you! Already on github: https://github.com/freebsd/freebsd/commit/2a1c75d8f2f60bf398ad401e6cde49562f938564. Time to rebase ;)

Yes, I was planning to commit it on Wednesday if I get a chance, but wouldn't mind if someone else does it in the meantime...

does this still need committing?

I’m fine with this patch unless you consider it as quick recovery from damage caused by r304459.
But, current usage of INTRNG on MIPS platform is still little ‘non-standard’ and I thing that MIPS needs more love in this area.

In D7692#160754, @adrian wrote:

(Eg, it needs a bunch more testing on non-FDT, non-INTRNG platforms, but I bet that's going to be easy..)

ok, cool. commit it and we'll shake out any other issues afterwards. :)

The updated diff also fixes additional problems seen on Broadcom MIPS (INTRNG without FDT) as a result of the r304459 changes. The new diff was boot tested by mizhka.

This looks good to me.

Quick check on Broadcom 4716.

Provide more diff context

nathan, what do you think about this? it's fallout from the last intrng change.

In D7692#160205, @adrian wrote:

Hm, can you get someone who does FDT stuff on #bsdmips to look at this?

Hm, can you get someone who does FDT stuff on #bsdmips to look at this?

Previous diff was not compiling for BCM kernel config, as BCM only uses INTRNG but not FDT.
Rework the fix, so that cpu_establish_[hard|soft]intr uses a different intr mapping strategy, which doesn't require FDT-specific data to be exposed to non-FDT kernels.

Update for ARM64 and MIPS.

Update diff

Updated diffs upon suggestions from adrian and bsdimp.