On 8 June 2015 at 16:50, Liviu Ionescu wrote:
>
>> On 08 Jun 2015, at 18:21, Peter Maydell wrote:
>>
>> ... 'readline' mode and 'control' mode.
>> The latter won't have the cursor-editing, but it's the QMP
>> protocol monitor (intended for controlling QEMU from other programs,
>> different syntax
> On 08 Jun 2015, at 18:21, Peter Maydell wrote:
>
> ... 'readline' mode and 'control' mode.
> The latter won't have the cursor-editing, but it's the QMP
> protocol monitor (intended for controlling QEMU from other programs,
> different syntax to the human monitor protocol).
> -chardev stdio,id
On 8 June 2015 at 15:54, Liviu Ionescu wrote:
>
>> On 08 Jun 2015, at 17:10, Peter Maydell wrote:
>>
>> ... You can always turn off the readline
>> feature if you don't want it.
>
> how? with the existing manual I could not figure out how to do it.
Hmm, you're right, we have 'readline' mode and
> On 08 Jun 2015, at 17:10, Peter Maydell wrote:
>
> ... You can always turn off the readline
> feature if you don't want it.
how? with the existing manual I could not figure out how to do it.
the only option that worked for me was '-monitor stdio'. most of other option
combinations just term
On 8 June 2015 at 15:04, Liviu Ionescu wrote:
> as I said, probably the qemu readline implementation assumes all
> consoles in the world are vt100 terminals, which is obviously too
> optimistic, a notable exception being exactly the Eclipse console.
Well, readline assumes that you have an interac
> On 08 Jun 2015, at 13:56, Peter Maydell wrote:
>
> ... Is this verbosity also the thing printing the line with all
> the escape characters in it?
no, after some more debugging I identified the place where these chars are
displayed: in the readline.c file:
/* update the displayed command li
> On 08 Jun 2015, at 14:05, Liviu Ionescu wrote:
>
>
>> On 08 Jun 2015, at 13:56, Peter Maydell wrote:
>>
>> Is this verbosity also the thing printing the line with all
>> the escape characters in it?
>
> I don't think so, the code added at around line 4135 in monitor.c looks like:
>
> #if
> On 08 Jun 2015, at 13:56, Peter Maydell wrote:
>
> Is this verbosity also the thing printing the line with all
> the escape characters in it?
I don't think so, the code added at around line 4135 in monitor.c looks like:
#if defined(CONFIG_VERBOSE)
if (verbosity_level >= VERBOSITY_COM
On 8 June 2015 at 11:51, Liviu Ionescu wrote:
>> On 08 Jun 2015, at 12:17, Peter Maydell wrote:
>> What is printing the "Execute ..." line? A quick grep of the
>> sources suggests it's not QEMU.
>
> it is part of the increased verbosity needed by my use case.
> for this I added -verbose, which ca
> On 08 Jun 2015, at 12:17, Peter Maydell wrote:
>
> On 8 June 2015 at 09:46, Liviu Ionescu wrote:
>>
>> Q: is there any simple way to get rid of them?
>
> This is probably the readline support (so you can do cursor
> editing of command lines). You can turn that off, though I forget
> the syn
On 8 June 2015 at 09:46, Liviu Ionescu wrote:
>
>> On 07 Jun 2015, at 01:11, Peter Maydell wrote:
>>
>> One handy debugging tool for tracking down this kind of thing is to
>> use the QEMU monitor's "info mtree" command,
>
> I added "-monitor stdio" to the Eclipse configuration used to start the
> On 07 Jun 2015, at 01:11, Peter Maydell wrote:
>
> One handy debugging tool for tracking down this kind of thing is to
> use the QEMU monitor's "info mtree" command,
I added "-monitor stdio" to the Eclipse configuration used to start the
emulator, and I got access to the monitor, but apparen
> On 07 Jun 2015, at 01:11, Peter Maydell wrote:
>
> ...
> So, there's two odd things here:
> (1) why ... a chunk ...
> (2) ... size in bytes ... flash_size_kb is what the name suggests, you're
> trying to map a region that's a lot smaller than you want.
right, this was a bug in my code.
t
On 6 June 2015 at 20:01, Liviu Ionescu wrote:
> while working on the STM32 emulation, I noticed a problem related to the
> specific memory layout of STM32 devices.
>
> these devices have the FLASH region at 0x0800 instead of 0x, and
> since the specs require the presence of the reset
while working on the STM32 emulation, I noticed a problem related to the
specific memory layout of STM32 devices.
these devices have the FLASH region at 0x0800 instead of 0x, and
since the specs require the presence of the reset vector at 0x0, there is an
internal alias of the entir
15 matches
Mail list logo
