On Aug 18, 2010, at 3:12 PM, Matthew McClintock wrote:
> We currently do not add a cpu-release-addr for core 0, this is needed
> when we want to reset core 0 and later restart it from Linux
> ---
> arch/powerpc/cpu/mpc85xx/fdt.c | 21 -
> 1 files changed, 8 insertions(+), 13
On Aug 18, 2010, at 3:41 PM, Wolfgang Denk wrote:
> Dear Becky,
>
> your commit f51cdaf1: "83xx/85xx/86xx: LBC register cleanup" breaks
> building of the ve8313 board which now fails like this:
>
> fsl_elbc_nand.c: In function 'fsl_elbc_run_command':
> fsl_elbc_nand.c:231: error: 'fsl_lbc_t' ha
On Aug 17, 2010, at 11:33 PM, Kumar Gala wrote:
> From: york
>
> The board specific parameters associated with quad rank dimms where
> missing. This fixes it so the board will function if quad rank dimms
> are placed in it.
>
> Signed-off-by: York Sun
> Signed-off-by: Kumar Gala
> ---
> boa
On Aug 17, 2010, at 11:21 PM, Kumar Gala wrote:
> Official docs call it the Job Ring not Job Queue for the p4080 security
> block. Match the docs to reduce confusion.
>
> Signed-off-by: Kim Phillips
> Signed-off-by: Kumar Gala
> ---
> arch/powerpc/cpu/mpc85xx/p4080_ids.c |8
> ar
We get two build errors:
fsl_elbc_nand.c: In function 'fsl_elbc_run_command':
fsl_elbc_nand.c:231: error: 'fsl_lbc_t' has no member named 'lsor'
make[1]: *** [/work/wd/tmp-ppc/drivers/mtd/nand/fsl_elbc_nand.o] Error 1
and
ve8313.c: In function 'initdram':
ve8313.c:104: error: expected '=', ',',
Dear Rogan Dawes,
In message <4c6cd111.4070...@dawes.za.net> you wrote:
>
> > Then please mark it as such in the subject - adding a "[RFC]" or
> > similar tag would help.
>
> Sorry, git-send-email newbie here.
>
> Will figure it out for the next time around.
You can manually edit the patch befo
Dear Kumar Gala,
In message you wrote:
>
> Sorry, I had a few other fixes I was queuing up for a pull request.
Please do, as I want to get a -rc1 out asap (tonight?)
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Off
On 2010/08/19 7:35 AM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
>
> In message <4c6cc059.4080...@dawes.za.net> you wrote:
>>
>> The patch was simply to allow people to see my non-working config, in
>> the hope of getting suggestions on how to improve it.
>
> Then please mark it as such in the sub
On Aug 18, 2010, at 5:46 PM, Kim Phillips wrote:
> On Wed, 18 Aug 2010 23:50:26 +0200
> Wolfgang Denk wrote:
>
>> your commit a37c36f4: "powerpc/8xxx: query feature reporting register
>> for num cores on unknown cpus" breaks a number of boards with error
>> messages like here:
>
>> Please fix.
Ben Gardiner nanometrics.ca> writes:
[...] snip
> +
> +void dram_init_banksize (void)
> +{
> + gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> + gd->bd->bi_dram[0].size = gd->ram_size;
> +}
> +#endif
>
dram_init() gets called from arch/arm/lib/board.c and initializes gd->ram_size
On Wednesday, August 18, 2010 16:36:39 Albert ARIBAUD wrote:
> Le 18/08/2010 19:54, Mike Frysinger a écrit :
> > On Wed, Aug 18, 2010 at 1:46 PM, Albert ARIBAUD wrote:
> >> Le 18/08/2010 18:46, Mike Frysinger a écrit :
> >>> you need to include linux/compiler.h first ... but i would have
> >>> thou
Dear Rogan Dawes,
In message <4c6cc059.4080...@dawes.za.net> you wrote:
>
> The patch was simply to allow people to see my non-working config, in
> the hope of getting suggestions on how to improve it.
Then please mark it as such in the subject - adding a "[RFC]" or
similar tag would help.
Best
On 2010/08/19 12:23 AM, Wolfgang Denk wrote:
>
> But this is an attempt to sneak in an incomplete (no entries to
> MAKEALL or MAINTAINER, for example) board when no MW is open.
>
> NAK for this part.
Hi Wolfgang,
The patch was simply to allow people to see my non-working config, in
the hope of
Hi Detlev,
On Wed, Aug 18, 2010 at 21:23:46, Detlev Zundel wrote:
> Hi Sekhar,
>
> > The TI DA850/OMAP-L138/AM18x EVM can be populated with devices
> > having different maximum allowed CPU clock rating.
> >
> > The maximum clock the chip can support can only be determined from
> > the label on th
This patch adds basic support for s5pc210.
s5p-common will be used by all of s5p SoCs.
Signed-off-by: Minkyu Kang
Signed-off-by: Kyungmin Park
---
Makefile |7 +
arch/arm/cpu/armv7/s5p-common/Makefile | 46 +++
arch/arm/cpu/armv7/s5p-common/cpu_info.c
Because of these are common files around s5p Socs, rename from s5pc1xx to s5p.
And getting cpu_id is SoC specific, so move to SoC's header file.
Signed-off-by: Minkyu Kang
Signed-off-by: Kyungmin Park
---
arch/arm/cpu/armv7/s5p-common/cpu_info.c | 11 +--
arch/arm/cpu/armv7/s5p-common
On Wed, 2010-08-18 at 19:39 -0500, Nishanth Menon wrote:
> Remove the register offset and common defines which are
> already present in drivers/i2c/omap24xx.h. All of these
> defines carry the same value even.
>
> Cc: Steve Sakoman
> Cc: Heiko
> Cc: Sandeep Paulraj
> Cc: Wolfang Denk
>
> Sign
On Wed, 2010-08-18 at 19:39 -0500, Nishanth Menon wrote:
> Make the header guard to be generic to stop conflicting with
> omap2 i2c header file arch/arm/include/asm/arch-omap24xx/i2c.h
>
> Cc: Steve Sakoman
> Cc: Heiko
> Cc: Sandeep Paulraj
> Cc: Wolfang Denk
>
> Signed-off-by: Nishanth Menon
On Wed, 2010-08-18 at 19:39 -0500, Nishanth Menon wrote:
> OMAP2420 ES2.3 trm defines syss register offset as 0x10. Add it.
>
> Cc: Steve Sakoman
> Cc: Heiko
> Cc: Sandeep Paulraj
> Cc: Wolfang Denk
>
> Signed-off-by: Nishanth Menon
Acked-by: Steve Sakoman
Steve
> ---
> arch/arm/include
On Wed, 2010-08-18 at 19:39 -0500, Nishanth Menon wrote:
> As reported by wolfgang [1] sdp2420 platform build is broken atm
>
> looking at the same showed some potential cleanups possible
> in addition to fixing the problem
Thanks Nishanth! You beat me to it.
These look fine to me, I'll add my
Remove the register offset and common defines which are
already present in drivers/i2c/omap24xx.h. All of these
defines carry the same value even.
Cc: Steve Sakoman
Cc: Heiko
Cc: Sandeep Paulraj
Cc: Wolfang Denk
Signed-off-by: Nishanth Menon
---
arch/arm/include/asm/arch-omap24xx/i2c.h | 1
Make the header guard to be generic to stop conflicting with
omap2 i2c header file arch/arm/include/asm/arch-omap24xx/i2c.h
Cc: Steve Sakoman
Cc: Heiko
Cc: Sandeep Paulraj
Cc: Wolfang Denk
Signed-off-by: Nishanth Menon
---
drivers/i2c/omap24xx_i2c.h |4 ++--
1 files changed, 2 insertion
As reported by wolfgang [1] sdp2420 platform build is broken atm
looking at the same showed some potential cleanups possible
in addition to fixing the problem
Warning: i dont have a board around, so only build tested for omap2,
tested for omap3
Nishanth Menon (3):
i2c: omap2+: change header g
OMAP2420 ES2.3 trm defines syss register offset as 0x10. Add it.
Cc: Steve Sakoman
Cc: Heiko
Cc: Sandeep Paulraj
Cc: Wolfang Denk
Signed-off-by: Nishanth Menon
---
arch/arm/include/asm/arch-omap24xx/i2c.h |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/arch/arm/i
On Wed, 18 Aug 2010 23:50:26 +0200
Wolfgang Denk wrote:
> your commit a37c36f4: "powerpc/8xxx: query feature reporting register
> for num cores on unknown cpus" breaks a number of boards with error
> messages like here:
> Please fix.
I posted a fix when you first brought this up. Whilst I sent
commit 47e26b1b "cmd_usage(): simplify return code handling" caused
the following compile warnings:
bedbug_860.c: In function 'bedbug860_do_break':
bedbug_860.c:73: warning: 'return' with a value, in function returning void
bedbug_860.c:121: warning: 'return' with a value, in function returning vo
The typo caused build issues like these:
Configuring for edminiv2 board...
In file included from /work/wd/tmp-arm/include2/asm/arch/orion5x.h:39,
from cpu.c:32:
/work/wd/tmp-arm/include2/asm/arch/cpu.h:79:1: warning: "/*" within comment
In file included from /work/wd/tmp-arm/inclu
Dear Rogan Dawes,
In message <1281993065-19803-1-git-send-email-u...@aphrodite> you wrote:
> From: Rogan Dawes
>
> ---
> arch/arm/include/asm/arch-orion5x/cpu.h |2 +-
This is a fix that is good... If there only was a SoB line...
> board/D-Link/dns323_b1/Makefile | 53 ++
Dear Steve,
your commit d708395d "ARMV7: Modify i2c driver for more reliable
operation on OMAP4" breaks building of the omap2420h4 board:
omap24xx_i2c.c: In function 'i2c_init':
omap24xx_i2c.c:117: error: 'struct i2c' has no member named 'syss'
omap24xx_i2c.c:117: error: 'I2C_SYSS_RDONE' undeclar
Dear Andy & Kumar,
all QorIQ NAND-Boot configurations are apeareantly failing to build.
I get
ld: NAND bootstrap too big
error messages for these board configurations: P1011RDB_NAND,
P1020RDB_NAND, P2010RDB_NAND, and P2020RDB_NAND
Please fix.
Thanks in advance.
Best regards,
Wolfgan
Dear Kim,
your commit a37c36f4: "powerpc/8xxx: query feature reporting register
for num cores on unknown cpus" breaks a number of boards with error
messages like here:
cpu.c: In function 'cpu_numcores':
cpu.c:113: error: 'CONFIG_SYS_MPC85xx_PIC_ADDR' undeclared (first use in this
function)
cpu.c
During a few months, offsets of files in multi-file images were miscalculated,
this has been fixed by 02b9b22446e3d7ad6a6382be17a1ce79a7de589b,
but unfortunatly, some devices (I'm thinking of the Neo FreeRunner) are using
a broken version of U-Boot.
This problem can easily be worked around at imag
Dear Becky,
your commit f51cdaf1: "83xx/85xx/86xx: LBC register cleanup" breaks
building of the ve8313 board which now fails like this:
fsl_elbc_nand.c: In function 'fsl_elbc_run_command':
fsl_elbc_nand.c:231: error: 'fsl_lbc_t' has no member named 'lsor'
make[1]: *** [/work/wd/tmp-ppc/drivers/mt
Le 18/08/2010 19:54, Mike Frysinger a écrit :
> On Wed, Aug 18, 2010 at 1:46 PM, Albert ARIBAUD wrote:
>> Le 18/08/2010 18:46, Mike Frysinger a écrit :
>>> you need to include linux/compiler.h first ... but i would have
>>> thought this be a header already included globally. maybe that's a
>>> new
We currently do not add a cpu-release-addr for core 0, this is needed
when we want to reset core 0 and later restart it from Linux
---
arch/powerpc/cpu/mpc85xx/fdt.c | 21 -
1 files changed, 8 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/
Hallo!
Leider, konnte ich nicht bei Ihnen ich melden, weil ich ihre E-Mail-Adresse
nicht finden konnte. Ich habe eine gute Nachricht fur Sie. Wir haben einen
geeigneten Job in Deutschland fur Sie qusgesucht.
Das ist ein Arbeit nach freier Zeitplan. Mindestlohn ist Euro 2.000.
Ingesamt 3 bi
> >
> >> I wonder what is the status of this patch?
> >
> > As someone trying to do development on a 3630, this would be helpful
> > to have in the upstream tree.
>
> I'm preparing a patch series to support 37XX versions of Beagle and
> Overo. It includes enhancements to the existing code in
> a
Hi Jeff,
> >> I tried this patch today and DRAM seems to not work after u-boot
>
> > I'll take a look at this, thanks for noting it.
> >
> > Best regards,
> > Aldo Brett
>
> It dawns on me that I didn't ask what toolchain you are using. I've been
> using
> gcc version 4.3.2 (Sourcery G++ Lite 20
Dear Jef,
In message
<226bc4afa29fc24789dfd00dff3084c2524247e...@safemail.safetran.railad.com> you
wrote:
> > Why did you not follow the description in the Manual?
>
> Did you mean:
> http://www.denx.de/wiki/view/DULG/SystemSetup
Yes.
> I can't get Kermit for Windows to work with U-boot.
Why
Dear Reinhard Meyer,
In message <4c6c3133.4000...@emk-elektronik.de> you wrote:
>
> I see. I was assuming that one downloads the text file to ones
> own kernel tree and let the auto-magic work to create the latest
> mach-types.h. I can try to do that but I have not yet
> started to try to compile
Dear s-paul...@ti.com,
In message <1282142754-15756-1-git-send-email-s-paul...@ti.com> you wrote:
> From: Sandeep Paulraj
>
> This patch updates the mach-types.h based on the latest linux kernel
>
> Signed-off-by: Sandeep Paulraj
> ---
>
> Wolfgang Please pull this. Tom used to do thsi regula
Dear Paulraj, Sandeep,
> 3026 actually
Yep, changed after I loaded the page today...
> The patch was against linus's master.
>
> Have all these made it to some kernel tree yet?
>
> It is not un common for kernel to be a little behind.
I see. I was assuming that one downloads the text file to one
> Subject: Re: [PATCH] ARM: Update ARM mach-types
>
> Dear s-paul...@ti.com,
> > +#define MACH_TYPE_FLEXIBITY2965
> > +#define MACH_TYPE_WLAN_COMPUTER2966
> Thanks for the patch, however the latest number in
> http://www.arm.linux.org.uk/developer/machines/
> is 3025
302
Dear s-paul...@ti.com,
> +#define MACH_TYPE_FLEXIBITY2965
> +#define MACH_TYPE_WLAN_COMPUTER2966
Thanks for the patch, however the latest number in
http://www.arm.linux.org.uk/developer/machines/
is 3025
Reinhard
___
U-Boot mailin
commit 47e26b1b "cmd_usage(): simplify return code handling" caused
the following compile warnings:
bedbug_860.c: In function 'bedbug860_do_break':
bedbug_860.c:73: warning: 'return' with a value, in function returning void
bedbug_860.c:121: warning: 'return' with a value, in function returning vo
Dear Stefan Roese,
In message <201008180930.17192...@denx.de> you wrote:
> The following changes since commit 962ad59e25640e586e2bceabf67a628a27f8f508:
>
> env_nand: return error when no device is found (2010-08-13 13:32:42 -0500)
>
> are available in the git repository at:
> git://www.denx.
On Wed, Aug 18, 2010 at 1:46 PM, Albert ARIBAUD wrote:
> Le 18/08/2010 18:46, Mike Frysinger a écrit :
>> you need to include linux/compiler.h first ... but i would have
>> thought this be a header already included globally. maybe that's a
>> new topic to start.
>
> I don't understand why I should
Le 18/08/2010 18:46, Mike Frysinger a écrit :
> On Wed, Aug 18, 2010 at 8:49 AM, Albert ARIBAUD wrote:
>> Le 14/08/2010 19:42, Mike Frysinger a écrit :
>>> On Sat, Aug 14, 2010 at 4:33 AM, Albert ARIBAUD wrote:
Le 14/08/2010 10:25, Mike Frysinger a écrit :
>> int print_buffer (ulong addr
Dear Peter Barada,
In message <1282151376.23742.30.ca...@thunk> you wrote:
>
> Hmm, sounds like you don't use any flow-control on the serial port so
> when u-boot goes away to do work it signals the other end(your host
> running Terraterm/HyperTerminal) to stop transmitting until u-boot's
> seria
Dear "Mangelschots, Jef",
In message
<226bc4afa29fc24789dfd00dff3084c2524247e...@safemail.safetran.railad.com> you
wrote:
> What file transfer protocol do I use when sending an S-record file when I
> issue the loads command ?
There is no protoco. You just send line by line...
> I tried with b
On Wed, 2010-08-18 at 10:11 -0700, Mangelschots, Jef wrote:
> What file transfer protocol do I use when sending an S-record file when I
> issue the loads command ?
>
> I tried with both TerraTerm and Hyperterminal.
>
> In Terraterm, when I use File | Send File ...,
> In HyperTerminal, I use the
What file transfer protocol do I use when sending an S-record file when I issue
the loads command ?
I tried with both TerraTerm and Hyperterminal.
In Terraterm, when I use File | Send File ...,
In HyperTerminal, I use the menu Transfer | Send Text File ...
In both these cases, it reads the firs
Dear Rogan Dawes,
In message <4c6c0b33.8090...@dawes.za.net> you wrote:
>
> Well, I thought that was the point of the "mkimage" header, with the
> Load Address and Entry Point fields. Although, of course, you'll never
These fields are only relevant for executable images, not for data
like ramdisk
On Wed, Aug 18, 2010 at 8:49 AM, Albert ARIBAUD wrote:
> Le 14/08/2010 19:42, Mike Frysinger a écrit :
>> On Sat, Aug 14, 2010 at 4:33 AM, Albert ARIBAUD wrote:
>>> Le 14/08/2010 10:25, Mike Frysinger a écrit :
> int print_buffer (ulong addr, void* data, uint width, uint count, uint
> line
On 2010/08/18 5:33 PM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
>
> Your kernel may not be able to pick up a ramdisk image in flash.
>
> Mainline ARM cannot do that, for example.
>
> [Patches to support that have been submitted, but rejected.]
>
>> Surely that should be Ok? Besides, U-boot is s
Hi Wolfgang,
> Signed-off-by: Wolfgang Denk
> Cc: Heiko Schocher
> Cc: Stefan Roese
> Cc: Roderik Wildenburg
Acked-By: Detlev Zundel
Thanks!
Detlev
--
But in terms of creative information, information that people can use
or enjoy, and that will be used and enjoyed more the more peopl
Hi Sekhar,
> The TI DA850/OMAP-L138/AM18x EVM can be populated with devices
> having different maximum allowed CPU clock rating.
>
> The maximum clock the chip can support can only be determined from
> the label on the package (not software readable).
>
> Introduce a method to pass the maximum all
The TI DA850/OMAP-L138/AM18x EVM can be populated with devices
having different maximum allowed CPU clock rating.
The maximum clock the chip can support can only be determined from
the label on the package (not software readable).
Introduce a method to pass the maximum allowed clock rate informat
The README.davinci in documentation folder is missing information
regarding DA850 which is a supported DaVinci device.
Add this information.
Signed-off-by: Sekhar Nori
---
Applies to latest of U-Boot mainline.
doc/README.davinci | 11 +++
1 files changed, 11 insertions(+), 0 deletion
Dear Rogan Dawes,
In message <4c6bf138.20...@dawes.za.net> you wrote:
>
> > Try copying the raw ramdisk image (i. e. without the U-Boot header) to
> > RAM, and try that one, i. e. something like
> >
> > => cp.b ff9a0040 0160 ...size...
> > ...
> > => bootm ff82 160
>
> Un
From: Sandeep Paulraj
This patch updates the mach-types.h based on the latest linux kernel
Signed-off-by: Sandeep Paulraj
---
Wolfgang Please pull this. Tom used to do thsi regularly
arch/arm/include/asm/mach-types.h | 1140 -
1 files changed, 1116 inserti
On 2010/08/18 12:54 PM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
>
> In message <4c6bac5a.6060...@dawes.za.net> you wrote:
>>
>> Thanks for the suggestion. It did make a slight difference in the boot
>> logs. bootcmd uses the default (in flash) location for the ramdisk,
>
> Actually it's a pretty
Dear Kumar Gala,
In message <1282139990-17758-1-git-send-email-ga...@kernel.crashing.org> you
wrote:
> From: Lian Minghuan
>
> In funciton board_early_init_r(), serdes does not initialize yet.
> variable "serdes_prtcl_map" in function is_serdes_configured() does
> not initialize. sRIO will alw
> Dear Sandeep,
>
> In message <0554bef07d437848af01b9c9b5f0bc5d9fffc...@dlee01.ent.ti.com>
> you wrote:
> >
> > I am not supposed to be adding this patch below
> > http://www.mail-archive.com/u-boot@lists.denx.de/msg34906.html
> >
> > I will need an ACK from the responsible custodian.
>
> Who
From: Lian Minghuan
In funciton board_early_init_r(), serdes does not initialize yet.
variable "serdes_prtcl_map" in function is_serdes_configured() does
not initialize. sRIO will always be disable.
In the original code, there is a undefined variable gur if SRIO is not defined.
Signed-off-by:
Le 14/08/2010 19:42, Mike Frysinger a écrit :
> On Sat, Aug 14, 2010 at 4:33 AM, Albert ARIBAUD wrote:
>> Le 14/08/2010 10:25, Mike Frysinger a écrit :
int print_buffer (ulong addr, void* data, uint width, uint count, uint
linelen)
{
- uint8_t linebuf[MAX_LINE_LENGTH_B
On Wednesday 18 August 2010 14:14:17 Wolfgang Denk wrote:
> Signed-off-by: Wolfgang Denk
> Cc: Heiko Schocher
> Cc: Stefan Roese
> Cc: Roderik Wildenburg
Acked-by: Stefan Roese
Thanks.
Cheers,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munic
Signed-off-by: Wolfgang Denk
Cc: Heiko Schocher
Cc: Stefan Roese
Cc: Roderik Wildenburg
---
board/{ => manroland}/hmi1001/Makefile |0
board/{ => manroland}/hmi1001/config.mk |0
board/{ => manroland}/hmi1001/hmi1001.c |0
board/{ => manroland}/mucmc52/Makefile
Hi Wolfgang,
> Dear Detlev Zundel,
>
> In message you wrote:
>>
>> > Even though its pretty descriptive - for the sake of consistency I
>> > recommend to omit the "_mhz" part.
>>
>> I know that I will mutter a not so nice remark every time I use the
>> variable and am forced to look up the doc
Dear Rogan Dawes,
In message <4c6bac5a.6060...@dawes.za.net> you wrote:
>
> Thanks for the suggestion. It did make a slight difference in the boot
> logs. bootcmd uses the default (in flash) location for the ramdisk,
Actually it's a pretty significant difference, as for the first time
you actuall
Dear Detlev Zundel,
In message you wrote:
>
> > Even though its pretty descriptive - for the sake of consistency I
> > recommend to omit the "_mhz" part.
>
> I know that I will mutter a not so nice remark every time I use the
> variable and am forced to look up the documentation for a single s
Le 18/08/2010 10:47, Ilya Yanok a écrit :
> Hello Albert,
>
> Albert ARIBAUD free.fr> writes:
>
>> At the moment your problem is not being able to reset the PHY at times
>> other than boot, i.e. the 'PHY API' would be limited to reset_phy()
>> which is pretty much board-specific anyway.
>
> The p
On 2010/08/18 7:51 AM, Wolfgang Denk wrote:
> Dear Rogan Dawes,
>
> In message <4c6b08f1.9000...@dawes.za.net> you wrote:
>>
>> The ramdisk is located at ff9a (in flash). Its image header
>> relocates it to 0080:
>
> Try to copy the ramdisk to RAM, and pass the Linux kernl an address in
>
Boards can pass display timing info for drivers using EDID
block. Provide common function to add board specific EDID
data to the device tree. Subsequent patch makes use of this
functionality.
Detailed timing descriptor data from EDID is used for
programming the display controller. This is currentl
Hi Detlev,
On Tue, Aug 17, 2010 at 20:46:16, Detlev Zundel wrote:
> And by the way, if you still fail to see any point in my reasoning, then
> remember that I never NAKed your patches - I was only trying to help.
> The repsective custodians have the final word over acceptance.
Thanks for the rev
Hello Albert,
Albert ARIBAUD free.fr> writes:
> At the moment your problem is not being able to reset the PHY at times
> other than boot, i.e. the 'PHY API' would be limited to reset_phy()
> which is pretty much board-specific anyway.
The problem is the PHY being reseted by the driver and goi
Hi Anatolij,
> Boards can pass display timing info for drivers using EDID
> block. Provide common function to add board specific EDID
> data to the device tree. Subsequent patch makes use of this
> functionality.
You could mention that this is currently implemented on the Linux side
by the fsl-di
Hi Daniel,
> -Original Message-
> From: Daniel Gorsulowski [mailto:daniel.gorsulow...@esd.eu]
> Sent: Monday, August 09, 2010 5:17 PM
> To: u-boot@lists.denx.de
> Cc: Xu, Hong; Daniel Gorsulowski
> Subject: [PATCH v3 3/3] at91: Enabeling USB host on meesc board
>
> There was an redesign
Hi Daniel,
> -Original Message-
> From: Daniel Gorsulowski [mailto:daniel.gorsulow...@esd.eu]
> Sent: Monday, August 09, 2010 5:17 PM
> To: u-boot@lists.denx.de
> Cc: Xu, Hong; Daniel Gorsulowski
> Subject: [PATCH v5 2/3] at91: Update meesc board to new SoC access
>
> * convert meesc boa
Hi Anatolij,
> PDM360NG board uses this functionality to pass display
> timing info to the Linux Framebuffer driver.
>
> Signed-off-by: Anatolij Gustschin
Acked-by: Detlev Zundel
Thanks!
Detlev
--
Der erfahrene Politiker hantiert mit Werten wie mit Fahnen. Man tut so,
als ob klar sei, was
> -Original Message-
> From: Daniel Gorsulowski [mailto:daniel.gorsulow...@esd.eu]
> Sent: Monday, August 09, 2010 5:17 PM
> To: u-boot@lists.denx.de
> Cc: Xu, Hong; Daniel Gorsulowski
> Subject: [PATCH v3 1/3] at91: Defined main clock frequency on
> esd at91 boards
>
> Autodetection
Hi Wolfgang,
> Dear Detlev Zundel,
>
> In message you wrote:
>>
>> > You mean replace "maxspeed" by "cpuclk"? As I have noted a number of times
>> > before, we are not passing the cpu clock speed here. That information
>> > kernel
>> > directly reads from system registers. No need to pass it fr
Dear Joakim Tjernlund,
In message
you
wrote:
> > Joakim Tjernlund wrote:
> >
> > > uec_init() adds an udelay(10) even though
> > > the PHY status read went well, don't do that.
> > >
> > > Signed-off-by: Joakim Tjernlund
> > > ---
> > Acked-by: Kim Phillips
>
> hmm, who gets this into t
Dear Albert ARIBAUD,
In message <4c6b858f.9060...@free.fr> you wrote:
>
> At the moment your problem is not being able to reset the PHY at times
> other than boot, i.e. the 'PHY API' would be limited to reset_phy()
> which is pretty much board-specific anyway. What prevents simply adding
> calls t
>
> Kim Phillips wrote on 2010/08/12 07:17:49:
> >
> > On Wed, 11 Aug 2010 11:44:22 +0200
> > Joakim Tjernlund wrote:
> >
> > > This udelay looks bogus and doesn't help my board.
> > >
> > > Signed-off-by: Joakim Tjernlund
> > > ---
> > >
> > > This delay was introduced by ee62ed3286f83b98b7785
>
> On Wed, 11 Aug 2010 11:44:22 +0200
> Joakim Tjernlund wrote:
>
> > This udelay looks bogus and doesn't help my board.
> >
> > Signed-off-by: Joakim Tjernlund
> > ---
> >
> > This delay was introduced by ee62ed3286f83b98b7785e0318dc6379e78f7ff6
> > Kim, is this really needed for you?
>
> not
The following changes since commit 962ad59e25640e586e2bceabf67a628a27f8f508:
env_nand: return error when no device is found (2010-08-13 13:32:42 -0500)
are available in the git repository at:
git://www.denx.de/git/u-boot-cfi-flash.git master
Kim Phillips (1):
cfi_flash: flinfo: allow u
>
> On Wed, 11 Aug 2010 11:44:21 +0200
> Joakim Tjernlund wrote:
>
> > uec_init() adds an udelay(10) even though
> > the PHY status read went well, don't do that.
> >
> > Signed-off-by: Joakim Tjernlund
> > ---
> Acked-by: Kim Phillips
>
> Kim
hmm, who gets this into the tree?
On Friday 13 August 2010 12:43:02 Stefan Roese wrote:
> This patch does the following:
>
> - Extract code to detect if sector is erased into function
> sector_erased().
> - Because of this, we don't have variable declarations inside the
> sector loop in flash_print_info()
> - Change "return" t
On Tuesday 17 August 2010 18:40:25 Philippe De Muyter wrote:
> I have "ported" U-boot to a in house made board with Numonyx Axcell P33/P30
> 256-Mbit 65nm flash chips.
>
> After some time :( searching for bugs in our board or soft, we have
> discovered that those chips have a small but annoying bu
Hi Alex,
> -Original Message-
> From: Alexander Stein [mailto:alexander.st...@systec-electronic.com]
> Sent: Monday, August 09, 2010 2:35 PM
> To: u-boot@lists.denx.de
> Cc: Jens Scharsig; Xu, Hong
> Subject: Re: [U-Boot] [PATCH V3] AT91 Fix: return value of get_tbclk
>
> Hello,
>
> Am
Le 18/08/2010 01:16, Ilya Yanok a écrit :
> Hello Ben, Everybody,
>
> some boards used to have their PHY quirks in board-specific reset_phy()
> function. This used to work because of reset_phy() being called later
> than Ethernet drivers initialization during startup.
> But nowadays some drivers (i
92 matches
Mail list logo
