From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefan Roese Date: Thu, 28 Sep 2006 20:44:51 +0200 Subject: [U-Boot-Users] DCR register read/write for PPC440EP In-Reply-To: <406A31B117F2734987636D6CCC93EE3C043814@ehost011-3.exch011.intermedia.net> References: <406A31B117F2734987636D6CCC93EE3C043814@ehost011-3.exch011.intermedia.net> Message-ID: <200609282044.52630.sr@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Leonid, On Thursday 28 September 2006 18:58, Leonid wrote: > > What you really need, is an U-Boot command to set/get SDR registers, > > indirectly accessed via the DCR 0x0e/0x0f registers. Something > > like "setsdr/getsdr". > > [Leonid] I thought rather of some generic function, allowing indirect > access to DCR-related registers since 0xE/0xF is not only combination of > address/data - for EBC they use 0x12/0x13 for instance. To that end, GET > command must receive 3 "address" arguments - DCR address register, DCR > data register and offset while SET will also need a value. Please advice > on command's name. Something like that I guess: > > getidcr e f 0x40 > setidcr e f 40 0xbadd > > where "i" in the middle stays for "indirect". What do you think? Good idea. Much more flexible this way. I'm just thinking, if we really need this 2nd argument for the "DCR data register", since all "DCR data registers" I found upon a quick look into on of the AMCC manuals, are located at "DCR address register + 1". This way we would save one parameter, but would loose some flexibility. Best would be, if you made the 2nd paramter optional: getidcr e [f] 0x40 setidcr e [f] 40 0xbadd This way, you could decide upon the parameter count (argc), if the "DCR data register" is supplied or not. What do you think? > Now regarding implementation. Simplest way is to call > set_dcr()/get_dcr() from C code but that actually doesn't ensure that > the register under consideration was not overwritten in between. I can > disable interrupts, do you think it's OK? This is debug monitor function > after all, nobody cares regarding performance here... Yes, you should definitely disable the interrupts in this function. > > It would be best, if you could supply a proper patch > > with such additional commands. > > [Leonid] It will be quite a honor for me to serve this community. Can > you refer me to proper link how I do proceed with patch submission: > review, help information, actual sources delivering, etc... This is explained at the end of the README under "Submitting Patches:". And please also take a look at "Coding Standards:". Thanks. Best regards, Stefan