On Thu, Mar 1, 2018 at 12:53 AM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 28 February 2018 at 00:09, Michael Clark <m...@sifive.com> wrote: > > I've just talked to SiFive about this. They have agreed that we can > remove > > the sifive_e300 and sifive_u500 boards from the patch series that we are > > going to submit upstream again later this week or early next week. These > > machines and their devices are pretty easy for us to maintain in the > riscv > > or a sifive repo. This trims the number of machines from 5 to 3 and lets > us > > remove the SiFiveUART and SiFivePRCI from the next patch series we are > > going to submit. e.g. v8 > > Models of boards which people actively want and are using are fine > (though indeed you can save them for a later round of patches if you > like). And it sounds like the 1.9.1 stuff is genuinely wanted, so > thanks for the clarification there. What I want to avoid is boards > going into QEMU just because you happened to have them already. Once > a board model goes into QEMU it's a commitment to supporting it for > the long term, and getting rid of it again is hard. Most folk in the community at large are interested in the 'spike' and 'virt' machines. Well, the linux distributors are currently targetting 'virt' as it has working network and block storage. It's mostly SiFive customers that are interested in the SiFive machines. SiFive do intend to submit their machines upstream however we've decided that we want to review the naming of the machine/board/SOC in light of several new models, as there are infact more MCU/SOC models than are currently represented in the RISC-V QEMU port (E21, E31, E51, U54, U54MC). Those are the SOCs and then there are boards like the HiFive1, the LoFive, the HiFive Unleashed and several others (the 7th RISC-V Foundation Workshop had an electronic badge with the FE310 designed by antmicro). SiFive might like to review the naming and re-jig the SOC / board relationship. Presently we created two generic boards to represent the MMU-less E-series (sifive_e300) and the U-series (sifive_u500) however that doesn't cover the E21 and E51. As well as silicon, there are soft-cores, including soft-cores from other vendors (who have not yet submitted anything to the QEMU port). After reflecting on this we don't think the naming of the two sifive machines is quite right and they are not yet complete emulations. The sifive_u500 is supposed to model the HiFive Unleashed however we don't have device emulation for all of the hardware widgets yet, and some of the drivers are not yet in upstream Linux. Linus essentially accepted the generic core, which is what we are now suggesting for QEMU. We are totally happy to submit them if folk don't mind us potentially renaming them later. This is 2 patches for 2 machines and 2 or 3 devices. It would reduce the patch series from 23 patches to 18 patches and we'd maintain the 5 files and associated headers out-of tree until things firm up. The core of the port is pretty solid as Fedora have build stage 4 images using SMP on the 'virt' machine. > > However I'm inclined to leave it as it is, at this point. It is not > > something that we can't change in the future once the code is in-tree. > > With my 'upstream dev' hat on, I tend to be suspicious of this > line of argument, because in a lot of cases what tends to happen > is that the code for some new target or device goes in-tree, and > then the people who worked on submitting it disappear, or never > actually do get round to refactoring[*]. You get more leeway for > making this argument the longer you've been around and participating > in QEMU development, because then you have a track record of > following up on things. > > [*] in fact we're currently discussing deleting support for > a couple of target architectures that were basically "once the > code went into mainline nothing further was ever done to it except > global-refactorings and other tree wide maintenance by other > QEMU developers". I might explore coalescing the two spike boards before the v8 spin then. I was thinking about using a global to enable the backwards compatibility mode. It seems -global is for driver properties? Is it appropriate to use a global property to change the behaviour of a machine? Okay, I see raspi.c contains raspi, raspi 2, raspi 3, and it just defines multiple machines in the same file and passes a version number to routines that are shared. We could go with that approach.
