Recently, I've been trying to catch up with some of the technical debt that the FreeBSD/arm port has accumulated. Some of that technical debt was my fault, of course, but some of it wasn't. I don't really much care whose fault things were, but I would like to get things cleaned up. Some of these are paths not taken. Some are porting shims that never got properly connected. There's also some features that were poo-poo-ed by some (including me) years ago that seem to make more sense now.
None of this stuff is terribly sexy. Some of it will be addressed by the summer of code project that's working its way through some of the maze of twisty passages in initarm() that are subtly different between the different boards for no good reason.
We have no common place for boot loader code. Some arm ports do use a common routine to fake up just enough metadata that debugging and other symbols work. Some arm ports assume a full /boot/loader is present. However, there's no common facility for getting information from via the Linux boot protocol, nor is there any provisions for having multiple boards supported by a single kernel. There's no uniform interface to get this information that might be passed in by other means. There's no real way for a board to get control early enough to get at meta-data a custom boot loader might pass in.
The first big thing that I'd like to comment on is a small change to the interface between locore.S' _start routine and the first port-specific code in initarm. I've preserved the first 4 registers that were passed in on boot to _start(). Before, there'd be no way to access the Linux ATAGs, for example, by a port since these are passed in as arg 3. To allow for future expansion, I'm just passing in one structure now.
In the coming weeks, I'll be implementing routines to parse these arguments based on standard boot protocols, while allowing customization for special needs.
In the coming months, I plan to expand our support for having multiple boards based on a single Atmel SoC. Once I have the one at a time SoC code working, I hope to get multiple SoCs working in one kernel. While the extra 'bloat' isn't optimal for many users, the convenience of being able to boot one kernel for installation, or trying out the system, is a feature that's been much requested. I've already eliminated the need to have a compiled-in master clock frequency, with improved main clock detection with fallback for people using unconventional frequencies.
I'm also interested in sweeping into the tree many of the Atmel arm changes that have been accumulating in the PR database. Some of these will be easy to integrate, while others may be difficult due to drift from the original submission.
Once we get a good baseline, I hope to merge these changes into 9.x and 8.x. To date, the interfaces that have change have been purely internal ones we do not support. External users may experience some bumpy waves if they haven't been working to get their changes merged upstream. The more that you've submitted, the more I'm likely to go the extra mile to help smooth any transitions. With luck, 8.3 and 9.2 will both benefit from these efforts.
No comments:
Post a Comment