I've done DRAM training from scratch with custom boards before. It's not impossible, but it is a lot of work, and it doesn't stop once you get the first boards out of the lab, as you run into new edge cases throughout production. I had to release firmware updates once to support 10 boards that got built with the wrong fiberglass material (these were $10k+ boards, so worth not scrapping them) that caused the timings to change slightly. Things might work at initial boot for a while then crash, as you find you have to retrain if ambient temps change too much and you're on the edge of the signal eye. We even had Micron make us special DIMMs that met more specific timings so we had more margin. You just give them the parameters, and they dial them into their tester to bin specific parts for you. That said, I definitely wouldn't want to do it on anything but a custom board where there's total control. Handling all the edge cases for memory quality, temps, power, etc. that a consumer-grade motherboard would see would be nuts.
There is zero (or even , -1) accepted standard for platform initialization / boot sequencing on ARM (cue XKCD "23 standards"). Syslinux, LILO, GRUB, systemd-boot, none of them wanted to develop branches for every ARM snowflake until some agreement was reached. UEFI was there, and one bad option adopted by everyone is better than everyone pulling across purposes (witness MS-DOS, Windows, X11 and Linux)
This is way beyond me but I have learned a few things. Good talk. If someone can tell me how the open source firmware efforts are doing with regards to these concerns that would be great.
Gosh, what Oxide is doing here is real dope shit but it's gonna be hard to interest the mainstream with those topics...
I've done DRAM training from scratch with custom boards before. It's not impossible, but it is a lot of work, and it doesn't stop once you get the first boards out of the lab, as you run into new edge cases throughout production.
I had to release firmware updates once to support 10 boards that got built with the wrong fiberglass material (these were $10k+ boards, so worth not scrapping them) that caused the timings to change slightly. Things might work at initial boot for a while then crash, as you find you have to retrain if ambient temps change too much and you're on the edge of the signal eye. We even had Micron make us special DIMMs that met more specific timings so we had more margin. You just give them the parameters, and they dial them into their tester to bin specific parts for you.
That said, I definitely wouldn't want to do it on anything but a custom board where there's total control. Handling all the edge cases for memory quality, temps, power, etc. that a consumer-grade motherboard would see would be nuts.
There is zero (or even , -1) accepted standard for platform initialization / boot sequencing on ARM (cue XKCD "23 standards"). Syslinux, LILO, GRUB, systemd-boot, none of them wanted to develop branches for every ARM snowflake until some agreement was reached. UEFI was there, and one bad option adopted by everyone is better than everyone pulling across purposes (witness MS-DOS, Windows, X11 and Linux)
This is way beyond me but I have learned a few things. Good talk.
If someone can tell me how the open source firmware efforts are doing with regards to these concerns that would be great.