Re: [PATCH v3 6/8] dm: treewide: Complete migration to new driver model schema
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 list, not by cc'ing me into u-boot mailing list discussions. That's where the QEMU developers are... thanks -- PMM
Re: [PATCH v6 00/25] fdt: Make OF_BOARD a boolean option
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 https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/highbank.dts ? -- PMM
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
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 that with whatever extra information you want". > > That looks just reasonable this way. > So we need a « -mergedtb » option for Qemu to have the same > capability. This would merge the QEMU generated one with the > command line provided. No, I mean that the guest, ie u-boot, should do the merging, not QEMU. -- PMM
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
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 and easy way would be to upstream a Qemu change to merge a > > supplied overlay to the generated one. This the same idea as applying the > > NT_FW_COnFIG overlay in the TFA world. In both cases previous loaders do > > their job properly for U-Boot : setting up the stage as needed. > > For the record, I believe Simon did propose this and the QEMU response > was that no, you should dumpdtb, combine externally and pass that > directly. 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 that with whatever extra information you want". The dumpdtb option is primarily intended as a debug feature, so you can have a look at the dtb QEMU created to see why your OS isn't booting; although you can script stuff up that does a dumpdtb-modify-pass-to-QEMU that is pretty clunky given the need to invoke QEMU twice with matching arguments both times. -- PMM
Re: [PATCH v5 06/26] arm: qemu: Add a devicetree file for qemu_arm64
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 generated it with 2) you pass QEMU the exact same command line arguments you used when you generated it thanks -- PMM
Re: Bug: qemu_arm64: Cannot access the second flash bank
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 > > Basically I fix the reg property to reflect the fact that the size-cell is > one. Isn't #size-cells here inherited from the fdt root node (where we set it to 2) ? thanks -- PMM
Re: Bug: qemu_arm64: Cannot access the second flash bank
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 configuration you want). Instead of starting the VM QEMU will write the dtb to the specified file and exit. thanks -- PMM
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
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 mode is always Secure: this is exactly why an MCR to change SCR.NS is OK only in Monitor mode -- it doesn't change from Secure to Non-Secure. Only when you do an exception-return to leave Monitor mode will you drop into the NonSecure world. Use an MCR instruction that writes SCR.NS to change from Secure to Non-secure state. This means ARM recommends that software does not alter SCR.NS in any mode except Monitor mode. ARM deprecates changing SCR.NS in any other mode. The text says don't change from Secure to NonSecure by flipping SCR.NS. It then lays out the corollary: the only time you then can change SCR.NS is when it won't switch from Secure to NonSecure, which is when you're in Monitor mode. -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/8] ARM: add assembly routine to switch to non-secure state
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 drop back into NS-SVC, and execute an HVC instruction which puts you into hyp mode at the hvc entry point in your vector table. See patch 7 in the series. -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Unified u-boot feature set for simpler distro support
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 kernel, when loading an initramfs u-boot automatically calculates an address that ensures it does not overlap with the kernel. same for a fdt if loaded. I say auto calculated because what we think today will be enough room may not be tomorrow, dynamically calculating gives the flexibility for whatever may come. I looked into doing this for QEMU's boot loader once. I wasn't able to come up with a solution because there's no way given a zImage to determine how big it will be uncompressed, so all you can do is make a best-guess about where to put other things. Maybe I missed a way to do this cleanly though? thanks -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/6] ARM: add secure monitor handler to switch to non-secure state
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 meaning) and ambiguous (as there are actually several documents with the title of 'ARMvXXX Reference Manual' and which would end up with the same acronym). ARM ARM is the standard abbreviated way of referring to the ARM Architecture Reference Manual (and as you can see it's not a redundant acronym, since the A doesn't stand for ARM). A TRM (Technical Reference Manual) is a completely different document type, describing a specific processor. Andre is correct that the restriction in question is architectural (and thus described in the ARM ARM), not implementation specific (which would be what you'd find in a TRM). So if you don't want to use 'TRM' (which I can understand), then at least please replace 'ARM ARM' with 'ARMv7-AR Reference Manual'. Stating the DDI* reference is not a must, unless you want to specify a given revision (but then I suggest adding it after 'Manual' too). ARMv7-AR Reference Manual is confusing, because you've dropped the Architecture bit. Since this is only a git comment, I'd suggest ARM architecture reference manual as both clear for non-ARM people and sufficiently unambiguous, or ARMv7-AR Architecture Reference Manual if you want to be a bit more formal about it. thanks -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/6] ARMv7: Add HYP mode switching support
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, surely? Because it avoids regressions. I kind of feel uneasy to do a lot of tinkering with secure state and the GIC unconditionally, especially if enabled on many boards with virt-capable CPUs. There aren't exactly very many of those out there, so if we default to boot in HYP mode then (a) KVM will just work out of the box and (b) people doing u-boot ports to their board will find any issues and be able to submit fixes. If we don't turn it on by default then we'll end up stuck in a world where KVM doesn't work on half the virt capable boards out there. I have no objection to a turn this off escape hatch if you think it's useful. -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH 0/6] ARMv7: Add HYP mode switching support
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 entered in that HYP mode. This patch series introduces a new U-Boot command called hypmode which can be used at any time at the U-Boot command prompt to switch the CPU into HYP mode - ideally this would be done before starting the kernel. 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, surely? thanks -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] qemu-arm (was: [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support)
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 -- for software like u-boot, which is very low-level and can encounter issues such as a RAM controller misconfiguration (or plain bad BAR setting, mind) addressing outside physically available space, including writing to RO memory or fetching bad code, is something we can see in practice, at least in the first times of a board's bring up. Sure, but I imagine that for debugging that sort of thing it doesn't make a great deal of difference whether you discover it by getting a cpu abort, by having the core just go off into the weeds somewhere or by getting a fatal error message from qemu. So that was partly what I meant by in practice -- yes, it's a deviation from correct behaviour, but it's not really any more of an impediment to debugging than correctly modelled behaviour would be, once you know what qemu is doing wrong... (Which is not to defend the current qemu behaviour so much as to try to explain why this particular bug isn't at the top of my todo list :-)) -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V4 1/2] arm926ejs: fix linker file for newer ld support
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 required for u-boot, but it *could* be useful sometimes. I think the only thing it can do is halt :-) qemu does simulate data/insn aborts caused when the MMU is enabled and you try an access forbidden by the access permissions set up in the page table. That particular error message happens when you try to execute from a physical address which isn't RAM or ROM, so you'll only see it if you have not enabled the MMU or if you get your page tables wrong. There's no particular reason this couldn't be made to take a simulated fault instead, I think -- there's an #ifdef that means qemu for Sparc and MIPS will simulate a fault instead of aborting. (In theory I think the behaviour shouldn't necessarily always be to fault, but if there is a non-RAM non-ROM device at the address to simulate the effect of trying to fetch instructions from your serial device registers, for example :-)) This is an example of a general tendency in qemu-arm for the modelling to be a bit weak for situations which will never be triggered by a correct program/OS but which nonetheless have well defined failure behaviour. Other examples include execution of various opcode values which should UNDEF (may trigger qemu internal error warnings or decode to some other instruction), and execution of VFP or Neon when the CPACR is set to disable access to cp10/11 (should fault but won't). Mostly these things don't cause a problem in practice, which is why they haven't been corrected yet. -- PMM ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
