On 22 February 2015 at 02:19, Laszlo Ersek wrote:
> So, before I try to reason more about code that's potentially not
> covered by this patch, let me ask this -- is it conceivable that in the
> following:
>
> //
> // child base cpu base
> //type add
On 14 February 2015 at 22:01, Laszlo Ersek wrote:
> Alex Graf has written patches for QEMU that add a generic PCI express
> host to the "virt" machine (qemu-system-arm, qemu-system-aarch64). The
> QEMU patches are now queued for merging in the following repo:
>
> git://git.linaro.org/people/pmay
On 16 January 2015 at 09:58, Peter Maydell wrote:
> On 16 January 2015 at 00:32, Laszlo Ersek wrote:
>> (2) Check out the latest upstream qemu (git), and apply the following
>> patch on top (it's been reviewed and queued in target-arm.next):
>>
&
On 16 January 2015 at 00:32, Laszlo Ersek wrote:
> (2) Check out the latest upstream qemu (git), and apply the following
> patch on top (it's been reviewed and queued in target-arm.next):
>
> http://article.gmane.org/gmane.comp.emulators.qemu/312419/raw
Oops. I'll get this into master by end of n
On 17 December 2014 at 19:50, Richard W.M. Jones wrote:
> I agree with Peter here, although -kernel w/o -initrd really is a
> developer option :-) Even qemu-sanity-check which is a program I
> wrote[1] that has probably the most minimal userspace that it's
> possible for Linux to have, still uses
On 17 December 2014 at 19:13, Laszlo Ersek wrote:
> Lack of -initrd results in a zero-sized initrd file in the synthetic
> filesystem, and a kernel command line parameter that references that
> zero sized file ("initrd=initrd"), so the firmware code itself does not
> break.
>
> Second, AFAICT ther
On 27 November 2014 at 23:34, Laszlo Ersek wrote:
> Thanks for the hint, I was actually wondering if some official registry
> existed for the node names and types. So yeah I'll attempt to get it in
> there. (Once I find the docs in question in the kernel :))
Documentation/devicetree is probably a
On 27 November 2014 at 23:18, Laszlo Ersek wrote:
> fw_cfg already supports exposure over MMIO (used in ppc/mac_newworld.c,
> ppc/mac_oldworld.c, sparc/sun4m.c); we can easily add it to the "virt"
> board.
>
> The mmio register block of fw_cfg is advertized in the device tree. As
> base address we
On 9 September 2014 12:10, Ard Biesheuvel wrote:
> On 9 September 2014 12:58, Olivier Martin wrote:
>> Any reason why you moved from the 8 arguments used by ArmSmcLib to 4
>> arguments for ArmHvcLib?
>> I thought I read somewhere the HVC calling convention was the same as the
>> SMC calling conve
On 28 August 2014 20:57, Laszlo Ersek wrote:
> The FDF under review follows exactly scheme 2. The FD starts with a DATA
> region that starts with a manually encoded branch instruction to 0x1000.
> The DATA region encodes this branch instruction in 4 bytes, and the rest
> (4092 byes) come from the
On 28 August 2014 16:22, Laszlo Ersek wrote:
> You're saying "put the vector table somewhere else than the base of RAM".
Sorry, that was a thinko on my part. I meant "base of
physical address space".
-- PMM
--
Slashdot
On 28 August 2014 16:08, Laszlo Ersek wrote:
> - Even if someone wants to implement such, where should (where *can*,
> actually) the exception handler table exist at all? The addresses
> that I listed above are backed by the (read-only) flash chip. The
> exception handler table should be bui
On 28 August 2014 16:16, Laszlo Ersek wrote:
> On 08/28/14 16:59, Ard Biesheuvel wrote:
>> However, putting a vector table in that particular place is
>> troublesome, as the whole point of having the region is to avoid
>> putting a Firmware Volume (FV) there. And having to code the whole
>> vector
On 28 August 2014 15:30, Laszlo Ersek wrote:
> So we got, in the NOR-mapped FD file:
>
> address 0: jump instruction to 4K, otherwise a bunch of emptiness
> (according to erase polarity!)
Ideally this should be a proper complete vector table with
handlers for all the exception vector
On 27 August 2014 19:15, Olivier Martin wrote:
> I have been through the patchset yet. But I noticed the name of the platform
> in another email.
> Is this new platform AArch64 specific? Could we imagine this platform being
> easily ported to ARMv7 (with Virtualization extension)?
No, it's not 64
On 27 August 2014 17:58, Ard Biesheuvel wrote:
> On 27 August 2014 18:03, Laszlo Ersek wrote:
>> I'll mention in passing that
>> "MdeModulePkg/Universal/Variable/RuntimeDxe/VariableRuntimeDxe.inf" is
>> good for a non-authenticated variable store only, ie. no secure boot
>> support. For secure bo
On 27 August 2014 17:58, Ard Biesheuvel wrote:
> On 27 August 2014 18:03, Laszlo Ersek wrote:
>> - Why require a 64MB flash drive, if we only use 768 KB of it?
>>
>
> The ARM Versatile Express development hardware is set up like this,
> that is the whole and only reason.
> I guess we could change
On 25 August 2014 22:03, Laszlo Ersek wrote:
> On 08/25/14 21:19, Ard Biesheuvel wrote:
>> This series adds a platform config to support QEMU based virtual machines,
>> either in TCG or KVM mode. These virtual machines declare their platform
>> configuration by passing a device tree which needs to
18 matches
Mail list logo
