From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eugeniu Rosca Date: Mon, 1 Apr 2019 17:26:55 +0200 Subject: [U-Boot] [PATCH v2 5/5] fdt: boot_get_fdt: android: use ENV 'fdtaddr' as fallback In-Reply-To: <20190401105252.30002-1-erosca@de.adit-jv.com> References: <20190401104537.29801-1-erosca@de.adit-jv.com> <20190401105252.30002-1-erosca@de.adit-jv.com> Message-ID: <20190401152655.GA26131@vmlxhi-102.adit-jv.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi All, especially the Android specialists, On Mon, Apr 01, 2019 at 12:52:52PM +0200, Eugeniu Rosca wrote: > Our platform doesn't store the DTB into the Android image second area, > but rather copies the DTB to RAM from a dedicated dtb.img partition [0], > prior to booting the Android image by calling bootm. > > Similar to [1], we find it useful to just call 'bootm' and have the > right DTB being passed to OS (assuming its address has been previously > stored in 'fdtaddr' by calling `fdt addr `). > > Booting Android with DTB from 'fdtaddr' will only occur if: > - No DTB is embedded in the second area of Android image > - 'fdtaddr' points to a valid DTB in RAM > > [0] https://source.android.com/devices/architecture/dto/partitions > [1] https://patchwork.ozlabs.org/patch/1046652/ > ("Support boot Android image without address on bootm command") FWIW, I believe this patch could make use of the "second address" [1] stored in the Android image to fulfill my use-case, even if the second area is left empty. I believe some consensus is needed about that in community. With this alternative approach, changing the DTB RAM address would mean regenerating the Android image, so it would be somewhat less flexible. I am curious if anybody has gone through the same use-case, as it is hard to believe I am the first one booting an image lacking the DTB in its second area. Best regards, Eugeniu. [1] => iminfo 4c000000 ## Checking Image at 4c000000 ... Android image found kernel size: 85b9d1 kernel address: 48080000 ramdisk size: 54ddbc ramdisk addrress: 4a180000 second size: 0 second address: 48000800 tags address: 48000100 page size: 800 os_version: 1200012a (ver: 0.9.0, level: 2018.10) name: cmdline: buildvariant=userdebug