GitLab

The BCM2711 manual suggests that yes, the BCM2835-style memory barriers
are still needed when accessing peripherals

Detail:
  The 8GB model has a new PCB revision too.
Admin:
  Submission from David Pitt.

Version 0.85. Tagged as 'HAL_BCM2835-0_85'

The MAC address when encoded as a Dallas unique id is in network byte order.
For example, a Risc PC returns OS_ReadSysInfo 4 with r0=&A4123456 r1=&0000 because Acorn's EUI is 00:00:A4.

Version 0.84. Tagged as 'HAL_BCM2835-0_84'

The 2GB new minor revision is in the wild.
Also tidy HAL_[Ext]MachineID leftovers.

Version 0.83. Tagged as 'HAL_BCM2835-0_83'

Minor DFM changes resulted in a new revision number
  https://www.raspberrypi.org/documentation/hardware/raspberrypi/revision-codes/README.md
but only for 4GB.

Give the ISPENDRn address directly, since its only the HAL that knows that iDev_GPU is encoded from 64+, rather than having to bake it into DWCDriver.

The MPHI is (ab)used by DWCDriver as a means to do a FIQ downgrade to IRQ, but Pi 4 has no MPHI, so instead we substitute the GIC (as the GICD_ISPENDRn can be used to cause an IRQ from software).

VCHIQ bulk transfers on Pi 4 use a different page list format, in order
to allow for full use of the larger 36bit physical address space. Add a
flags word to the VCHIQ HAL device so that we can let the VCHIQ module
know what page list format it should use for the machine we're running
on.

The USB controller is at physical addresses outside 32b range, extend so that it can be picked up by PCI manager, and hence use its SWIs (rather than *Memory P) to see registers.
Also write the interrupt number into the config space so it can be picked up.
Requires PCI-0_18.

Memory window now enabled on the VIA VL805, on-chip bridge set to forward memory transactions, ARM CPU to PCI address space translated.
Since we know there's only the VIA chip on the bus, there's no dynamic probing going on like platforms that have PCI sockets. Its BAR settings are derived from defines at the top of PCI.s, so to browse the XHCI capability registers just peek at
  *Memory p 600100000 +20
Only 1 of the 4 address space translation windows is used.

Basic HAL device to expose the GENET peripheral for the driver.

Just enough pokes to be able to scan configuration space such that the VIA XHCI controller can be seen by PCI Manager. Note: at present there are no memory or IO windows open, so you can't (yet) see XHCI registers.

* Requires 'enable_gic=1' in config.txt (or Pi4 dtb to be present?)
* IRQs are managed via the GIC, FIQs via the BCM2838 FIQ controller
* Implemented in s.IntVC6 to avoid making s.Interrupts too
confusing.
* Previous VC6 interrupt support removed from s.Interrupts
* From the OS's perspective, interrupt numbers mostly remain
unchanged. However iDev_QA7 interrupts are unavailable, and some of
the BCM2838 interrupts have been overlaid ontop of them.
* Device drivers must take care to issue HAL_IRQClear, as that is
a new requirement for this HAL

HAL_QueryPlatform was attempting debug output before the debug
UART had been initialised. Since both the PL011 & MiniUART
configuration depends on getting/setting firmware values, fix it
by just removing the debug prints from HAL_QueryPlatform.

RAM sizes above 1GB are not reported by the usual mailbox property, and it
seems unlikely that this will change because the VC RAM allocation has to
remain within the bottom 1GB of the address space (the VC still uses the
upper two bits of its addresses for cache policy) and this property cannot
describe a non-contiguous range. Use the board revision bitfield to recognise
when additional general-purpose RAM exists above the VC allocation. For now,
we're running in "low peripherals" mode, so the top 64MB of 4GB RAM machines
is inaccessible. If the VC allocation is also 64MB, that means the startup
banner of Pi 4 will read 960MB, 1984MB or 3968MB.

Also fix HAL_PhysInfo (and by implication, OS_Memory 6 and 7) to report the
full 35-bit physical address space on Pi 4. The `range` struct filled in by
HAL_PhysInfo has not been extended to 64-bit physical addresses because it
describes RAM, and for now at least, RAM just squeezes into 32-bit addresses.

This controller is now preferred over the legacy EMMC controller, and it is
capable of UHS speeds (pending support in SDIODriver).

Requires RiscOS/Sources/HWSupport/SD/SDIODriver!4

Both still use GIC bypass mode. Assuming for now that extended GPU peripherals
can't support FIQ without GIC (it seems as though they either all use IRQ or
all use FIQ, and RISC OS isn't set up for there being multiple FIQ sources
active at once).

Detail:
* Implement SD activity LED for Pi 4
* Remove inappropriate reprogramming of GPIO47 for Pi 3 B(+) and A+
* Correct the value for SDHCIWriteInterval which is used during SetSDCLK()

