From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Jackson Date: Tue, 01 Sep 2009 16:56:46 +0100 Subject: [U-Boot] [PATCH] atngw100: Use virtual address in CONFIG_ENV_ADDR In-Reply-To: <20090901172047.28e67875@hskinnemoen-d830> References: <1251448970-15252-1-git-send-email-haavard.skinnemoen@atmel.com> <20090831155327.62b58f8f@hskinnemoen-d830> <20090831174610.D5FF3834A950@gemini.denx.de> <20090901105752.5bb77fc0@hskinnemoen-d830> <20090901094705.02BCB834A950@gemini.denx.de> <20090901123829.55fcb24e@hskinnemoen-d830> <20090901110555.A185F834A950@gemini.denx.de> <20090901134257.59961e79@hskinnemoen-d830> <20090901130443.EF801834A950@gemini.denx.de> <20090901152305.68e8d339@hskinnemoen-d830> <20090901172047.28e67875@hskinnemoen-d830> Message-ID: <4A9D443E.9080702@mimc.co.uk> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Haavard Skinnemoen wrote: > Right...I'm beginning to doubt that anyone is familiar enough with the > u-boot code, since everyone seems to have their own opinion about how > things are supposed to work. > > To summarize, here are the possible ways to fix the problem as I see it: > - Use virtual address in CONFIG_ENV_ADDR to conform with the way the > CFI driver currently works. Rejected by Wolfgang because virtual > addresses don't exist. > - Fix the API and user interface breakage by reverting commit > 09ce9921. Rejected because virtual addresses are used everywhere. > - Fix it by using map_physmem() in a way that works for all > architectures. Rejected because all other architectures than PPC > are evil and need to be punished for doing things differently. Your "triple revert" patch doesn't look overly complex, and seems to only add a few map_physmem() calls (I'm summarising *quite* a bit there !!). Is there not some way using weak functions (or similar) to add some AVR32 specific workarounds. Or ... there's *plenty* of arch specific #ifdefs in most of the rest of u-boot, so could we not just "#ifdef AVR32" the existing code for the time being until this sticking point gets unstuck ? > - Introduce a custom flash driver for ATNGW100. Rejected because > stupid principles are more important than making things work. > > So I don't really know where to proceed from here. I guess two > additional options are forking the damn thing or creating a proprietary > bootloader, but I don't really want to do either. Me neither !! Mark