From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anton Leontiev Date: Sat, 31 Aug 2019 22:52:59 +0300 Subject: [U-Boot] [PATCH] cmd: pxe: Use internal FDT if external one cannot be retrieved In-Reply-To: <40c2ba60-4ef5-7861-8725-9347f9346439@wwwdotorg.org> References: <20190823144043.26792-1-scileont@gmail.com> <40c2ba60-4ef5-7861-8725-9347f9346439@wwwdotorg.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit To: u-boot@lists.denx.de чт, 29 авг. 2019 г. в 23:35, Stephen Warren : > On 8/29/19 5:20 AM, Anton Leontiev wrote: > > 2019-08-26 at 18:59, Stephen Warren : > > We have a GNU/Linux distribution that use FDTDIR in its extlinux.conf > > to support several boards. But some boards have FDT embedded in U-Boot > > and it is't present in FDTDIR. In such configuration U-Boot fails to > > boot an entry, despite no exact FDT is specified in it. Distribution > > itself is designed to work on any board. > > I lookead at that referenced commit description in full and the code, > and I believe what you want is for U-Boot to set fdt_addr to the > location of the in-RAM DT, and leave fdt_addr_r unset. This will > indicate to the pxe code that no FDT should be loaded when parsing > extlinux.conf, but instead to use fdt_addr directly. > > Does that work for you, or does it break some other script/use-case on > this board? Indeed, it's a possible option. However, if fdt_addr_r is not set, user can't override embedded FDT using extlinux.conf. README.distro says about fdt_addr_r: "This is mandatory even when fdt_addr is provided, since extlinux.conf must always be able to provide a DTB which overrides any copy provided by the HW." So it should be considered as a workaround rather than a solution. Best regards, Anton Leontiev