<zmatt>
that's a thing for the old beagleboard right?
<Guest61>
Yes, exactly. Only the first one have this NAND
<set_>
Forget it. Everything is back working and people stopped thinking I was spam.
<set_>
Blah.
<zmatt>
Guest61: lemme see how strange it is
<zmatt>
ohh right this omap3 doesn't even have ELM yet (the hardware BCH Error Location Module)
<Guest61>
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.
<Guest61>
Yeah, TI created some strange stuff so make out of 1kbyte code 2 kbyte flash-content - really weird.
<Guest61>
(fail only in xloader, other than that is better protected of course)
<zmatt>
oh gosh, what an adorable tiny BCH code
<Guest61>
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).
<Guest61>
How does other solve that? Just use SD card?
<zmatt>
I'm afraid I don't know anything about xloader or the boot process of the old beagleboard, this is from before my time
<zmatt>
I do understand the format they're describing and how to generate it, although presumably TI will have some tool for it
lucascastro has joined #beagle
<Guest61>
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.
<zmatt>
fun \o/
<Guest61>
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?
<zmatt>
but do you not have some known-good example you can simply reflash onto the iffy devices?
<zmatt>
no, the payload is always an entire 512-byte sector
<Guest61>
Sure, but that is padded with either 0x0000 of 0xffff - even that I have to check out.
<zmatt>
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
<zmatt>
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
<Guest61>
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.
<zmatt>
(computation of those ECC bits is very similar to how you compute a CRC)
<Guest61>
Yes, I understand it like that. First a checksum + padding and than extending each 16bit word by another 16bit.
<zmatt>
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?
<zmatt>
in theory, if bootrom works correctly, it should be able to correct up to 2 bit errors in each 32-bit word
<Guest61>
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.
<zmatt>
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?
<Guest61>
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!
<zmatt>
I don't follow, there's no hamming code in the section you referring to, so you're talking about a different boot stage?
<Guest61>
I have a good xloader, but its protected by a simple hamming - that's what TI uses for SLC nand
<zmatt>
ohh, and you want to switch to this format to extra robustness?
<zmatt>
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
<Guest61>
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.
<zmatt>
(and pray the device doesn't power off right at the moment you're doing this... lol)
<zmatt>
okay yeah, I get it now
<zmatt>
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
<Guest61>
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.
<zmatt>
that's weird, ECC algorithms normally don't care whether it's a data bit or ECC bit that flips
<Guest61>
Right, not a sample for this weird coding. Never seen that or heard about before.
<zmatt>
the problem is that I'm not sure this description in the TRM is actually sufficiently detailed to generate this format
<Guest61>
Nevertheless my only chance is this BCH/Checksum coding.
<zmatt>
e.g. the bit-endianness is not really clear
<Guest61>
Yes, here we are.... that's my problem.
<zmatt>
well, hmm
<Guest61>
Only chance to do some best guesses, but ... no debug. Just fire and pray.
<zmatt>
right, but fortunately there aren't that many options for endianness ;)
<zmatt>
lemme think if I can guess what they mean here
<zmatt>
they seem to be using little endian byte-order for the 16- and 32-bit words
<Guest61>
To start simple - what would be the checksum? Just added and skip higher bits?
<zmatt>
well, for the 32-bit words at least, so presumably also for the 16-bit words
<zmatt>
yeah just add 'em... they say "modulo 16" but that's almost certainly a typo for module 2-to-the-power-of-16
<zmatt>
*modulo
<zmatt>
i.e. just interpret the sector as an uint16_t[256] and add those together
<Guest61>
aabb+ff+350c = e0c6
<zmatt>
yep
<Guest61>
They mention: stream is: BCH[3..0], BCH[11..4]+0000b, Byte0, Byte1, BCH[3..0], BCH[11..4]+0000b, Byte3, Byte4, …
<zmatt>
yeah, those are the 32-bit words, in little-endian byte-order
<zmatt>
ehh
<zmatt>
except with mistakes, lol
<Guest61>
what is this extra +b ??? And how to calculate 12bit BCH out of 16bit?
<zmatt>
I'm working on that calculation
<zmatt>
hold on, lemme see if a TRM of a later omap3 happens to describe this same algorithm with less typos and mistakes
<zmatt>
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
<zmatt>
they've got to mean BCH[7..0], 0000b+BCH[11..8]
<zmatt>
all in all, not very confidence-inspiring
<Guest61>
8+4 = 12bit ECC, that is right
<Guest61>
0000b b=binary! I though 0xb ....
<Guest61>
Now I understand. And how do calculation of BCH[11..0] works?
<Guest61>
I guess this is some quick and dirty workaround because original hardware 4 bit ECC was buggy (according to Errata).
<zmatt>
no the issue is that the omap3 only implements the ECC calculation in hardware, but error correction has to be done in software
<zmatt>
and doing error correction for the large whole-sector BCH codes is too complicated to do in bootrom
<Guest61>
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.
<zmatt>
yeah I was working on writing a code snippet for that, but I had to go for a moment, give me a few moments
<Guest61>
If solved that I need to linear write to flash, so use OOB data as it would be normal payload. That is another hurdle.
<zmatt>
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
<zmatt>
assuming it compiles, I haven't even tried that ;)
<Guest61>
Thanks I will go and check this tomorrow. I will give you a sign ... you are here usually?
<zmatt>
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
<Guest61>
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.
<zmatt>
and if the first attempt doesn't work, try changing the first line from #if 1 to #if 0
<Guest61>
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.
<zmatt>
oh, looks like the link to the code is dead, that's a shame
<Guest61>
Mh, but thats anothe generator polynom (whatever it does).
<zmatt>
yeah that's a completely separate thing
<Guest61>
Ok, thanks - time for rest! I am feeling less lost now.
<zmatt>
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*)
<Guest61>
Yes, it needs less space. In our case we almost double the code 16 + 12 !
Guest61 has quit [Quit: Client closed]
<zmatt>
yep, this ECC is very wasteful, but presumably it makes error correction easy
<zmatt>
easy enough for bootrom
rob_w has quit [Read error: Connection reset by peer]
<jfsimon1981>
Hi,
<jfsimon1981>
Do you know which software is used on Windows to write the image to microSD
<jfsimon1981>
?
Shadyman has joined #beagle
<set_>
Me?
<set_>
Etcher.
<set_>
Use Etcher instead of dd on Linux.
<set_>
On Windows, Etcher works.
<set_>
There are a few more that work but that should do it. GUI!
<set_>
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.
<set_>
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.
<set_>
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.
<set_>
Try Linux if you got one. dd!
<set_>
That longest part to dd is the formatting of the drive. It takes forever...
<jfsimon1981>
ok thank you
Guest23 has joined #beagle
Guest23 has quit [Client Quit]
<set_>
jfsimon1981: did you make it work yet?
otisolsen70_ has joined #beagle
<jfsimon1981>
i'm making all sort of things,
<jfsimon1981>
an installer, so on.
<jfsimon1981>
I flashed under linux but the client has windows
otisolsen70 has quit [Ping timeout: 256 seconds]
otisolsen70_ has quit [Client Quit]
otisolsen70 has joined #beagle
<set_>
Oh.
<set_>
Okay. Whelp, more power to you. Never quit for my sake. I always need more, more, more Linux-BBB times.
<jfsimon1981>
indeed it's a lot of work and stuff to learn
<set_>
Right.
<set_>
I am trying to get a masters degree now. I am some hillbilly LA person looking to a new york university for edu!
<set_>
ha.
<set_>
The only thing missing is a feather in my hat called Macaroni.
<set_>
If I am accepted, I am going broke! If I can pass, I am McDugal for the year.
<set_>
@zmatt: Are you still working on that lib. and adding PWM instances to it?
<set_>
You just left it to rot? Well, I need to build more anyway. I should not have to rely.
vagrantc has joined #beagle
<set_>
bbl!
otisolsen70_ has joined #beagle
otisolsen70 has quit [Ping timeout: 240 seconds]
doppo has quit [Ping timeout: 240 seconds]
doppo has joined #beagle
otisolsen70_ has quit [Quit: Leaving]
starblue has quit [Ping timeout: 276 seconds]
lucascastro has quit [Remote host closed the connection]
florian has quit [Killed (NickServ (GHOST command used by florian_kc!~florian@dynamic-093-133-074-167.93.133.pool.telefonica.de))]
florian_kc has joined #beagle
vagrantc has quit [Quit: leaving]
<set_>
I made it back!
balrog has quit [Quit: Bye]
balrog has joined #beagle
Guest76 has joined #beagle
Guest76 has quit [Ping timeout: 252 seconds]
jfsimon1981 has quit [Ping timeout: 246 seconds]
ikarso has quit [Quit: Connection closed for inactivity]