bb.org debian next...

So here's some random thoughts... Now that the wheezy images is out,
(We will still maintain it!) there were a few things i wished it had
working out of the box <cough> sgx </cough>.

So on that note, I've been looking at what we have queued up for
Jessie (which should "freeze" november-ish, ship 7.0 6 months later
(lets say may 2015)).

Some cool things, like a newer systemd (by default), qt 5.x,
wayland/weston, libhybris, gcc-4.9... Thus we 'might' just be able to
have sgx working by borrowing the Android bits..

http://en.wikipedia.org/wiki/Hybris_(software)#Features

So today, I was messing with a Jessie rootfs build, trying to start
weston for the first time. yeah. We definitely have some work ahead
of us.

Thoughts? I'm not promising anything right now, I might just end up
with more grey hairs..

So here's some random thoughts... Now that the wheezy images is out,
(We will still maintain it!) there were a few things i wished it had
working out of the box <cough> sgx </cough>.

That'd certainly be nice. Probably one of those things to raise again
on linux-omap and for Gerald, Cody and I to ping the folks in TI and
Imagination. Doubtful it'll get much priority, but it is more likely
if we all squeak a bit.

So on that note, I've been looking at what we have queued up for
Jessie (which should "freeze" november-ish, ship 7.0 6 months later
(lets say may 2015)).

Some cool things, like a newer systemd (by default), qt 5.x,
wayland/weston, libhybris, gcc-4.9... Thus we 'might' just be able to
have sgx working by borrowing the Android bits..

http://en.wikipedia.org/wiki/Hybris_(software)#Features

So today, I was messing with a Jessie rootfs build, trying to start
weston for the first time. yeah. We definitely have some work ahead
of us.

Thoughts? I'm not promising anything right now, I might just end up
with more grey hairs..

Seems like a good focus to me, but I'd like to see a jump to a
closer-to-mainline kernel as soon as we can work out the cape support.
My thought of trying to include overlays within the EEPROMs seems to
have completely died. My feeling is that we are going closer to
maintaining a single .dts file and having people use the same
techniques as cape-universal to switch the modes.

I'm working on a merge of the kernel devicetree history into my fork
at https://github.com/jadonk/cape-firmware and will push it later
tonight and send a pull request to
https://github.com/beagleboard/devicetree-source.

Should we take a detour on the way to Jessie+SGX to get the capes
working against mainline (without dynamic overlays for now)? Certainly
don't want to miss the Jessie merge window and would love to get more
eyeballs on that, but I am hoping the kernel jump could be a bit of
lower-hanging fruit and something we'd want for Jessie?

weston: (running as root, in jessie)

export XDG_RUNTIME_DIR="/tmp/wayland"
mkdir -p "$XDG_RUNTIME_DIR"
chmod 0700 "$XDG_RUNTIME_DIR"

weston --backend=fbdev-backend.so

or

weston --backend=drm-backend.so --use-pixman

(fbdev actually works better)

Regards,

So here's some random thoughts... Now that the wheezy images is out,
(We will still maintain it!) there were a few things i wished it had
working out of the box <cough> sgx </cough>.

So on that note, I've been looking at what we have queued up for
Jessie (which should "freeze" november-ish, ship 7.0 6 months later
(lets say may 2015)).

Some cool things, like a newer systemd (by default), qt 5.x,
wayland/weston, libhybris, gcc-4.9... Thus we 'might' just be able to
have sgx working by borrowing the Android bits..

http://en.wikipedia.org/wiki/Hybris_(software)#Features

So today, I was messing with a Jessie rootfs build, trying to start
weston for the first time. yeah. We definitely have some work ahead
of us.

Thoughts? I'm not promising anything right now, I might just end up
with more grey hairs..

weston: (running as root, in jessie)

export XDG_RUNTIME_DIR="/tmp/wayland"
mkdir -p "$XDG_RUNTIME_DIR"
chmod 0700 "$XDG_RUNTIME_DIR"

weston --backend=fbdev-backend.so

or

weston --backend=drm-backend.so --use-pixman

