Hi Jerry, > 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.
Isn't this "natural" for a 64-bitter? >> 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. Why 4 bytes? 3 + 1 + 12 = 16 as stated. >>> or this also might work, >>> >>> struct NS16550 { >>> unsigned long rbr; >>> unsigned long pre_padrbr[3]; >>> : ^^^^ >>> : >>> }; > > Again, a stride of 4 bytes, *not* 16. 4 * sizeof(unsigned long) = 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). It's a 16-byte stride, although the register shows up neither at the top, nor at the low end, but "slightly to the left", i.e. at offset 0x3 ;) > 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. That's what my previous hack offered - REG_TYPE for the actual "size" of accesses and REG_SIZE for the stride. Now that you mention it, one should probably use REG_TYPE and REG_STRIDE... Cheers Detlev -- Cyberwar is certainly not a myth. But you haven't seen it yet, despite the attacks on Estonia. Cyberwar is warfare in cyberspace. And warfare involves massive death and destruction. When you see it, you'll know it. -- Bruce Schneier, Nov. 2007 -- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot