I should be getting a tiny number of beta X15 boards on Wednesday. I’d like to minimize the turn-around from arrival with me to boards in key developer hands, I’d like for people anxious for boards to reply to this list with:
I should be getting a tiny number of beta X15 boards on Wednesday. I’d like to minimize the turn-around from arrival with me to boards in key developer hands, I’d like for people anxious for boards to reply to this list with:
What your plans for the boards would be.
What open source repositories (URLs please) will host your contributions.
What expertise you have to accomplish your goals.
I would like to run openSUSE on the board and maintain appropriate official image. I have been effectively maintaining openSUSE for BBB (including updating armv7l kernel configs several times). openSUSE approach for ARM is to supply upstream components (boot-loader and kernel) for all boards. I think there are no so many openSUSE BBB users, but sometimes they appear in out maillists with questions and issues.
I should be getting a *tiny* number of beta X15 boards on Wednesday. I'd like to minimize the turn-around from arrival with me to boards in key developer hands, I'd like for people anxious for boards to reply to this list with:
1) What your plans for the boards would be.
My primary plan is to make sure that Fedora runs well on the board. Beyond that, I'd like to use it for some open source telephony projects, especially because of the on-board DSP.
2) What open source repositories (URLs please) will host your contributions.
a) Enablement in openSUSE's Linux kernel and U-Boot packages.
(I'll happily give preference to Matwey here - he's been providing
valuable contributions, e.g., kernel config patches for AM3xxx.)
b) Testing of KVM virtualization. Requires an LPAE enabled kernel, which
we at openSUSE haven't tested any TI board with yet. Might require
U-Boot enablement for HYP mode? Would allow safely running Open Build
Service workers, among others.
c) Checking on OpenOCD status, if the JTAG header is shipped populated.
I remember seeing some TI patch activity, but no ti_beagleboard-x15.cfg
or am5*.cfg got merged yet.
However, my main interest would be the TI-specific gadgets:
d) PRU - testing drivers and gnupru binutils/newlib/gcc toolchain.
For BBB there still seemed to be a gap between mainline (uio_pruss) and
Sitara SDK (remoteproc_pruss according to TI Wiki).
e) C66x - evaluating driver and toolchain situation. There are some old
contributed packages from Beagleboard-xM, but no official gcc5 based
cross-compiler packages that I'm aware of at least.
f) Cortex-M4 - investigating a nommu Linux port. Requires the M4 to have
access to SDRAM - not quite clear from the TRM block diagram...
2) What open source repositories (URLs please) will host your contributions.
Just to add to this, I just started doing basic checkups on my spare
time with 3.14 kernel - I can definitely take all the help I can - all I
get now a days is around 2-3 hours a week to look at this. Last weekend
was mostly setup stuff. Marshmallow 3.14 is up on j6-evm so that should
give us a great starting point if folks are interested. A 4.1 kernel
variant will probably be nice as well.
I should be getting a *tiny* number of beta X15 boards on Wednesday. I'd
like to minimize the turn-around from arrival with me to boards in key
developer hands, I'd like for people anxious for boards to reply to this
list with:
1) What your plans for the boards would be.
Enable the reversed engineer Android Auto headunit implementation on
X15. Support X15 on the (still very young) OpenIVI auto distro. On
another platform I'm working on this AA implementation looks like:
End goal is to use X15 in an open source head unit.
I also plan to support NuttX on one of the M4s to handle some safety critical
features for the car. This is similar to how we use an external STM32
for these things on a current design with another SoC.
2) What open source repositories (URLs please) will host your contributions.
3) What expertise you have to accomplish your goals.
I have kernel experience on OMAP/AM parts, OE experience, experience with
the PRUs, experience supporting NuttX on similar Cortex-M architecture, and
experience enabling the reversed engineered Android Auto implementation on
other platforms.
c) Checking on OpenOCD status, if the JTAG header is shipped populated.
I remember seeing some TI patch activity, but no ti_beagleboard-x15.cfg
or am5*.cfg got merged yet.
Last time I tried OpenOCD it was pretty crappy in dealing with ARMv7
targets in general: it didn't properly handle WAIT responses from DAP but
treated them as errors, forcing you to decrease performance to the
estimated worst-case latency to avoid getting random errors. It also didn't
support connecting to DAP (to gain full memory and peripheral access)
without also connecting to a processor. ICEPick support was limited and
messy.
Also, XDS100v2 support was incomplete due to the inability to read (let
alone get events on) inputs of the FTDI chip, which made it impossible to
detect target disconnected / unpowered.
BTW, I've managed to scrape together a nearly complete register map of
ICEPick-C/D, so if you need it let me know.
f) Cortex-M4 - investigating a nommu Linux port. Requires the M4 to have
access to SDRAM - not quite clear from the TRM block diagram...
They have access to everything on the L3 interconnect.
Note also that they actually have MMUs... two of 'em cascaded actually: the
first one ("AMMU") really limited and quirky but it is integrated with the
Unicache and you need it to set the cache policy and access control, and
translation of requests within the subsystem (e.g. to put local peripherals
and/or local ram in bitband-capable address range). The second one
ARMv6/v7-compatible (same type as the device MMUs) but only used for
translation of requests going out to the L3 interconnect.
What makes things a bit more interesting is that the two cores in each
subsystem cannot be distinguished by the MMUs and therefore share identical
address space views (apart from their PPB).
how long ago was that, btw ? I've had good success with AM335x (cortex-a8) and am437x (cortex-a9). Others have had success with non-TI cortex-a targets.
It's certainly not perfect (cache handling needs a lot of work), but I wouldn't
say it's all that bad.
A15 should be well supported too (apart from some generic cortex-a target bugs
like the cache handling thing) and it only needs a proper configuration script.
For reference, look at how AM437x config looks like. It's doing pretty much
everything TI's GEL is doing (locking PLLs, setting higher frequencies, etc).
If that's done for other cortex-a targets, then we will end up with a pretty
good setup for cheap (and actually pretty fast) debug interface.
What openocd really, desperately needs is more people; both users and coders.
The project is really small and the guys who are actually active in it don't
even have access to any cortex-a targets, that makes things a little difficult
for us, cortex-a users.
I should be getting a *tiny* number of beta X15 boards on Wednesday. I'd like to minimize the turn-around from arrival with me to boards in key developer hands, I'd like for people anxious for boards to reply to this list with:
1) What your plans for the boards would be.
Enable the reversed engineer Android Auto headunit implementation on
X15. Support X15 on the (still very young) OpenIVI auto distro. On
another platform I'm working on this AA implementation looks like:
End goal is to use X15 in an open source head unit.
I also plan to support NuttX on one of the M4s to handle some safety critical
features for the car. This is similar to how we use an external STM32
for these things on a current design with another SoC.
2) What open source repositories (URLs please) will host your contributions.
3) What expertise you have to accomplish your goals.
I have kernel experience on OMAP/AM parts, OE experience, experience with
the PRUs, experience supporting NuttX on similar Cortex-M architecture, and
experience enabling the reversed engineered Android Auto implementation on
other platforms.
I would've worded it "reviewers". There's around a dozen ARMv7-A
patches waiting for review on the Gerrit site I gave the URL of.
Personally I don't feel qualified to review all of them, but if we
peer-review and +1 any Beagleboard-related configs or bug fixes we can
actually test, they should have a fairly good chance of getting accepted
sometime.
Having gotten a few openocd changes in I would +1 this sentiment. Further,
since we're talking on the x15 list, do we want to reach out to the openocd
folks and see if donating them a board would help in any particular way?
Just curious, did TI bother to correctly program the CoreSight ROMs this
time, or is it still leaving them blank (main DAP) or with wrong content
(IPU) ?
[Apologies if anybody sees a duplicate post, had some “reply” issues]
I should be getting a tiny number of beta X15 boards on Wednesday. I’d like to minimize the turn-around from arrival with me to boards in key developer hands, I’d like for people anxious for boards to reply to this list with:
What your plans for the boards would be.
Enable the reversed engineer Android Auto headunit implementation on
X15. Support X15 on the (still very young) OpenIVI auto distro. On
another platform I’m working with this AA implementation looks like:
End goal is to use X15 in an open source head unit.
I also plan to investigate using NuttX on one of the M4s to handle some
safety critical features for the car. This is similar to how we use an external
STM32 for these things on a current design with another SoC.
What open source repositories (URLs please) will host your contributions.
I have kernel experience on OMAP/AM parts, OE experience, experience with
the PRUs, experience supporting NuttX on similar Cortex-M architecture, and
experience enabling the reversed engineered Android Auto implementation on
other platforms.
I should be getting a *tiny* number of beta X15 boards on Wednesday. I'd
like to minimize the turn-around from arrival with me to boards in key
developer hands, I'd like for people anxious for boards to reply to this
list with:
1) What your plans for the boards would be.
Add support for beagle-x15 to Debian's u-boot, flash-kernel, enable
linux kernel configuration options in the default linux kernel shipped
with Debian, and debian-installer.
Additionally, I'd like to use it as a build node for the armhf part of
the reproducible builds project:
Additional boards would be helpful, not only for additional CPU cycles,
but different CPU types may help to detect software that might optimize
based on CPU (we currently have 3 IMX6 boards and an Allwinner A20
board). I heard from Robert Nelson that they've outperformed the
wandboard-quad, which is one of the more powerful build nodes.
It would also be a thorough stress-test for the beagleboard-x15, as the
reproducible build nodes run builds constantly.
2) What open source repositories (URLs please) will host your
contributions.
ftp.us.debian.org, git.debian.org, if needed, getting additional patches
into upstream u-boot.
3) What expertise you have to accomplish your goals.
I'm the current maintainer of u-boot in Debian. I've worked on support
in u-boot/flash-kernel/linux/debian-installer for the beaglebone black,
wandboard, cubieboard, hummingboard and cubox-i.
I'm host the current 4 armhf build nodes for the reproducible builds
project.
There's around a dozen ARMv7-A