(fbdev actually works better)

How does the performance look? Wanting to encourage more people to poke on it?

For run-time HDMI resizing, we'll need to use DRM, no?

Robert,

I understand that with limited resources and high popularity of
Beaglebone this will be the primary target for development, but would
there be a chance for older boards to receive a bit more love than
with current debian images?

thx,
j.

So here's some random thoughts... Now that the wheezy images is out,
(We will still maintain it!) there were a few things i wished it had
working out of the box <cough> sgx </cough>.

So on that note, I've been looking at what we have queued up for
Jessie (which should "freeze" november-ish, ship 7.0 6 months later
(lets say may 2015)).

Some cool things, like a newer systemd (by default), qt 5.x,
wayland/weston, libhybris, gcc-4.9... Thus we 'might' just be able to
have sgx working by borrowing the Android bits..

http://en.wikipedia.org/wiki/Hybris_(software)#Features

So today, I was messing with a Jessie rootfs build, trying to start
weston for the first time. yeah. We definitely have some work ahead
of us.

Thoughts? I'm not promising anything right now, I might just end up
with more grey hairs..

weston: (running as root, in jessie)

export XDG_RUNTIME_DIR="/tmp/wayland"
mkdir -p "$XDG_RUNTIME_DIR"
chmod 0700 "$XDG_RUNTIME_DIR"

weston --backend=fbdev-backend.so

or

weston --backend=drm-backend.so --use-pixman

(fbdev actually works better)

How does the performance look? Wanting to encourage more people to poke on it?

It's actually very smooth in fbdev mode.. In in drm mode the screen
gets crazy corrupted the harder you push the cpu. (on our v3.8.x
kernel)

For run-time HDMI resizing, we'll need to use DRM, no?

Correct, we need drm mode for that.

It's very minimal, it should be good platform for getting the
'current' sgx graphics binaries up and running..

But right now it's just a collection of notes to get it up. I figure
in a week I'll have something for users to test.

Regards,

Robert,

I understand that with limited resources and high popularity of
Beaglebone this will be the primary target for development, but would
there be a chance for older boards to receive a bit more love than
with current debian images?

Oh, they are getting some love. (ignoring the dsp).

For the xM (other then ulcd7 support)
1Ghz operation (although i disabled this in v3.15.x)

beagle cx: (v3.15.x)
display broken
i2c feature (annoying dmesg spam)
600Mhz limitation

beagle xm
1Ghz operation:
(but with this error:

(and now with gmail's shortcut keys disabled, this is the worst thing
to ever copy from outlook!)

Oh, they are getting some love. (ignoring the dsp).

For the xM (other then ulcd7 support)
1Ghz operation (although i disabled this in v3.15.x) (1)
DRM graphics works
USB pll workaround

beagle cx: (v3.15.x)
display broken
i2c feature (annoying dmesg spam)
600Mhz limitation

But one thing we probably won't ever have support for again on these
boards is the dsp stuff. (no one who knows it is working on it.)

1: http://pastebin.com/D8BdymHF
2: http://pastebin.com/TAHExszJ

Regards,

Robert,

I understand that with limited resources and high popularity of
Beaglebone this will be the primary target for development, but would
there be a chance for older boards to receive a bit more love than
with current debian images?

(and now with gmail's shortcut keys disabled, this is the worst thing
to ever copy from outlook!)

Oh, they are getting some love. (ignoring the dsp).

For the xM (other then ulcd7 support)
1Ghz operation (although i disabled this in v3.15.x) (1)
DRM graphics works
USB pll workaround

beagle cx: (v3.15.x)
display broken
i2c feature (annoying dmesg spam)
600Mhz limitation

But one thing we probably won't ever have support for again on these
boards is the dsp stuff. (no one who knows it is working on it.)

Yeah, TI stopped supporting SysLink after V3.2. After V3.2, mainline
standardized on RPMSG (SYSLINK3), but TI have no plans to add DM3730
support for RPMSG. Currently, there is support for OMAPL13x, OMAP4, OMAP5
and KeyStone I believe.

Regards,
John