To boot NetBSD on the 122-16, copy the .dtb built from
zynq-red-pitays-122-16.dts, the first-stage bootloader (called
boot.bin) and U-Boot that came with the 122-16 and a kernel image,
netbsd.ub, built for earmv7hf to an MS-DOS partition on an
MBR-partitioned SD card. At the U-Boot prompt, "Zynq> ", type these
commands:
i2c dev 0
eeprom read 0 0x50 0 0x1804 0x400
env import -b 0 0x400 hw_rev serial ethaddr
setenv bootargs "root=ld0a"
fatload mmc 0 0x01f00000 device~1.dtb
fatload mmc 0 0x02000000 netbsd.ub
fdt addr 0x01f00000
fdt set /axi/ethernet@e000b000 local-mac-address $ethaddr
bootm 0x02000000 - 0x01f00000
Note that the ethernet PHY will not attach unless you have applied
the patches from Lloyd Parkes in kern/58083.
On NetBSD, libdrm uses this to discover what kind of bus the device
is on, without which it refuses to expose the render node at all,
rendering it useless. With this change, libdrm is able to use render
nodes on NetBSD.
Since this is just reading out information about the bus type and
bus/dev/func numbers, I don't think it's problematic to expose to
render nodes.
This requires tweaking the access path to the master.
PR kern/58180
Leave a little ACPI-related functionality disabled for now, like
getting EDID out of ACPI -- needs a bit more work to make this work,
and I don't have hardware to work on that.
Should help with failures of the forms:
- unable to locate a BIOS ROM
- bios: unable to locate usable image
on various machines.
Add an assert to usbd_xfer_schedule_timeout to enforce this.
Since access to ux_status is serialized by the bus lock, and nothing
releases the bus lock in the interim, this doesn't make a functional
change. But it does reduce confusion by readers, who no longer have
to worry if some callers got the order wrong. It could also now
potentially be factored out in a subsequent commit.
Use sg_alloc_table_from_bus_dmamem to do this.
i915_gem_mman.c vm_fault_cpu and i915_gem_object_release_mmap_offset
both rely on sg_pgs to be a page array, so providing a table with
only one entry doesn't work (except by accident, if the object is
page-sized anyway). And they rely on the sg_pgs entries to be
initialized, which we weren't doing before, and which
sg_alloc_table_from_bus_dmamem does for us.
Related to PR kern/57833.
XXX pullup-10
Use sg_alloc_table_from_bus_dmamem to do this.
i915_gem_mman.c vm_fault_cpu and i915_gem_object_release_mmap_offset
both rely on sg_pgs to be a page array, so using something else like
size >> ilog2(mem->mm.chunk_size) entries doesn't work. And they
rely on the sg_pgs entries to be initialized, which we weren't doing
before, and which sg_alloc_table_from_bus_dmamem does for us.
Related to PR kern/57833.
XXX pullup-10
This is needed by i915 gem fault, which maps user virtual addresses
to those pages, and by i915 gem object destruction, which does
pmap_page_protect on the pages to remove any of those user virtual
mappings.
This needs pmap_kenter_pa rather than pmap_enter(pmap_kernel(), ...)
in order to preserve the _kernel's_ mapping of the pages after
pmap_page_protect.
But bus_dmamem_map currently uses pmap_enter(pmap_kernel(), ...)
instead which creates a mapping that is removed by pmap_page_protect.
So we use a variant of bus_dmamem_map that uses pmap_kenter_pa
instead. Perhaps bus_dmamem_map should do this itself, but this
change is less risky to pull up than a change to bus_dmamem_map
itself.
PR kern/57833: kernel panic on xorg exit
XXX pullup-10
sg_npgs currently fails to match obj->base.size/PAGE_SIZE only due to
bugs in the construction of sg_pgs in various i915 gem object types,
which we should also fix, but let's avoid compounding it here.
Related to PR kern/57833.
XXX pullup-10
PR kern/57268
XXX pullup-10
commit 4fbe112a569526e46fa2accb5763c069f78cb431
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Feb 24 10:11:20 2020 +0000
drm/i915/gtt: Downgrade gen7 (ivb, byt, hsw) back to aliasing-ppgtt
Full-ppgtt on gen7 is proving to be highly unstable and not robust.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/694
Fixes: 3cd6e8860ecd ("drm/i915/gen7: Re-enable full-ppgtt for ivb & hsw")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224101120.4024481-1-chris@chris-wilson.co.uk
The files are taken from the visionfive branch with latest DTS related commit
commit 9b5f280fa413ee76fac20cd575075fc53468d527
Author: Emil Renner Berthing <kernel@esmil.dk>
Date: Sun Oct 31 17:15:58 2021 +0100
riscv: dts: Add full JH7100, Starlight and VisionFive support
The hacky way of getting the BIOS mapped only works on x86. ACPI
should be preferred if available. Makes BIOS reading though VFCT
work on aarch64 with EDK2. (But only if EDK2 has POSTed the GPU.)
XXX amdgpu should get the same treatment.
linux_pci.c revisions 1.24 and 1.25 implemented most of the remaining
missing PCIe backends, but only enabled them for some amdgpu portions.
this enables all code marked with "XXX amdgpu pcie", "XXX radeon pcie",
and "XXX pcie speed". for most of it, simply removing #ifndefs __NetBSD__
to enable compliation was required, once the new "bus->max_bus_speed"
member was added to struct pci_bus. add an "always fails" backend for
pci_enable_atomic_ops_to_root() which seems to only be necessary
for virtual GPU functionality (and could be implemented if needed.)
tested on radeon 5450, 7750, R7 240 [radeon], and RX 550 [amdgpu], and
nvidia 750 and 1030 [nouveau].
this still does not quite work on nvidia cards. there are two problems
that remain:
- the call to set the link speed is skipped because the speed is set
to the default value of "-1". nvkm_pcie_set_link() will actually
determine the right value for this and for some cards, calling this
function if the current speed is -1 helps set the link speed. it
may be that on linux other paths we don't have enabled properly
would set this (there's one via debugfs, and a jetson specific one,
though perhaps setting either AC or DC speed values as boot options
(after hooking up these for netbsd) would currently work.
- worse, cards newer than kepler - geforce 900, 1000, and newer, are
all lacking the backing support to set pcie link speed. the GT 1030
card i have been testing with remains at pcie 1.0.
Kernel should build now with all pci drm drivers stripped out but
DRM_LEGACY still enabled. (Might not be very useful, but it'll
build. Maybe we should also have DRM_LEGACY_PCI so those drivers can
be modloaded later.)
----------------------------------------
28 June 2023. Summary of changes for version 20230628:
0) Global changes:
Fixed a problem with the ASL/AML Timer() operator. Discovered by
UBSAN: ?array-index-out-of-bounds in acpica/dswexec.c:401:12 index
-1 is out of range for type 'acpi_operand_object?. Added
AML_NO_OPERAND_RESOLVE flag to Timer (since there are no runtime
arguments). Reported by: Abhishek Mainkar abmainkar@nvidia.com.
Added a define for size of acpi_srat_generic_affinity DeviceHandle.
Replaced a magic number with a define. The Linux kernel code will
utilize this. Reported by Dave Jiang dave.jiang@intel.com.
Added support for _DSC (Deepest State for Configuration) as per ACPI 6.5.
1) ACPICA kernel-resident subsystem:
Added port definitions for CDAT SSLBIS. Add upstream port and any
port definitions for SSLBIS. Reported by: Dave Jiang dave.jiang@intel.com.
Fixed misspelled CDAT DSMAS define: ACPI_CEDT_DSMAS_NON_VOLATILE
-> ACPI_CDAT_DSMAS_NON_VOLATILE. Reported by: Dave Jiang
dave.jiang@intel.com.
1) ACPICA kernel-resident subsystem:
Fix GCC 12 dangling-pointer warning. We're storing a persistent
pointer to an ephemeral local variable which technically is a
dangling pointer and the compiler is correct. However, since we
never indirect the pointer, this is a safe operation and we can
suppress the warning.
Also, some C run-times (like MUSL) aren't including <stdint.h>
indirectly so we must include it explicitly or we won't have the
type definition for uintptr_t.
2) iASL Compiler/Disassembler and ACPICA tools:.
IASL/RHCT: Enable dumping and compiling newly added nodes. The RHCT
table is updated with new nodes. Add compile and dump functionality
for these new structures.
AcpiExec: Added a new command, ?interrupt?. The Interrupt command
simulates an interrupt with a IntID (GSIV) equal to the first
argument of the call/invocation. The acpiexec code simulates the
behavior by OSPM: execute the _EVT method of the GED device associated
with that IntID. Submitted by: Jose Marinho jose.marinho@arm.com.
AcpiExec: Detect GED device and keep track of _EVT. The GED device
is described by a _HID of ACPI0013. This code traverses the namespace
identifying all GED devices. For each GED device in the namespace
we record the Interrupt object and the _EVT method. This information
is used when an interrupt is simulated via the ?interrupt? command.
Submitted by: Jose Marinho jose.marinho@arm.com.
----------------------------------------
31 March 2023. Summary of changes for version 20230331:
This release is available at https://acpica.org/downloads
0) Global changes:
Update all copyright notices to the year 2023. This effects all source
modules, as well as utility signons.
Add OS-specific support for Zephyr RTOS.
Fix miscellaneous code that accesses various objects.
Remove some dead code.
Add C ?Flexible Array? support.
Add support for 64 bit LoongArch compilation.
Add first batch of RISC-V related definitions.
Performed a global automated update to remove tabs, fix indentation
issues, etc.
1) ACPICA kernel-resident subsystem:
hwvalid: Drop port I/O validation.
2) ACPICA tools and utilities:
iASL: Added full macro support in the preprocessor. Example:
#define ABCD(a,b,c,d) a+b+c-d
Known macro support limitations (at this time):
No support for multi-line #define macros (backslash continuation
lines)
No support for the C-style ternary operator
No support for the stringizing operator (#)
No support for the concatenation (token pasting) operator (##)
No support for variable number of macro arguments
Add support for AMD Secure Processor Table (ASPT) version 1.
Add support for Arm's MPAM ACPI table version 2.
ACPI 6.5: MADT: add support for trace buffer extension in GICC.
Headers: Delete bogus NodeArray array of pointers from AEST table.
PHAT table support is still ongoing.
there's a 1-element long array and a loop conditional that tries to see
if indexes for it are not identical. as these indexes will always both
be 0, the only valid index, the condition is always false. GCC 12
triggers a strange warning on this code that can never run (see below),
so simply assert the array size is 1 and comment the rest.
amdgpu_dc_stream.c:470:55: error: array subscript [0, 0] is outside array bounds of 'struct dc_writeback_info[1]' [-Werror=array-bounds]
470 | stream->writeback_info[j] = stream->writeback_info[i];
This driver is not built-in by default, thus loadable module can help (un)lucky
owners of 64-bit capable VIA (Nano/Eden) systems or early AMD/Intel systems
with some VIA chipsets, which include VIA integrated graphics.
I also boldly added product IDs for few later models from VX8xx/VX9xx chipsets
without 3D support (DX9_0) to "expand" the driver support to more systems.
Tested successfully basic functionality on VX800, and partially successfully
on VX900 (on VX900 Xorg failed to initialize due to openchrome related issues,
viadrmums attaches and it is by used the driver).
Didn't test on VX855, I don't have one.
Pull up to netbsd-10 is needed.
most of these are like, eg
void foo(int[2]);
with either of these
void foo(int*) { ... }
void foo(int[]) { ... }
in some cases (such as stat or utimes* calls found in our header files),
we now match standard definition from opengroup.
found by GCC 12.
If cv_wait_sig returns because a signal is delivered, we may
nonetheless have been granted the lock. It is harmless for us to
ignore this fact in three of the four paths, but in
ww_mutex_state_wait_sig, we may now have ownership of the lock and
MUST NOT return failure because the caller MUST release the lock
before destroying the ww_acquire_ctx.
While here, restructure the other three loops for clarity, so they
match the structure of the fourth and so they have a little less
impenetrable negation.
PR kern/57537
XXX pullup-8
XXX pullup-9
XXX pullup-10
This way they are computed -- using FP instructions -- before
DC_FP_END, after which point FP instructions will trap or behave
unpredictably.
This is a workaround, not a proper solution -- really, the
DC_FP_START/END calls should happen in a separate compilation unit
built without -mhard-float or whatever, but that's a lot more work to
make happen for now.
PR kern/57059
XXX pullup-10
drm_sched_init() is not called for these rings, and we'd panic trying
to mutex_destroy() a mutex that wasn't initialised.
this seems like a general bug, not a bug in netbsd port.
dyoung