From owner-freebsd-hackers@freebsd.org Thu Apr 18 03:51:13 2019 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BF4F1586636 for ; Thu, 18 Apr 2019 03:51:13 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound3d.ore.mailhop.org (outbound3d.ore.mailhop.org [54.186.57.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7D5C7743E0 for ; Thu, 18 Apr 2019 03:51:12 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1555559471; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=nu1ycIaJXMNJbSm/oL9o0ZlZMEh5TyVXJgiPVfXBm/kyHxjrCKX6zfXWN9Qo8fBhRaa4d4GqFzOIc Zu4g7NqPu1TxjH1/f3pTgoxDs6xuiRBkYEm1tybVFpi5oMwpINQotZ5vYl3/PgvFIYfmgtwEMHgM+d +xeR8/nBw0vPB3JCJRSyuSsAJ2N70mo4ByRJM7z9TTqV+aFDF5u2fgPRyuucQrNonewyxst54Z6zbp E/zQ7fXwp/Jp8GQkP8ffm/BVU47+U2ZvrjIo2w2RzwNvzod6C9tgPP43RdkC6NUQvDPEO31wNqAsnW yhpbmfpF/QgfDwKZo5TW4uqxacNjm8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=t/Riosij/44oO9Ps2jyWO0QeuCNVGpggXpx2ZR1ysGQ=; b=DSDMSL8FdZUKRfHVKXlv3XBqLN7S4FXlZ03CAfAw1hZD3WqVO1AuUi6dlNWv9a8FolP0bfkZq+/8S Lrm2Qaf95TokTcCGYux4LDo3qU6cykRivlyS9Qj3FyNxZAgqZ3Ox6QIL8PpihKNcZDsWhTzmT9akc8 sCFgy0GloHsVRf0O9MLPa1GuB5w8oC4ByHKpeLJauzsBengmuZaIKWfJ6VkbwyHA5O/oT98EtWWihm NWUR5HuB4H8K4/Gm9N+CBtWimcfooZVNngv33AJQhsy0QfwZYP3C5ZViWSuoKIFItXHrPQRoQ2TVCM qB/3WZ9+g7Pu9vswNp9X7uLnIw0KSmw== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=t/Riosij/44oO9Ps2jyWO0QeuCNVGpggXpx2ZR1ysGQ=; b=DXz07/4jrLP/P/cV+oBMuDWDs/prabqtGRN5Z3e0QkJ0vcYaDLQ84aP2Htvc5jh4ulPGnzE4koLQA q6kXexbzbTnkdzdqRitEon3Cyo75XMEVid9R1fVRD/hPgMH38Kig+jMOrI3LVzy+nkA+CgLJlND462 u6Ml5HyTyijvCkj5Ab40mb/4G7W5OL2XlWCglknM4nlVh1+ngIb7VlRhVO2cO38WQHPbr/v4Dp0oV8 e9TQossYgS0Io1OigHg4h5EaHuVqop8kva4tOvUlpB08rbx7Ihp3BYDHnQI+BxyD1I7lMgCCv+EY5o YVkzlZemYYTqZTLX1ohpr+ZHwJj3c2A== X-MHO-RoutePath: aGlwcGll X-MHO-User: 332cd770-618d-11e9-990e-673a89bc4518 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 332cd770-618d-11e9-990e-673a89bc4518; Thu, 18 Apr 2019 03:51:10 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id x3I3p8KI049227; Wed, 17 Apr 2019 21:51:08 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <9e1fd08ab9f7c9d82a55186e95ff4d910c62dcc0.camel@freebsd.org> Subject: Re: What code loads kernel modules at boot? From: Ian Lepore To: Warner Losh Cc: FreeBSD Hackers , Lee D Date: Wed, 17 Apr 2019 21:51:08 -0600 In-Reply-To: References: <173b3741db8be891cff8b7005b2058a416d43115.camel@freebsd.org> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 7D5C7743E0 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.98 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.98)[-0.981,0]; ASN(0.00)[asn:16509, ipnet:54.186.0.0/15, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 03:51:13 -0000 On Wed, 2019-04-17 at 21:44 -0600, Warner Losh wrote: > On Wed, Apr 17, 2019 at 9:07 PM Ian Lepore 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