On 12/17/18 6:10 AM, Linus Walleij wrote:
On Sun, Dec 16, 2018 at 8:43 PM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
At least for qemu this doeesn't work: It causes boots from mmc to
fail for vexpress-a9 and vexpress-a15 machine types.
Oh not good. How do I reproduce this?
My qemu command line looks like this:
qemu-system-arm -M vexpress-a9 -no-reboot -smp cpus=4 -kernel
${HOME}/zImage -dtb ${HOME}/vexpress-v2p-ca9.dtb -hda hda.img -append
"root=/dev/sda init=init console=ttyAMA0" -serial stdio
I use:
/opt/buildbot/qemu-install/v3.0/bin/qemu-system-arm -M vexpress-a9 \
-kernel arch/arm/boot/zImage -no-reboot \
-snapshot -drive file=rootfs-armv5.ext2,format=raw,if=sd \
-append 'root=/dev/mmcblk0 rootwait rw console=ttyAMA0,115200 console=tty1' \
-nographic
Works fine for me, and always did (up to now, that is).
I can't figure out how to make QEMU Vexpress boot from MMC, is it
some option that is not documented in man qemu-system-arm?
Reason is that
OF_GPIO_ACTIVE_LOW was so far not set for those machine types, but
it is now set by the code below. This may also affect other machines -
hard to say, since there are lots of boot failures in -next right now,
and the symptoms are often similar.
Since the lack of {cd,wp}-inverted now always sets OF_GPIO_ACTIVE_LOW,
I suspect that all active-high configurations which do not also explicitly
specify {cd,wp}-inverted in their devicetree files are now broken.
Indeed this can be the problem.
The device tree node (arch/arm/boot/dts/vexpress-v2m.dtsi) looks
like this:
mmci@5000 {
compatible = "arm,pl180",
"arm,primecell";
reg = <0x05000 0x1000>;
interrupts = <9 10>;
cd-gpios = <&v2m_mmc_gpios 0 0>;
wp-gpios = <&v2m_mmc_gpios 1 0>;
max-frequency = <12000000>;
vmmc-supply = <&v2m_fixed_3v3>;
clocks = <&v2m_clk24mhz>, <&smbclk>;
clock-names = "mclk", "apb_pclk";
};
According to the bindings, this means that the GPIOs are active
low, because all CD/WP lines are active low unless
"[cd|ro]-inverted" is specified, despite the fact that the second
cell on the gpios here is 0 meaning they should be active high.
But since all ARM reference designs I have seen actually have
active low GPIOs for this I am a bit confused.
I can't comment on that. I only see that qemu no longer works after your
patch has been applied, and it used to work with all older kernels I ever
tested.
Either case, your patch does introduce a semantic change which affects
all systems with active high cd and wp pins (and, frankly, I don't see
the point of the {cd,wp}-invert properties; they seem redundant and ask
for trouble).
Thanks,
Guenter
I suspect it's rather some bug making them active high. But I
would need to reproduce and look closer.
Yours,
Linus Walleij
