Copying Andreas in case he has further advice.
Peter Crosthwaite writes:
> On Wed, Jun 3, 2015 at 5:31 AM, Liviu Ionescu wrote:
>>
>>> On 01 Jun 2015, at 23:36, Liviu Ionescu wrote:
>>>
>>> ... I just pushed a preliminary version where all STM32 MCUs and
>>> STM32 related boards use the new fr
On Wed, Jun 3, 2015 at 5:31 AM, Liviu Ionescu wrote:
>
>> On 01 Jun 2015, at 23:36, Liviu Ionescu wrote:
>>
>> ... I just pushed a preliminary version where all STM32 MCUs and STM32
>> related boards use the new framework.
>
> please disregard the current version, I'm already re-working the code
> On 01 Jun 2015, at 23:36, Liviu Ionescu wrote:
>
> ... I just pushed a preliminary version where all STM32 MCUs and STM32
> related boards use the new framework.
please disregard the current version, I'm already re-working the code to be
more compliant with the (quite complicated) object in
On Tue, Jun 2, 2015 at 4:01 AM, Liviu Ionescu wrote:
>
>> On 02 Jun 2015, at 13:42, Peter Maydell wrote:
>>
>> On 2 June 2015 at 11:32, Peter Crosthwaite
>> wrote:
>>> On Tue, Jun 2, 2015 at 3:15 AM, Liviu Ionescu wrote:
similar content is also present in Table B3-1 "ARMv7-M address map",
> On 02 Jun 2015, at 13:42, Peter Maydell wrote:
>
> On 2 June 2015 at 11:32, Peter Crosthwaite
> wrote:
>> On Tue, Jun 2, 2015 at 3:15 AM, Liviu Ionescu wrote:
>>> similar content is also present in Table B3-1 "ARMv7-M address map", in ARM
>>> DDI 0403D, "ARMv7-M Architecture Reference Manu
On 2 June 2015 at 11:32, Peter Crosthwaite wrote:
> On Tue, Jun 2, 2015 at 3:15 AM, Liviu Ionescu wrote:
>> similar content is also present in Table B3-1 "ARMv7-M address map", in ARM
>> DDI 0403D, "ARMv7-M Architecture Reference Manual".
>>
>> 0x-0x1FFF | Code | Typically ROM or fla
On Tue, Jun 2, 2015 at 3:15 AM, Liviu Ionescu wrote:
>
>> On 01 Jun 2015, at 01:59, Liviu Ionescu wrote:
>>
>>
>>> On 01 Jun 2015, at 01:10, Peter Crosthwaite
>>> wrote:
>>>
>>> ... If
>>> there is an ARM doc specifying this (separate from ARM ARM M profile
>>> doc) then let me know, cause this
> On 01 Jun 2015, at 01:59, Liviu Ionescu wrote:
>
>
>> On 01 Jun 2015, at 01:10, Peter Crosthwaite
>> wrote:
>>
>> ... If
>> there is an ARM doc specifying this (separate from ARM ARM M profile
>> doc) then let me know, cause this will very easily justify the change
>> you just made. That s
> On 01 Jun 2015, at 03:14, Liviu Ionescu wrote:
>
>> I have added your git branch to my to-review queue. I'll have a look
>> over next few days.
>
> thank you, any comments/suggestions are highly appreciated, but, again, as it
> is now, it is preliminary work, only STM32-H103 and STM32F103RB
> On 01 Jun 2015, at 12:16, Peter Crosthwaite
> wrote:
>
> If all we are worried about the name of -kernel can we give it an alias?
in my initial implementation I aliased it to --image, but I received a strong
opposition on the list, for polluting the command line, and I did not insist.
I'd
On 01/06/2015 11:23, Liviu Ionescu wrote:
> however, the desired behaviour is
>
> - the -pflash specifies a file path, no need for size
> - when emulation starts, if -pflash is used and the file exists, its content
> is loaded as initial flash content
> - when emulation ends, if -pflash is used
> On 01 Jun 2015, at 11:53, Paolo Bonzini wrote:
>
>> if -kernel is not used, but -gdb is used, memory content is loaded by the
>> gdb client, as for any debug session using a jtag/swd.
>
> This can simply be the case where -pflash is not specified. The flash
> is then initialized with zeros.
On 1 June 2015 at 10:16, Peter Crosthwaite wrote:
> You still want to be able to use elf using a proper elf load process
> even if the target memory is a persistent flash. These micros tend to
> have small memory-mapped executable flashes so from a debug and
> programming model that really look an
On Mon, Jun 1, 2015 at 1:53 AM, Paolo Bonzini wrote:
>
>
> On 01/06/2015 10:30, Liviu Ionescu wrote:
>> if -kernel is present, the memory content is loaded from the external image
>> (which is not at all a kernel, as the confusing option implies).
>
> In this case, you should use -pflash, not -ke
On 01/06/2015 10:30, Liviu Ionescu wrote:
> if -kernel is present, the memory content is loaded from the external image
> (which is not at all a kernel, as the confusing option implies).
In this case, you should use -pflash, not -kernel; it should be a binary
file, not ELF. -pflash does not ha
> On 01 Jun 2015, at 10:19, Paolo Bonzini wrote:
>
> Regarding flash, I'm still curious about some questions I have...
>
> 1) who initializes flash contents?
the flash region is created with
memory_region_init_ram()
memory_region_set_readonly()
so it behaves like ram, but prevents writes.
On 31/05/2015 16:05, Liviu Ionescu wrote:
> I followed your advice and I ended up with the following:
>
> - I added a new type "cortexm-mcu" that I use as parent for all Cortex-M MCU
> objects (like "STM32F103RB")
>
> - I added the following properties to this type:
>
> cortexm-mcu.flas
> On 01 Jun 2015, at 05:26, Peter Crosthwaite
> wrote:
>
> to see a developers' changes ... do this (bash):
>
> git diff $(git merge-base target-branch master) target-branch
:-)
I was a 'unix typist' for more than 25 years, now I'm getting old and getting
lazy. in 2009 I switched to Ma
On Sun, May 31, 2015 at 5:14 PM, Liviu Ionescu wrote:
>
>> On 01 Jun 2015, at 02:44, Peter Crosthwaite
>> wrote:
>>
>> ... I would stay away from Stellaris as much as possible for this
>> framework type stuff as it is a legacy pre-qdev machine.
>
> ok
>
>> Alistair
>> straightened out many of th
> On 01 Jun 2015, at 02:44, Peter Crosthwaite
> wrote:
>
> ... I would stay away from Stellaris as much as possible for this
> framework type stuff as it is a legacy pre-qdev machine.
ok
> Alistair
> straightened out many of the mistakes in Stellaris in the STM32F work
> which is a much bette
On Sun, May 31, 2015 at 3:59 PM, Liviu Ionescu wrote:
>
>> On 01 Jun 2015, at 01:10, Peter Crosthwaite
>> wrote:
>>
>> ... If
>> there is an ARM doc specifying this (separate from ARM ARM M profile
>> doc) then let me know, cause this will very easily justify the change
>> you just made. That sa
> On 01 Jun 2015, at 01:10, Peter Crosthwaite
> wrote:
>
> ... If
> there is an ARM doc specifying this (separate from ARM ARM M profile
> doc) then let me know, cause this will very easily justify the change
> you just made. That said, a critical mass of manufacturers doing the
> same thing ma
> On 01 Jun 2015, at 01:27, Peter Crosthwaite
> wrote:
>
>> my branch is publicly available from SourceForge
>> (https://sourceforge.net/p/gnuarmeclipse/qemu/ci/gnuarmeclipse-dev/tree/),
>
> I got 404d on that.
hmmm... SourceForge is less and less reliable...
> Do you have a github or a git
> -Original Message-
> From: Liviu Ionescu [mailto:i...@livius.net]
> Sent: Sunday, May 31, 2015 3:24 PM
> To: Peter Crosthwaite
> Cc: Peter Maydell; Igor Mammedov; QEMU Developers; Alistair Francis
> Subject: Re: [Qemu-devel] [RFC] extensions to the -m memory option
> On 01 Jun 2015, at 01:10, Peter Crosthwaite
> wrote:
>
> I think we are getting close to the point where we need to see some
> WIP code to get a better idea. Want to send what you have so far as an
> RFC patchset?
my branch is publicly available from SourceForge
(https://sourceforge.net/p/g
On Sun, May 31, 2015 at 1:59 PM, Liviu Ionescu wrote:
>
>> On 31 May 2015, at 21:45, Peter Crosthwaite
>> wrote:
>>
>> On Sun, May 31, 2015 at 7:05 AM, Liviu Ionescu wrote:
>>>
On 30 May 2015, at 12:39, Peter Crosthwaite
wrote:
On Fri, May 29, 2015 at 2:49 PM, Liviu Ionesc
> On 31 May 2015, at 21:45, Peter Crosthwaite
> wrote:
>
> On Sun, May 31, 2015 at 7:05 AM, Liviu Ionescu wrote:
>>
>>> On 30 May 2015, at 12:39, Peter Crosthwaite
>>> wrote:
>>>
>>> On Fri, May 29, 2015 at 2:49 PM, Liviu Ionescu wrote:
however the question remains: in this nicely la
On Sun, May 31, 2015 at 7:05 AM, Liviu Ionescu wrote:
>
>> On 30 May 2015, at 12:39, Peter Crosthwaite
>> wrote:
>>
>> On Fri, May 29, 2015 at 2:49 PM, Liviu Ionescu wrote:
>>> however the question remains: in this nicely layered model, what command
>>> line options would be more appropriate t
> On 30 May 2015, at 12:39, Peter Crosthwaite
> wrote:
>
> On Fri, May 29, 2015 at 2:49 PM, Liviu Ionescu wrote:
>> however the question remains: in this nicely layered model, what command
>> line options would be more appropriate to overwrite the MCU hard-wired
>> ram/flash sizes?
>>
>
>
On Sat, May 30, 2015 at 3:32 AM, Paolo Bonzini wrote:
>
>
> On 30/05/2015 11:55, Peter Crosthwaite wrote:
>> I think the same is true of NOR.
>
> NOR is sized according to the capacity of its backing file, at least in
> the PC case.
>
So that might be the exception to the rule. I assume that is t
On 30/05/2015 11:55, Peter Crosthwaite wrote:
> I think the same is true of NOR.
NOR is sized according to the capacity of its backing file, at least in
the PC case.
Paolo
On Fri, May 29, 2015 at 4:08 AM, Paolo Bonzini wrote:
>
>
> On 29/05/2015 00:11, Liviu Ionescu wrote:
>> for more flexibility, in the new Cortex-M implementation I'm working on, I
>> can overwrite the vendor defined MCU internal SRAM size by using:
>>
>> -m sizeK
>>
>> I'm trying to find a
On Fri, May 29, 2015 at 2:49 PM, Liviu Ionescu wrote:
>
>> On 30 May 2015, at 00:40, Peter Maydell wrote:
>>
>> ... Whether you call it
>> an SoC or an MCU, the key point is that there's a level of
>> abstraction, a container, between the CPU itself and the board.
>> That's where the RAM and flas
> On 30 May 2015, at 00:40, Peter Maydell wrote:
>
> ... Whether you call it
> an SoC or an MCU, the key point is that there's a level of
> abstraction, a container, between the CPU itself and the board.
> That's where the RAM and flash usually live and that's where
> the properties to control t
On 29 May 2015 at 21:26, Liviu Ionescu wrote:
>> On 29 May 2015, at 22:32, Peter Maydell wrote:
>> RAM and flash size is not a property of the CPU -- the M3 itself
>> has no builtin memory. RAM and flash are external to the CPU and
>> are part of the SoC, so the CPU would be the wrong place to sp
> On 29 May 2015, at 23:15, Paolo Bonzini wrote:
>
>> ... But then in the common case I suspect you want your flash to be
>> non-zero at startup?
nope. I just want a method to adjust the size of the internal ram & flash,
existing inside the MCU, sizes currently hard-wired in the QEMU definit
> On 29 May 2015, at 22:32, Peter Maydell wrote:
>
> On 29 May 2015 at 20:22, Liviu Ionescu wrote:
>> -machine? in other words board? the ram-size is not a characteristic
>> of the board, Cortex-M MCUs have both RAM & flash internally, so if
>> --memory is not ok, probably ram & flash should be
On 29/05/2015 22:13, Liviu Ionescu wrote:
>>> You can use -drive
>>> if=mtd,snapshot=on,file=null-co://,file.size=128K to start QEMU
>>> with a zero 128K NOR flash.
> did someone else have a faint thought that:
>
> - the above syntax might be a bit too complicated or non intuitive?
Sure, this c
> On 29 May 2015, at 22:33, Paolo Bonzini wrote:
>
> On 29/05/2015 21:27, Liviu Ionescu wrote:
>>> If the flash is persistent, it should be tied to either "-pflash"
>>> (NOR) or "-mtd" (NAND). Just using a different image then
>>> results in resizing the flash.
>>
>> I did not try the resizing
On 29/05/2015 21:27, Liviu Ionescu wrote:
>> If the flash is persistent, it should be tied to either "-pflash"
>> (NOR) or "-mtd" (NAND). Just using a different image then
>> results in resizing the flash.
>
> I did not try the resizing mechanism, but I don't think it is
> appropriate, one of my
On 29 May 2015 at 20:22, Liviu Ionescu wrote:
> -machine? in other words board? the ram-size is not a characteristic
> of the board, Cortex-M MCUs have both RAM & flash internally, so if
> --memory is not ok, probably ram & flash should be an extensions
> of --cpu?
RAM and flash size is not a pro
> On 29 May 2015, at 14:08, Paolo Bonzini wrote:
>
>
>
> On 29/05/2015 00:11, Liviu Ionescu wrote:
>> for more flexibility, in the new Cortex-M implementation I'm working on, I
>> can overwrite the vendor defined MCU internal SRAM size by using:
>>
>> -m sizeK
>>
>> I'm trying to find
> On 29 May 2015, at 12:11, Igor Mammedov wrote:
>
> On Fri, 29 May 2015 01:11:30 +0300
> Liviu Ionescu wrote:
>
>> for more flexibility, in the new Cortex-M implementation I'm working on, I
>> can overwrite the vendor defined MCU internal SRAM size by using:
>>
>> -m sizeK
>>
>> I'm
On 29/05/2015 00:11, Liviu Ionescu wrote:
> for more flexibility, in the new Cortex-M implementation I'm working on, I
> can overwrite the vendor defined MCU internal SRAM size by using:
>
> -m sizeK
>
> I'm trying to find a way to also overwrite the internal flash size and the
> first
On Fri, 29 May 2015 01:11:30 +0300
Liviu Ionescu wrote:
> for more flexibility, in the new Cortex-M implementation I'm working on, I
> can overwrite the vendor defined MCU internal SRAM size by using:
>
> -m sizeK
>
> I'm trying to find a way to also overwrite the internal flash size an
for more flexibility, in the new Cortex-M implementation I'm working on, I can
overwrite the vendor defined MCU internal SRAM size by using:
-m sizeK
I'm trying to find a way to also overwrite the internal flash size and the
first idea I had was to extend the "-m" command like:
46 matches
Mail list logo
