Alessandro Rubini wrote: >> From: Scott Wood <scottw...@freescale.com> > > Unfortunately freescale.com i.e. mail.global.frontbridge.com i.e. microsoft > has blacklisted me. I'm trying to do what they say but I fear you won't > get direct email.
Hmm, I've e-mailed the postmaster inquiring as to why. Is there a specific IP address or range that is being blocked? Is there a rejection message? >>> +static inline int parity(int b) /* b is really a byte; returns 0 or ~0 */ >> If it's really a byte, then why not tell the compiler this with uint8_t? > > Because otherwise it will add instructions to mask the value. OK. >>> + __asm__ __volatile__( > >> Why is this volatile? >> The underscores are unnecessary, BTW. > > Both for my own pedantry. volatile should be left off of pure calculations; you're just removing optimization opportunity. And I think the underscores are ugly. :-) >> Have you verified that this is noticeably better than C code? > > Well... it looked like I only checked without -O. I rechecked and the > result is the same. Ok, will switch to the C version. OK, good. >>> +/* >>> + * This is the ECC routine used in hardware, according to the manual. >>> + * HW claims to make the calculation but not the correction; so we must >>> + * recalculate the bytes for a comparison. >>> + */ >> Why must you recalculate? What does the hardware do with the ECC it >> calculates? > > It only makes it available. You must recalculate and compare. Makes what available? If it makes the calculated ECC available, you should only need to do the code in ecc_correct, not ecc512. > However, I haven't been able to make the hardware work (nor original vendor > code did actually use the hardware). OK, that seems to be the more relevant reason. :-) Include a comment to that effect. >>> + .oobfree = { {0x08, 0x08}, {0x18, 0x08}, {0x28, 0x08}, {0x38, 0x08} }, >>> +}; >> Any particular reason why bytes 0x05-0x07, 0x10-0x11, 0x15-0x17, >> etc. aren't marked free? > > Since most other ECC routines use 2..7 I chose to leave open the > possibility to switch over from 2..4. Is that wrong? It's not wrong as long as the free bytes you do claim meet all expected needs; I was just curious. >>> + len >>= 2; >> What if "len" isn't a multiple of 4? > > I thought it never is. This always reads either 512 or 64 > bytes. Aligned, too. Suppose it only wants to read a few bytes of OOB. >>> -#define CONFIG_SYS_NAND_BASE 0x40000000 >>> +#define CONFIG_SYS_NAND_BASE 0x40000000 /* SMPS0n */ >> What is "SMPS0n"? > > It's the chip select. OK. Just making sure it wasn't something left in by accident. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot