in bsd.lib.mk there's a check for "MKDEBUG != no" that will add
-g to CFLAGS (maybe) and to CSHLIBFLAGS (always), given that it
isn't in CFLAGS already.. except the conditional is "||" instead
of "&&" and since the MKDEBUG/NODEBUG checks pass, the CFLAGS
check isn't even performed.
additionally, check CXXFLAGS as well as CFLAGS.
this fixes the attempt to use "-g1" in the llvmrt build, which
fails because the compile lines end up being "... -g1 .. -g ..",
(the "-g" comes from the CSHLIBFLAGS variable in that case.)
this reduces the size of llvm-enabled gallium debug by ~1.5GiB
on amd64.
Reapply the fix to dt_status() from rev 1.10
("Don't return success when the target CPU is offline")
which was lost in rev 1.12 ("sync with FreeBSD").
The FreeBSD version that we have been using since then does run on NetBSD
but always reports that CPU 0 is online and all other CPUs are offline,
because the sysctl that it uses does not exist on NetBSD.
Poted from OpenBSD/vax. Note smg(4) monochrome onboard framebuffer
driver is also changed attached only if gpx(4) is not installed
or flags 1 is specified in config files, as OpenBSD did.
Tested on my VAXstation 3100/m30 with and without 8bpp gpx(4).
Revied on port-vax@ and "Please go ahead!" from ragge@.
https://mail-index.netbsd.org/port-vax/2023/01/thread1.html#004147
Worth to pullup to netbsd-10.
there are several problems solved in this change:
- lots of work was re-done when we already have determined the
device booted from, so several new early returns introduced
if booted_device has been set
- due to the lack of cpu_bootconf(), raidframe softroot would
override "root=xxx" on the boot command line (note that
platforms that use eg, device_register() to detect the boot
device are not affected by this issue as they find the
boot device much earlier.)
- in the new cpu_bootconf(), switch the order of the platform
boot-config with the set_root_device() call. this avoids a
problem where "root=xxx" is checked after automated methods,
and is thus ignored.
- in fdt_detect_root_device(), remove the code to add "root=xxx""
string to the boot_args[] that would be later parsed by the
set_root_device() call, and simply set booted_device and, for
mbr installs, booted_partition directly. also, for any
successful call, perform an early return.
- define __HAVE_CPU_BOOTCONF so early boot calls cpu_bootconf().
tested on:
- rockpro64 booting from emmc, sata (big, and little endian)
- rockpro64 loading kernel from msdos partition
- rockpro64 booting from network (fails to auto-detect, with or
without this change)
- quartz64 booting from nvme
- lx2k booting from nvme
XXX: pullup-10
there are DEBUG-only aprint_normal() calls early in eg, ksyms
setup that may happen before eg curcpu() is setup. this is the
case in sparc64, where it sets up ksyms as early as it can so
that DDB has symbols early, which is before the curcpu() setup
is created, and thus the calls to pserialize_read_enter() and
pserialize_read_exit() attempt to access unmapped cpu_info and
due to being so early, the system faults to the prom.
simply use "cold" to determine whether to skip these pserialize
calls or not.
ok riastradh
XXX: pullup-10
The names of the tests were misleading: 'recursive' should have been
'nested', and the interesting topic in the 'cast' tests was not the cast
but the pointer dereference.
Whilehere, also remove VM definitions for obsolete COMPAT_HPUX stuff.
All hp300 machines has RAMs at a region from the highest address
i.e. 0xFFFFFFFF to smaller address (as HP claims "it's the MSB first"),
so kernels have to prepare PA==KVA mappings as the "last PT page" to
guarantee the running kernel works both before and after the MMU is
turned on. For such a special mapping, we have to set up necessary
segment table and page table during early startup, in pmap_bootstrap()
invoked from locore.s.
On the other hand, NeXT machines have RAMs at a region from 0x40000000
to below (i.e. to larger address) so we still need a PA==KVA mapping.
However currently NetBSD/next68k just uses the transparent translation
registers to achieve the PA==KVA mapping, so unlike hp300 we don't have
to prepare special segment table and page table for it.
Note many other m68k ports (like luna68k, news68k, x68k etc.) have
RAMs at a region from 0x00000000 so usually we can assume PA==KVA
and don't have to bother to prepare such speicial mappings.
No user visible changes (except now freed wasted pages for the tables).
Tested on my NeXTstation slab.
mlelstv