By adding a resolver to a given glyph set, the glyph set is
automatically pulled into the image.
Glyph set is now co-located in the bao-video process, instead
of the loader.
The orignial argument for putting the font data in the loader
is that it's a large, static blob; by putting it in the loader,
updates can be more compact, and fonts don't need to be schlepped
over every time you have an application update.
This came with consequences. It made verifying the loader more
complicated (because its memory space is split between the graphics
manager and root keys). It also means we have to fix the partition
size for the loader at "fairly large" for fonts, even if we don't
need all of them in all of the configs.
With baochip, we have swap memory! Off-chip memory is cheap and
only the fonts actually used by the host get mapped into main memory.
This means we don't have as much of a trade-off in terms of
cost for fonts if we put them in off-chip swap storage. Also,
the updates are split between swap and main memory, and the roadmap
includes an item for swap to be individually loadable programs
so that if the video server doesn't need an update, it won't be
pulled into the update set.
The code base had evolved through several code names, interim
names, company names and chip names that alternatively did or did
not exist.
Baochip is the definitive name of the company, and the Baochip1x
(full part number BAO1X2S4F-WA) is the definitivey part number of
the SoC. For convenience, the part number is shortened to 'bao1x'
in most feature flags and variable references.
This commit fixes all of the odd names and removes some unmaintained
early targets.
This was introducing a mysterious "line" artifact on text rendering
in new systems.
Probably need to do some real on-device testing of this change
because the automated tests won't catch a dirty bit error on
the LCD.
