Repository navigation
Merge aurora-wip batch 6 (fleet14o and the Alpha 17 fixes, 9ff2b9a3) into integration/aurora - #878
Merged
Merged
Conversation
Commit eac7924 ("spi: apple-qspi: use the J616s Macronix boot NOR ID and registers") pinned the J616s boot NOR to c22b27, the Macronix ID macOS reports, in place of the W25Q64 ID. Not every J616s has that part: on a Mac16,7 RDID returns ef6517, the ID the driver already calls W25Q64, and SFDP is valid. That Mac now fails every NVRAM program and erase with -ENODEV. flash_status fails as well, because 35h is refused for the whole board although it is an ordinary SR2 read on this part. Let a board name a second JEDEC ID and list W25Q64 on the J616s. Decide 35h from the flash's own RDID, since the table no longer says which part is fitted. An empty second slot admits nothing, so a bus that reads zeroes stays refused. The status checks already follow the ID read from the flash. Fixes: eac7924 ("spi: apple-qspi: use the J616s Macronix boot NOR ID and registers") Assisted-by: LLM Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com>
The Redbird colour temperature was exported as an IIO_CCT channel, in_cct_input. No other driver uses that type and the IIO ABI does not document it, so userspace looking for an ambient colour temperature (for example an ambient white point policy) reads in_colortemp_*, the documented channel that hid-sensor-als also provides. Report the same firmware-computed Kelvin value as a processed IIO_COLORTEMP channel, in_colortemp_input. Lux, the report decoding and the CT720 and CT817 parts are unchanged. Update the driver ABI note, the driver documentation and the J616s parity collector to the new name. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…tates T6000 DCS accepts raw states 5, 6, 7 and 9. Write only the selected raw command as a complete 32-bit store, including rollback and T6000 suspend/resume, instead of replaying status bits from an earlier read. Keep fabric accesses separate and reject unsettled current state before a vote. Exercise command words, invalid raw states, table validation and rollback with a hardware-status model in KUnit. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Use the DCS state set 5, 6, 7 and 9. Raw 8 is invalid and fabric state codes belong to a separate controller. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Document the sparse raw-state allowlist, whole-word commands and settled-state requirement. The existing sleep floor remains a policy choice, not a validity floor. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…ecovery A recovery for one client's hang still killed the others: a CS2 reason-0 recovery cancelled 42 commands and Hyprland got ECANCELED from fail_unpublished(), which Honeykrisp treats as a lost device, so the desktop froze until a reboot. - ECANCELED is not reported as this client's failure from fail_unpublished(), the ordered output publication, or fail_while_owned() for spared work. Work the firmware listed as interrupted keeps reporting its failure. - Publication waits for a pending recovery, or for this owner's spared pair to drain, for up to RECOVERY_WAIT_MS (26 s) instead of the usual 2 s: the compute admission deadline extends (Admission:: extend_for_recovery) in ensure_compute, in the recovery waits of compute_packet including the input-source wait, and in Gate::enter_until, whose gate only a recovery closes; the render waits keep a WaitClock whose usual bound starts afresh once the recovery ends, and render admission extends its deadline while a recovery is pending. A spared quarantined pair waits until the caller's deadline; a guilty pair's publication still fails after a second. - Commands with failed inputs or predecessors stay cancelled: a failed fence does not prove its producer retired. The compute deadline host tests move to the longer recovery budget, and a mutant now checks that removing the extension fails them. Link: #433 Co-developed-by: Ryan Murray <ryan@aurorasilicon.org> Signed-off-by: Ryan Murray <ryan@aurorasilicon.org> Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
…led with A command whose input fence, ordered predecessor or compute source failed inherits the failure through inherited_error(). Only EIO, ENODEV and ETIMEDOUT became ECANCELED; any other error passed through unchanged and was reported as the consumer's own failure, which userspace treats as a lost device. A GPU recovery fails the render groups it dropped and cannot replay with ENODATA. One such recovery (render slot 10, 11 groups of a muvm GPU worker) took down Xwayland, whose next command consumed one of the worker's buffers. Xwayland's own commands then failed, so its buffers kept that failure in their fences, and 85 minutes later a newly started muvm GPU worker that imported them failed with ENODATA too, without any recovery. Cancel the consumer for every producer failure. ECANCELED is not reported as a device loss and does not poison the consumer's VM; its fence still carries the error, as the UAPI documents. An interrupted fence wait is not a producer failure and keeps its own error. G15 reports every input failure as a client failure anyway, so it keeps inherited_error() unchanged. Signed-off-by: Jonathan Goyvaerts <jonathan.goyvaerts@gmail.com> Assisted-by: LLM
The 14-inch M4 Pro uses the existing T6040 SEP and fingerprint sensor profile. Admit its board compatible alongside J616s. On a J614s with the board-specific boot and firmware setup, fingerprint enrollment and authentication work, including after a reboot.
Override the inherited J616s panel, audio chassis, touchpad, radio and fingerprint firmware identifiers with the J614s values used by a working J614s installation.
Describe the GL9755 reader, its SMC power enable, PCIe port and DART on J614s. Select both CLKREQ pins on the controller to avoid conflicting claims on the port.
Bring the J614s board up to aurora-wip, which is now the base of this pull request. integration/aurora carries an older J616s tree. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Fold in mchalunderscore's J614s panel, chassis, radio, trackpad and Touch ID identifiers from #816 Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Fold in mchalunderscore's J614s GL9755 SD reader description from #818 Both pull requests appended to the end of t6040-j614s.dts. Keep both blocks as they are. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Fold in mchalunderscore's change admitting the T6040 SEP profile on J614s from #813 Apple's J614s and J616s device trees describe the SEP and the Touch ID sensor the same way, and the change was tested with enrolment and authentication on a J614s. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The J614s (MacBook Pro 14-inch, M4 Pro) has the same speaker amps and headphone codec on the same AOP streams as the J616s, in a different chassis with different speakers. Add the speaker and jack card compatibles for it, so the 14-inch reports its own identity to userspace. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Apple's J614s device tree describes the same six SN012776 amps, TDM slots, sense layout and CS42L84 jack as the J616s. Only the chassis and speakers differ (acoustic ID 34 against 35). That is rule 2 of the table: same amps and layout, different chassis, so a compatible of its own sharing the J616 data. The card is then AppleJ614, not AppleJ616, so no J616 speaker profile, DSP tuning or UCM file is picked for the 14-inch speakers. There is no qualified J614 speaker protection profile yet. Until one exists the speakers stay at the lock this driver applies at probe: the amp volume is held at its lowest step, and only a protection daemon holding the Speaker Volume Unlock control can lift it. speakersafetyd has no J614 profile. speakerguardd starts only for profiled cards, and the J614 profile in its unreleased set says qualified = false, which it refuses to govern without an explicit opt-in. So nothing takes the lock on this card. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Apple's device trees for the J614s and J616s (MacBook Pro 14-inch and 16-inch, M4 Pro) are the same apart from the board identity, the panel, the speaker tuning, the Wi-Fi module, the trackpad and the power limits. Including the whole J616s board file left the 14-inch reporting 16-inch values to drivers and userspace, the J616 speaker card among them. Move the J616s board file into t604x-j614-j616.dtsi without the board values, as the J314/J316, J414/J416 and J514/J516 generations do, and label the Wi-Fi, Bluetooth, panel and trackpad nodes so the board files can set them. Each board file now sets its compatible and model, the brcm,board-type, the panel compatible and size, the AOP audio chassis name, the speaker and jack cards, the trackpad firmware and the Touch ID firmware names. The J616s and J616s tether DTBs decompile to the same tree as before. For the J614s the values are those of #816 and the SD reader of #818, with two changes: - The speaker and jack cards are apple,j614-macaudio and apple,j614-macaudio-jack ("MacBook Pro J614"), not the J616 cards. The J616 speaker protection profile and tuning are for the 16-inch speakers. With the J614 cards the speakers stay locked until a J614 protection profile exists. - adj-height-mm is 189, as on the J314s, J414s and J514s, which have the same 3024x1964 panel. It is the height below the notch and is only read while the notch is hidden. The SD reader stays J614s-only for now: Apple's J616s tree describes it the same way, but it has not been tried on a J616s. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Our model strings name the machine without its release date. Use "Apple MacBook Pro (14-inch, M4 Pro)" and "Apple MacBook Pro (16-inch, M4 Pro)". The boot loader already drops the date when it builds the SMBIOS tables, so About pages do not change. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Fresh SHAREDMALLOC slots and allocation requests both have a zero header. Polling their body without the matching channel notification can answer while firmware is still publishing the request. Snapshot the notified batch after the exact IRQ acknowledgment, before sending any answer, and retain a count across service calls. This preserves coalesced requests and prevents a later request from borrowing an old notification. Keep the existing absolute deadline and reply barriers. Add KUnit cases for delayed and unrelated notifications, batch wraparound, descriptor-selected IRQ bits and acknowledgment-before-read ordering. The boot simulator now publishes real notifications instead of relying on unconditional scanning.
…reads Document the MMIO accessor ordering contract and give the H17 backend the full barrier already used by H16. Include the notified batch count in H16 startup timeout evidence.
Desktop DCP firmware announces every compact EPIC service again under a fresh interface after each DCP poweron, on every endpoint, without closing the previous interface. Only the hotplug endpoints 0x27-0x29 replaced such services in place, so on the J616s each s2idle resume filled one more slot on endpoint 0x2a (both DCPs) and 0x2b (internal DCP) until "too many enabled compact services" stopped new services from binding. Count iomfb poweron generations per DCP and record the generation on each compact service. A service announced with the same binding, name and unit as an enabled one from an earlier generation replaces it in place, on any endpoint. Services from the current generation stay, so DPAVCTRL's same-name, no-unit siblings still coexist, and the hotplug endpoints keep replacing within a generation as before. Extend the AFKV2 host test to 64 poweron generations over every compact endpoint on two DCPs, plus hotplug, sibling, identity and capacity cases. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
aurora-wip added the RTC aliases and the ANE performance domain to t6040-j616s.dts. Both describe hardware the J614s and J616s share, so they go into t604x-j614-j616.dtsi. The J616s DTB still decompiles to the aurora-wip one apart from the model string. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
A CD321x port waits for its USB4/Thunderbolt router only until the driver core stops waiting for missing dependencies, ten seconds after the last driver bound. After that it continues without the router for good: a Thunderbolt or USB4 dock still enters TBT mode on the Type-C side, but ACIO is never started, the NHI is never populated and only the dock's USB 2.0 hubs appear. Fedora's initramfs carries tps6598x for USB keyboards at an encrypted root's passphrase prompt, but not thunderbolt_apple. While the prompt waits, the deferred probe timeout fires and the ports give up; the router module loads from the root filesystem twenty seconds later and registers its switches with nobody to take them. On a J414s with LUKS: [14.308] tps6598x 0-003b: deferred probe timeout, ignoring dependency [14.308] tps6598x 0-003b: USB4/Thunderbolt router unavailable, continuing without it [31.156] systemd[1]: Switching root. The same machine's Arch install, without LUKS, switches root at 2 s and its docks work. Keep a port that gave up on its router watching for it. The typec core now notifies watchers when a USB4/Thunderbolt switch registers; the port looks its router up again, takes the switch and reapplies the current cable through it with the restore event used after system sleep, so a dock attached since boot gets its tunnels too. The watch starts after the probe-time lookup and is followed by one lookup of its own, so a router that registers in between is not missed. Removal stops the watch and drains a pending lookup before it releases the switch. Assisted-by: Claude Opus 5.5 Signed-off-by: DjDeveloperr <hey@djdev.me>
…e trips Every thermal zone on the J616s runs the power allocator, and every one has a single passive trip. With one passive trip the allocator has no switch-on point, so it computes a budget and throttles at any temperature. The seven GPU zones carry no sustainable-power either, so the allocator estimates it from the CPU cooling devices' lowest states, about 2.6 W. While the GPU is off, those zones read placeholder values near 3 C, and their output is about 7.5 W for all 14 CPUs. The thermal core applies the deepest state any zone asks for, so under any all-core load the clusters sat at 1.26/1.02/1.26 GHz with the die near 55 C. This started when the CPU cooling devices got power actors from the energy model; before that the same load ran at 4.5 GHz. Give each zone a passive switch-on trip below its control trip: 100 C for the die and CPU zones (control 116 C) and 90 C for the GPU zones (control 101 C). Below the switch-on point the allocator resets and grants full power, which is what these zones are meant to do: catch a failure of the PMP's own die loop, not act in normal use. Give the GPU zones the die's sustainable power, 51300 mW, instead of the estimate. The placeholder readings then stay far below the switch-on point. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
arm64: dts: apple: t6040-j616s: switch the power allocator on near the trips
…rs off The J614s ships experimental and its speakers need their own bring-up. There is no J614 protection profile and the speakers have not been measured, so nothing may drive them. Give the J614 speaker card its own configuration with the speakers disabled, so the driver never binds the speaker link even if the card is enabled. In the J614s device tree disable the speaker card and the six SN012776 amps as well, so no amp driver probes and no stream can reach them. The headphone jack card is unchanged. The J616s keeps its configuration and its DTB is unchanged. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
Bring in the J616s thermal fix from #857. The J616s board file is now a thin file on top of t604x-j614-j616.dtsi, so the change goes into the shared dtsi: a passive switch-on trip below each control trip (100/116 C for the die and CPU zones, 90/101 C for the GPU zones) and a sustainable power of 51300 mW on the seven GPU zones. The J614s gets the same trips. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…r-wip usb: typec: tipd: take the USB4 router when it binds after the deferred-probe timeout (aurora-wip)
arm64: dts: apple: add the J614s (MacBook Pro 14-inch, M4 Pro) The J614s ships EXPERIMENTAL. It has not been booted here, and nothing in this tree is claimed as proven on the J614s. J614s: internal speakers disabled pending bring-up. The J614s board file disables &sound and all six amps, and macaudio's J614 config has the speakers off. The headphone jack card stays enabled. Hardware evidence comes from mchalunderscore's J614s boots of this tree's values on combined stacks with local loader changes, as described in #816 (GPU, display, keyboard, trackpad, Wi-Fi, NVMe root), #818 (GL9755 SD reader, SDXC card at SDR104) and #813 (Touch ID enrolment and authentication with the T6040 SEP profile). DJ compile checked the tree. Gates on the merged tree (aurora-wip 8eb5b79 plus this branch): W=1 for the three DTBs, macaudio.o and sep.o with no new warnings; dtbs_check with only the existing ANE findings; dt_binding_check for apple,macaudio clean; host tests 175/175. The J616s and J616s tether DTBs decompile identical to aurora-wip's apart from the model string, so the J616s thermal fix from #857 is carried unchanged. The J614s DTB carries the same switch-on trips. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
On a MacBook Pro M2 Pro (T6020, J414s), a second Linux install never got
a Touch ID keybag. CREATE_KEYBAG makes the enclave rewrite one existing
kind-4 xART record. That record is one of the four kind-4 records the
enclave reads at every attach. A 2026-09-26 capture from the first Linux
install already has it, and macOS's enclave rewrote it on 2026-11-02
while no Linux install was running. It predates every Linux install, so
it is never on Linux's list, and xart_guard=1 refused it. The enclave
did not fail the create. It stopped answering, and the hardware RNG and
every later key-store request timed out. The driver also kept its create
intent, so every later boot refused to create a keybag ("identity keybag
state is ambiguous: EEXIST"), and trusted keys failed with EEXIST.
The other Linux install is not the cause. Every guarded keybag creation
on that Mac asks for the same rewrite. The first install has a keybag
only because it was made before the guard existed. An M1 Pro (T6000)
rewrites one pre-Linux attach record the same way. It runs the same
stub sepOS, so the risk to macOS is the same, and so far it has needed
xart_guard=0.
Run the identity CREATE_KEYBAG in the window a boot policy change
already uses. It allows one rewrite per boot, of one kind-4 record that
existed at probe. It never allows a delete or another kind, the roots
follow the level, the previous value is saved on the host first, and
nothing is adopted. The exchange now waits up to 6 s, as a 13.5 key
store's does, because the saved value and the new slot are flushed
inside it. Every other session record that existed at probe stays
refused, before, during and after the create. That includes any record
another Linux install made.
Make an unfinished create recoverable. The intent now records how long
the guard's list was. New session records are listed before they are
written, so a later boot whose list has not grown knows the create left
nothing behind, and sends it again. An intent from an earlier kernel
records no length. It is sent again only while the list is empty, which
recovers the installs this refusal already left stuck.
A guarded cold-boot Mac is no longer reported as matching "blocked"
just for being cold-boot. That rule assumed its keybag could only be
created with the guard off. It is now "unverified", like a warm-attach
Mac, until the guard refuses a write. aurora-sep-ready drops the
matching reason, and the ABI doc and XART-SAFETY.md follow.
KUnit covers the window's terms, the list length kept from load, the
retry rule, and the intent format, including the zero-UUID intent that
earlier kernels wrote.
Signed-off-by: DjDeveloperr <hey@djdev.me>
Assisted-by: Claude:claude-opus-5-5
drm/apple: afk: replace compact services re-announced after poweron Qualified on the J616s (t-4547) over about 25 s2idle resumes on three boots with the ANE up, 0 "too many enabled compact services", SELinux enforcing with 0 AVCs. Host selftests 175/175. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
The typec-probe and probe-mux-pm-dispatch units extract the real cd321x_register_port() and cd321x_unregister_port(). Since the port keeps watching for a USB4/Thunderbolt router that binds after it gave up, both use cd321x_tbt_watch_late(), INIT_WORK() and three new struct cd321x members, and the units no longer build. Mock the watch the way the driver uses it: it holds the port fwnode until the port is unregistered and cd321x_stop_work() ends it. Check that a port probed without its router watches for it, that a watch which cannot start leaves the port probed without one, that a router present at probe needs no watch, and that every case leaves the watch and fwnode balanced. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…g' into ane/h16-start-stall
…outer (#858) selftests: apple-dcp: follow the late USB4 router watch in cd321x probe
The H16 host now serves the SHAREDMALLOC ring only after the firmware raises its notification bit, as macOS does. Count the polls that found a request body in the ring before that bit, and log the count with the number of allocations at the end of every startup. A nonzero count marks a start where the earlier host would have answered the request while the firmware was still posting it, which is the window behind the intermittent startup and resume stalls. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
…ndow-wip soc: apple: sep: let a second Linux install create its Touch ID keybag on M2 Pro/Max (aurora-wip)
…-parts spi: apple-qspi: admit both J616s boot NOR parts. Reviewed; qspi-nvram-tests and run-host-tests --only qspi pass on the merge with aurora-wip 467335c.
Some J700s carry a GigaDevice GD25UF16E boot NOR (RDID c8 83 15) in place of the Winbond W25Q16 the board entry names. On those Macs every NVRAM program and erase fails with -ENODEV, so asahi-bless cannot select a boot volume. The part is also 2 MiB, takes 3-byte addresses and uses the same 02h page program and 20h 4 KiB erase, so the J700 partition and mutation policy hold unchanged. Its status registers differ from Winbond: - SR1 bits 6:2 are BP4 to BP0. Winbond has SEC and TB at bits 6:5, which the Winbond check leaves as found. - SR2 bit 2 is SUS2, program suspend. It is reserved on Winbond. - SR3 has no WPS. Bit 2 there is LPE, a low-power setting. Name the part in the second JEDEC slot of the J700 entry and give GigaDevice its own status check: WIP, WEL, CMP, SUS1 and SUS2 are refused, BP2 to BP0 only where the board allows them, and BP3 and BP4 always on the J700. The check is picked from the manufacturer the flash reports. flash_status prints all three registers for GigaDevice parts too. The bit layout is from the GD25UF16E datasheet, Rev 1.0 (DS-01151). Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
iio: aop_als: report colour temperature as IIO_COLORTEMP
spi: apple-qspi: admit the J700 GigaDevice boot NOR. Host tests (qspi) pass on the merge with aurora-wip 9aaa357; KUnit 11/11 (UML); Neo Winbond bless round trip and write-back-unchanged pass.
accel/ane: serve H16 shared-memory requests only after their notification
soc: apple: pmgr: whole-word T6000 DCS commands and valid-state checks
…covery-wip drm/asahi: g17: keep innocent clients alive across another client's recovery
…nto integration/aurora Bring integration/aurora up to the aurora-wip tip 9ff2b9a. After this merge the two branches have the same tree. The range contains the fleet14o source c243830 (#857, #858, #795, #859), which was promoted on all four machines on 2026-11-02 and 03, and the merges after it: #861 (apple-dcp selftest stubs for #858), #860 (SEP keybag in the shared xART window, the aurora-wip copy of #856), #724 (J616s boot NOR, both parts), #779 (ALS colour temperature ABI), #862 (J700 GD25UF16E boot NOR, the Neo bless fix), #863 (J616s ANE H16 start stall), #797 (T6000 DCS whole-word writes) and #803 (G17 keeps innocent clients alive across another client's recovery). #858 and #860 make the same changes integration/aurora already had as #855 and #856, so they merge without conflicts. Assisted-by: LLM Signed-off-by: Ryan Murray <ryan@aurorasilicon.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Batch 6 of 6 bringing integration/aurora up to aurora-wip. It's a merge commit, with no rebase and no rewrite.
Range
aurora-wip up to its tip, 9ff2b9a. After this merge, the integration/aurora tree is identical to aurora-wip's (
git diff aurora-wipis empty).PRs:
No conflicts. #858 and #860 make the same changes integration/aurora already had.
Hardware evidence
Source: aurora-ctl/reports/fleet14-20261101/RESULTS.md
Gates on this merge tree (buildbox, fleet recipe: canonical Fedora asahi base + asahi.config)
🤖 Generated with Claude Code