GitLab

Recent commits resulted in the HAL growing to just over 64K. To avoid needing
to change the space allocation for the HAL, reclaim some of the space
reserved for workspace during the pre-MMU-activation stage of booting.

This reverts the microSD performance to that seen with the SDHCI controller.

Benchmarks on Pi Zero W (ARM1176JZF-S):
  SDHCI:      23.8 MB/s
  SDHOST PIO:  1.9 MB/s
  SDHOST DMA: 24.4 MB/s

Benchmarks on Pi Zero 2W (Cortex-A53):
  SDHCI:      23.8 MB/s
  SDHOST PIO:  8.6 MB/s
  SDHOST DMA: 24.4 MB/s

This also mandates the SDIO card interrupt support functions, so have a stab
at those (currenty untested). This requires all accesses to SDHCFG register
to be protected by a spinlock.

This is used for driving the SD memory card slot on Pi 3B, 3B+, 3A+, 0W and
02W.

Now support multiple controllers on the same board. For Pi 4B & 400, expose
both the old (slow) and new (fast) Arasan SDHCI controllers, and reconfigure
the pins so the slow one sees the WiFi chip. Earlier models only have the
one SDHCI controller; for Pi 3B, 0W, 3B+, 3A+ and 02W, which only have the
slow SDHCI controller, reconfigure the pins so they see the WiFi chip. At
this point, that leaves these models unable to access the SD memory card slot
at all; that will be addressed in a later commit.

The code that determined the base clock for the slow Arasan block has been
rewritten to read it from the VCHIQ mailbox instead. On Pi 4, this uses the
same clock id as the sole SDHCI controller on earlier models. The older,
empirical method didn't work reliably on Pi 4, and at this point we can
safely assume we're running on firmware that's new enough to expose this
clocking information via the VCHIQ mailbox.

Also: turn off pull-up resistor on SD clock pins, mirroring the configuration
used by Raspbian.

Both the Compute module 3+ and 4 have variants both with and without on-board
eMMC memory, in addition to the Compute module 3. Assume we can use the
same GPIO header to configure these appropriately. Untested.

This seems to have broken at some point - I'm guessing due to a firmware
change? Raspbian doesn't use the hardware card detect line at all, so it
would have gone unnoticed.

The card detect works using a contact switch to short a GPIO pin to ground.
If you touch the switch with a finger, it reads general noise, so it's still
functioning as an input, but it appear as though the pull-up resistor is no
longer operational, as the pin stays at 0V when the switch is open (hence
it always appears as though the card is inserted - so as soon as you remove
the card, you only ever get timeout errors from any command you issue).

Work around this by pretending there is no card detect functionality (as per
model 1 B+ and later).

* Add missing `.gitignore`
* When some BASIC test programs were added, the required update to
  `.gitattributes` was overlooked
* Remove a small number of recent whitespace errors so that future
  introductions of new ones can be automatically detected and flagged

* Makefile now uses shared HAL makefile fragment
* Filenames converted to OS-agnostic form
* Remove PIC attributes from AREA declarations: since the code isn't
  position-independent, this is factually incorrect, and will produce
  false linker warnings when we link with libraries that are also non-PIC

Version 0.96. Tagged as 'HAL_BCM2835-0_96'

The Zero 2 W will boot with existing ROMs if you update the firmware, but
GPIO handling and the SD activity LED need some tweaking to fully adapt to
the new board.

Version 0.95. Tagged as 'HAL_BCM2835-0_95'

Update OS_AddRAM sequence to detect 8GB Pi models and register the extra
RAM bank.

Also, remove the software RAM clear code; it won't work for clearing RAM
above the 4GB barrier, and (for a software RAM clear) it's quicker for
the kernel to clear the RAM itself (since it'll do it with the
MMU/caches enabled, and will do it in parallel with the keyboard scan).
E.g. for a 4GB Pi, the time between the HalStartup debug message (prior
to HAL RAM clear) and ModuleInit debug message (after kernel RAM clear)
used to be 1124cs, but is now 636cs. For an 8GB Pi the time is 948cs.

Version 0.94. Tagged as 'HAL_BCM2835-0_94'