Detail:
* Board recognition for Pi 4
* Updated the pin enumeration table to specify new functions available in Pi 4
  (I2C[3456], SPI[3456], UART[2345])

Detail:
* Efforts to get the faster EMMC2 controller working are ongoing. In the
  meantime, this enables the backward-compatible EMMC1 controller.
* The method required to control the activity LED appears to have changed,
  yet again. I haven't worked out how yet, so this is currently
  non-functional.

Detail:
* For now, this uses the legacy interrupt controller, whose register layout has
  unfortunately changed in some unhelpful ways. There is also a GICv2 in the
  SoC, which we will need to transition across to in order to use some of the
  newer peripherals (including USB3 and gigabit Ethernet).
* This requires a corresponding set of changes to start.elf: substitute all
  three instances of &E30011E7 with &E3001000.
* FIQs are not currently supported, as the legacy interrupt controller has
  changed how these are handled. It seems likely that we'll transition to
  GIC before too long, which means it's not worth bothering to implement them
  for the legacy interrupt controller.

Because the mini-UART clock is derived from the core clock, and this varies
by hardware platform and even firmware version, move the initial mailbox
read to before UART initialisation so that this information is available.

Also:
* the IO region previously used only for the QA7 extensions now holds a GIC
  as well on Pi 4, so give it a more generic name
* there's a new, second peripheral IO region to map in as well

The default state for the Serial device (aka OS_SerialOp, and redirection to serial via *FX) is to expect hardware handshaking. However the implementation of HAL_UARTModemStatus when ModemControl = {FALSE} state didn't set a return value so ended up returning a1 = the port number (=0) rather than valid status bits. In turn, DualSerial took that to mean CTS/DSR deasserted and refused to send anything.
To a lesser extent HAL_UARTModemControl also affected, returning a1 = port number 0 too.
For both, set a return value; the value is as though a cable is always present with RTS=CTS and DTR=DSR.

Also, fix the bugs in ModemControl = {TRUE}. This also fakes DTR=DSR which status/control bits don't appear to be implemented in the UART peripheral. Tested briefly, checking CTS state when plugging/unplugging a cable.

Version 0.82. Tagged as 'HAL_BCM2835-0_82'

RISCOS_MapInIO does relatively little processing on the L1PT flags that the
HAL passes to it. However, when modules come along later and try to locate
IO again, using OS_Memory 13, access permissions are specified using a
variation on dynamic area flags. The kernel translates from these to L1PT
flags, and one of the rules it applies is that the shareability bit is set
if on a multiprocessor system. On Pi 2 and later, this means it doesn't find
a match amongst the sections that were mapped in by the HAL, and in practice
this means BCMVideo ends up causing 16MB of IO space to be mapped in twice.

Fix this by passing the L1_S flag to RISCOS_MapInIO on Pi 2 and later. This
effectively frees up an additional 16MB of logical address space for dynamic
areas.

Version 0.81. Tagged as 'HAL_BCM2835-0_81'

On entry to HAL_SendHostMessage, we ensure the contents of the mailbox buffer
are flushed out to the ARM L2 cache (if applicable) and main memory. There
were a couple of instructions to fill in the top two bits of the address
before passing it to the VC, but they were commented out for reasons that are
not clear.

The effect of this is that the VC will look in its L1 and L2 caches for the
data in the buffer. On Pi 1 and 0, this wouldn't be too bad, since ARM11
didn't have its own L2 cache and would have written the data into the VC L2
cache instead, meaning that there would only be coherencency problems if the
VC L1 cache still contained the old contents of the address. On Pi 2-4, it's
more risky, because the VC L2 cache could also be inconsistent with main
memory at this point.

Reinstating the top two bits doesn't appear to cause any ill effects I can
see (tested on Pi 1 and 4), so put these instructions back in.

Version 0.80. Tagged as 'HAL_BCM2835-0_80'

GPIO.s,hdr/BCM2835: Table of known ids updated
SPI.s: Fix long broken compute module support (only the original CM1 would have exported SPI2 due to not checking for the new id scheme).
Unrelated, SDIO.s: Use CallOS macro.

Thanks to Chris Hall for testing this on a CM3+ 8GB model.

Version 0.79. Tagged as 'HAL_BCM2835-0_79'

