Yes, I'm happy for p...@codesourcery.com to be linked to my current email for
attribution purposes.
Paul
On 26 September 2022 14:46:05 BST, "Alex Bennée" wrote:
>Do you want to map old commits to your canonical email now as well?
>
>Signed-off-by: Alex Bennée
>Cc: Paul
Rewrite the blendv helpers so that they can easily be extended to support
the AVX encodings, which make all 4 arguments explicit.
No functional changes to the existing helpers
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h | 119 +-
1 file changed
These use the W bit to encode the operand width, but otherwise fairly
straightforward.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 17 +
target/i386/ops_sse_header.h | 6 ++
target/i386/tcg/translate.c | 17 +
3 files changed, 40 insertions
More perparatory work for AVX support in various integer vector helpers
No functional changes to existing helpers.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h | 133 +-
1 file changed, 104 insertions(+), 29 deletions(-)
diff --git a/target/i386
Make the pclmulqdq helper AVX ready
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git a/target/i386/ops_sse.h b/target/i386/ops_sse.h
index 9f388b02b9..b7100fdce1 100644
--- a/target/i386
Noting special here
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 28
target/i386/ops_sse_header.h | 2 ++
target/i386/tcg/translate.c | 2 ++
3 files changed, 32 insertions(+)
diff --git a/target/i386/ops_sse.h b/target/i386/ops_sse.h
index
For AVX we're going to need both 128 bit (xmm) and 256 bit (ymm) variants of
floating point helpers. Add the register type suffix to the existing
*PS and *PD helpers (SS and SD variants are only valid on 128 bit vectors)
No functional changes.
Signed-off-by: Paul Brook
---
target/i386
later.
Signed-off-by: Paul Brook
---
target/i386/helper.h | 2 +
target/i386/tcg/fpu_helper.c | 3 +
target/i386/tcg/translate.c | 370 +--
3 files changed, 319 insertions(+), 56 deletions(-)
diff --git a/target/i386/helper.h b/target/i386/helper.h
Prepare the "easy" floating point vector helpers for AVX
No functional changes to existing helpers.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h | 144 ++
1 file changed, 119 insertions(+), 25 deletions(-)
diff --git a/target/i386/o
.
Signed-off-by: Paul Brook
---
target/i386/tcg/translate.c | 12
1 file changed, 12 insertions(+)
diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index d148a2319d..278ed8ed1c 100644
--- a/target/i386/tcg/translate.c
+++ b/target/i386/tcg/translate.c
@@ -2780,6
remainder of the destination from
first source operand. If the operation only has a single source value,
then the VEX.V encodes an additional operand from which is coped to the
the remainder of destination.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 214 +--
t
128-bit vinsert/vextract instructions. The integer and loating point variants
have the same semantics.
This is where we encounter an instruction encoded with VEX.L == 1 and
a 128 bit (xmm) destination operand.
Signed-off-by: Paul Brook
---
target/i386/tcg/translate.c | 78
Make the AES vector helpers AVX ready
No functional changes to existing helpers
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 63 ++--
target/i386/ops_sse_header.h | 55 ++-
2 files changed, 85 insertions(+), 33
A set of shuffle operations that operate on complete 256 bit registers.
The integer and floating point variants have identical semantics.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 73
target/i386/ops_sse_header.h | 3 ++
target/i386/tcg
Include AVX and AVX2 in the guest cpuid features supported by TCG
Signed-off-by: Paul Brook
---
target/i386/cpu.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/target/i386/cpu.c b/target/i386/cpu.c
index 99343be926..bd35233d5b 100644
--- a/target/i386/cpu.c
+++ b
Include sha512 built with avx[2] in the tcg tests.
Signed-off-by: Paul Brook
---
tests/tcg/i386/Makefile.target | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tests/tcg/i386/Makefile.target b/tests/tcg/i386/Makefile.target
index eb06f7eb89..a0335fff6d 100644
Make the dpps and dppd helpers AVX-ready
I can't see any obvious reason why dppd shouldn't work on 256 bit ymm
registers, but both AMD and Intel agree that it's xmm only.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h | 54 ---
1 file changed, 46
sk operand.
Thankfully the operands may not overlap, and we do not have to make the whole
thing appear atomic.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 65 +++
target/i386/ops_sse_header.h | 16
target/i386/tcg/transla
AVX includes additional a more extensive set of comparison predicates,
some of some of which our softfloat implementation does not expose directly.
Rewrite the helpers in terms of floatN_compare
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 149
Handle 3DNOW instructions early to avoid complicating the AVX logic.
Signed-off-by: Paul Brook
---
target/i386/tcg/translate.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index
Update ops_sse_helper.h ready for 256 bit AVX helpers
Signed-off-by: Paul Brook
---
target/i386/ops_sse_header.h | 67 +---
1 file changed, 40 insertions(+), 27 deletions(-)
diff --git a/target/i386/ops_sse_header.h b/target/i386/ops_sse_header.h
index
Fixup various vector helpers that either trivially exten to 256 bit,
or don't have 256 bit variants.
No functional changes to existing helpers
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h | 159 --
1 file changed, 139 insertions(+), 20 deletions
The use the same opcode as EMMS, which I guess makes some sort of sense.
Fairly strightforward other than that.
If we were wanting to optimize out gen_clear_ymmh then this would be one of
the starting points.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 48
replace it with explicit temporaries and element assignments.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h | 707 ++
1 file changed, 437 insertions(+), 270 deletions(-)
diff --git a/target/i386/ops_sse.h b/target/i386/ops_sse.h
index d0424140d9
We don't have any migration concerns for usermode emulation, so we may
as well enable all available CPU features by default.
Signed-off-by: Paul Brook
---
linux-user/x86_64/target_elf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/x86_64/target_elf.h b/linux
The catch here is that these are whole vector operations (not independent 128
bit lanes). We abuse the SSE_OPF_SCALAR flag to select the memory operand
width appropriately.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 51
target/i386
Rewrite the "simple" vector integer helpers in preperation for AVX support.
While the current code is able to use the same prototype for unary
(a = F(b)) and binary (a = F(b, c)) operations, future changes will cause
them to diverge.
No functional changes to existing helpers
Signed-of
This is semantically eqivalent to VBLENDPS.
Signed-off-by: Paul Brook
---
target/i386/tcg/translate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index 95ecdea8fe..73f3842c36 100644
--- a/target/i386/tcg/translate.c
+++ b/target
.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h | 96 +++
1 file changed, 70 insertions(+), 26 deletions(-)
diff --git a/target/i386/ops_sse.h b/target/i386/ops_sse.h
index 4137e6e1fa..d128af6cc8 100644
--- a/target/i386/ops_sse.h
+++ b/target/i386
Some potentially surprising details when comparing vpermilpd v.s. vpermilps,
but overall pretty straightforward.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 82
target/i386/ops_sse_header.h | 4 ++
target/i386/tcg/translate.c | 4 ++
3
Decoding these is a bit messy, but at least the integer and float variants
have the same semantics once decoded.
We don't try and be clever with the load forms, instead load the whole
vector then mask out the elements we want.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 48
The AVX variants of the BLENDV instructions use a different opcode prefix
to support the additional operands. We already modified the helper functions
in anticipation of this.
Signed-off-by: Paul Brook
---
target/i386/tcg/translate.c | 18 --
1 file changed, 16 insertions(+), 2
Rewrite the vector shift helpers in preperation for AVX support (3 operand
form and 256 bit vectors).
For now keep the existing two operand interface.
No functional changes to existing helpers.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h | 250
Add a flags field each row in sse_op_table6 and sse_op_table7.
Initially this is only used as a replacement for the magic
SSE41_SPECIAL pointer. The other flags will become relevant
as the rest of the avx implementation is built out.
Signed-off-by: Paul Brook
---
target/i386/tcg/translate.c
the number of
function calls that need to be split over multiple lines.
No functional changes.
Signed-off-by: Paul Brook
---
target/i386/tcg/translate.c | 60 +
1 file changed, 27 insertions(+), 33 deletions(-)
diff --git a/target/i386/tcg/translate.c b
-by: Paul Brook
---
target/i386/tcg/translate.c | 159 +---
1 file changed, 149 insertions(+), 10 deletions(-)
diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index 66ba690b7d..2f5cc24e0c 100644
--- a/target/i386/tcg/translate.c
+++ b/target
Add a new hflag bit to determine whether AVX instructions are allowed
Signed-off-by: Paul Brook
---
target/i386/cpu.h| 3 +++
target/i386/helper.c | 12
target/i386/tcg/fpu_helper.c | 1 +
3 files changed, 16 insertions(+)
diff --git a/target/i386/cpu.h b
Reject invalid VEX encodings on MMX instructions.
Signed-off-by: Paul Brook
---
target/i386/tcg/translate.c | 26 ++
1 file changed, 26 insertions(+)
diff --git a/target/i386/tcg/translate.c b/target/i386/tcg/translate.c
index 5335b86c01..66ba690b7d 100644
--- a/target
Add a flags field each row in sse_op_table1.
Initially this is only used as a replacement for the magic
SSE_SPECIAL and SSE_DUMMY pointers, the other flags will become relevant
as the rest of the AVX implementation is built out.
Signed-off-by: Paul Brook
---
target/i386/tcg/translate.c | 316
(but harmless) add operation
from DPPD
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h | 47 +++
1 file changed, 25 insertions(+), 22 deletions(-)
diff --git a/target/i386/ops_sse.h b/target/i386/ops_sse.h
index 535440f882..a5a48a20f6 100644
--- a/target/i386
to 32 bits, and will give
the wrong anser for the most negative value.
Fix by open coding the saturation check before taking the absolute value.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h | 20 +---
1 file changed, 9 insertions(+), 11 deletions(-)
diff --git a/target/i386
.
Signed-off-by: Paul Brook
---
target/i386/ops_sse.h| 8
target/i386/ops_sse_header.h | 4
2 files changed, 12 insertions(+)
diff --git a/target/i386/ops_sse.h b/target/i386/ops_sse.h
index a5a48a20f6..23daab6b50 100644
--- a/target/i386/ops_sse.h
+++ b/target/i386
On Wed, 2022-04-20 at 16:19 +0200, Paolo Bonzini wrote:
> On 4/18/22 21:45, Paul Brook wrote:
> > > Massively too large for a single patch, I'm afraid. This needs
> > > to be split, probably into at least twenty patches, which each
> > > are a reviewable chunk of cod
On Mon, 2022-04-18 at 20:33 +0100, Peter Maydell wrote:
> On Mon, 18 Apr 2022 at 18:48, Paul Brook wrote:
> >
> > Add TCG translation of guest AVX/AVX2 instructions
> > This comprises:
> >
>
> Massively too large for a single patch, I'm afraid. This needs
>
We don't have any migration concerns for usermode emulation, so we may
as well enable all available CPU features by default.
Signed-off-by: Paul Brook
---
linux-user/x86_64/target_elf.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/linux-user/x86_64/target_elf.h b/linux
Add a new hflag bit to determine whether AVX instructions are allowed
Signed-off-by: Paul Brook
---
target/i386/cpu.h| 3 +++
target/i386/helper.c | 12
target/i386/tcg/fpu_helper.c | 1 +
3 files changed, 16 insertions(+)
diff --git a/target/i386/cpu.h b
or 64/128 bit mm/xmm operations.
I've included the tests I used during development to the linux-user
testsuite, and also ran these manually inside a debian x86-64 guest.
Appologies for the big patch, but I can't think of a good way to split
the bulk of the instruction translation.
Paul Brook (4):
Ad
-pointless sys_inotify* wrappers.
Tested using x86-64 inotifywatch on aarch64 host, and vice-versa
Signed-off-by: Paul Brook
---
linux-user/fd-trans.c | 5 ++---
linux-user/syscall.c | 50 +--
2 files changed, 12 insertions(+), 43 deletions(-)
diff --git
modification of the comment structure. This patch rebases
our softfloat code to SoftFloat-2a in order to have a GPLv2 compatible
license.
Acked-by: Paul Brook p...@codesourcery.com
the VersatilePB did
not include the IO region. The PCI interrupt routing still seems to be missing
from the docs.
Acked-by: Paul Brook p...@codesourcery.com
[Ignoring any issues with the backwards comaptibility hacks]
On 03/01/2013 09:58 PM, Paul Brook wrote:
+#ifdef TARGET_WORDS_BIGENDIAN
+if (arm_feature(env, ARM_FEATURE_V6)
+|| arm_feature(env, ARM_FEATURE_V7)) {
+/* IE and EE bits stay set for big-endian */
+env-cp15.c1_sys |= (1 31) | (1 25);
+}
+#endif
The bytes with the register are transmitted in target byte order.
/* Aliases for Q regs. */
nregs += 16;
if (reg nregs) {
-stfq_le_p(buf, env-vfp.regs[(reg - 32) * 2]);
-stfq_le_p(buf + 8, env-vfp.regs[(reg - 32) * 2 + 1]);
+
From GDB Remote Serial Protocol doc:
The bytes with the register are transmitted in target byte order.
/* Aliases for Q regs. */
nregs += 16;
if (reg nregs) {
-stfq_le_p(buf, env-vfp.regs[(reg - 32) * 2]);
-stfq_le_p(buf + 8,
+#ifdef TARGET_WORDS_BIGENDIAN
+if (arm_feature(env, ARM_FEATURE_V6)
+|| arm_feature(env, ARM_FEATURE_V7)) {
+/* IE and EE bits stay set for big-endian */
+env-cp15.c1_sys |= (1 31) | (1 25);
+}
+#endif
This is wrong for all the CPUs QEMU crrently
Probably what you'll want is to have a separate feature bit for 32
dregs which is set by default for vfpv3, and then use that in
VFP_DREG rather than the vfpv3 feature bit.
Right, it might be easier than I though. Maybe add a
ARM_FEATURE_VFP3_D16 and do:
#define VFP_DREG(reg, insn,
@@ -100,6 +102,7 @@ struct CPUState {
bool stop;
bool stopped;
volatile sig_atomic_t exit_request;
+volatile sig_atomic_t tcg_exit_req;
Do we really need annother variable/check? It seems like this should be at
least partially redundant with the existing icount code. I
In addition to the comments others made about patch formatting, etc:
+/* conditional breakpoint evaluation on target*/
+pstrcat(buf, sizeof(buf), ;ConditionalBreakpoints+);
I'm pretty sure this is a lie for most targets, given later on we have:
+#if
To be able to create generic GPIO devices or other devices that have GPIO
like pins (e.g MDIO), and hook those up to external buses through common
frameworks, we need agreement on how to model tristate pins.
A tristate pin model, or at least agreement on how to model these with
multiple
@@ -44,6 +45,10 @@ typedef struct {
uint8_t int_level;
uint8_t int_mask;
MemoryRegion mmio;
+
+/* MDIO bus and the attached phy */
+struct qemu_mdio mdio_bus;
+struct qemu_phy phy;
} smc91c111_state;
static const VMStateDescription vmstate_smc91c111 = {
@@
From: Kuo-Jung Su dant...@faraday-tech.com
Faraday keyboard/mouse controller (FTKBC010) is compliant with the
IBM PS/2 interface.
Your description doesn't appear to match the code at all. Surely if this were
true then you should be using the existing PS2 keyboard emulation.
Paul
Since the NAND and SPI flash memories do not support random access,
so most of the systems which use such memory as main storages
usually has some bootstrap code stored inside the embedded ROM of
its SoC, and the bootstrap code is responsible for SDRAM initialization
and then load the
The FTAPBBRG020 supports the DMA functions for the AHB-to-AHB,
AHB-to-APB, APB-to-AHB, and APB-to-APB transactions.
All the timer code in this file looks suspect. As a general rule everything
should be event driven and complete immediately (or at least schedule a BH for
immediate action if
In order to reduce the processing load of the host CPU, the FTGMAC100
implements TCP, UDP, and IP V4 checksum generation and validation, and
supports VLAN tagging.
I see no evidence of these features in the code.
+static void ftgmac100_read_desc(hwaddr addr, void *desc)
+{
+int i;
+
The FTMAC110 is a high quality 10/100 Ethernet controller
Which looks largely the same as the other ethernet controller you added in the
previous patch.
Paul
+if (!(s-dcr DCR_WR) (s-datacnt 0)) {
+ret = sd_read_data(s-card)
+| sd_read_data(s-card) 8
+| sd_read_data(s-card) 16
+| sd_read_data(s-card) 24;
+s-datacnt -= 4;
+if (s-datacnt = 0) {
+
+qemu_mod_timer(s-qtimer,
+qemu_get_clock_ns(vm_clock) + get_ticks_per_sec());
This will not work reliably. You can not rely on timers triggering promptly.
Plus you're loosing the time taken to execute the callback every tick.
Additionally you can calculate values on demand,
It also worries me that there isn't a clean separation between the MDIO
bus and the bitbang interface. IMO the bitbang interface should be a
separate device, and if we're wiring up bitbang interfaces then it
really should be via standard GPIO pins (aka qemu_irq).
Only the bitbang
+#ifdef USE_THIS_DEAD_CODE
+void mdio_detach(struct qemu_mdio *bus, struct qemu_phy *phy, unsigned int
addr) +{
+bus-devs[addr 0x1f] = NULL;
+}
+#endif
This is clearly wrong.
It also worries me that there isn't a clean separation between the MDIO bus
and the bitbang interface. IMO
diff --git a/disas/cris.c b/disas/cris.c
+/* XXX: questionable fallthrough */
Inherited from binutils; if you want to clean this up, suggest to do it
there.
Except that upstream binutils is GPLv3, so this code is effectively orphaned.
Paul
I don't think there's much point adding tons of XXX comments
when a bunch of these aren't actually wrong code. If you want to fix
this I think a better approach would be more focused patches aimed
at adding 'break;' or /* fallthrough */ based on actual human
examination of the surrounding
* ARMv5TE series (FA606TE, FA626TE, FA616TE, FA726TE)
All the single core RISC listed above are included in this patch.
And there are two Faraday CP15 extensions (AUX and I/D-Scratchpad)
have been implemented as NOP.
Is a NOP appropriate? Should you at least read the value
This changes the driver behavior to choose the default machine
model based on the CPU being used. Defaulting the machine this
way makes it easier to use QEMU as an ISS by just specifying
the -cpu option since a default machine that is suitable for
emulating the full ISA can be chosen.
Just to pick an obvious example, you can't stick a core
which supports VFPv4 (the A15 is the only one we have) into
the integratorcp
Yes you can.
No you can't. integratorcp.c doesn't create the parts of the CPU
which live in QEMU's 'a15mpcore_priv' device, so the resulting
mess is
On 16 August 2012 15:11, Markus Armbruster arm...@redhat.com wrote:
Peter Maydell peter.mayd...@linaro.org writes:
As suggested in the recent discussion on Markus' patchset to suppress
unused default drives, this patchset cleans up the omap and pxa2xx
SD card controllers to behave like
On 16 August 2012 16:17, Markus Armbruster arm...@redhat.com wrote:
Paul Brook p...@codesourcery.com writes:
I think this may be the wrong way to fix this. SD cards aren't really
have removable media. In the same way that a SCSI HDD are generally
not removable media - you hotplug
One way is to treat the SD card as a hot-pluggable device. A card
reader device model provides a connector for the SD card device model.
The SD card device model is backed by a block backend, with
non-removable medium. Card change is device hot plug.
...
Note that we could model floppies
*can* use it for something entirely else, if=sd notwithstanding:
(qemu) device_add lsi
(qemu) device_add scsi-cd,drive=sd0
If/when we get a PCI SD card controller model, would all the PCI
using machines need to be added to take the 'no default sd card'
setting out again, or does
Recent gcc notice that the ASLA configure check uses an uninitialized
variable, causing spurious failures. Adjust the testcase to avoid this.
Signed-off-by: Paul Brook p...@codesourcery.com
---
configure |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b
The coprocessor register rework broke cp15 based WFI instructions.
We incorrectly fall through the normal register write case, which
incorrectly adds a forced block termination. We've already done
a special version of this (DISAS_WFI), so return immediately.
Signed-off-by: Paul Brook p
This series depends on my QOM -object series that I just posted.
In Amit's thread on virtio-rng, danpb mentioned that we really ought to
have a proper RNG backend infrastructure and of course he's correct on
that.
Now that we have QOM, I wanted to demonstrate how we can use QOM to
openSUSE uses a version patched so that IIUC 3G are reserved.
Just today this failed on a system where swap got disabled and the
mmap() thus failed.
Err... why? We map with MAP_NORESERVE, so swap shouldn't matter...
I can't say if it's the same cause, but we fail with ulimit -v 4046848.
On 28.06.2012, at 02:06, Paul Brook wrote:
openSUSE uses a version patched so that IIUC 3G are reserved.
Just today this failed on a system where swap got disabled and the
mmap() thus failed.
Err... why? We map with MAP_NORESERVE, so swap shouldn't matter...
I can't say if it's
'guest_validate_base' is currently called for three reasons: (1) in main.c
when using -B, (2) in main.c when using -R after mapping the reserved va
region, and (3) and when probing for a guest base in probe_guest_base.
For case (1) I suppose things are pretty much the same -- we just need to
Im looking to QOMifying and refactoring the AXI stream interfaces
between the AXI ethernet and AXI DMA modules. I could use some
guidance on how to do this as I can think of about 6 different
solutions. Sources are hw/xilinx_axienet.c and hw/xilinx_axidma.c.
...
So what im proposing is AXI
On 8 June 2012 10:13, Paul Brook p...@codesourcery.com wrote:
Of course we then hit the usual problem with QOM that we can only link to
objects, and it's impossible to expose multiple interfaces of the same
type.
I'm pretty sure Anthony claimed this was entirely possible --
presumably
So what im proposing is AXI stream is implemented as a unidirectional
point to point bus. The xilinx ethernet system would consist of two of
these buses one for tx, one for rx.
I thought the idea was that with QOM the bus/device model would go away.
The DMA controller implements an
Of course we then hit the usual problem with QOM that we can only link
to objects, and it's impossible to expose multiple interfaces of the
same type.
I'm pretty sure Anthony claimed this was entirely possible --
presumably that's how Pins are going to work.
Really? Every time
On 5th April, when we first RFC'd our SPI layer support, you said to Peter:
==
I don't believe there is any difference between SSI and SPI. It's the
exact same thing - the same way that many devices support a two-wire
interface that is actually just I2C with a different name.
The
I'm still not convinced modelling this as a multipoint bus is a good
idea. If nothing else you've failed to model the case where multiple
slaves are selected simultanously.
The bus can easily be changed such that multiple devices are
selectable at once to get your desired multi device
Patch 1 Enhances SSI bus support to properly support multiple attached
devices. An api is provided for SSI/SPI masters to select a particular
device attached to the bus.
Patch 2 is a device model for the m25p80 style SPI flash chip.
Patch 3 is the Xilinx XPS SPI contoller. Its a sysbus
+void cpu_tlb_flush(CPUState *cpu, bool flush_global)
+{
+CPUClass *cc = CPU_GET_CLASS(cpu);
+
+g_assert(cc-tlb_flush != NULL);
+
+cc-tlb_flush(cpu, flush_global);
+}
This needs to be able to call tlb_flush() itself
rather than having to have every single
Recent testing showed the SPI mode SD card emulation (ssi-sd.c) doesn't
actually work if the guest tries to use features from the SD Physical
Layer Specification v2 (this incluldes SDHC).
This series replaces my previous single patch.
Paul Brook (2):
Fix SPI SD card command responses
hw/sd.c
Implement CMD58. This command is only valid in SPI mode, and required when we
implement CMD8. Most of the code is already there, we just need to
trigger it.
Signed-off-by: Paul Brook p...@codesourcery.com
---
hw/sd.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff
to follow)
this gets messy, with both parts requiring command specific knowledge.
We already have magic SPI-mode behavior in sd.c, so may as well just
generate the correct response there.
Signed-off-by: Paul Brook p...@codesourcery.com
---
hw/sd.c | 125
If this command could be issued in transfer state maybe in addition to
IDLE_STATE you also need to set other bits (ADDRESS_ERROR,
COM_CRC_ERROR, ILLEGAL_COMMAND, ERASE_SEQ_ERROR) in MSB of R3 response?
In theory, yes. I was thinking of a follow-up patch to move the spi
status byte
And drop passing is_spi argument to SDCardClass::init function.
spi property could be set while SD card is in IDLE state. It defaults to
false.
Why? This isn't something that should be under user or board control. The SD
card object is an implementation detail. It's something that's part
Move feature register value setup to per-CPU init functions.
+env-cp15.c0_c1[0] = cpu-id_pfr0;
+env-cp15.c0_c1[1] = cpu-id_pfr1;
+env-cp15.c0_c1[2] = cpu-id_dfr0;
+env-cp15.c0_c1[3] = cpu-id_afr0;
+env-cp15.c0_c1[4] = cpu-id_mmfr0;
+env-cp15.c0_c1[5] = cpu-id_mmfr1;
-sd_adtc, sd_none, sd_none, sd_none, sd_none, sd_none, sd_none,
+sd_adtc, sd_none, sd_bc, sd_bc, sd_none, sd_none,
sd_bcr? not that it really matters though
Err, probably.
+case 58:/* CMD58: READ_OCR */
+if (!sd-spi) {
+goto bad_cmd;
+
On 23 April 2012 23:21, Peter Chubb peter.ch...@nicta.com.au wrote:
Peter Are these two devices really on the same IRQ?
Yes. A single interrupt line comes from the FPGA into the AVIC.
Inside the FPGA the interrupts for the UARTs, SD card and NAND flash
are connected to that single
Im happy to spend the 10 mins updating stellaris.c accordingly, but is
someone sitting on a binary package and brief instructions or some
such to regression test it? Do you of this machine have some sort of
kernel image handy?
I've attached a tarball with some test binaries. They're built
1 - 100 of 1522 matches
Mail list logo
