Date: Thu, 26 Jul 2018 17:00:07 +0200 From: Emmanuel Vadot <manu@bidouilliste.com> To: Greg V <greg@unrelenting.technology> Cc: Kyle Evans <kevans@freebsd.org>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Allwinner dtb overlays on CURRENT. Also, flashrom SPI! Message-ID: <20180726170007.a825dcaca1d96ec739719259@bidouilliste.com> In-Reply-To: <1532613717.49616.0@hraggstad.unrelenting.technology> References: <1532548163.59286.0@hraggstad.unrelenting.technology> <CACNAnaGLPgEs0MVMBbit78WGDCOMxxAcTXBYFZgamPZBmf5p3g@mail.gmail.com> <20180725234000.e917566724f997319f8fe2fd@bidouilliste.com> <1532598504.2425.0@hraggstad.unrelenting.technology> <20180726120926.9648d6b691ab7be7cbb37653@bidouilliste.com> <1532613717.49616.0@hraggstad.unrelenting.technology>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 26 Jul 2018 17:01:57 +0300 Greg V <greg@unrelenting.technology> wrote: >=20 >=20 > On Thu, Jul 26, 2018 at 1:09 PM, Emmanuel Vadot <manu@bidouilliste.com>=20 > wrote: > > On Thu, 26 Jul 2018 12:48:24 +0300 > > Greg V <greg@unrelenting.technology> wrote: > >> On Thu, Jul 26, 2018 at 12:40 AM, Emmanuel Vadot > >> <manu@bidouilliste.com> wrote: > >> > On Wed, 25 Jul 2018 15:14:29 -0500 > >> > Kyle Evans <kevans@freebsd.org> wrote: > >> > This is wrong bindings. Yes I know that it's working with our=20 > >> driver > >> > for ths but this is wrong. > >> > 1) ths module isn't in ahb but apb. > >> > 2) We need nvmem framework to get the sensor calibration data,=20 > >> please > >> > see https://reviews.freebsd.org/D16419 > >>=20 > >> I guess it's good to have a framework, but the existing driver > >> communicates with aw_sid directly (aw_sid_read_tscalib), and that=20 > >> seems > >> to work fine? > >=20 > > Yeah and this is really gross. > > Also the bindings aren't upstreamed and can't be without nvmem-cells. >=20 > It's nice that we're going to have clean upstreamable stuff, but it's a=20 > bit sad that making everything work out of the box on current *now* is=20 > not a priority. Enabling it on current is my priority, which is why I'm working on the upstream process. > Especially since overlays are perfect for enabling=20 > temporary hacks. Temporary hacks don't exists. > >> >> > SPI: https://github.com/freebsd/freebsd/pull/166 > >> > > >> > What is the point of the spigen interface ? > >> > If aw_spi is working on H3 (I haven't check but it should), if=20 > >> you > >> > have a good dtb with the spi flash described you can use it=20 > >> directly. > >>=20 > >> Uhhh I'm surprised you don't know what's the point of spigen? > >> The point is raw *userspace* access. > >=20 > > I'm surprised that you thing I don't know what spigen is :) >=20 > Hah, sorry, I guess you should've added "for accessing flash" right=20 > there before the question mark. >=20 > > Having a spigen for things other than flash is good, for flash I=20 > > don't > > see the point. >=20 > Yeah, it should be exposed out of the box for all kinds of things,=20 > exactly! >=20 > Kernel drivers are good for permanently attached flash, but if you're=20 > going to, say, connect various motherboards' flash chips to=20 > dump/recover the firmware or flash coreboot, you don't want kernel=20 > drivers, you specifically want *flashrom* with its auto detection (and=20 > probably its support for more chips?) Ok I see. Your SPI overlays needs to be split (one for SPI0 and one for SPI1). Can you open a review on https://reviews.freebsd.org/ for this ? Thanks >=20 > Fun story: I recovered my PC after a bad firmware update using an RPi=20 > once. I couldn't attach all the wires because the board has a header=20 > with 2mm pins and I had thicker connectors, so I ended up not=20 > connecting ground. It didn't work at default speed, but flashrom=20 > detected the chip when using very low speed and flashing was successful=20 > :D --=20 Emmanuel Vadot <manu@bidouilliste.com> <manu@freebsd.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180726170007.a825dcaca1d96ec739719259>