Version 0.93. Tagged as 'HAL_BCM2835-0_93'

* Raspberry Pi 400: verified as booting to desktop.
* Compute Module 3+: some changes to SD support to make it behave like the
  plain Compute Module 3 (previously it was falling into the model B+ code
  path and setting up GPIO in the expectation that an activity LED was
  attached, which is not a given for a Compute Module). Not tested.
* Compute Module 4: tentative support added. Not tested. In particular, we
  don't know what the revision numbers will be yet, so the entries in
  `GPIO_Board_Conversion_Table` may not match real hardware.
* SD subsystem now assumes any future models are similar to the Pi 4 and 400,
  and thus we're more likely that they will "just work" out of the box.

Version 0.92. Tagged as 'HAL_BCM2835-0_92'

Detail:
* Fixes register corruption in GPIOPullDirection.
* Pre-seeds the soft copies with the values from the datasheet (so no need for a function
  to read them). This should also help other models of Pi which assumed they were all
  disabled when it seems they are not!
* Reworks the SDIO driver to call through to the GPIO so that its softcopy is kept in
  sync, and so the settings do something on a Pi 4 at all.
Admin:
  Tested on Pi4 and a Pi 3B+.

Version 0.91. Tagged as 'HAL_BCM2835-0_91'

Version 0.90. Tagged as 'HAL_BCM2835-0_90'

The bridge was incorrectly configured with 2 overlapping mappings (0-&FFFFFFFF and another 0-&8000000). When the VL805 wanted to bus master into main memory the bridge was confused where the transaction should go, causing a master abort to be logged on the secondary side.
Reorganise the PCI memory so that only a small window in the top 1GB is actively decoded (we can't bus master above 3GB anyway due to a chip design "feature"), meaning the rest of the secondary address space is forwarded 1:1 to the primary.
Further, because the CPU side windows can only be sized in powers of 2, reduce that to 2GB in size.

Some Pi 4's - for example, the recently released 8GB variant - don't have the firmware EEPROM on the VL805 fitted. The VideoCore loads default firmware on power on in order to do USB booting, but when RISC OS takes over and does a PCI fundamental reset the VL805 ends up with no firmware running.
Detect this (by peeking the firmware version) and use the NotifyXHCIReset mailbox message to cause the VideoCore to softload the firmware again. Earlier built PCBs *do* contain a firmware EEPROM and skip the mailbox message.

By inspection with a prototype version in BASIC it appears the SCB access needs to be enabled for this to work, it previously wasn't, hence the extra PCI setup step.

Also, reduce the PCI reset delay and rename PCIe_RGR1_SW_INIT1_POWERDOWN to more accurately reflect what it does.

Version 0.89. Tagged as 'HAL_BCM2835-0_89'

The pin list table had the Pi 4-only alternates mixed in, the result of which is that enumerating the pins on something other than Pi 4 would return ghost alternates for peripherals that don't exist.
Split the pin lists and pick the appropriate one.

Also, add 2 missing board revisions that have sneaked out for 2B/3B.

CPUDetect was corrupting the pointer needed for storing the table size

Version 0.88. Tagged as 'HAL_BCM2835-0_88'

Detail:
  The offset to the pull up/down clock register was computed in v4 but then v2 was used instead.

Version 0.87. Tagged as 'HAL_BCM2835-0_87'

From the deep dark recesses of my hard disc, some Pi 1-era test code for
CPU & DMA driven PWM audio, now updated to run on Pi 2, 3, & 4.

Version 0.86. Tagged as 'HAL_BCM2835-0_86'

* Update DMA & DMA lite channels to work on Pi 4 (HAL_IRQClear calls
needed)
* Fix DMAL_Abort / DMAL_Reset to reset the channel properly (register
muddle meant the old reset code wasn't doing anything - and wasn't a
particularly great way of resetting anyway)
* Fix DMAL_CurtailListTransfer not working very well
* Fix IRQ mapping of channels 11-14, allowing channels 12-14 to be used
* Implement support for Pi 4 DMA4 channels. On Pi 4 these are the only
channels we'll bother using, since DMA & DMA lite have annoying
restrictions on accessing RAM above 1GB

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