From: Andy Shevchenko <andriy.shevchenko@intel.com>
To: GaryWang <is0124@gmail.com>
Cc: JunYingLai <junyinglai@aaeon.com.tw>,
"Thomas Richard" <thomas.richard@bootlin.com>,
linux-gpio@vger.kernel.org,
"JasonHuang 黃仁杰" <JasonHuang@aaeon.com.tw>
Subject: Re: Up Squared Pro 7000 (UPN-ADLN01) broken BIOS?
Date: Fri, 10 Jul 2026 12:11:05 +0300 [thread overview]
Message-ID: <alC3Kc2BcjkmUVwV@ashevche-desk.local> (raw)
In-Reply-To: <CANYHO6rgn19uxjmc+1xv-pmadZQ1EaePmwvC3Kfy-E6ckwcYqA@mail.gmail.com>
On Fri, Jul 10, 2026 at 04:37:56PM +0800, GaryWang wrote:
> Add AAEON software JunYing.
Thanks, waiting for the response!
> yeah the ACPI flag should not set for HAT pins, JunYin knows it,
> They clear the ACPI flag from the driver now, their BIOS uses the default
> from CRB, but they should fix it from the BIOS to match the right usage.
How do they clean it from the driver? IIRC the ownership registers are locked
when BIOS hands over to the OS. Technically any pin that marked as GPIO input
must not be owned by ACPI to allow users to connect whatever they want there
and get an interrupts. Many of them also have "Locked full" permissions,
that's also may not be convenient. Another thing is the absence of bi-di GPIO
configuration (or did I miss that?), which people may want to have (my
use case, for instance).
In any case I have latest and greatest BIOS version (r3.5 of this year) and
problem still persists. Can AAEON share a BIOS for testing? (Note, if you
want, it can be done under our Intel-AAEON existing NDA, I believe.)
> On Fri, Jul 10, 2026 at 4:48 AM Andy Shevchenko
> <andriy.shevchenko@intel.com> wrote:
> >
> > Since I have been playing with the $Subject board, I wondering if I miss
> > something or the BIOS configuration is utterly broken. The problem what
> > I see is that most of the pins on the SoC are marked with [ACPI] if you
> > look at the debugfs 'pins' file for INTC1057:00 device instance.
> >
> > This means *none* of them (which are user visible via HAT connector) may
> > serve as an interrupt resource to the OS. How the OS should request interrupts
> > on those pins?
> >
> > As far as I understand that the BIOS does initial settings of CPLD and
> > basically I can use transparently the pins as per their configuration done
> > in BIOS. Right?
> >
> > Btw, do we have any contacts to engineers in AAEON or whoever who does these
> > UP boards nowadays?
--
With Best Regards,
Andy Shevchenko
prev parent reply other threads:[~2026-07-10 9:11 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-09 20:48 Up Squared Pro 7000 (UPN-ADLN01) broken BIOS? Andy Shevchenko
2026-07-10 8:37 ` GaryWang
2026-07-10 9:11 ` Andy Shevchenko [this message]
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=alC3Kc2BcjkmUVwV@ashevche-desk.local \
--to=andriy.shevchenko@intel.com \
--cc=JasonHuang@aaeon.com.tw \
--cc=is0124@gmail.com \
--cc=junyinglai@aaeon.com.tw \
--cc=linux-gpio@vger.kernel.org \
--cc=thomas.richard@bootlin.com \
/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.