On 14 July 2017 at 00:06, Daniel Thompson <daniel.thomp...@linaro.org> wrote:
> On 13/07/17 08:33, Bin Chen wrote: > >> Hi Tom, >> >> Thanks for the review. >> >> On 13 July 2017 at 04:25, Tom Rini <tr...@konsulko.com <mailto: >> 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 <mailto: >> 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. >> > > All arm64 kernels are multi-platform (even if for some minimized builds > only drivers for one platform are actually enabled). That means a uImage > kernel target is problematic because the kernel build system does not know > its eventual physical load address. On arm64 that is entirely delegated to > the bootloader. > > That doesn't mean uImage can never be used; just that the kernel build > system has no business authoring one. Yes, that's exactly what I mean, and why I'm tentative adding a uImage target for arm64. Actually I did add that target and found the issue you described. > > > >> 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. >> >> >> The analogy would be that we use bootm for Android >> on arm not bootz. Thanks! >> >> -- >> Tom >> >> >> >> >> -- >> Regards, >> Bin >> > > -- Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
