mx51 cpufreq driver, it passed test on mx51 babbage 3.0 board.
___
linaro-dev mailing list
linaro-dev@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-dev
From: Yong Shen
it is tested on babbage 3.0
Signed-off-by: Yong Shen
---
arch/arm/Kconfig |6 +
arch/arm/mach-mx5/Kconfig |1 +
arch/arm/mach-mx5/Makefile |2 +-
arch/arm/mach-mx5/board-mx51_babbage.c |7 +-
arch/arm/mach-mx5/clock
> From: Yong Shen
>
> it is tested on babbage 3.0
One big comment and a couple of smaller ones:
It would be better to make this code a proper device driver,
probably a platform_driver unless you have a way to probe
the presence of the registers on another bus.
Making it a driver that registers
Are available from
https://launchpad.net/~peter-pearse/+archive/cross-source
deb http://ppa.launchpad.net/peter-pearse/cross-source/ubuntu maverick main
deb-src http://ppa.launchpad.net/peter-pearse/cross-source/ubuntu maverick main
[Any binaries produced will be amd64/i686 proving the host buil
Hi Peter,
On Tue, Oct 5, 2010 at 2:47 PM, Peter Pearse wrote:
> [Any binaries produced will be amd64/i686 proving the host build is
> unbroken]
>
> Only tested to build with gcc-4.5-arm-linux-gnueabi &&
>> xdeb -a armel --apt-source
>
> Resulting armel binaries not tested
Is there a plan to make
On Tue, Oct 5, 2010 at 2:04 PM, Alexander Sack wrote:
> Hi Peter,
>
> On Tue, Oct 5, 2010 at 2:47 PM, Peter Pearse
> wrote:
> > [Any binaries produced will be amd64/i686 proving the host build is
> > unbroken]
> >
> > Only tested to build with gcc-4.5-arm-linux-gnueabi &&
> >> xdeb -a armel --ap
I believe that the libgcc.a in our toolchain contains Thumb-2 code. I
verified this by doing objdump on libgcc.a and I see combinations of
16 and 32 bit instructions. So does that mean that the toolchain is
only usable for ARM versions that support Thumb-2?
Thanks,
John
On Wed, Oct 6, 2010 at 10:44 AM, John Rigby wrote:
> I believe that the libgcc.a in our toolchain contains Thumb-2 code. I
> verified this by doing objdump on libgcc.a and I see combinations of
> 16 and 32 bit instructions. So does that mean that the toolchain is
> only usable for ARM versions t
Thanks Michael. Just wanted to make sure I understood. The "do no
harm" goal and the Thumb2 libgcc seem to be somewhat contradictory
however. I realize that choices need to be made and only odd ducks
like me will likely run into issues. My particular case is wanting to
build u-boot for old and
On Wed, Oct 6, 2010 at 11:23 AM, John Rigby wrote:
> Thanks Michael. Just wanted to make sure I understood. The "do no
> harm" goal and the Thumb2 libgcc seem to be somewhat contradictory
> however. I realize that choices need to be made and only odd ducks
> like me will likely run into issues.
On Tue, Oct 05, 2010 at 04:23:01PM -0600, John Rigby wrote:
> Thanks Michael. Just wanted to make sure I understood. The "do no
> harm" goal and the Thumb2 libgcc seem to be somewhat contradictory
> however. I realize that choices need to be made and only odd ducks
> like me will likely run into
On Wed, Sep 29, 2010 at 3:53 PM, Jamie Bennett wrote:
> On Tue, Sep 28, 2010 at 06:50:03PM -0300, Christian Robottom Reis wrote:
>> On Tue, Sep 28, 2010 at 11:28:26AM +0100, Jamie Bennett wrote:
>> > OK, I put together:
>> >
>> > http://wiki.linaro.org/Process/ReleaseTesting
>>
>> Could we add s
On Thu, Sep 30, 2010 at 5:37 PM, Loïc Minier wrote:
>> >> + cat > ${TMP_DIR}/boot.cmd << BOOTCMD
>> >> +setenv bootcmd 'fatload mmc 0:1 0x9000 uImage; fatload mmc 0:1
>> >> 0x9080 uInitrd; bootm 0x9000 0x9080'
>> >
>> > no mmc init?
>> >
>> This is something I'm not very clea
On Thu, Sep 30, 2010 at 6:25 PM, Loïc Minier wrote:
> On Thu, Sep 30, 2010, Loïc Minier wrote:
>> I added a non-FS data partition in the
>> bzr version now, and factored your code with the general case.
>
> Hmm I'll have to disable that on OMAP, otherwise u-boot
Greets,
As a side project I've created a fairly simple performance improvement
for the linaro-media-create tool. Basically the copying of the root_fs
happens earlier in the process such that hwpack and a number of other
steps are done in parallel and then at the end there's one last rsync
to make
Hi Arnd,
Really appreciate your valuable comments. Most of them are accepted. I have
different option about two comments.
1.
> It would be better to make this code a proper device driver,
> probably a platform_driver unless you have a way to probe
> the presence of the registers on another bus.
>
16 matches
Mail list logo
