From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Wed, 27 Aug 2014 11:41:55 -0600 Subject: [U-Boot] [PATCH v2 01/40] vsprintf: Add modifier for phys_addr_t In-Reply-To: <20140827070101.GH15640@ulmo> References: <1409067268-956-1-git-send-email-thierry.reding@gmail.com> <1409067268-956-2-git-send-email-thierry.reding@gmail.com> <53FCBE38.9020304@wwwdotorg.org> <20140827070101.GH15640@ulmo> Message-ID: <53FE1863.8040906@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 08/27/2014 01:01 AM, Thierry Reding wrote: > On Tue, Aug 26, 2014 at 11:04:56AM -0600, Stephen Warren wrote: >> On 08/26/2014 09:33 AM, Thierry Reding wrote: >>> From: Thierry Reding >>> >>> Provide a new modifier to vsprintf() to print phys_addr_t variables to >>> avoid having to cast or #ifdef when printing them out. The %pa modifier >>> is used for this purpose, so phys_addr_t variables need to be passed by >>> reference, like so: >>> >>> phys_addr_t start = 0; >>> >>> printf("start: %pa\n", &start); >>> >>> Depending on the size of phys_addr_t this will print out the address >>> with 8 or 16 hexadecimal digits following a 0x prefix. >> >> The series, >> >> Tested-by: Stephen Warren >> >> Note that I did see the following printed a couple of times when I executed >> "run bootcmd_pxe": >> >> pci_hose_bus_to_phys: invalid physical address >> >> ... but everything worked perfectly, so I guess we can track that down >> later. > > Yes, it should definitely be tracked down. I don't see that message on > my setup. I've seen it for example when noncached_alloc() fails and > returns 0, but in that case everything shouldn't be working perfectly. It looks like it happens when "dhcp" or "pxe get" attempt to download a file that doesn't exist on the server. > It would be helpful if that message showed what physical address was > considered invalid. The address is 0. I think this is because rtl_recv() is being called after rtl_halt(). rtl_halt() NULLs out all tpc->RxBufferRing[] entries, so calling rtl_recv() after that tries to convert address 0 to a PCI address. I haven't fully tracked this down, but it seems like a bug in the U-Boot networking or TFTP core, rather than anything to do with drivers for R8169 or the Tegra PCIe controller. I'm not planning on tracking this down any further at the moment.