What code loads kernel modules at boot?

[Ian Lepore]

On Wed, 2019-04-17 at 21:44 -0600, Warner Losh wrote:
> On Wed, Apr 17, 2019 at 9:07 PM Ian Lepore <ian at freebsd.org> wrote:
> 
> > On Wed, 2019-04-17 at 20:52 -0400, Lee D wrote:
> > > A couple of years ago I wrote a FreeBSD bootloader for Zynq
> > > (Arm32).
> > > It's been working well, but now I need to add the ability to load
> > > kernel modules at boot.  This is for 11.0.1 (updating to 12 soon,
> > > hopefully).
> > > 
> > > Can anyone point me to the code that actually loads a kernel
> > > module
> > > for arm?  I got lost reading the source in /src/sys/boot/common,
> > > and
> > > can't quite figure out what routine is actually called.
> > > 
> > > I assume I need to parse the sections out of the .ko file and
> > > place
> > > them carefully in memory, like I do with the kernel image.
> > > 
> > > Also, if you're feeling loquacious, where do I put the darn thing
> > > and
> > > how do I tell the kernel how to find it (part of the MODINFO
> > > stuff I
> > > assume)?
> > > 
> > > This is all in the context of loading custom real time clock and
> > > I2C
> > > drivers so they are available at boot time.
> > > 
> > > Thanks,
> > > 
> > > 
> > 
> > The bulk of the module-loading code (the arch-independent part of
> > it)
> > is in src/stand/common/module.c.  There is also
> > archsw.arch_loadaddr,
> > which figures out where to put the modules (handling arch-specific
> > things like alignment requirements).
> > 
> 
> That code gets called from the command line commands, as well as
> indirectly
> in the .conf file parsing each of the interpretive languages have.
> 
> 
> > For some reason, I thought Zynq used u-boot.  That would allow
> > using
> > either ubldr or the arm uefi loader (depending on how old the u-
> > boot
> > is); those are just flavors of loader(8) that would get you module
> > handling and all the other loader goodness.
> > 
> 
> Yea, if the loader that he's written loads /boot/loader, he doesn't need to
> do anything. if it loads the kernel and modules, he'll need to do what the
> code in src/stand/common/module does in terms of laying out memory and
> passing the proper meta-data to the kernel.
> 
> 

It would have to do more than just load /boot/loader (or ubldr)... it
would have to provide some sort of bios-like services for loader to do
I/O.  I almost mentioned that in my original post... if you've got a
loader that can do disk I/O, it wouldn't be too hard to make it provide
the same API services that u-boot does, then ubldr would work.  What
you need to implement for the api isn't much more than some simple disk
read/write stuff, console read/write, and env var support (which could
be mostly stubbed out).

-- Ian