From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dirk Behme Date: Fri, 08 May 2009 17:10:56 +0200 Subject: [U-Boot] [PATCH] OMAP3EVM: net_chip uses CS5 not CS6 In-Reply-To: References: <1241614855-8087-1-git-send-email-mludwig@ultratronik.de> <4A01A4CD.2060605@googlemail.com> <19F8576C6E063C45BE387C64729E739404323ED93C@dbde02.ent.ti.com> <20090507071155.GA8961@ultratronik.de> <20090507083634.5ECB883420E8@gemini.denx.de> <4A02FB34.2090907@googlemail.com> <20090507185817.EDBFB83420E8@gemini.denx.de> <4A0333FC.6090900@freescale.com> <20090507204225.70EAE832C2FB@gemini.denx.de> <4A034B09.7030105@freescale.com> <20090507210425.1A06C832C2FB@gemini.denx.de> <4A034E49.8040704@freescale.com> Message-ID: <4A044B80.9050107@googlemail.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, Detlev Zundel wrote: > Hi, > >> Wolfgang Denk wrote: >>> Dear Scott Wood, >>> >>> In message <4A034B09.7030105@freescale.com> you wrote: >>>>> Or what replaced the "immr" structs? >>>> The device tree, mainly... >>> Right, of course. >>> >>>> ... But #defines can work for u-boot. >>> Of course they _can_ work. But they can easily fail (as we just see >>> in this patch), and we don't have typechecking. So until DT's are >>> omnipresent, let's use structs in U-Boot, please. >> You *do* have typechecking as long as the individual blocks are >> described with structs. >> >> We could take immap to extremes by defining one big 4GiB struct that >> shows where memory, immr, flash, desired PCI bars, FPGAs, etc. are -- >> but that would be silly. IMHO, so is doing it at the immr level. :-) >> >> How would you deal with blocks being at different locations in different >> chips? It's a lot easier to ifdef (or have the config file specify) a >> couple addresses than to ifdef the locations of fields in a struct, >> especially when you have more than a couple variations. > > For what its worth, I'm with Scott here. Structures for register blocks > is very nice and should be mandated and it seems they are maintainable. > Locations of individual blocks (or number of incarnations thereof) seem > to change frequently and thus tend to be less friendly to "whole > internal address space" structures. So the latter may better be mapped > by single defines. The correctness of them is easily validated and an > incorrect value will immediatley be discovered. I tend to agree with Scott and Detlev, too. At least from practical point of view http://www.ti.com/litv/pdf/spruf98b (attention: ~40MB) ;) Best regards Dirk