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:
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
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
logic.
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
@@ -2
der 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
--- a
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 f
he mask 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/tr
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 dele
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/
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
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
: 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
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
es 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
.
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 o
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/
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
-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
t; and a global 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
ime I implemented the VersatilePB did
not include the IO region. The PCI interrupt routing still seems to be missing
from the docs.
Acked-by: Paul Brook
[Ignoring any issues with the backwards comaptibility hacks]
> >> "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.re
> 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 */
> >> +
> +#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 crrent
> 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
> > 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,
> @@ -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.
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 defined(TARGET
> +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 deman
> +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
> 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
> 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 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
> 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 spe
> From: Kuo-Jung Su
>
> 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
> @@ -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_smc91c1
> 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 q
> > > 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).
> >
> > O
> +#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
> > 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 surroun
> * 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
> >> 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 resu
> > 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
> 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 flopp
> On 16 August 2012 16:17, Markus Armbruster wrote:
> > Paul Brook 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 - yo
> On 16 August 2012 15:11, Markus Armbruster wrote:
> > Peter Maydell 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 the other controllers:
> >
> > *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
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
---
configure |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index c65b5f6
> 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
>
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
> '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 nee
> 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...
> > 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
> >>> 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.
> >
>
> >> 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 im
> On 8 June 2012 10:13, Paul Brook 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 entirel
> 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
> > 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
> 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.
>
> T
> 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 sy
> >> +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 havi
> 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
> 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
> >> 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
> >
d CMD58 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
---
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
---
hw/sd.c | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/hw/sd.c b/hw
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_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_cm
coded status
byte is insufficient. CMD58 is specific to SPI mode. It is undefined in
regular SD mode.
Signed-off-by: Paul Brook
---
hw/sd.c | 57 ++---
hw/ssi-sd.c | 11 +--
2 files changed, 47 insertions(+), 21 deletions(-)
diff --
> 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 1782 matches
Mail list logo