Do an upfront check for the model being 0, if that ever changes there's probably something seriously different. Look only at the Board_Revision elsewhere.
Add the other Compute module to the SPI2 check (though currently the checks don't consider "New" revision words).

Version 0.78. Tagged as 'BCM2835-0_78'

SDIO.s: a condition code mixup meant that during intense SD card activity the thunder bolt symbol would appear due to poking the non-LED lines on 3B+
GPIO.s: extend the 'free for use' table to include 3A+ pins, otherwise it read off the end; add an ASSERT to catch this in future

Version 0.77. Tagged as 'BCM2835-0_77'

Not tagged

Detail:
  hdr/StaticWS - Reserve workspace for QA7 peripheral address, HAL-wide spinlock, and doorbell device
  Makefile, s/DBell - Add doorbell device implementation
  hdr/BCM2835 - Clean up dead macros, add new macros for spinlock claim/release and basic CPU detection. Define new IRQ numbers for the "QA7" peripheral.
  hdr/CastleMacros, s/Top - Generate two HAL descriptors and entry point tables: One for single-core machines and one for multi-core machines. This avoids some MP-related overheads on ARM11 models of Pi. Implement SMP HAL entry points.
  s/Interrupts - Add support for the QA7 interrupts. Although some interrupts can be flexibly routed to different cores, we currently stick with a static scheme.
  s/Messaging - Use CPUDetect macro
Admin:
  Untested
  Requires Kernel-6_09


Version 0.76. Tagged as 'BCM2835-0_76'

Top.s: HAL_UARTStartUp takes 0's based UART numbers, so the debug setup would go wrong (if HAL_UARTStartUp actually checked the value).
UART.s: Re-express the baud register default value so its origin is clear.
Retagged as BCM2835-0_75 as the (non-debug) version is binary identical.

Add Pi3 B+ and Zero W.
Split out CM3 from CM1, since the CM3 reuses some high GPIO lines as bit bashed SMPSU IIC bus, so we can't offer those for GPIO like on CM1.

Version 0.75. Tagged as 'BCM2835-0_75'

Detail:
  hdr/BCM2835 - Add some new board revision values
  s/SDIO - Treat the 3B+ the same as the 3B when handling the activity LED. Also detect the Embest-manufactured CM1 and treat it the same as the Sony one.
Admin:
  Tested on Raspberry Pi 3B+


Version 0.74. Tagged as 'BCM2835-0_74'

Detail:
  s/KbdScan - Add RTSupport to the list of modules (dependency of DWCDriver)
Admin:
  Tested on Raspberry Pi 3


Version 0.73. Tagged as 'BCM2835-0_73'

Detail:
  Add keyboard scan code with list of modules that the kernel needs to do the same.
  Reorder the HALEntries to match Kernel-5_89.
  Remove unused stub functions (now KbdScan exists).
Admin:
  Submission for USB bounty.

Version 0.72. Tagged as 'BCM2835-0_72'

Detail:
  Firmware as of 28th July will allow the GPU to make use of the top 16MB of RAM in 1GB machines. This overlaps the ARM's IO space, essentially making that area of memory inaccessible to us.
  This causes problems because we rely on a couple of buffers which are located in VC memory (virtual GPIO buffer & FT5406 touchscreen buffer)
  At some point extra mailbox messages were added to allow the ARM to dictate the location of these buffers; so make use of those messages wherever possible.
  File changes:
  s/Messaging - Remove VirtGPIOBuf and TouchBuf related tags from the initialisation tag sequence. Add new GetVCBuffer function that can be called post-MMU init to deal with getting/setting the buffer addresses.
  s/Top - Use GetVCBuffer to initialise VirtGPIOBuf
  s/Touch - Use GetVCBuffer to get touchscreen buffer
  hdr/StaticWS - Remove TouchBuf from workspace, no longer needed
Admin:
  Tested on Raspberry Pi 3 with firmware from March 2016 (Set commands not supported), 21st July 2017 (set commands supported, but upper 16MB not used), 28th July 2017 (set commands supported and necessary)


Version 0.71. Tagged as 'BCM2835-0_71'

GPOI -> GPIO
set -> cleared
No code change, not tagged.

Apparently there are some A+ 1.1 and B+ 1.2's in the wild not built with their former id's (0x12 and 0x13) but using the newer 24 bit id scheme. Add aliases for these.

Version 0.70. Tagged as 'BCM2835-0_70'

The SDIO HAL device reports when it is sure fixed disc media is attached (ie. eMMC soldered on the same PCB) which causes SDFS to report this to FileCore as a fixed disc, skipping the removable safety checks.
However, CM3 and CM3L both return the same board id so we can't work out which is which. Additionally, someone could attach an external eMMC in theory on a custom expansion board (instead of an SD card socket like the CMIO has).
To resolve this, we assign IO expander line 6 of U8 to be a safety catch. If that line is held low, it signifies this is definitely a CM3 - in effect this is a "definitely has eMMC" or "maybe has eMMC" switch.

Tested on CM1, CM3, CM3L, and a suitably modified CM3 with the help of Chris Hall.

Version 0.69. Tagged as 'BCM2835-0_69'