On Mon, 6 Feb 2023 at 17:12, Simon Glass wrote:
>
> For QEMU, where to start... I already sent a patch to fix this
> problem[1].
If you want to propose changes to QEMU or to revive
discussions about old patchsets because the circumstances
have changed, please do that on the qemu-devel mailing
On Thu, 2 Dec 2021 at 16:40, Simon Glass wrote:
> The word 'fake' applies to only three of the boards (highbank, bcm7xxx
> and octeontx), where I could not even figure out where to get a
> devicetree. One might think this would be a significant problem!
Isn't highbank
On Thu, 4 Nov 2021 at 11:22, François Ozog wrote:
> Le jeu. 4 nov. 2021 à 12:09, Peter Maydell a écrit
> :
>>
>> Well, our recommendation really was that the ideal thing would
>> be "you take the dtb that QEMU passes you at runtime, and at
>> runtime combine t
On Wed, 3 Nov 2021 at 14:41, Tom Rini wrote:
>
> On Wed, Nov 03, 2021 at 06:29:20AM +0100, François Ozog wrote:
> [snip]
> > > 3. Anything else?
> > >
> > > For qemu_arm_spl, it *does not boot* unless the U-Boot SPL properties
> > > are present. There is no easy way to fix this.
> >
> > one clean
On Tue, 26 Oct 2021 at 01:33, Simon Glass wrote:
>
> Add this file, generated from qemu, so there is a reference devicetree
> in the U-Boot tree.
>
> Signed-off-by: Simon Glass
Note that the dtb you get from QEMU is only guaranteed to work if:
1) you run it on the exact same QEMU version you
On Mon, 13 Sept 2021 at 10:31, Matthias Brugger wrote:
>
> Hi Robin,
>
> It's a long long time that you reported this issue.
>
> I prepared a fix in qemu for it. Would you mind to try it out? You can find a
> branch with the fix on top here:
> https://github.com/mbgg/qemu/tree/vrit-flash-dtb-bug
On Thu, 9 Jan 2020 at 13:11, Robin Randhawa wrote:
> I dumped the DTB to the host filesystem using GDB and 'dump mem' then
> dtc'd it to get the DTS.
The easier way to dump the DTB is to pass QEMU the extra
command line option -machine dumpdtb=file.dtb (plus all the
other arguments for the
On 20 September 2013 06:55, Mj Embd mj.e...@gmail.com wrote:
Hello Andre,
I need a bit clarification here, if you read the next line after the line
you have quoted. It clearly says that you can use a MCR to change from
Secure to NS in Monitor Mode
No, it's not saying that, because Monitor
On 20 September 2013 07:50, Mj Embd mj.e...@gmail.com wrote:
[MJ] Ok got your point. Then what would be the steps to return from Monitor
to Hyp mode?
You can't do it directly. While still in the Secure world you set up
the HVBAR and a suitable vector table for hyp mode exceptions.
Then you can
On 3 August 2013 08:11, Dennis Gilmore den...@ausil.us wrote:
when it comes to memory addressing a distro and user shouldn't need to
know anything. Ideally u-boot will auto allocate addresses based on the
size of loaded objects. starting with a base address internal to u-boot
you load a
On 23 May 2013 13:34, Albert ARIBAUD albert.u.b...@aribaud.net wrote:
Well -- if you form the acronym, you do end with 'A R M' indeed, but
this is quite unfortunate, as 'ARM ARM' is redundant (as the acronym's
A already has ARM in it), confusion (as 'ARM' already bears a quite
established
On 26 April 2013 14:24, Andre Przywara andre.przyw...@linaro.org wrote:
On 04/26/2013 03:18 PM, Peter Maydell wrote:
The obvious question here is why do we need a new command?.
The kernel booting specification says boot the kernel in
Hyp mode so we should just always do that for booting Linux
On 26 April 2013 14:14, Andre Przywara andre.przyw...@linaro.org wrote:
ARM CPUs with the virtualization extension have a new mode called
HYP mode, which allows hypervisors to safely control and monitor
guests. The current hypervisor (KVM and Xen) implementations
require the kernel to be
On 16 November 2010 13:54, Albert ARIBAUD albert.arib...@free.fr wrote:
Mostly these things
don't cause a problem in practice, which is why they haven't
been corrected yet.
Thanks Peter for the clarification. I imagine that in practice can bear
different meanings depending on the practice --
On 15 November 2010 15:09, Loïc Minier loic.min...@linaro.org wrote:
On Mon, Nov 15, 2010, Albert ARIBAUD wrote:
One last question:
qemu: fatal: Trying to execute code outside RAM or ROM at 0x3400
Does this mean that qemu does not simulate data or instruction
aborts? Not that it is
15 matches
Mail list logo
