Date: Sun, 16 Nov 2014 15:47:39 +1030 From: "O'Connor, Daniel" <darius@dons.net.au> To: Alexander Kabaev <kabaev@gmail.com> Cc: Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: Newbus question Message-ID: <F0293717-56CA-4771-88AE-9800344B8888@dons.net.au> In-Reply-To: <20141115133525.51a25bfa@kan> References: <EE77EB4C-E317-4EAB-9319-18F0B292571F@dons.net.au> <20141115121730.3a5bac94@kan> <20141115180302.GL17068@kib.kiev.ua> <20141115133525.51a25bfa@kan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16 Nov 2014, at 5:05, Alexander Kabaev <kabaev@gmail.com> wrote: >> I think that debugging should be available much earlier than the >> device tree is explored and devices are attached. It probably makes >> sense to operate the debugging port outside the newbus at all, in >> particular, before the pci and acpi machinery is initialized. >>=20 >> You might want a callback from ehci driver when it appropriated the >> resources, to handle the case of bar realocation. >=20 > If one wants early debugger, then whole thing will need to be split > into pre-newbus and after-newbus part, similar to dcons. OK thanks. I think for now I=92ll just ignore the EHCI driver and get it working as = a device driver which attaches to an EHCI controller. After that works I=92ll look at the early part, hopefully it won=92t be = too difficult :) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?F0293717-56CA-4771-88AE-9800344B8888>