Wookey writes:
> Debconf13 (last week) considered the matter of bare-metal
> cross-toolchains in Debian. Ideally we would have one toolchain source
> package from which the existing linux native compilers, and
> cross-compilers are built, including bare-metal cross-compilers. There
> is already m
Matthew Gretton-Dann writes:
> Can you please provide the output of:
> 1. arm-none-eabi-gcc -v
> 2. arm-none-eabi-gcc -print-multi-lib
Yeah, I figured it out, thanks -- the patches I had to add ARM multilib
support updated configure.ac but I didn't rebuild the configure script,
so my attempt
Matthias Klose writes:
> Am 19.08.2013 17:27, schrieb Keith Packard:
>> Wookey writes:
>>
>>> The alternative it to simply repack the existing linaro
>>> cross-toolchain sources, but them we get to keep doing that for new
>>> releases, and we have
Joey Ye writes:
> I'm not sure what blocked M0. There are a few things suspicious:
> * Which C library is used? The one gcc-arm-embedded works, and the only one
> I know works for Cortex-M, is newlib. Other than that, good luck :-(
I'm using pdclib, which is not the best solution in most ways ex
Wookey writes:
> The alternative it to simply repack the existing linaro
> cross-toolchain sources, but them we get to keep doing that for new
> releases, and we have gratuitous extra copies of gcc sources and
> corresponding differences between A* and M* toolchains/versions.
I'm working on this
On Tue, 20 Sep 2011 10:29:23 +0200, Patrik Jakobsson
wrote:
> It would be nice to have a model that fits both DSI and SDVO, and the option
> to configure some of it from userspace.
> I thought the purpose of drm_encoder was to abstract hardware like this?
SDVO is entirely hidden by the drm_enc
On Mon, 19 Sep 2011 09:33:34 +0300, Tomi Valkeinen
wrote:
> I think it's a bit more complex than that. True, there are MIPI
> standards, for the video there are DPI, DBI, DSI, and for the commands
> there is DCS. And, as you mentioned, many panels need custom
> initialization, or support only pa
On Thu, 15 Sep 2011 18:39:21 +, Florian Tobias Schandinat
wrote:
> Well, I'm not against sharing the code and not against taking DRM's current
> implementation as a base but the steps required to make it generally
> acceptable
> would be to split it of, probably as a standalone module and s
On Thu, 15 Sep 2011 20:21:15 +0300, Tomi Valkeinen
wrote:
> 2) panel drivers, handles panel specific things. Each panel may support
> custom commands and features, for which we need a dedicated driver. And
> this driver is not platform specific, but should work with any platform
> which has the
On Thu, 15 Sep 2011 17:12:43 +, Florian Tobias Schandinat
wrote:
> Interesting that this comes from the people that pushed the latest mode
> setting
> code into the kernel. But I don't think that this will happen, the exposed
> user
> interfaces will be around for decades and the infrastru
On Thu, 15 Sep 2011 18:29:54 +0300, Tomi Valkeinen
wrote:
> 1) It's part of DRM, so it doesn't help fb or v4l2 drivers. Except if
> the plan is to make DRM the core Linux display framework, upon which
> everything else is built, and fb and v4l2 are changed to use DRM.
I'd like to think we could
On Thu, 15 Sep 2011 15:07:05 +0300, Tomi Valkeinen
wrote:
> This was a very rough and quite short proposal, but I'm happy to improve
> and extend it if it's not totally shot down.
Jesse Barnes has put together a proposal much like this to work within
the existing DRM environment. This is pretty
12 matches
Mail list logo
