From patchwork Tue Mar 13 15:34:49 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Peter Maydell X-Patchwork-Id: 131474 Delivered-To: patches@linaro.org Received: by 10.46.84.17 with SMTP id i17csp884702ljb; Tue, 13 Mar 2018 08:35:03 -0700 (PDT) X-Google-Smtp-Source: AG47ELvg5APiDenf5humctGLZqyN2YomrblDAofJ6LZOk84TKRvO+C7jhY5HQQv55c/x6g8QjUyX X-Received: by 10.28.59.130 with SMTP id i124mr1107678wma.23.1520955303209; Tue, 13 Mar 2018 08:35:03 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1520955303; cv=none; d=google.com; s=arc-20160816; b=H4l4wgAJ2rwnc7i+mW01HStpOop2c/aexny9PEReeQ9hLV83WvzfXWvJ9diRhjphII vtgbZpwC0Z/JjhOshFK5RM28TTSEMkvHu3SZYGhQOfhI/Zh+aE9aQRR3brMMfRWMtbKn UlIYIhqevQDqqwq4qukHSs/eHBzyxADfiUzpScZQ2RaZqOi/qMbBKYwLDLd0L4/ZNC6v jifS7qJA2GcoHs89iOGMXFIotlAP4CUN5Wd6sM7QYV4Inxp0DO5TvYcszVc3oWD6wiX5 kqSnxhONFn4W9k6aTG6NvlNhWiN8fcHNpHsSPBo7ecYmJGlwBbBlv9T3qR/Viu77zdfv 8vjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=message-id:date:subject:cc:to:from:arc-authentication-results; bh=xwXxUNwT/o72vgoNBnRyX1rPBmR1tINRmh11G2Ia9rw=; b=ZHNBOlrcYtZ7GALt8NcSozu/9PzXfAWL/M5aJptWWz6KICS9c2fLxGXT2cpIi4TrHM /y2LNbNoBVmVUPIJG2kd7j1Q9ux1lBwzRfdq97mvXJVhuX6j751WXnY448x0Fvsgr1Tl P9A6aCl3hpU1y9iKbXUvwxKgANn2xTJbUU60czyfMkIrjoB8FPVu0kEET3/l9NPxkuCy euSCbE1PWK/wpov4JrZwv07/dxRwOuQ6eddclM2uxOje6G1XIVqZ9Tbm38wtGeZujDrU PbZEMXV3FYqGgfeYuIkG/VRiK872GrG0+8hde4guSvF+N9fj5lf594//vJ4e5ovsvwx4 n1gA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of pm215@archaic.org.uk designates 2001:8b0:1d0::2 as permitted sender) smtp.mailfrom=pm215@archaic.org.uk; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from orth.archaic.org.uk (orth.archaic.org.uk. [2001:8b0:1d0::2]) by mx.google.com with ESMTPS id f127si285270wmf.132.2018.03.13.08.35.03 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 13 Mar 2018 08:35:03 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of pm215@archaic.org.uk designates 2001:8b0:1d0::2 as permitted sender) client-ip=2001:8b0:1d0::2; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of pm215@archaic.org.uk designates 2001:8b0:1d0::2 as permitted sender) smtp.mailfrom=pm215@archaic.org.uk; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: from pm215 by orth.archaic.org.uk with local (Exim 4.89) (envelope-from ) id 1evlx6-0003E1-VY; Tue, 13 Mar 2018 15:35:00 +0000 From: Peter Maydell To: qemu-arm@nongnu.org, qemu-devel@nongnu.org Cc: patches@linaro.org, Pekka Enberg , =?utf-8?q?Philippe_Mathieu-Daud=C3=A9?= , Andrew Baumann Subject: [PATCH 0/9] raspi3: various fixes for Linux booting Date: Tue, 13 Mar 2018 15:34:49 +0000 Message-Id: <20180313153458.26822-1-peter.maydell@linaro.org> X-Mailer: git-send-email 2.16.2 I had a go at booting Debian's Linux kernel on our raspi3 model. These patches fix a variety of bugs that were stopping that working: * the board was trying to boot in secure mode, which isn't right for AArch64 Linux kernels * the hw/arm/boot.c code didn't set SCR_EL3.HCE, which meant that the HVC instruction would UNDEF and the guest would panic trying to initialize KVM * BCM2837 uses different affinity (cluster ID) values than BCM2836; this really confused Linux since it didn't think the primary CPU existed and it ended up panicing in an obscure way. I opted to fix this one with a modest refactor of the bcm2836 code into one device for each SoC, similar to how we handle the Aspeed SoCs. * the board was trying to use AArch32 code for the secondary CPU bootup, so secondaries just went into an infinite UNDEF exception loop. Using the correct instruction set and the right spintable protocol allows the kernel to detect all the secondaries. Unfortunately this doesn't entirely suffice to boot, because there's a problem with our bcm2835_sdhost device model. I've analysed the problem, but am not sure how to fix it because as far as I can tell there is no public documentation for this bit of the hardware :-( Does anybody have a datasheet for it? [Summary of the sdhost issue: The Linux bcm2835_sdhost driver doesn't work on QEMU, because our model raises spurious data interrupts. Our function bcm2835_sdhost_fifo_run() will flag an interrupt any time it is called with s->datacnt == 0, even if the host hasn't actually issued a data read or write command yet. This means that the driver gets a spurious data interrupt as soon as it enables IRQs and then does something else that causes us to call the fifo_run routine, like writing to SDHCFG. The driver's IRQ handler then spins forever complaining that there's no data and the SD controller isn't in a state where there's going to be any data: [ 41.040738] sdhost-bcm2835 3f202000.mmc: fsm 1, hsts 00000000 [ 41.042059] sdhost-bcm2835 3f202000.mmc: fsm 1, hsts 00000000 (continues forever). Without the h/w docs it's hard to know exactly when we are supposed to signal interrupts, though obviously what we do now is definitely wrong... ] thanks -- PMM Peter Maydell (9): hw/arm/raspi: Don't do board-setup or secure-boot for raspi3 hw/arm/boot: assert that secure_boot and secure_board_setup are false for AArch64 hw/arm/boot: If booting a kernel in EL2, set SCR_EL3.HCE hw/arm/bcm2386: Fix parent type of bcm2386 hw/arm/bcm2836: Rename bcm2836 type/struct to bcm283x hw/arm/bcm2836: Create proper bcm2837 device hw/arm/bcm2836: Use correct affinity values for BCM2837 hw/arm/bcm2836: Hardcode correct CPU type hw/arm/raspi: Provide spin-loop code for AArch64 CPUs include/hw/arm/bcm2836.h | 31 ++++++++++++++---- hw/arm/bcm2836.c | 81 +++++++++++++++++++++++++++++++++++------------- hw/arm/boot.c | 12 +++++++ hw/arm/raspi.c | 77 ++++++++++++++++++++++++++++++++++++--------- 4 files changed, 158 insertions(+), 43 deletions(-) -- 2.16.2