> > *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
> 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:
> >
> 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
> 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
> > 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
> >> 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
> > There is a declarative solution for this that I know of, a C++ class
> > definition ;-)
>
> So what's the reason not to go with one of the object-oriented,
> C-compatible languages GCC supports, like C++ or Objective-C/C++?
> (Objective-C has native reflection capabilities fwiw.)
I'd avoid Ob
> If compiled with CONFIG_FDT, allow user to specify a device tree file using
> the -dtb argument. If the machine supports it then the dtb will be loaded
> into memory and passed to the kernel on boot.
Adding annother machine feels wrong. Why does the board specific code need to
know about this
> There is a lot of configuration in the .dts file that the QEMU user may
> want to manipulate; particularly when using QEMU for testing embedded
> platforms. The direction I want to go is to select the machine model based
> on the top level DT compatible property (making -M optional), and then
> a
> We could also just change machine->init() and pass the dtb in there. In a
> QOM world these would become machine device properties anyways.
>
> machine->init(ram_size, boot_devices,
> kernel_filename, kernel_cmdline, initrd_filename,
> cpu_model);
>
> Essentially we should
> This is an RFC for a suite of Device models and a machine model for the
> Xilinx Zynq-7000 Extensible Processing Platform:
>
> http://www.xilinx.com/products/silicon-devices/epp/zynq-7000/index.htm
I don't see any documentation on that page. Are technical docs available?
It's much easier to rev
> Implemented cadence Triple Timer Counter (TCC)
It looks like you're implementing a periodic timer as sequence of chained
oneshot timers. This is a bad idea. In qemu interrupt latency may be high,
so you're likely to suffer from significant time skew.
Paul
> diff --git a/hw/versatilepb.c b/hw/versatilepb.c
> index 6e28e78..e42d845 100644
> --- a/hw/versatilepb.c
> +++ b/hw/versatilepb.c
> @@ -313,12 +313,14 @@ static void versatile_init(ram_addr_t ram_size,
> /* 0x101f3000 UART2. */
> /* 0x101f4000 SSPI. */
>
> -versatile_binfo.ram_
> > > Implemented cadence Triple Timer Counter (TCC)
> >
> > It looks like you're implementing a periodic timer as sequence of chained
> > oneshot timers. This is a bad idea. In qemu interrupt latency may be
> > high,
> > so you're likely to suffer from significant time skew.
> >
> Ok, I could
> > > + arm_load_kernel(env, &versatile_binfo);
> > > + }
> > >
> > > }
> >
> > This should be using the new object you just added.
>
> Yes I agree. There is another question tho that if this approach is to be
> considered, should this call to arm_load_kernel be removed from the
> > I suspect we want to replace the arm_load_kernel call with an
> > arm_linux_loader device with appropriate properties.
>
> Ok, so does this mean the machine model would still explicitly instantiate
> the bootloader device?
Yes. Bootloaders inherently have machine specific knowledge. They n
> 2012/2/8 Paul Brook
>
> > > > I suspect we want to replace the arm_load_kernel call with an
> > > > arm_linux_loader device with appropriate properties.
> > >
> > > Ok, so does this mean the machine model would still explicitly
>
> > - When are interrupts raised. You mention a user specified match value.
> > Do we also get an interrupt on wraparound?
>
> Yes, an interrupts occur on wrap around of the 16 bit timer value. There
> are three match registers which correspond to three more
> (separately maskable) interrupts w
> So if we consider this bootloader a device and its -dtb argument a property
> of that device, then what you are implying is that every device property of
> every device in a machine must be managed by the machine model? Isn't the
> dynamic machine model work that is in progress is trying to get a
> Its the other problem I am more worried about, i.e. when I -device
> instantiate my bootloader with an existing machine how do I get my ram_size
> and board_ID? The no machine opts for devices policy makes this impossible
> such that I would have to pass in board_id and ram_size to
> the boot-loa
> So here are some of the problems im trying to solve with the bootloader:
>
> Smp bootstrap secondary CPUs while loading an elf (currently elfs will be
> assumed to be not kernels).
> Change the kernel, initrd and dtb load address on the command line.
> Use my own SMP secondary bootloop.
>
> My
> Ok, that sounds more workable :). So i would add my initrd_addr property to
> the bootloader as a qdev prop as I suggested before, then something like:
>
> qemu-system-arm -M verstailepb -property
> /foo/bar/arm_linux_loader.0,initrd_addr=0x1000
Yes.
There are various implementation/syntax
> The purpose of the "helper" option for "-net tap" isn't obvious
> based on its name. This patch changes the option name to
> "bridgehelper" to make its purpose more self-documenting.
>
> With this patch, a typical invocation will be similar to one of the
> following (where the default bridge is
> > starting your own toy kernel is a fun thing to do and there are many
> > tutorials out there on how to do it. Unfortunately when one wants to
> > write a kernel in 64bit it becomes much harder because one can't
> > compile 64bit code as elf32 image and converting a elf64 image to
> > elf32 form
> +static void i8042_isa_mouse_fake_event(void *opaque, int n, int level)
> {
> ISADevice *dev = opaque;
> KBDState *s = &(DO_UPCAST(ISAKBDState, dev, dev)->kbd);
>
> -ps2_mouse_fake_event(s->mouse);
> +if (level) {
> +ps2_mouse_fake_event(s->mouse);
> +}
> }
>...
> /* multicore boards that use the default secondary core boot functions
> * can ignore these two function calls. If the default functions won't
> * work, then write_secondary_boot() should write a suitable blob of
> * code mimicing the secondary CPU startup process used by the b
> >> What about naming the problem instead:
> >>
> >> /* Comparison with IOCTL macros on 32-bit hosts requires unsigned. */
> >
> > Just once, it would be nice to post something to this list and get a
> > substantive comment _before_ the bitching about minutiae.
> >
> > Oh, and it's not just 32-
> The ARM devboard models (vexpress-a9, realview, versatilepb, etc)
> were accidentally trying to set one of the arm_sysctl properties
> after device init. This has now become a fatal error; set the property
> before device init where it should be done instead.
>
> Signed-off-by: Peter Maydell
>
> the results of readelf -l hello are as follow:
> program headers:
> TYPE offsetvirtAddr phyAddr FileSiz
>MemSiz LOAD 0x0540x4000 0x4000 0x02bf0
> 0x02bf0
Clearly not a linux binary. Those have file offsets and vi
> Am 09.02.2012 13:15, schrieb Paul Brook:
> >> The ARM devboard models (vexpress-a9, realview, versatilepb, etc)
> >> were accidentally trying to set one of the arm_sysctl properties
> >> after device init. This has now become a fatal error; set the property
&g
> Paul Brook writes:
> >> > starting your own toy kernel is a fun thing to do and there are many
> >> > tutorials out there on how to do it. Unfortunately when one wants to
> >> > write a kernel in 64bit it becomes much harder because one can't
> > "objcopy -I elf64-x86-64 -O elf32-i386 64.elf 32.elf" worked for me.
> > Relocations get a bit confused, but you shouldn't have relocations in
> > your multiboot images to start with.
>
> Why no relocations? Isn't exactly that the advantage of building an elf
> image, that you can build a relo
Fix format type mismatches in do_brk debug printfs.
Signed-off-by: Paul Brook
---
linux-user/syscall.c | 16 +---
1 files changed, 9 insertions(+), 7 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index ee8899e..ee32089 100644
--- a/linux-user/syscall.c
libcacard is only used by system emulation.
Only define libcacard_libs/cflags once.
Signed-off-by: Paul Brook
---
configure | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/configure b/configure
index 763db24..faa65a8 100755
--- a/configure
+++ b/configure
ribly if both newfstatat and stat64 are defined,
so also add a check for that.
Signed-off-by: Paul Brook
---
linux-user/syscall.c | 12 +++-
1 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/linux-user/syscall.c b/linux-user/syscall.c
index ee32089..6e0999b 100644
--- a/
> > On ARM Linux glibc provides a makecontext() that always fails ENOSYS,
> > so our configure test thinks there is makecontext support but when we
> > try to use it for coroutines it will fail and we abort.
> >
> > I have a workaround in qemu-linaro that just forces the makecontext
> > test to fa
> > I'd rather not. If at all possible we should avoid runtime tests. Even
> > for "native" systems they generally give the wrong answer as the machine
> > you're building on often isn't the one you will be running on. If we
> > know arm hosts are broken then that's what we should test for in
>
> There is no reason why the minimum timeout should be 1sec, it could
> easily be 1h and we would save lots of cpu cycles.
No.
The reason we have this is because there are bits of code that rely on
polling. IIRC slirp and the floppy DMA engine were the main culprits.
qemu_calculate_timeout is
> Add a definition of a Cortex-A15 CPU. Note that for the moment we do
> not implement any of:
> * Large Physical Address Extensions (LPAE)
> * Virtualization Extensions
> * Generic Timer
Are there feature bits that the guest can check before blindly using them? I
assume for at least LPAE and
> >> Add a definition of a Cortex-A15 CPU. Note that for the moment we do
> >> not implement any of:
> >> * Large Physical Address Extensions (LPAE)
> >> * Virtualization Extensions
> >> * Generic Timer
> >
> > Are there feature bits that the guest can check before blindly using
> > them? I as
> I do hope we find a solution to deal with n displays in the future. I
> consider that a post-QOM topic and maybe Anthony's planned DisplayState
> refactoring helps with that.
It used to work. Not particularly pretty or user friendly, but definitely
functional. I put a fair amount of effort in
> On 02/10/2012 01:26 AM, Paul Brook wrote:
> > The reason we have this is because there are bits of code that rely on
> > polling. IIRC slirp and the floppy DMA engine were the main culprits.
> > qemu_calculate_timeout is an ugly hack to poll at least once a second,
>
> >> > At least the floppy DMA engine is fine with it, it uses idle bottom
> >> > halves (which are a hack and could be replaced by timers, but that's
> >> > not relevant now).
> >
> > I thought idle bottom halves were one of the things that made this timout
> > necessary. How else are they go
> Changes which require knowledge of a specific device model are often not
> trivial to anyone who hasn't studied the specification. So if the patch
> requires background knowledge of ppc ABI, hardware registers, etc then
> it's usually best sent to relevant subsystem maintainer (see
> ./MAINTAINE
> > Make MIPS N32 be a variant of mips64, rather than a new architecture in
> > its own right. This matches how sparc/ppc work, and makes TARGET_MIPS64
> > the right thing to check for a 64-bit mips core.
> >
> > As side-effect of this is that linux-user/mipsn32 gets merged into
> > linux-user/mi
> There's two slightly different scenarios to consider here:
>
> i) User specifies command line options that cannot possibly work.
> => Ideally, yeah, we should just provide an understandable error message
> and exit with error code.
>
> ii) Some tracing of mine indicates QEMU has a highly dynami
> +#ifdef CONFIG_SLIRP
> +static inline void slirp_update_timeout(uint32_t *timeout)
> +{
> +*timeout = MIN(1000, *timeout);
> +}
> +#else
> +static inline void slirp_update_timeout(uint32_t *timeout) { }
> +#endif
Shouldn't we be testing whether slirp is actually in use? I doubt many people
> I am running this tiny OS on QEMU then using GDB to connect it.
>
> I want to follow task 1 after the forking, but it seems that GDB
> stick with task 0 and cannot follow task 1 even I do `set follow-fork-mode
> child`.
You have exactly one CPU. That's what the qemu GDB stub exposes. Multipl
> Am 11.02.2012 00:25, schrieb Paul Brook:
> >> ii) Some tracing of mine indicates QEMU has a highly dynamic memory
> >> usage during runtime, be it due to network layer, block layer or
> >> whatever exactly.
> >
> > We do? Significant compared to
> +static void cadence_timer_sync(CadenceTimerState *s)
> +{
>...
> +r = (int64_t)cadence_timer_get_steps(s, s->cpu_time - old_time);
> +x = (int64_t)s->reg_value + ((s->reg_count & COUNTER_CTRL_DEC) ? -r :
> r); +
> +for (i = 0; i < 3; ++i) {
> +if (is_between((int64_t)s->reg_m
nt to select in case timeout is the
> maximum value;
>
> Signed-off-by: Stefano Stabellini
Acked-by: Paul Brook
> > abort can create core dumps or start a debugger which is
> > useful for me and maybe other developers, too.
>
> I consider abort() on OOM somewhat eccentric. abort() is for
> programming errors. Resource shortage is an environmental error that is
> sometimes (but not always) caused by a prog
> > In a nutshell, I don't know what a SHPC is (nor OSHP), so I'm looking
> > for an additional Ack.
>
> No problem, I'll get an Ack :)
> Meanwhile - here's a summary, as far as I understand it.
>
> Originally PCI SIG only defined the electrical
> and mechanical requirements from hotplug, no stan
> This series of patches implements coroutines method with
> sigaltstack.
>
> The flow of creation and management of the coroutines is
> quite similar to the coroutine-ucontext.c. The way to use
> sigaltstack to achieve the needed stack manipulation is
> done in a way quite similar to the GNU Port
> > The only way to handle this rebustly is to pre-allocate all the memory
> > we're ever going to need[1]. I don't see that happening.
>
> FWIW, users can already opt-in to pre-allocation if running KVM enabled
> QEMU
>
>-mem-path /dev/shm -mem-prealloc (or /dev/hugepages more usefully)
> > > Now an OS can have a standard driver and use it
> > > to activate hotplug functionality. This is OS hotplug (OSHP).
> >
> > So presumably this will work on targets that don't have ACPI?
> > Assuming a competent guest OS of course. Have you tested this?
>
> This being the qemu side of thing
> i see an error message has been added, which is great (i killed a
> couple hours of $%!@ until i noticed the truncated length was *exactly
> 32* bytes; silent truncation), but it would really be great if this
> restriction could be lifted, or at least mitigated by expanding the
> field some.
>
>
> > 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
> 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...
> '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
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
> 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
>
> > > 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
> 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
> @@ -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
> 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
> 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
> 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
> +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
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
> @@ -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.
> > 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,
> 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
> +#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
> 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 */
> >> +
> >> "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
> I'm going to apply this series quickly and will start running 'make
> check-quick' as part a sniff test before pushing patches.
>
> I'd like to request that all maintainers/submaintainers do the same and
> that everyone contributes unit tests to this target.
>
> The general rules for 'make chec
> From: Stuart Yoder
>
> Previous check in configure's endian test was to determine if
> this is a cross-compile build by testing whether --cross-prefix
> was used. This does not work for cross build environments
> like Yocto that may set CC instead of --cross-prefix.
>
> Instead, test whether
> Contrary to Paul's argument QEMU does not only support a fixed
> set of known host architectures, but also unknown hosts (via TCI).
> For those, there remains a small chance that they are big endian
> and that they get the wrong endianness now. TCI is still experimental,
> so I don't care too muc
> The internal CPU feature flags were only ever set in
> cpu_reset_model_id(). Therefore move their initialization into
> ARMCPUClass. We might want to tweak them in the future though (e.g.,
> -cpu cortex-r4,+fpu), so keep a copy in ARMCPU. This in turn means we
> need to infer features for both AR
> For now set them in the reset function.
> +/* TODO Move these into arm_cpu_initfn() once no longer zeroed above.*/
> +memcpy(env->cp15.c0_c1, klass->cp15.c0_c1, 8 * sizeof(uint32_t));
> +memcpy(env->cp15.c0_c2, klass->cp15.c0_c2, 8 * sizeof(uint32_t)); +
Why bother copying them into
> Option two looks kind of nice, but I'm not sure whether it would
> actually work. I think you could do 95% of what you need for a
> different CPU that way (lots of properties for "value of ID_MMFR1",
> "value of "ID_MMFR2", "reset value of SCTLR", etc etc, plus properties
> for all our existing A
> > If we're going to use the class hierachy to implement functionality then
> > there are other candidates. Given the primary purpose of QOM is [IMO]
> > to handle interaction between devices, the external interface exposed by
> > the core seems like a better candidate for subclassing. i.e.
> >
> @@ -682,10 +733,18 @@ void virtio_init_pci(VirtIOPCIProxy *proxy,
> VirtIODevice *vdev) if (size & (size-1))
> size = 1 << qemu_fls(size);
>
> +proxy->bar0_mask = size - 1;
You'll get better performance if you use page-sized mappings. You're already
creating a mapping bigger tha
> Rather than key off an ID you could also just break
> implementation-specific functionality out into a set of interfaces you
> implement/override as part of the objects' initialization. Same ends, and
> still fits the model pretty nicely, assuming the functionality is all
> derivable from the com
> Make an ARMCPUClass that maps to the existing ARM support. Do *not* expose
> all of the different features as properties. Make ARMCPUClass abstract.
>
> Subclass ARMCPUClass for specific models, set default flags to implement
> the necessary logic. Expose tunables on a case-by-case basis (if
> >> Yes, I think I'd agree there. So should we just have an init function
> >> that provides the implementation-specific cp15 registers based on the
> >> value provided in the QOM property for the main ID register?
> >
> > Something like that, yes. I'm not convinced the main ID register is the
>
> On 24 March 2012 18:58, Blue Swirl wrote:
> > v2: fix patch 1, tweak patch 2 and rebase to master.
> >
> > URL git://repo.or.cz/qemu/blueswirl.git
> >http://repo.or.cz/r/qemu/blueswirl.git
> >
> > Blue Swirl (6):
> > arm: move neon_tbl to neon_helper.c
> > arm: move saturating ar
> > I just spoke with Paul on IRC about this. In summary:
> > * for a helper to cause an exception then it has (a) to make sure CPU
> >
> > state (pc, condflags) is sync'd before the call to the helper and (b)
> > the helper has to be in a file with access to global env, because it
> > needs to ca
> > For changes to
> > the TCG side we want to consider how we can provide useful aliasing
> > information, rather than a naive replacement of TCG_AREG0 with a
> > variable.
>
> What aliasing information?
Aliasing of cpu state accesses between tcg_global_mem_new_* variables,
qemu_ld/st ops, and
> > Yeah, that's why I said, "hard to do well". It makes it very hard to add
> > new socket types.
>
> PCI, USB, IDE, SCSI, SBus, what else? APICBus? I2C? 8 socket types
> ought to be enough for anybody.
Off the top of my head: AClink (audio), i2s (audio), SSI/SSP (synchonous
serial), Firewire,
> >> +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
> 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
> 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
> > 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
> 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
> 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
1 - 100 of 1782 matches
Mail list logo
