Hi, On 17/09/17 15:33, icen...@aosc.io wrote: > 在 2017-09-17 19:24，Siarhei Siamashka 写道： >> Hello All, >> >> The last version of sunxi-tools v1.4.2 has been released almost a year >> ago. So it's a high time to tag a new one soon. >> >> I propose to set a deadline for pull requests one week from now on the >> next Sunday (24.09.2017), then dedicate a week primarily to testing >> and improving documentation with the intention to tag the v1.5 release >> on 01.10.2017 > > P.S. I rebased your spi flashing branch onto the newest master, at [1]. > > Could you review it? > > [1] https://github.com/Icenowy/sunxi-tools/tree/spi-rebase
I agree that we should have this in the next release, if possible, as boot-strapping a SPI flash over FEL is a nice feature. In fact, I did a similar rebase last weekend: https://github.com/linux-sunxi/sunxi-tools/pull/107 I started reviewing your version. >> If necessary, we may have follow-up bugfix releases v1.5.1, v1.5.2, ... >> >> I can step up and nominate myself as a temporary sunxi-tools maintainer >> for this particular release if Bernhard Nortmann does not have any >> objections. >> >> As for the features, which should go into this release. First we need >> to resolve bug https://github.com/linux-sunxi/sunxi-tools/issues/104 >> People reported that v.1.4.2 has a problem in the compatible version >> checking code and fails to FEL boot newer U-Boot images with the >> following error message: >> >> sunxi SPL version mismatch: found 0x02 > maximum supported 0x01 >> You need a more recent version of this (sunxi-tools) fel utility. Yeah, I guess I am to blame here to breaking this. So what is the plan here? I guess for v1.5 we just need to extend "1" to "2", since this train has already left and we can't do much else about it. Any opinions for the future options? 1) We introduce a major.minor scheme, where we only increase major if we need to break backwards-compatibility. Newer U-Boot features which are handled correctly by older sunxi-fel versions just increase minor. 2) We introduce some option bitfields, split into compatible and non-compatible features (a similar scheme to what ext2 uses: r/o and r/w compatible features). If U-Boot introduces a new, but optional feature (like the DT name), we just allocate a "compatible" bit, which older sunxi-fel versions are free to ignore. 3) Some combination of the above. Is that the way to go? Any suggestions? >> The other things in the top priority list are the FIT container format >> support for the main U-Boot binary and TOC0 container format for >> the SPL. Currently sunxi-tools does not recognize either of these. >> And these features are needed to get full support for modern 64-bit >> Allwinner SoCs (A64/H64/H5). > > I think FIT support is not so necessary now, as we now still cannot > cleanly build a 32-bit SPL for 64-bit Allwinner SoCs, and 64-bit SPL > cannot return back to FEL. I agree, it's nothing for this version. For the records: I pushed some WIP branch[1] - mostly a forward port of some code - which creates a 32-bit SPL and works with FEL boot. We don't necessarily need FIT support in sunxi-fel for this, as one can pass down the "broken-down" binaries to sunxi-fel instead. Also I started to look into FEL for the AArch64 SPL lately. Interestingly it actually returns into AArch32 (proven by ARM32 code executed after the RMR), but dies later in the BROM FEL code, apparently. I suspect some caching issues, since the ARMv8 SPL uses the MMU and caches, but FEL does not. I guess we "just" need to properly invalidate the caches, possibly even turning the MMU off before doing the RMR. Anyway, this needs more time and is no material for v1.5. Cheers, Andre. [1] https://github.com/apritzel/u-boot/tree/a64-fel32-wip >> We also need to go through the list of bugreports and do something >> about them. >> >> Because way too many people have commit access to the sunxi-tools >> repository, I would like to see the following rules respected (this >> is nothing new, I've been following this practice myself since a while >> ago): >> 1. All features should go in via reviewed pull requests. One of the >> reasons for this is that we have travis-ci active, which does the >> initial basic QA check for any pull request submissions. >> 2. Never merge any pull requests without giving a 2-3 days notice >> via a github comment. Because absence of activity on some pull >> request does not automatically mean that nobody has any objections. >> But if you get no objections within this short notice period, then >> go ahead. >> >> The timeline is preliminary and we can extend the deadlines a bit if >> some features need more time (but preferably by no more than one extra >> week). Do you have any comments or suggestions? >> >> -- >> Best regards, >> Siarhei Siamashka > -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
