From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aggelos Manousarides Date: Wed, 07 Nov 2007 13:43:32 +0200 Subject: [U-Boot-Users] Spartan FPGA patch In-Reply-To: <20071105192158.E9101247F4@gemini.denx.de> References: <20071105192158.E9101247F4@gemini.denx.de> Message-ID: <4731A4E4.20308@inaccessnetworks.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Wolfgang Denk wrote: > In message <472F1393.7040306@inaccessnetworks.com> you wrote: >> Wolfgang Denk wrote: >>> In message <472752F9.9000307@inaccessnetworks.com> you wrote: >>>> The following patch fixes a bug in the slave serial programming mode for >>>> the xilinx spartan2 FPGA. A "char val" is declared, but it is used as a >>>> signed char. The check for negative value (<0) is always true on arm, or >>>> any other platform in which the char is not signed by default. As a >>>> result the FPGA cannot be programmed. >>> I have to admit that I hate to see "signed char" in the code. Is >>> there any special reaso why "val" has to be a "char" type? Why not >>> making it an "int" ? >> Another way to do this safely is to declare it as an "unsigned char" and >> instead of doing "val < 0", do "val & 0x80". I don't like the current >> code either. Shifting a signed char and testing for negativity is >> definitely not the best way to test that the MSB is set. > > So let me repeat my question: is there any special reason why "val" > has to be a "char" type? Why not making it an "int" ? Because you will run into endianness problems. You want to treat an "unsigned char" buffer as a bitstream, reading the MSB every time. How are you going to do this portably (in both big and little endian architectures) with an "int" type, which is at least 2 bytes wide? -- Angelos Manousaridis