From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jerry Van Baren Date: Thu, 30 Apr 2009 08:52:58 -0400 Subject: [U-Boot] [PATCH] include/ns16550.h: Unify structure declaration for registers In-Reply-To: References: <1238769946-30370-1-git-send-email-dzu@denx.de> <49F2657D.5080706@ruby.dti.ne.jp> <49F5C0AA.2000401@ruby.dti.ne.jp> <49F8A196.60202@pobox.com> Message-ID: <49F99F2A.1070603@ge.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Detlev Zundel wrote: > Hello Shinya, > >> Detlev Zundel wrote: >>> As I said, I understand now why there were different data-types involved >>> although this was kind of non-obvious. So I take it, you had a working >>> configuration with REG_SIZE = 4, correct? >> I might be unclear. I used to use REG_SIZE = -16, as 16550 registers >> are located at 0, +0x10, +0x20, ..., . 16 byte stride. That is seriously odd. > Ah, so you actually maintain an out-of-tree port. How should I have > foreseen that I break something that I don't even have the code to? > >> In this case, I don't think REG_SIZE = 4/-4 works. Let's see: > > No surely not. My replies were based on the (wrong) assumption that > your board port was in U-Boot code. > >> What I need is something like this: >> >> struct NS16550 { >> unsigned char prepad_rbr[3]; >> unsigned char rbr; >> unsigned char postpad_rbr[12]; >> : >> : >> }; This is showing a stride of 4 bytes, *not* 16. >> or this also might work, >> >> struct NS16550 { >> unsigned long rbr; >> unsigned long pre_padrbr[3]; >> : ^^^^ >> : >> }; Again, a stride of 4 bytes, *not* 16. >> Makes sense? > > Although I can see what you need, I would be lying if I said that this > makes sense to me. > >>> Can you enlighten me, why exactly the 8-bit accesses do not work on your >>> hardware? Is this because of a "too simplistic" address decoding logic? >>> What endianness is your CPU using? >> I don't know much about precise hardware logics, but the byte addresses >> under 16-bytes-border are ignored. I'm using a big-endian mips machine. > > This does not make much sense to me, sorry. The "16" of the "16-bytes-border" statement confuses me too. It sounds like Shinya has some pretty odd (read "broken") hardware that is decoding the registers with a 16 byte stride, although his example above shows a 4 byte stride (less broken). I would further deduce his hardware does not support byte write operations (I've never seen hardware that didn't support byte reads). I've had hardware that did not support byte writes, so s/w needed to write a word instead (given Shinya's description, the extra bytes are "don't care"). (I've also dealt with flash connections that only supported 64 bit writes - PITA!). My guess is his processor limitations prevent byte writes so he has to do 32bit (4byte) writes, but his hardware decoding results in a 16 byte stride. The result is setting REG_SIZE to 4 gives him the r/w access he needs (32 bits), but fails the stride. Setting it to 16 gives him the stride he needs, but a 16 byte register is nonsensical and breaks the software. My guess is Shinya needs another customization dial (I'm making this up) "REG_STRIDE" = 16 as well as "REG_SIZE" = 4. [snip] Best regards, gvb