Hi Peter, Thanks for your feedback!
From: Peter Crosthwaite [mailto:crosthwaitepe...@gmail.com] Sent: Tuesday, 17 November 2015 23:51 > I haven't looked beyond the diffstat yet, but a top level > architectural comment, I only see the one file in hw/arm. We are > promoting the split of board and SoC now as two separate objects. Each > of the patch series linked above demonstrates this. The BCM SoC would > be an object in its own right, then the board instantiates the SoC as > a composite device. I understand the rationale here, but is there much value pursuing this for the Pi? As far as I know, the Pi1/2 SOCs (bcm2835 and 2836) are one-off designs used only in the Pi. Moreover, the 2836 is basically a copy of the 2835 with the addition of a new block for a multi-core interrupt controller and mailboxes, so trying to split those out into two separate SOC definition files would require either lots of duplication, or a tight coupling between the two. Finally, there is basically nothing on the board besides the SoC and RAM (just a USB-Ethernet adapter), so the actual board definition files would be almost empty. As it is, I've already factored out all the common devices within hw/arm/raspi.c -- my feeling is that this is a cleaner way to do it for the Pi. > It is big. Work of this magnitude is generally better managed as > multiple series (each of multiple patches). A general approach with > new ARM boards is the first series is the bare minimum needed to get a > linux boot over the UART console. This usually means any CPU > customisations, timer, UART, intc, SoC and boards, maybe the > system/power controllers (if the kernel touches them in boot) and > optionally network or emmc. With network you can do an NFS root (this > was the only option on Allwinner/cubieboard for quite some time) and > with emmc you can do your root=/dev/mmcblk0p2 style boot as normal. If > you are using existing lan9118, network first might be a clear win, > although emmc is more realistic. Can always do both. > > The you can follow up with the USB, DMA, AUX, ... each independently > or as a follow up series'. > > Any core code and ARM CPU work that is a bugfix or stands in its own > right, you should send straight up as a separate work. Ok, understood. Even following this guidance, the first patch will be big -- Pi has custom interrupt and DMA controllers, and the GPU gets itself involved in the boot process. I think we could probably leave out fb/usb and maybe also dma, mphi, vchiq and power, but most of the rest will be needed to boot anything. BTW, I used lan9118 as a kludge for Windows, but it isn't present on a real Pi, and the device definition no longer instantiates it. At present, there is no usable network device. > Curious, does rPi kernel support device tree boot? This would be nice > for testing with a generic kernel. I believe it does on recent Raspbian images (I see a number of dtb files in Raspbian's boot partition), but I haven't tried to figure out how to use them. In general, we have limitations where the bootloader is concerned. On Pi HW, the boot process is driven by the GPU, which reads a plethora of options from config files (config.txt and cmdline.txt) on the boot partition. We don't emulate any of that stuff... instead, the previous raspi code did just enough to boot Linux using qemu's Linux loader support, and I figured out how to make UEFI happy on raspi2 so it can boot Windows, but that's about all. I will take a look at the patches you referred to, and try to refactor the devices accordingly. BTW, my main goal here is Windows support (surprise! :), so if anyone else is willing to help out with Linux that would be much appreciated. The kernel currently limps into early userspace before crashing on a SETEND instruction, and is clearly not as happy as it was when the original Pi1 support was being actively developed ~2 years ago. Thanks, Andrew
