**** BEGIN LOGGING AT Tue May 03 02:59:56 2022 **** BEGIN LOGGING AT Tue May 03 07:44:59 2022 May 03 13:23:44 I was looking at the github.com BeagleBoard.org website stuff and github said I caused something serious and kicked me out. May 03 13:23:53 Is the site okay or is github okay on your side? May 03 13:25:56 Has anybody ever created a x-loader/MLO for MLC-NAND? In that strange proprietary TI format? May 03 13:27:12 TRM: 26.4.7.4.3 MLC NAND Read Sector Procedure May 03 13:27:50 that's a thing for the old beagleboard right? May 03 13:28:31 Yes, exactly. Only the first one have this NAND May 03 13:30:55 Forget it. Everything is back working and people stopped thinking I was spam. May 03 13:30:57 Blah. May 03 13:31:21 Guest61: lemme see how strange it is May 03 13:32:27 ohh right this omap3 doesn't even have ELM yet (the hardware BCH Error Location Module) May 03 13:33:30 Can't simply forget it. Have some devices in the field which start to fail booting because of bit flips. Strange thing: they fail (hamming code/default) - if one bit is flipped in the few OOB/ECC bytes. Damned. May 03 13:34:19 Yeah, TI created some strange stuff so make out of 1kbyte code 2 kbyte flash-content - really weird. May 03 13:35:09 (fail only in xloader, other than that is better protected of course) May 03 13:40:01 oh gosh, what an adorable tiny BCH code May 03 13:41:42 I guess this coding was never implemented in any uboot to flash xloader. Guess I need a tool to create an raw image and flash that (including OOB). May 03 13:41:59 How does other solve that? Just use SD card? May 03 13:42:26 I'm afraid I don't know anything about xloader or the boot process of the old beagleboard, this is from before my time May 03 13:42:43 I do understand the format they're describing and how to generate it, although presumably TI will have some tool for it May 03 13:47:11 I ask there (less hope). But it's old stuff and (with some luck) there is something in their archives. But I not found any request about such a tool. I could try to write such tools, but not sure I understand it. And a little mistake ... and it will not boot nor you can debug it. May 03 13:49:05 fun \o/ May 03 13:49:19 If you understand and lets assume the (payload) data are just 3 words: 0xaabb, 0x00ff, 0x350c - how would look like the CRC and the 12bit BCH for each word? May 03 13:49:26 but do you not have some known-good example you can simply reflash onto the iffy devices? May 03 13:49:39 no, the payload is always an entire 512-byte sector May 03 13:50:37 Sure, but that is padded with either 0x0000 of 0xffff - even that I have to check out. May 03 13:51:13 it splits the 512-byte sector into 256 16-bit words, calculates the checksum and appends it and three padding words, giving 260 16-bit words total May 03 13:52:57 and then BCH is applied to each 16-bit word separately, i.e. the 16-bit word is padded to 20 bits and then 12 ECC bits are added to that to give 32 bits total May 03 13:53:13 Reflash is ok to refresh, but can't do that cyclic. These boards are remote and I don't have access. I just can ask people to do  and update. May 03 13:53:40 (computation of those ECC bits is very similar to how you compute a CRC) May 03 13:54:14 Yes, I understand it like that. First a checksum + padding and than extending each 16bit word by another 16bit. May 03 13:54:14 I don't think I follow... your issue is that this x-loader is slowly getting corrupted beyond the ability of bootrom to repair right? May 03 13:55:01 in theory, if bootrom works correctly, it should be able to correct up to 2 bit errors in each 32-bit word May 03 13:55:24 Yes, devices fail after some time. So I need to repair them with a same xloader but packed into this format. That is my hope. May 03 13:56:34 okay, but like I said... don't you have a known-good version you can use for comparison? i.e. at boot check if any of those flash sectors have one or more bit errors and if so just reflash that part of NAND with a known-good version? May 03 13:56:42 The original bootcode for 1bit hamming can correct only 1 bit in 512byte. But that device I get back fail because one of the ECC bits flipped! May 03 13:57:13 I don't follow, there's no hamming code in the section you referring to, so you're talking about a different boot stage? May 03 13:57:43 I have a good xloader, but its protected by a simple hamming - that's what TI uses for SLC nand May 03 13:58:08 ohh, and you want to switch to this format to extra robustness? May 03 13:59:03 though even with the SLC format the same idea should be possible: with one bit error it should still boot, and then you can notice the bitflip and repair it May 03 13:59:47 Sorry, talking about x-loader, which is read by hardcoded ROM in SoC. And this Bootcode loads x-loader out of NAND. This xloader needs a better error correction. Instead of the default 1 bit hamming, this weird CRC/BCH combination. May 03 13:59:48 (and pray the device doesn't power off right at the moment you're doing this... lol) May 03 14:00:11 okay yeah, I get it now May 03 14:00:51 so you *don't* have a known-good template, since you only have those for SLC format with a hamming code, not for this much more robust MLC format May 03 14:01:21 Current xloader will be repaired, but obviously (tested) not if ECC bits filp. Which is less likely as their are only a few, but it happens. May 03 14:02:00 that's weird, ECC algorithms normally don't care whether it's a data bit or ECC bit that flips May 03 14:02:31 Right, not a sample for this weird coding. Never seen that or heard about before. May 03 14:03:05 the problem is that I'm not sure this description in the TRM is actually sufficiently detailed to generate this format May 03 14:03:07 Nevertheless my only chance is this BCH/Checksum coding. May 03 14:03:22 e.g. the bit-endianness is not really clear May 03 14:03:35 Yes, here we are.... that's my problem. May 03 14:03:36 well, hmm May 03 14:04:13 Only chance to do some best guesses, but ... no debug. Just fire and pray. May 03 14:05:01 right, but fortunately there aren't that many options for endianness ;) May 03 14:05:46 lemme think if I can guess what they mean here May 03 14:06:25 they seem to be using little endian byte-order for the 16- and 32-bit words May 03 14:06:47 To start simple - what would be the checksum? Just added and skip higher bits? May 03 14:06:48 well, for the 32-bit words at least, so presumably also for the 16-bit words May 03 14:07:18 yeah just add 'em... they say "modulo 16" but that's almost certainly a typo for module 2-to-the-power-of-16 May 03 14:07:28 *modulo May 03 14:07:52 i.e. just interpret the sector as an uint16_t[256] and add those together May 03 14:08:40 aabb+ff+350c = e0c6 May 03 14:09:23 yep May 03 14:11:56 They mention: stream is: BCH[3..0], BCH[11..4]+0000b, Byte0, Byte1, BCH[3..0], BCH[11..4]+0000b, Byte3, Byte4, … May 03 14:12:25 yeah, those are the 32-bit words, in little-endian byte-order May 03 14:12:34 ehh May 03 14:12:43 except with mistakes, lol May 03 14:12:51 what is this extra +b ??? And how to calculate 12bit BCH out of 16bit? May 03 14:13:02 I'm working on that calculation May 03 14:13:20 hold on, lemme see if a TRM of a later omap3 happens to describe this same algorithm with less typos and mistakes May 03 14:14:56 with 0000b they mean the four zero bits, and with + they mean concatenation... but they messed up since BCH[11..4] are 8 bits and BCH[3..0] are four bits May 03 14:15:12 they've got to mean BCH[7..0], 0000b+BCH[11..8] May 03 14:15:27 all in all, not very confidence-inspiring May 03 14:16:48 8+4 = 12bit ECC, that is right May 03 14:17:19 0000b b=binary! I though 0xb .... May 03 14:18:09 Now I understand. And how do calculation of BCH[11..0] works? May 03 14:19:10 I guess this is some quick and dirty workaround because original hardware 4 bit ECC was buggy (according to Errata). May 03 14:27:33 no the issue is that the omap3 only implements the ECC calculation in hardware, but error correction has to be done in software May 03 14:27:49 and doing error correction for the large whole-sector BCH codes is too complicated to do in bootrom May 03 14:28:23 like, just for fun, browse the source code of the BCH error correction implementation in the linux kernel: https://elixir.bootlin.com/linux/latest/source/lib/bch.c May 03 14:30:00 You are right. Mh guess I have to ask someone who is better in math than me. I don't get how this 12bits are generated. I' checked what is in uboot already, but honestly - this is beyond my brain. May 03 14:30:57 yeah I was working on writing a code snippet for that, but I had to go for a moment, give me a few moments May 03 14:31:05 If solved that I need to linear write to flash, so use OOB data as it would be normal payload. That is another hurdle. May 03 14:31:30 Yes, I will stay online... May 03 14:54:42 Guest61: https://pastebin.com/StYv6FnL here's my stab at it May 03 14:55:12 I've not checked whether the output of omap3_mlc_bch() passes the verification of omap3_mlc_bch_verify() ... which would be a good first test to do May 03 14:55:32 assuming it compiles, I haven't even tried that ;) May 03 14:58:04 Thanks I will go and check this tomorrow. I will give you a sign ... you are here usually? May 03 14:58:48 yeah, my response time can vary depending on whether I'm busy or sleeping or whatever, but if you say something to me here I'll read it eventually May 03 14:59:41 I'm somewhat slower than you, guess I need some time. Probably will do a little tool creating that image and try to push it with nandwrite to flash. May 03 15:00:32 and if the first attempt doesn't work, try changing the first line from #if 1 to #if 0 May 03 15:01:51 That seems to me smallest effort to test. I just hope that (even if this works) it has no influence to the next boot-step. I mean it will switch internally to this weird mode, - who know what will happen. Probably I am the only one ever try to use it. May 03 15:02:22 btw, you mentioned the bch4 erratum May 03 15:03:01 I actually posted a workaround to that erratum too: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/349230/bch4-syndrome-calculation May 03 15:03:57 oh, looks like the link to the code is dead, that's a shame May 03 15:04:48 Mh, but thats anothe generator polynom (whatever it does). May 03 15:05:11 yeah that's a completely separate thing May 03 15:05:50 Ok, thanks - time for rest! I am feeling less lost now. May 03 15:06:00 it's for 4-bit error correction per 512-byte sector (as opposed to the scheme used by bootrom for MLC, which gives 2 bits of error correction *per 16 bits of data*) May 03 15:08:04 Yes, it needs less space. In our case we almost double the code 16 + 12 ! May 03 15:14:48 yep, this ECC is very wasteful, but presumably it makes error correction easy May 03 15:14:53 easy enough for bootrom May 03 17:01:43 Hi, May 03 17:02:04 Do you know which software is used on Windows to write the image to microSD May 03 17:02:06 ? May 03 17:03:39 Me? May 03 17:03:45 Etcher. May 03 17:03:54 Use Etcher instead of dd on Linux. May 03 17:04:29 On Windows, Etcher works. May 03 17:04:47 There are a few more that work but that should do it. GUI! May 03 17:06:36 or...if you are handy w/ WSL2, you can try that idea. It seems a bit difficult to get the /media/$USER/SD_CARD to show up in the WSL2 instance. May 03 17:07:08 I have tried over and over. They even have ideas on it. But! I think they were making things up. It does not work for me. May 03 17:11:08 Anyway, if it was not for it being around WSLinux, I would not post it but here are the examples that do not work: https://devblogs.microsoft.com/commandline/connecting-usb-devices-to-wsl/ . One would need a 22000 preview, insider build to handle this development and it is not working. May 03 17:11:51 Try Linux if you got one. dd! May 03 17:12:21 That longest part to dd is the formatting of the drive. It takes forever... May 03 17:43:53 ok thank you May 03 18:06:57 jfsimon1981: did you make it work yet? May 03 18:13:22 i'm making all sort of things, May 03 18:13:32 an installer, so on. May 03 18:13:54 I flashed under linux but the client has windows May 03 18:19:08 Oh. May 03 18:19:47 Okay. Whelp, more power to you. Never quit for my sake. I always need more, more, more Linux-BBB times. May 03 18:20:21 indeed it's a lot of work and stuff to learn May 03 18:26:09 Right. May 03 18:26:38 I am trying to get a masters degree now. I am some hillbilly LA person looking to a new york university for edu! May 03 18:26:39 ha. May 03 18:28:31 The only thing missing is a feather in my hat called Macaroni. May 03 18:34:46 If I am accepted, I am going broke! If I can pass, I am McDugal for the year. May 03 18:35:15 @zmatt: Are you still working on that lib. and adding PWM instances to it? May 03 18:37:17 You just left it to rot? Well, I need to build more anyway. I should not have to rely. May 03 19:01:15 bbl! May 03 21:59:22 I made it back! **** ENDING LOGGING AT Wed May 04 02:59:56 2022