Aaron Durbin wrote:
I guess JEDEC does have a structured format. Maybe it's XML or JSON. :)
I don't believe JEDEC has a format. And the one thing missing here is that there is no standard way of distributing these files. In fact, I've mainly seen spreadsheets as a form of distribution from the memory manufacturers.
Nod, then we would be creating the format.
The issue is that spds are for dimms while soldered down dram aren't dimms. The spds provide the illusion of an actual dimm to the memory training code which needs specific values. And because of this those files need to be edited at times because of errors.
Right, "accidental review" as these data sets pass by humans in the review process is a good reason for a text-based format. Editing, well, whether I edit a hex dump or use hexedit to edit a binary really doesn't make a big difference - in which case I strongly favor requiring developers who make edits to have more tooling, over requiring new tooling at build time.
FWIW, LPDDR has the ability to be queried on the command bus so these constructs should go away over time.
Old boards stay in the tree.
Fixing structure is more important IMO and shouldn't need to block on that.
What's the specific structural gripe you have? The snippet of duplicated Makefile code?
Code and data in mainboard directories for components which are not the mainboard.
//Peter
2015-10-23 17:48 GMT+02:00 Peter Stuge peter@stuge.se:
Code and data in mainboard directories for components which are not the mainboard.
In this case, they _are_ "the mainboard" just like magic numbers for USB trace lengths are. That stuff describes soldered-on components, it can't be more "mainboard" than that.
Patrick