Hi Cédric/Philippe and others,
I would also like to see eMMC support as its very useful for certain
embedded emulation.
I found a several discussions for SPI/eMMC in Qemu but couldn't find
anything that ever made a release, and the conversation seems to have
gone dead a couple years ago. The mai
On Tue, Oct 8, 2019 at 8:29 PM Philippe Mathieu-Daudé wrote:
>
> On 10/5/19 9:09 PM, Peter Maydell wrote:
> > On Sat, 5 Oct 2019 at 18:13, John Snow wrote:
> >> I'm not clear on the particulars of mail delivery protocols or what
> >> lists.sr.ht is, but we indeed do not like HTML mail sent to thi
Hi John,
On Sun, Oct 6, 2019 at 2:12 AM John Snow wrote:
> On 10/5/19 7:55 AM, Lucien Murray-Pitts wrote:
> > The last message I sent came back with a weird reply from
[snip]
>
> I'm not clear on the particulars of mail delivery protocols or what
> lists.sr.ht is, but we
Hey folks,
The last message I sent came back with a weird reply from
*mai...@lists.sr.ht*, claiming the list didnt support "HTML" formatted
mail (which is the default) for gmail, and then saying it couldnt be
delivered.
Thats a confusing mail as it would imply failure in delivery.Was I
suppos
Hi folks,
Whilst working on a m68k patch I noticed that the capstone in use
today (3.0) doesnt support the M68K and thus a hand turned disasm
function is used.
The newer capstone (5.0) appears to support a few more CPU, inc. m68k.
Why we move to this newer capstone?
Furthermore, if making a mov
Hi folks,
Whilst working on a m68k patch I noticed that the capstone in use today
(3.0) doesnt support the M68K and thus a hand turned disasm function is
used.
The newer capstone (5.0) appears to support a few more CPU, inc. m68k.
Why we move to this newer capstone?
Furthermore, if making a mov
On 7/10/19 4:04 AM, Richard Henderson wrote:
On 7/9/19 6:58 PM, Lucien Murray-Pitts wrote:
Any suggestions on how to obtain pc_next from the "m68k_cpu_do_interrupt(
CPUState *cs)" ?
test
I did have a suggestion. It was fairly detailed.
https://lists.gnu.org/archive/html/qemu-dev
> On Wed, Jul 10, 2019 at 4:04 AM Richard Henderson <
richard.hender...@linaro.org> wrote:
> > I did have a suggestion. It was fairly detailed.
> > https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg06522.html
>
> Your solution is elegant at about 10 lines that return getl_ilen(pc), but
it
M, Lucien Murray-Pitts wrote:
> > Any suggestions on how to obtain pc_next from the "m68k_cpu_do_interrupt(
> > CPUState *cs)" ?
>
> I did have a suggestion. It was fairly detailed.
>
> https://lists.gnu.org/archive/html/qemu-devel/2019-06/msg06522.html
>
>
> r~
>
On Mon, Jul 1, 2019 at 9:11 PM Peter Maydell
wrote:
> > On Mon, 1 Jul 2019 at 13:04, Lucien Anti-Spam
> > wrote:
> > > Further to my initial problem I noticed that TRAP #0 also jumps to the
> handlers +1 instruction.
> > > Same behavior can also be seen with ARM "SWI #0".(PC shows 0x0C vs
>
On Sat, Jun 29, 2019 at 12:15:44PM +0200, Richard Henderson wrote:
> On 6/28/19 5:50 PM, Lucien Murray-Pitts wrote:
> > op_helper.c
> >static void m68k_interrupt_all(CPUM68KState *env, int is_hw)
> >...
> > if (cs->
On Fri, Jun 28, 2019 at 11:35:48AM +0200, Richard Henderson wrote:
> On 6/28/19 2:27 AM, Lucien Murray-Pitts wrote:
> >
> > [snip] ... the "return" address is the instruction that causes the
> > exception.
> > So it immediately does return to the ISR.
>
On Thu, Jun 27, 2019 at 07:09:39PM +0200, Richard Henderson wrote:
> On 6/27/19 3:22 PM, Lucien Anti-Spam wrote:
> > Hi Laurent / Richard,
> > (resent email )
> >
> > Does anyone have any knowledge why
> > gen_exception(s, s->base.pc_next, EXCP_RTE);
> >
> > is generated for "RTE" instruction
: Lucien Murray-Pitts
---
target/m68k/cpu.c| 1 +
target/m68k/cpu.h| 8 +++-
target/m68k/helper.c | 3 ++-
3 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/target/m68k/cpu.c b/target/m68k/cpu.c
index 50260de97d..f1610e2745 100644
--- a/target/m68k/cpu.c
+++ b/target/m68k
is empty in this patch
and these registers will result in a cpu abort - which is the default prior
to this patch.
This patch aims to reach full coverage of all CR registers within the helpers.
Signed-off-by: Lucien Murray-Pitts
---
target/m68k/cpu.h| 4
target/m68k/helper.c | 14
Added more detailed comments to each case of m68k_move_to/from helpers to list
the supported CPUs for that CR as they were wrong in some cases, and
missing some cpu classes in other cases.
Signed-off-by: Lucien Murray-Pitts
---
target/m68k/helper.c | 41
fied MOVEC insn. as only supported in 68010.
Signed-off-by: Lucien Murray-Pitts
---
target/m68k/cpu.c | 3 +
target/m68k/cpu.h | 4 +
target/m68k/helper.c| 192 ++--
target/m68k/translate.c | 2 +-
4 files changed, 155 insertions(+), 46
the inheritence
- Created real m68030_cpu_initfn to replace the macro define
for more obvious calling/future expansion
Signed-off-by: Lucien Murray-Pitts
---
target/m68k/cpu.c | 58 +--
1 file changed, 36 insertions(+), 22 deletions(-)
diff --git a
Improvement in comments for the instantiation functions.
This is to highlight what each cpu class, in the 68000 series, contains
in terms of instructions/features.
Signed-off-by: Lucien Murray-Pitts
---
target/m68k/cpu.c | 47 +++
target/m68k/cpu.h
mission due to being incorrectly
formatted)
Lucien Murray-Pitts (6):
m68k cpu instantiation comments improvements
Cascade m68k_features by m680xx_cpu_initfn() to improve readability
Improved comments on m68k_move_to/from helpers
Add missing BUSCR/PCR CR defines, and BUSCR/PCR/CAAR CR to
comments in the existing code referring to the EC/L/and-so-on
classes, however no code has been implemented to handle these specific
varitations of each CPU class, and so no m68k_feature was mde to
distinguish them that way.
Signed-off-by: Lucien Murray-Pitts
---
Notes:
v1->v2
- Submitt
.
Signed-off-by: Lucien Murray-Pitts
---
Notes:
v1->v2
- removed my superfluous braces
- slightly amended the commit message
v2->v3
- removed my incorrect use of code block in a switch
target/m68k/gdbstub.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
.
Signed-off-by: Lucien Murray-Pitts
---
Notes:
v1->v2
- remove superfluous braces from my additional code
- slightly amended the commit message
target/m68k/gdbstub.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/target/m68k/gdbstub.c b/target/m68k/gdbstu
On Fri, Jun 07, 2019 at 01:58:05AM +0200, Aleksandar Markovic wrote:
> On Jun 7, 2019 1:42 AM, "Lucien Murray-Pitts"
> wrote:
> >
> > Altering all comments in target/m68k to match Qemu coding styles so that
> future
> > patches wont fail due to style breaches.
Altering all comments in target/m68k to match Qemu coding styles so that future
patches wont fail due to style breaches.
Signed-off-by: Lucien Murray-Pitts
---
Notes:
v1->v2
- incorrectly made split-single line comments multiple single lines
- added corrections for /** comments
Altering all comments in target/m68k to match Qemu coding styles so that future
patches wont fail due to style breaches.
Signed-off-by: Lucien Murray-Pitts
---
target/m68k/cpu.c| 4 +-
target/m68k/cpu.h| 30 --
target/m68k/fpu_helper.c | 6 +-
target/m68k/gdbstub.c
Altering all comments in target/m68k to match Qemu coding styles so that future
patches wont fail due to style breaches.
Signed-off-by: Lucien Murray-Pitts
---
target/m68k/cpu.c| 4 +-
target/m68k/cpu.h| 30 --
target/m68k/fpu_helper.c | 6 +-
target/m68k/gdbstub.c
The register request via gdbstub would return the SR part
which contains the Trace/Master/IRQ state flags, but
would be missing the CR (Condition Register) state bits.
This fix adds this support by merging them in the m68k
specific gdbstub handler
Signed-off-by: Lucien Murray-Pitts
---
target
A regression that was introduced, with the refactor to TranslatorOps,
drops two lines that update the PC when single-stepping is being performed.
( short commit 11ab74b )
This patch resolves that issue.
Signed-off-by: Lucien Murray-Pitts
---
target/m68k/translate.c | 2 ++
1 file changed, 2
exactly what differentiates each class. (m68k_features)
The movec instruction when accessing these shadow registers
in some configurations should issue a TRAP. This patch does not
add this funcitonality to the helpers.
Signed-off-by: Lucien Murray-Pitts
---
target/m68k/cpu.c| 1 +
target
expected from standard debuggers.
* vCont;c/s
** Step/Continue all threads
* vCont;c/s:[pX.]Y
** Step/Continue optional process X, thread Y
* vCont;C##/S##:[pX.]Y
** Step/Continue with signal ## on optional process X, thread Y
* If X or Y are -1 then it applies the action to all proces
- Step/Continue all threads
vCont;c/s:[pX.]Y - Step/Continue optional process X, thread Y
vCont;C##/S##:[pX.]Y - Step/Continue with signal ## on optional process
X, thread Y
* If X or Y are -1 then it applies the action to all processes/threads.
Signed-off-by:
32 matches
Mail list logo
