lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <20141106015716.GB7642@shlinux1.ap.freescale.net> Date: Thu, 6 Nov 2014 09:57:17 +0800 From: Dong Aisheng <b29396@...escale.com> To: Oliver Hartkopp <socketcan@...tkopp.net> CC: Marc Kleine-Budde <mkl@...gutronix.de>, <linux-can@...r.kernel.org>, <wg@...ndegger.com>, <varkabhadram@...il.com>, <netdev@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org> Subject: Re: M_CAN message RAM initialization AppNote - was: Re: [PATCH V3 3/3] can: m_can: workaround for transmit data less than 4 bytes On Wed, Nov 05, 2014 at 07:15:10PM +0100, Oliver Hartkopp wrote: > Hi all, > > just to close this application note relevant point ... > > I got an answer from Florian Hartwich (Mr. CAN) from Bosch regarding > the bit error detection found by Dong Aisheng. > > The relevant interrupts IR.BEU or IR.BEC monitor the message RAM: > > Bit 21 BEU: Bit Error Uncorrected > Message RAM bit error detected, uncorrected. Controlled by input > signal m_can_aeim_berr[1] generated by an optional external parity / > ECC logic attached to the Message RAM. An uncorrected Message RAM > bit error sets CCCR.INIT to ‘1’. This is done to avoid transmission > of corrupted data. > > 0= No bit error detected when reading from Message RAM > 1= Bit error detected, uncorrected (e.g. parity logic) > > Bit 20 BEC: Bit Error Corrected > Message RAM bit error detected and corrected. Controlled by input > signal m_can_aeim_berr[0] generated by an optional external parity / > ECC logic attached to the Message RAM. > > 0= No bit error detected when reading from Message RAM > 1= Bit error detected and corrected (e.g. ECC) > > --- > > The Message RAM is usually equipped with a parity or ECC functionality. > But RAM cells suffer a hardware reset and can therefore hold > arbitrary content at startup - including parity and/or ECC bits. > > So when you write only the CAN ID and the first four bytes the last > four bytes remain untouched. Then the M_CAN starts to read in 32bit > words from the start of the Tx Message element. So it is very likely > to trigger the message RAM error when reading the uninitialized > 32bit word from the last four bytes. > > Finally it turns out that an initial writing (with any kind of data) > to the entire message RAM is mandatory to create valid parity/ECC > checksums. > > That's it. > Thanks for sharing this information. Does it mean this issue is related to the nature of Message RAM and is supposed to exist on all M_CAN IP versions? > Regards, > Oliver > Regards Dong Aisheng -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists