All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Tomas Hlavacek <tomas.hlavacek@nic.cz>
Cc: "Uwe Kleine-König" <uwe@kleine-koenig.org>,
	"Jacek Anaszewski" <jacek.anaszewski@gmail.com>,
	linux-kernel@vger.kernel.org
Subject: Re: Turris Omnia firmware possibilities [Was: Re: led: hw-trigger, global brightness and multi-colored leds]
Date: Fri, 25 May 2018 20:50:07 +0200	[thread overview]
Message-ID: <20180525185007.GA29954@amd> (raw)
In-Reply-To: <CAEB7QLA3hs+Wa_UD4tUXN1JB535dWJxtBLo_jveKkGkyKyGAJQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2734 bytes --]

Hi!

> > On 05/25/2018 12:08 AM, Tomas Hlavacek wrote:
> >> But I also have good news: The FW of the MCU is also OSS (see the repo
> >> in the link (1)). There is a method for flashing the MCU over I2C from
> >> Linux and there is JTAG connector for the MCU, in case un-bricking is
> >> needed. Therefore the LED protocol can be changed to be more sensible
> >> and/or it is even possible to emulate some existing HW LED driver chip
> >> in Omnia MCU and reuse OSS driver for that chip.
> >
> > Yeah, I noticed, but when we start replacing the firmware, we'd need to
> > detect somehow when a machine has an old (or only different) firmware.
> > That would imply a versioning scheme and a generic way to read out the
> > firmware version. (CMD_GET_FW_VERSION_BOOT is already a start, but this
> > doesn't help me if I find an unknown hash.) So a CMD_GET_FW_SOMETHING
> > that yields a version string that is similar to the soname of a library
> > would be great.
> 
> Oh yes, I was actually trying to push rewrite of the FW before the
> production started, but it looked like a redundant work and I rather
> implemented the mentioned rule-breaking LED driver. Another good news
> is that all the produced boards had the same FW image and there were
> no (official and automated) updates so far. I think that in this
> situation it is possible to re-write the firmware it if proves to be
> the best solution for LED driver and fixing other glitches perhaps.
> The only thing we need regarding versions we need is to either check
> that we are upgrading the original version and/or consent from the
> user to rewrite any other version that we might encounter. (If there
> are some user-customized boards around.)

Actually, I believe you should try to write the driver for existing
firmware, and only if you find that performance is not good enough,
change the protocol.

> > Talking about firmware, I wonder if there is firmware supported needed
> > to solve
> > https://wiki.debian.org/InstallingDebianOn/TurrisOmnia#Power_Management
> > . Didn't look into that deeply yet and probably not high prio given that
> > normally the Turris Omnia will just run 7x24h.
> 
> That's right, there is no power-down signalization from the CPU right
> now. Btw. is there any mechanism in kernel to signal over arbitrary
> bus (like I2C) that the host is shutting down and the power can/should
> be cut to CPU in N seconds?

I'm pretty sure kernel can ask the hardware to cut its power. This
sounds like it: drivers/power/reset/gpio-poweroff.c

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

  reply	other threads:[~2018-05-25 18:50 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-02 15:11 led: hw-trigger, global brightness and multi-colored leds Uwe Kleine-König
2018-05-02 21:21 ` Pavel Machek
2018-05-03 18:49   ` Uwe Kleine-König
2018-05-03 21:14     ` Jacek Anaszewski
2018-05-03 21:52     ` Pavel Machek
2018-05-24 22:08 ` Tomas Hlavacek
2018-05-25  6:08   ` Turris Omnia firmware possibilities [Was: Re: led: hw-trigger, global brightness and multi-colored leds] Uwe Kleine-König
2018-05-25 14:02     ` Tomas Hlavacek
2018-05-25 18:50       ` Pavel Machek [this message]
2018-08-14  7:11       ` Uwe Kleine-König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180525185007.GA29954@amd \
    --to=pavel@ucw.cz \
    --cc=jacek.anaszewski@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tomas.hlavacek@nic.cz \
    --cc=uwe@kleine-koenig.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.