d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
0fe060a8f5
freebsd-dev/sys/mips/sibyte/sb_asm.S

102 lines
3.1 KiB
ArmAsm
Raw Normal View History

Add sibyte device support. Submitted by: Neelkanth Natu
2009-07-04 03:05:48 +00:00
/*-
* Copyright (c) 2009 Neelkanth Natu
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
Reimplement all functions to access the system control unit in C. The only reason we need to have the sb_load64() and sb_store64() functions in assembly is to cheat the compiler and generate the 'ld' and 'sd' instructions which it otherwise will not do when compiling for a 32-bit architecture. There are some 64-bit registers in the SCD unit that must be accessed using 64-bit load and store instructions.
2010-02-05 03:20:47 +00:00
*
* $FreeBSD$
Add sibyte device support. Submitted by: Neelkanth Natu
2009-07-04 03:05:48 +00:00
*/
#include <machine/asm.h>
SMP support for the mips port. The platform that supports SMP currently is a SWARM with a dual-core Sibyte processor. The kernel config file to use is SWARM_SMP. Reviewed by: imp, rrs
2010-02-09 06:24:43 +00:00
#include <machine/cpuregs.h>
Various fixes to get the SWARM config working on a big-endian Sibyte CPU. Getting the little-endian PCI bus working on the big-endian CPU proved to be quite challenging. We let the PCI devices be mapped in the "match byte lanes" address window. This is where they are mapped by the CFE and DMA transfers generated to or from addresses within this window are not subject to automatic byte-swapping. However any access by the driver to memory-mapped pci space is redirected via the "match bit lanes" address window. We get the benefit of automatic byte swapping through this address window and drivers don't need to change to deal with CPU big-endianness.
2010-02-17 06:43:37 +00:00
#include <machine/endian.h>
Add sibyte device support. Submitted by: Neelkanth Natu
2009-07-04 03:05:48 +00:00
/*
* We compile a 32-bit kernel to run on the SB-1 processor which is a 64-bit
* processor. It has some registers that must be accessed using 64-bit load
* and store instructions.
*
* So we have to resort to assembly because the compiler does not emit the
* 'ld' and 'sd' instructions since it thinks that it is compiling for a
* 32-bit mips processor.
*/
.set mips64
.set noat
.set noreorder
/*
Reimplement all functions to access the system control unit in C. The only reason we need to have the sb_load64() and sb_store64() functions in assembly is to cheat the compiler and generate the 'ld' and 'sd' instructions which it otherwise will not do when compiling for a 32-bit architecture. There are some 64-bit registers in the SCD unit that must be accessed using 64-bit load and store instructions.
2010-02-05 03:20:47 +00:00
* Parameters: uint32_t ptr
* Return value: *(uint64_t *)ptr
Add sibyte device support. Submitted by: Neelkanth Natu
2009-07-04 03:05:48 +00:00
*/
Reimplement all functions to access the system control unit in C. The only reason we need to have the sb_load64() and sb_store64() functions in assembly is to cheat the compiler and generate the 'ld' and 'sd' instructions which it otherwise will not do when compiling for a 32-bit architecture. There are some 64-bit registers in the SCD unit that must be accessed using 64-bit load and store instructions.
2010-02-05 03:20:47 +00:00
LEAF(sb_load64)
ld v1, 0(a0) /* result = *(uint64_t *)ptr */
Add sibyte device support. Submitted by: Neelkanth Natu
2009-07-04 03:05:48 +00:00
move v0, v1
Various fixes to get the SWARM config working on a big-endian Sibyte CPU. Getting the little-endian PCI bus working on the big-endian CPU proved to be quite challenging. We let the PCI devices be mapped in the "match byte lanes" address window. This is where they are mapped by the CFE and DMA transfers generated to or from addresses within this window are not subject to automatic byte-swapping. However any access by the driver to memory-mapped pci space is redirected via the "match bit lanes" address window. We get the benefit of automatic byte swapping through this address window and drivers don't need to change to deal with CPU big-endianness.
2010-02-17 06:43:37 +00:00
#if _BYTE_ORDER == _BIG_ENDIAN
Reimplement all functions to access the system control unit in C. The only reason we need to have the sb_load64() and sb_store64() functions in assembly is to cheat the compiler and generate the 'ld' and 'sd' instructions which it otherwise will not do when compiling for a 32-bit architecture. There are some 64-bit registers in the SCD unit that must be accessed using 64-bit load and store instructions.
2010-02-05 03:20:47 +00:00
dsll32 v1, v1, 0
dsrl32 v1, v1, 0 /* v1 = lower_uint32(result) */
Add sibyte device support. Submitted by: Neelkanth Natu
2009-07-04 03:05:48 +00:00
jr ra
Reimplement all functions to access the system control unit in C. The only reason we need to have the sb_load64() and sb_store64() functions in assembly is to cheat the compiler and generate the 'ld' and 'sd' instructions which it otherwise will not do when compiling for a 32-bit architecture. There are some 64-bit registers in the SCD unit that must be accessed using 64-bit load and store instructions.
2010-02-05 03:20:47 +00:00
dsrl32 v0, v0, 0 /* v0 = upper_uint32(result) */
#else
Add sibyte device support. Submitted by: Neelkanth Natu
2009-07-04 03:05:48 +00:00
dsll32 v0, v0, 0
Reimplement all functions to access the system control unit in C. The only reason we need to have the sb_load64() and sb_store64() functions in assembly is to cheat the compiler and generate the 'ld' and 'sd' instructions which it otherwise will not do when compiling for a 32-bit architecture. There are some 64-bit registers in the SCD unit that must be accessed using 64-bit load and store instructions.
2010-02-05 03:20:47 +00:00
dsrl32 v0, v0, 0 /* v0 = lower_uint32(result) */
Add sibyte device support. Submitted by: Neelkanth Natu
2009-07-04 03:05:48 +00:00
jr ra
Reimplement all functions to access the system control unit in C. The only reason we need to have the sb_load64() and sb_store64() functions in assembly is to cheat the compiler and generate the 'ld' and 'sd' instructions which it otherwise will not do when compiling for a 32-bit architecture. There are some 64-bit registers in the SCD unit that must be accessed using 64-bit load and store instructions.
2010-02-05 03:20:47 +00:00
dsrl32 v1, v1, 0 /* v1 = upper_uint32(result) */
#endif
END(sb_load64)
Add sibyte device support. Submitted by: Neelkanth Natu
2009-07-04 03:05:48 +00:00
/*
Reimplement all functions to access the system control unit in C. The only reason we need to have the sb_load64() and sb_store64() functions in assembly is to cheat the compiler and generate the 'ld' and 'sd' instructions which it otherwise will not do when compiling for a 32-bit architecture. There are some 64-bit registers in the SCD unit that must be accessed using 64-bit load and store instructions.
2010-02-05 03:20:47 +00:00
* Parameters: uint32_t ptr, uint64_t val
* Return value: void
Add sibyte device support. Submitted by: Neelkanth Natu
2009-07-04 03:05:48 +00:00
*/
Reimplement all functions to access the system control unit in C. The only reason we need to have the sb_load64() and sb_store64() functions in assembly is to cheat the compiler and generate the 'ld' and 'sd' instructions which it otherwise will not do when compiling for a 32-bit architecture. There are some 64-bit registers in the SCD unit that must be accessed using 64-bit load and store instructions.
2010-02-05 03:20:47 +00:00
LEAF(sb_store64)
Various fixes to get the SWARM config working on a big-endian Sibyte CPU. Getting the little-endian PCI bus working on the big-endian CPU proved to be quite challenging. We let the PCI devices be mapped in the "match byte lanes" address window. This is where they are mapped by the CFE and DMA transfers generated to or from addresses within this window are not subject to automatic byte-swapping. However any access by the driver to memory-mapped pci space is redirected via the "match bit lanes" address window. We get the benefit of automatic byte swapping through this address window and drivers don't need to change to deal with CPU big-endianness.
2010-02-17 06:43:37 +00:00
#if _BYTE_ORDER == _BIG_ENDIAN
Reimplement all functions to access the system control unit in C. The only reason we need to have the sb_load64() and sb_store64() functions in assembly is to cheat the compiler and generate the 'ld' and 'sd' instructions which it otherwise will not do when compiling for a 32-bit architecture. There are some 64-bit registers in the SCD unit that must be accessed using 64-bit load and store instructions.
2010-02-05 03:20:47 +00:00
dsll32 a2, a2, 0 /* a2 = upper_uint32(val) */
dsll32 a3, a3, 0 /* a3 = lower_uint32(val) */
dsrl32 a3, a3, 0
#else
dsll32 a3, a3, 0 /* a3 = upper_uint32(val) */
dsll32 a2, a2, 0 /* a2 = lower_uint32(val) */
dsrl32 a2, a2, 0
#endif
or t0, a2, a3
jr ra
sd t0, 0(a0)
END(sb_store64)
SMP support for the mips port. The platform that supports SMP currently is a SWARM with a dual-core Sibyte processor. The kernel config file to use is SWARM_SMP. Reviewed by: imp, rrs
2010-02-09 06:24:43 +00:00
#ifdef SMP
/*
* This function must be implemented in assembly because it is called early
* in AP boot without a valid stack.
*
* This cpu number is available in bits 25 to 27 of the coprocessor 0 PRID
* register. This is not documented in the BCM1250 user manual but can be
* gleaned from the CFE source code - see sb1250_altcpu.S
*/
LEAF(platform_processor_id)
mfc0 v0, MIPS_COP_0_PRID
srl v0, v0, 25
jr ra
and v0, v0, 7
END(platform_processor_id)
#endif /* SMP */
Reference in New Issue Copy Permalink