On 14 July 2017 at 00:55, Rob Herring <rob.herr...@linaro.org> wrote:
> On Thu, Jul 13, 2017 at 2:33 AM, Bin Chen <bin.c...@linaro.org> wrote: > > Hi Tom, > > > > Thanks for the review. > > > > On 13 July 2017 at 04:25, Tom Rini <tr...@konsulko.com> wrote: > >> > >> On Tue, Jul 11, 2017 at 03:56:04PM +1000, Bin Chen wrote: > >> > >> > It's my understanding that we are supposed to use booti, instead of > >> > bootm, > >> > for arm64 image. But booti lacks of android image support. Bootm has > >> > the andriod image support but lack of the arm64 image handling. > >> > > >> > So, what is suppose the right way of booting an android arm64 image? > >> > or, should we create a separate command? > >> > > >> > This patch is an invitation for that discussion. > >> > > >> > It *hacked* the booti command and it aslo assume the dtb is in the > >> > second area > >> > of android boot image. It also has other belives like u-boot should be > >> > in control of where to put the kernnel/ramdisk/dtb images so it > ignores > >> > the value specified in the android images. > >> > > >> > Signed-off-by: Bin Chen <bin.c...@linaro.org> > >> > >> So, booti is very much for the "Image" format described in the Linux > >> kernel in Documentation/arm64/booting.txt. One can (and people have) > >> used bootm on aarch64 for "uImage" style kernels and FIT kernels, and I > >> would see being able to boot an aarch64 Android image with bootm as the > >> way to go forward. > > > > > > Are you suggesting that we should use bootm path, instead of booti? > > > > I have two questions regarding this: > > > > 1. currently arm64 kernel don't have a uImage kernel target. And I'm not > > sure > > if adding that will be something that is wanted and/or sensible. > > Sure it does. You just run mkimage with the Image and create one. I > suppose you mean that step is not integrated into the kernel build. > Yes, that's what I mean. > That is not wanted. As Daniel pointed out, a uImage is platform > specific is the first reason. Also, putting every bootloader's custom > format into the kernel build doesn't really scale. > Thanks for the clarification. > > > 2. bootm path doesn't have the logic that is currently in the booti, > such as > > the > > kernel relocation. > > > > Also, one other question raised during internal discussion was why the > booti > > was created in the first place, if we could have had that implemented in > the > > bootm path. > > I think for simplicity. The bootm logic and command line options are > already complicated enough. I can appreciate that :) > Of course with that logic, we should have > made Android images a separate command too (some pre-mainline versions > of Android boot support did do a boota command). Though, IIRC I think > you can boot an Android boot image containing a uImage for the kernel > I tried but didn't succeed on that (using bootm with uImage created from a arm64 Image ). I didn't dig deeper and changed the route to trying the booti path instead. But there are a few things I observed on the bootm path: - load address: uImage specified the load address that isn't quite right for arch64 (as Daniel pointed out) (and in general, bootm path don't arm64 boot requirement correctly as booti did) - dtb handling : for arm64 , dtb must be provided; while arm32 kernel can handle concatenated dtb. And since android image don't have a place to put the dtb, so it seems not possible to get that implemented generically. I don't know how the boota command is implemented to pass the dtb information. > (not something I'd recommend). > > Rob > -- Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
