Of course, nothing is ever quite as simple as a single bit in the architecture. A small amount of firmware is required to coordinate the two worlds, facilitate switching, and so on. This firmwarecomponent is called the Monitor.
Alongside the two explicit operating modes (Secure and Non-Secure), there is a third processor mode called Monitor mode that runs a third separate software stack. In order to transition from NWd to SWd (or vice versa), requests must transition through Monitor mode and the Monitor firmware ensures that the transition is allowed, orderly, and secure.
The Monitor is able to access all the crucial security data in the system, so its quality and integrity are paramount. The code should be as small as possible and tested and reviewed regularly in order to be, if such a thing is possible, bug-free.
When NWd software wishes to contact SWd, it must issue a Secure Monitor Call (SMC) instruction. This invokes the Monitor, which must set the state of the NS bit in the Secure Configuration Register in the System Control Processor (CP15) (so that bus and memory devices know which world is executing and therefore calling them) and bank-sensitive registers to keep the system secure and consistent.
SMC calls are very simple: they take a single 4-byte immediate value that indicates to the software in the SWd what service is being requested, and the SWd runs that service. It's the responsibility of the system designer(s) to agree on conventional numbering and meanings for each value. 
Earlier we introduced the idea that interrupts from secure peripherals can be routed directly to the SWd without ever passing through any untrusted code at any privilege level. At this point, it's important to introduce another configuration for peripherals: not secure or insecure, but switchable. Some peripherals (a touchscreen, for example) only need to be secured part of the time: when executing sensitive transactions. At all other times, it's acceptable, even required, for the NWd to have control.
To police this and ensure that the correct software stack has control at the correct time, all such interrupts are actually caught by the Monitor, and the Monitor decides (based on a configuration table) which driver (SWd or NWd) should receive the interrupt. When entering a secure transaction, the SWd can reserve the peripheral, meaning it receives all the interrupts. When it has finished, it can release the peripheral, informing the Monitor that it should send interrupts on to the NWd driver instead.
To deal with the various practical issues of performance, potential conflicts, and so on, a typical ARM system reserves the two interrupt signals for separate purposes: IRQ for normal interrupts and FIQ for secure.  This allows certain efficiencies such as static routing tables for certain events.
Relationship to TPMs
Historically, ARM SoCs have been most prevalent in mobile devices: smartphones, tablets, and the like. As such, TrustZone systems haven't typically used a separate hardware TPM, but rather have used TrustZone as the TPM.
Starting around a decade ago with the Mobile Trusted Module specification, and continuing today with the TPM 2.0 Mobile and PC Client specifications, the trusted computing community has developed the concept of a firmware TPM. With fTPM, rather than relying on separate hardware chips, the TPM functionality is implemented in a protected firmware execution space such as TrustZone and then called by the NWd OS for measurements, sealing, and so on in the normal way.
While no hard-and-fast requirements or architecture are specified for the precise implementation of the fTPM (beyond conformance to the TPM 2.0 library specification of course), the operating environment is required to provide some fundamental protection for the TPM roots of trust and PCRs. In keeping with the TrustZone protection target, no software outside of the TPM implementation should be able to modify or access roots of trust directly, or manipulate PCRs except though the authorized interfaces.
A well-implemented TrustZone system is able to provide these guarantees (and, indeed, several implementations are commercially available).
-  Note a coming confusion: from ARM V8, there is an official definition of firmware for Exception Level 3 (high privilege level) that is more than just the Monitor components. This text only refers to the code responsible for coordinating world switching, not any other firmware duties such as power management.
-  The Monitor may even be a legitimate target for formally proven code.
-  To help with this, ARM publishes various recommended calling conventions, but the system isn't required to follow them.
-  An interrupt request (IRQ) is a signal sent from a hardware peripheral to alert the processor to anevent.
-  A fast interrupt request (FIQ) is an additional signal like IRQ but is (supposedly) handled faster.
-  Although not actually required, there are two reasons for this recommendation: compatibility (existing NWd software makes much more use of IRQ than FIQ) and security (the ARM architecture allows for masking control of FIQ in CP-15 but not IRQ).