From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Thu, 17 Jan 2019 20:15:10 -0500 Subject: [U-Boot] Test failures in u-boot/master on NVIDIA HW with recent push In-Reply-To: <4494ad2a-7897-91b7-767c-2e8c2319b4e2@wwwdotorg.org> References: <8c6f43eb-c436-e000-35e0-df73dabe652a@wwwdotorg.org> <20190118004217.GJ27429@bill-the-cat> <4494ad2a-7897-91b7-767c-2e8c2319b4e2@wwwdotorg.org> Message-ID: <20190118011510.GK27429@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Jan 17, 2019 at 05:50:27PM -0700, Stephen Warren wrote: > On 1/17/19 5:42 PM, Tom Rini wrote: > >On Thu, Jan 17, 2019 at 05:34:57PM -0700, Stephen Warren wrote: > > > >>Tom, > >> > >>The recent set of patches pushed to u-boot/master cause DFU failures on both > >>Jetson TK1 and Jetson TX1 (i.e. all platforms where I run the DFU test) with > >>the following in the log: > >> > >>host: > >>dfu-util -a 0 -U /var/lib/jenkins/workspace/u-boot-denx_uboot-master-test-py/U_BOOT_BOARD/jetson-tk1/build/u-boot/jetson-tk1/dfu_readback.bin > >>-p 3-2.3 > >> > >>target: > >>** Reading file would overwrite reserved memory ** > >>dfu: Read error! > >>dfu_read: Failed to fill buffer > >>Tegra124 (Jetson TK1) # > >> > >>I noticed some lmb fixes in the list, so I guess it's due to that. > > > >So.. intentional! Adding in Simon here, but I think the short answer is > >that you need to change where you're saying the file goes in memory. > >FWIW I run the DFU test on my dra7xx_evm and it's passing. > > You applied a change which intentionally broke functionality??? That sounds > pretty bad... So, yes. A design decision / feature of "don't check where we're loading payloads to" is also a security vulnerability to bypass secure boot. So we now have changes in that make a good attempt at keeping us from loading a payload that can in turn overwrite ourself. And I merged it super early in the merge window to try and catch the unintended consequences. > Looking at the precise test that failed, we don't actually specify where the > data goes in memory; it's written to the filesystem and all memmory > locations are internally allocated by U-Boot. So when you say "you need to > change where you're saying the file goes in memory", do you mean via the DFU > altinfo variable (which does not specify a memory location in this case, so > I can't), or by modifying some board-/SoC-specific config file or code to > specify where DFU buffers data (in which case, I'd argue that a > backwards-compatible default should have been put in place to prevent > breaking functionality)? > > The DFU altinfo values that are tested on both boards are: > > Fails: > > Device mmc 1 (which is an SD card): > "alt_info": "/dfu_test.bin ext4 1 1;/dfu_dummy.bin ext4 1 1", > > All pass: > > Device mmc 1 (which is an SD card): > "alt_info": "/dfu_test.bin part 1 3;/dfu_dummy.bin ext4 1 1", > > Device mmc 1 (which is an SD card): > "alt_info": "/dfu_test.bin raw 4196352 18432;/dfu_dummy.bin ext4 1 1", > > Device ram > "alt_info": "alt0 ram 80000000 01000000;alt1 ram 81000000 01000000", So that's interesting. How big is dfu_test.bin? Checking my config, I don't have SD card only RAM. If you do RAM only tests does it pass (as that might narrow down where maybe something is wrong) ? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: