The EFI HTTP boot puts the ISO installer image at some location in memory. Information about this image has to be passed on to the OS kernel, which is done by adding a persistent memory(pmem) node to the devicetree(DT) that is passed to the OS. The OS kernel then gets information about the presence of this ISO image and proceeds with the installation. In U-Boot, this ISO image gets mounted as a memory mapped blkmap device slice, with the 'preserve' attribute. Add a helper function which iterates through all such slices, and invokes a callback. The callback adds the pmem node to the DT and removes the corresponding memory region from the EFI memory map. Invoke this helper function as part of the DT fixup which happens before booting the OS. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Some blkmap memory mapped devices might have to be relevant even after U-Boot passes control to the next image as part of the platform boot. An example of such a mapping would be an OS installer ISO image, information for which has to be provided to the OS kernel. Use the 'preserve' attribute for such mappings. The code for adding a pmem node to the device-tree then checks if this attribute is set, and adds a node only for mappings which have this attribute. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Add information about the type of blkmap slices as an attribute in the corresponding slice structure. Put information in the blkmap slice structure to identify if it is associated with a memory or linear mapped device. Which can then be used to take specific action based on the type of the blkmap slice. Signed-off-by: Sughosh Ganu <sughosh.ganu@linaro.org> Reviewed-by: Tobias Waldekranz <tobias@waldekranz.com> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
As part of bringing the master branch back in to next, we need to allow for all of these changes to exist here. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
When bringing in the series 'arm: dts: am62-beagleplay: Fix Beagleplay Ethernet"' I failed to notice that b4 noticed it was based on next and so took that as the base commit and merged that part of next to master. This reverts commit c8ffd1356d42223cbb8c86280a083cc3c93e6426, reversing changes made to 2ee6f3a5f7550de3599faef9704e166e5dcace35. Reported-by: Jonas Karlman <jonas@kwiboo.se> Signed-off-by: Tom Rini <trini@konsulko.com>
Remove <common.h> from this driver directory and when needed add missing include files directly. Reviewed-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> Signed-off-by: Tom Rini <trini@konsulko.com>
User needs to call several functions to create the ramdisk with blkmap. This adds the utility function to create blkmap device and mount the ramdisk. Signed-off-by: Masahisa Kojima <masahisa.kojima@linaro.org> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Ilias Apalodimas <ilias.apalodimas@linaro.org> Signed-off-by: Ilias Apalodimas <ilias.apalodimas@linaro.org>
At present if a device to map has a block size other than 512, the blkmap map process just fails. There is no reason why we can't just use the block size of the mapped device. Signed-off-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Simon Glass <sjg@chromium.org>
These 2 are only used in drivers/block/blkmap.c. Signed-off-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Simon Glass <sjg@chromium.org>
Avoid using the magic number 512 directly. Signed-off-by: Bin Meng <bmeng@tinylab.org> Reviewed-by: Simon Glass <sjg@chromium.org>