I tried to ask in the other thread where are your hands or how to take you by the hand.
I'm not sure if trying to help here I'll be able to help or I'll just waste other people's time.
Hey, I did not forget you
The plan is to discuss the whole topic with EvilDragon during our 5 hour trip to the Gamescom.
I personally did not look into it ever and have no idea how to build it.
So what we need is
- A tutorial how to change settings and put them on a boot SD card
- A way to do it somewhat efficiently so it does not take 15 minutes to build the whole thing (no idea if that is an issue)
I don't know enough about the hardware. Not sure if getting some parameters wrong in the DRAM timings could damage the hardware permanently somehow.
If you're desesperate enough, because the hardware you might damage is going to the dust bin anyway, then I guess it should be OK.
If there's some suspicion that the hardware might be permanently damaged by the test, the problem is that then you may not want to test twice on the same board
(because the second test might be the right solution, but not working because the first test damaged the hardware).
And that may be wasteful of boards.
Edit: But worse than waste, you are not sure all your defective boards are equally defective,
or need the same RAM timings, so not trying everything on the same board is a problem too.
Edit2: A compromise could be: make a list beforehand of the test you want to do. Do them all on one board, then on the next board do a different permutation of the same tests.
There's of course a combinatory explosion to take into account, but it's better than nothing, I guess.
The change of order does not need to be random if you have some intuition of which tests are more risky to damage hardware. You could start by the safest.
No worries, there is no risk to permanently damage the PCBs.
As far as I understand, the current situation is that to change DRAM timings one needs to:
0 install the build tooling and git. That might be easier on a similar system, like a Pyra, than on a computer where you need to cross compile.
1 download the U-boot source code for the Pyra. Configure it for building the Pyra boot loader and not for some other machine.
2 edit(*) the source code for MLO (=U-boot SPL = U-Boot 1st stage), Commit or document your changes somehow.
3 recompile the MLO. That may be slower on a Pyra or similar system than in a more powerful computer where you cross compile.
4 install it to a Pyra
5 boot to test. Document your tests.
6 since it didn't work, go back to 2.
(*) The first time you try step 2 you don't edit anything, just build a pristine MLO to test that it works on a workign board, so that you know
you're compiling things right.
How many of those steps do you already know how to do and how many could someone help you do ?
Can you use a Debian system to do it?
Which architecture is your debian system on ?
Basically all I know is how to install git.
It would be super helpful to get a tested README or tutorial of any sorts on how to do the other steps.
We both are experienced with Linux and I am a programmer by profession.
The issue is time. We do not have time to figure it all out by our own.
Cross compiling is a thing, if someone will make a build environment for us. Maybe a Docker image.
Else compiling on a Pyra is fine for me, depending on how long the build takes.
The alternative would be to change MLO so that it loads the setting from some place, and then write a program that is able to write the settings in that place.
The program that writes the settings in that place could be made more or less user friendly relatively easy.
But changing MLO to load the settings from somewhere is difficult, because MLO does not have all the computer ready to work when loading things.
Remember that at that time, it can't even use RAM, because it's not yet initialized, So let alone OS functionality or most libraries. MLO binary code should also be space constrained somehow. You can't write all the code you want because it won't fit in SRAM, cache as RAM or whatever it is. In U-Boot some TPL or SPL stages are able to load the next stage (so then they should be just as able to load RAM settings) and some are not able and have to request it from bootrom or some external system.
So it's not ordinary C programming, although something should be doable.
A third alternative would be some way to edit an MLO binary to just change some constant where the RAM settings are, without needing to recompile.
Could be so easy as: Put some UUID in a constant in the code. Put the RAM settings constant next, put some UUID right after it. Persuade the compiler not to suppress those useless UUIDs that nothing is using.
Use a binary editor to change the constant between the 2 UUIDs. Install the edited binary MLO and test.
But I find that dirty.
I do not think those are options we should consider if not absolutely necessary.