communicate the kernel's physical load address from where it's known in
initarm() into cpu_mp_start() which is called from non-arm code and
takes no parameters.
This adds the global variable and ensures that all the various copies
of initarm() set it. It uses the variable in cpu_mp_start(), eliminating
the last uses of KERNPHYSADDR outside of locore.S (where we can now
calculate it instead of relying on the constant).
a new physmem.c file. The new code provides helper routines that can be
used by legacy SoCs and newer FDT-based systems. There are routines to
add one or more regions of physically contiguous ram, and exclude one or
more physically contiguous regions of ram. Ram can be excluded from crash
dumps, from being given over to the vm system for allocation management,
or both. After all the included and excluded regions have been added,
arm_physmem_init_kernel_globals() processes the regions into the global
dump_avail and phys_avail arrays and realmem and physmem variables that
communicate memory configuration to the rest of the kernel.
Convert all existing SoCs to use the new helper code.
devices. This is a nop, except for what's reported by atmelbus for the
resources.
It would be nice if we could dymanically allocated these things, but
the pmap_mapdev panics if we don't keep the static mappings, so we
still need to play the carefully allocate VA space between all
supported SoC game.
User's with their own devices may need to make adjustments.
clients. Mask RX interrupts while grabbed on the atmel serial
driver. This UART interrupts every character. When interrupts are
enabled at the mountroot> prompt, this means the ISR eats the
characters. Rather than try to create a cooperative buffering system
for the low level kernel console, instead just mask out the ISR. For
NS8250 and decsendents this isn't needed, since interrupts only happen
after 14 or more characters (depending on the fifo settings). Plumb
such that these are optional so there's no change in behavior for all
the other UART clients. ddb worked on this platform because all
interrupts were disabled while it was running, so this problem wasn't
noticed. The mountroot> issue has been around for a very very long
time.
MFC after: 3 days
completely full, we'd not complete any of the mbufs due to the fence
post error (this creates a large leak). When this is fixed, we still
leak, but at a much smaller rate due to a race between ateintr and
atestart_locked as well as an asymmetry where atestart_locked is
called from elsewhere. Ensure that we free in-flight packets that
have completed there as well. Also remove needless check for NULL on
mb, checked earlier in the loop and simplify a redundant if.
MFC after: 3 days
vm_max_virtual_address to be KERNVIRTADDR + 256MB. This allows some
future shock protection since the KVA requirements have gone up since
the unmapped changes have gone in, as well as preventing us from
overlapping with the hardware devices, which we map at 0xd0000000,
which we'd hit with anything more than 85MB...
MFC after: 3 days
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.
This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.
A similar change was made in OpenBSD.
Discussed with: -arch, rdivacky
Reviewed by: cperciva
new devmap.[ch] files. Emphasize the MD nature of these things by using
the prefix arm_devmap_ on the function and type names (already a few of
these things found their way into MI code, hopefully it will be harder to
do by accident in the future).
really need it. That would be almost everywhere it was included. Add
it in a couple files that really do need it and were previously getting
it by accident via another header.
transparent layering and better fragmentation.
- Normalize functions that allocate memory to use kmem_*
- Those that allocate address space are named kva_*
- Those that operate on maps are named kmap_*
- Implement recursive allocation handling for kmem_arena in vmem.
Reviewed by: alc
Tested by: pho
Sponsored by: EMC / Isilon Storage Division
Changes to make rtc/cts flow control work...
This does not turn on the builtin hardware flow control on the SoC's usart
device, because that doesn't work on uart1 due to a chip erratum (they
forgot to wire up pin PA21 to RTS0 internally). Instead it uses the
hardware flow control logic where the tty layer calls the driver to assert
and de-assert the flow control lines as needed. This prevents overruns at
the tty layer (app doesn't read fast enough), but does nothing for overruns
at the driver layer (interrupts not serviced fast enough).
To work around the wiring problem with RTS0, the driver reassigns that pin
as a GPIO and controls it manually. It only does so if given permission via
hint.uart.1.use_rts0_workaround=1, to prevent accidentally driving the pin
if uart1 is used without flow control (because something not related to
serial IO could be wired to that pin).
In addition to the RTS0 workaround, driver changes were needed in the area
of reading the current set of DCE signals. A priming read is now done at
attach() time, and the interrupt routine now sets SER_INT_SIGCHG when any
of the DCE signals change. Without these changes, nothing could ever be
transmitted, because the tty layer thought CTS was de-asserted (when in fact
we had just never read the status register, and the hwsig variable was
init'd to CTS de-asserted).
Changes to support bulk high-speed (230kbps and higher) data reception...
Allow the receive fifo size to be tuned with hint.uart.<dev>.fifo_bytes.
For high speed receive, a fifo size of 1024 works well. The default is
still 128 bytes if no hint is provided. Using a value larger than 384
requires a change in dev/uart/uart_core.c to size the intermediate
buffer as MAX(384, 3*sc->sc_rxfifosize).
Recalculate the receive timeout whenever the baud rate changes. At low
baud rates (19.2kbps and below) the timeout is the number of bits in 2
characters. At higher speed it's calculated to be 500 microseconds
worth of bits. The idea is to compromise between being responsive in
interactive situations and not timing out prematurely during a brief
pause in bulk data flow. The old fixed timeout of 1.5 characters was
just 32 microseconds at 460kbps.
At interrupt time, check for receiver holding register overrun status
and set the corresponding status bit in the return value.
When handling a buffer overrun, get a single buffer emptied and handed
back to the hardware as quickly as possible, then deal with the second
buffer. This at least minimizes data loss compared to the old logic
that fully processed both buffers before restarting the hardware.
Rewrite the logic for handling buffers after a receive timeout. The
original author speculated in a comment that there may be a race with
high speed data. There was, although it was rare. The code now handles
all three possible scenarios on receive timeout: two empty buffers, one
empty and one partial buffer, or one full and one partial buffer.
Reviewed by: imp
add the ability for userland to be notified of changes on gpio pins via
a select(2)/read(2) interface.
Change the interrupt handler from filtered to threaded.
Because of the uiomove() calls in the new interface, change locking from
standard mutex to sx.
Add / restore the at91_gpio_high_z() function.
Reviewed by: imp (long ago)
of bits, not just a 0/1 indicating whether any of the masked bits are on.
This is compatible with the single in-tree caller of this function right now
(at91_vbus_poll() in dev/usb/controller/at91dci_atemelarm.c).
and that can drive someone crazy. While m_get2() is young and not
documented yet, change its order of arguments to match m_getm2().
Sorry for churn, but better now than later.
processors, either on reboot or after power down with battery backup.
However, the AT91RM9200 RTC always resets on reboot making it just
about useless at the moment (if we support a low-power mode or an
extended sleep mode, it might become useful).
Submitted by: Ian Lepore
On single core devices set_stackptrs is only ever called with cpu = 0 in
initarm and will be identical to the existing function. On SMP this needs
to be implemented for sys/arm/mp_machdep.c, but the implementations are
identical for each SoC.
o Disable multi-block operations: they sometimes fail.
o Don't use the PROOF bits yet: they hang the system hard.
o Disable the the multi-block operations for !rm9200, but it
still doesn't help.
o Fix writing < 12 bytes errata to actually work.
o Enable, for the moment, reporting extra bytes soaked up.
restructuring of the driver. I've tried to preserve the other silicon
workarounds that we've added over the years, but haven't had a chance
to extensively test on other hardware. On my AT91RM9200 with 30MHz/1
wire/64 block transfers, I've been able to go from ~.66MB/s to
2.25MB/s in the simple tests I performed, almost a 3.5x improvement.
This cuts the boot time almost in half when everything else goes
right (timed from rtc message to login: prompt).
PR: 155214
Submitted by: Ian Lapore
explicltly enable that. The driver chose to use 60MHz / 2 (30MHz)
most of the time rather than 60MHz / 4 (15MHz) based on the Linux
driver of the time. This pushes the spec a little in order to not
suffer the penalty of running at 15MHz. However, when other bus
masters are active in the system, and the user tries 4-wire mode, the
internal bus arbitration would fail with data loss as a result.
# Comments from PR were reworked to reflect my historical perspective
PR: 155214 (partial)
Submitted by: Ian Lepore
Cummulative patch of changes that are not vendor-specific:
- ARMv6 and ARMv7 architecture support
- ARM SMP support
- VFP/Neon support
- ARM Generic Interrupt Controller driver
- Simplification of startup code for all platforms
FDT-enabled targets were broken after r238043 that relies
on device up the hierarchy to properly setup interrupt.
nexus device for ARM platforms did job only partially:
setting handler but not unmasking interrupt. Unmasking
was performed by platform code.
Reviewed by: andrew@
the linker set of CPU modules. The newbus method, although clever,
had many flaws: it didn't really support multiple SoC, many of the
comments about order were just wrong, and it did a few things far too
late to be useful. delay and cpu_reset now work much earlier in the
boot process.
having the CPU device that's a child of atmelarm that does stuff.
o Create a linker_set for the support fucntions for the SoCs.
o Rename soc_data to soc_info.
o Move the delay and reset function pointers to new soc_data struct
o Create elements for all known SoCs
o Add lookup of the SoC we found, and print a warning if it isn't one
we know about.
arm platform. Add all the atmel boards to the ATMEL kernel for
testing purposes. Until boot loader arg parsing of baord type
is done, this won't actually be able to do the runtime selection.
running with multiple SoCs compiled in very well anyway, so this just
wastes space. As more and more SoCs arrive in the tree, it is better
to edit one master file that builds them all than many board files.
for TX transfer completion as for reasons unknown this occasionally
causes SPI_SR_RXBUFF and SPI_SR_ENDRX to not rise.
In any case, once the RX part of the transfer is done it's obvious
that the preceding TX part had finished and checking of SPI_SR_TXEMPTY
was introduced to rule out a possible cause for the data corruption
mentioned in r236495 but which didn't turn out to be the problem
anyway.
MFC after: 3 days
aren't very pretty yet, but this takes DELAY and cpu_reset and makes
them pointers.
# I worry that these are set too late in the boot, especially cpu_reset.
Create a new option for at91rm9200 support. Set this option in
std.at91. Create a new option for the at91sam9 standard devices. Set
this option in std.at91sam9. Retire files.at91sam9. Add options for
at91sam9x25 SoC and SAM9X25EK board, but don't connect it just yet as
the supporting files aren't quite ready.
Note: device at91rm9200 and device at91sam9 are presently mutually
exclusive.
this array either from Linux boot data, when enabled, or in the
typical way that most ports do it. arm_pyhs_avail_init is coming
soon since it must be a separate function.
the boot parameters from initarm first thing. parse_boot_param parses
the boot arguments and converts them to the /boot/loader metadata the
rest of the kernel uses. parse_boot_param is a weak alias to
fake_preload_metadata, which all the platforms use now, but may become
more extensive in the future.
Since it is a weak symbol, specific boards may define their own
parse_boot_param to interface to custom boot loaders.
Reviewed by: cognet@, Ian Lapore
SoC variants. Fold the AT91SAM9XE chips into the AT91SAM9260
handling, where appropriate. The following SoCs/SoC families are recognized:
at91cap9, at91rm9200, at91sam9260, at91sam9261, at91sam9263,
at91sam9g10, at91sam9g20, at91sam9g45, at91sam9n12, at91sam9rl,
at91sam9x5
and the following variations are also recognized:
at91rm9200_bga, at91rm9200_pqfp, at91sam9xe, at91sam9g45, at91sam9m10,
at91sam9g46, at91sam9m11, at91sam9g15, at91sam9g25, at91sam9g35,
at91sam9x25, at91sam9x35
This is only the identification routine: no additional Atmel devices
are supported at this time.
# With these changes, I'm able to boot to the point of identification
# on a few different Atmel SoCs that we don't yet support using the
# KB920X config file -- someday tht will be an ATMEL config file...
structure with the first 4 registers to allow a wider range of boot
loaders to work. Future commits will make use of this to centralize
support for the different loaders.
- Move DMA tag and map creature to at91_spi_activate() where the other
resource allocation also lives. [1]
- Flesh out at91_spi_deactivate(). [1]
- Work around the "Software Reset must be Written Twice" erratum.
- For now, run the bus at the slowest speed possible in order to work
around data corruption on transit even seen with 9 MHz on ETHERNUT5
(15 MHz maximum) and AT45DB321D (20 MHz maximum). This also serves as
a poor man's work-around for the "NPCSx rises if no data data is to be
transmitted" erratum of RM9200. Being able to use the appropriate bus
speed would require:
1) Adding a proper work-around for the RM9200 bug consisting of taking
the chip select control away from the SPI peripheral and managing it
directly as a GPIO line.
2) Taking the maximum frequencies supported by the actual board and the
slave devices into account and basing the whole thing on the master
clock instead of hardcoding a divisor as previously done.
3) Fixing the above mentioned data corruption.
- KASSERT that TX/RX command and data sizes match on transfers.
- Introduce a mutex ensuring that only one child device is running a SPI
transfer at a time. [1]
- Add preliminary, #ifdef'ed out support for setting the chip select. [1]
- Use the RX instead of the TX commando size when setting up the RX side
of a transfer.
- For controllers having SPI_SR_TXEMPTY, i.e. !RM9200, also wait for the
completion of the TX part of transfers before stopping the whole thing
again.
- Use DEVMETHOD_END. [1]
- Use NULL instead of 0 for pointers. [1, partially]
Additional testing by: Ian Lepore
Submitted by: Ian Lepore [1]
MFC after: 1 week
console so initialized will work upon return from cninit. While this
is the very next line, other platforms setup all this stuff before
calling cninit. Also, initialize the SDRAM base register in the inner
block in at91_ramsize().
compiled into the kernel. This allows us to boot the same kernel on
machines with different master clock frequencies, so long as we can
determine the main clock frequency accurately. Cleanup the pmc clock
init function so it can be called in early boot so we can use the
serial port just after we call cninit.
# We have two calls to at91_pmc_clock_init for reasons unknown, that will
# be fixed later -- it is harmless for now.
