[Buildroot] [RFC v2 1/1] ti-gfx: add new package
Thomas Petazzoni
thomas.petazzoni at free-electrons.com
Wed Jun 26 19:46:58 UTC 2013
Dear Spenser Gilliland,
On Wed, 26 Jun 2013 12:52:52 -0500, Spenser Gilliland wrote:
> > Nice, thanks for your work on this. Having support for OpenGL on
> > OMAP3, OMAP4 and AM335x is definitely one of the most important part
> > of the GSoC.
>
> I completely agree. I'm working very diligently on this.
Great!
> > > Additional Info:
> > > I've been using the 3.9.6-x3 tag of the kernel at
> > > https://github.com/RobertCNelson/stable-kernel by use of the
> > > LINUX_OVERRIDE_SRCDIR option.
> >
> > Are there some reports of the ti-gfx stuff working on such recent
> > kernels? Have you looked at the Yocto meta-ti layer at
> > http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/ ? If I look there,
> > they apparently don't have anything more recent than 3.0 or 3.1.
>
> Yes, the RobertCNelson kernel has builds up to 3.9.6. I am using this
> with fairly good success. I've been using the meta-ti layer
> extensively to understand the process of installing the SGX drivers.
> Many things refer to a 3.8 kernel from ti. However, this kernel was
> unbootable on the Beagle-XM. This may be a more apporiate option for
> the Beagle Black though.
Ok.
> > Also, are you still trying on the Beagle-XM, or have you switched to
> > the BeagleBone Black.
>
> The Beagle-XM is the current target. From the start, I was trying to
> read the revision number on the SGX core using devmem2. However for
> some unknown reason, devmem2 is not working properly on the
> Beagle-XM. When I finally tried the devmem from busybox, the revision
> was correctly read. Thus, I'm thinking that there is a bug in devmem2
> which is causing the problem. See patch here
> https://github.com/openembedded/meta-oe/blob/master/meta-oe/recipes-support/devmem2/devmem2/devmem2-fixups-2.patch
Argh, strange. The patch seems like devmem2 may not be working properly
on platforms that don't support unaligned accesses.
> > Also, I'm surprised you're not passing $(TARGET_CONFIGURE_OPTS) to
> > ensure the right compiler is used, etc.
>
> This information is included in LINUX_MAKE_FLAGS.
Ah, correct, ok!
> > I guess this could maybe be refactored, but we can see that later once
> > the whole thing works.
>
> Yes, it's kinda ugly. I'm still working out the issues. Once I know
> exactly what must be installed, I can start to clean this up.
Yes sure, that's also why I haven't looked in more detail on what else
to propose.
Best regards,
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
More information about the buildroot
mailing list