Hello,
On Thursday 16 September 2010, 19:44:20 you wrote:
> This patch fixes lib_arm/board.c build errors.
> The combination of "weak" alias and "inline" attributes
> lead to a compile time error when using gcc version 4.4 and above.
>
> Signed-off-by: Stanislav O. Bezzubtsev
> ---
> lib_arm/bo
Whether the latest u-boot supports BCM8727 10GbE SFI-to-XAUI PHY.
--
View this message in context:
http://old.nabble.com/BCM-8727-tp29735532p29735532.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@l
Le 16/09/2010 23:26, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4c927c0c.1080...@free.fr> you wrote:
>>
>> I did not write 'the goal of using fPIC in u-boot', I wrote 'the goal of
>> fPIC', and as such, I think I read it right. I do agree though (and I
>> think I made it clear f
Hi Wolfgang,
Thanks for the info.
We created a custom board based on OMAP4 Blaze EVM Board. Our board is using
LPDDR2 and I am not sure if the
existing x-loader for the said chipset is already configured for LPDDR2.
Do you have any idea how to verify if the LPDDR2 is enabled on the code or
how to
Hi,
Is it ok now for merging?
Thanks,
Lei
On Mon, Sep 13, 2010 at 10:07 PM, Lei Wen wrote:
>
> Signed-off-by: Lei Wen
> ---
> V2:
> Change log:
> change the puts to printf to better formating.
>
> drivers/mmc/mmc.c | 10 ++
> 1 files changed, 10 insertions(+), 0 deletions(-)
>
>
Jaggi Manish-B10520 wrote:
> Most of the read/write functions do this way
> 0:+ int sw = set_mux_to_lbc();
> 1:+
> 2:+ ret = __raw_readl(addr);
> 3:+ if (sw)
> 4:+ set_mux_to_diu();
>
> compiler might reorder 2 before 3 and 0, read / write wont have any
> issue , rig
Hi,
A trivial question
Most of the read/write functions do this way
0:+ int sw = set_mux_to_lbc();
1:+
2:+ ret = __raw_readl(addr);
3:+ if (sw)
4:+ set_mux_to_diu();
compiler might reorder 2 before 3 and 0, read / write wont have any issue ,
right ?
-manish
---
On Tue, 14 Sep 2010 22:40:40 +0200
Ilya Yanok wrote:
> - clrsetbits_be32(&clk->sccr, SCCR_PCIEXP1CM ,
> - SCCR_PCIEXP1CM_1);
> -
this causes a new warning:
Configuring for MPC8308RDB board...
mpc8308rdb.c: In function 'pci_init_board':
mpc8308rdb.c:89: warnin
On Tue, 14 Sep 2010 22:40:37 +0200
Ilya Yanok wrote:
> MPC8308 has only one PCIE host controller so we want it to compile
> without CONFIG_SYS_PCIE2_CFG_{BASE,SIZE} defined.
> +#if defined(CONFIG_SYS_PCIE2_CFG_BASE) && defined(CONFIG_SYS_PCIE2_SIZE)
> #define PCIE_MAX_BUSES 2
> +#else
> +#defin
Hi Marcel,
> What I want to do is upgrade my kernel and rootfs via USB. I'm using an Atmel
> SAM9.
You might be able to find some inspiration in
./boards/mcc200/auto_update.c and ./boards/mcc200/mcc200.c which uses
the U-Boot USB stack for this purpose.
This assumes there is USB host support for
On the Freescale P1022, the DIU and the LBC share address pins, which means
that when the DIU is active (e.g. the console is on the DVI display), NOR flash
cannot be accessed. So we use the weak accessor function feature of the CFI
flash code to temporarily switch the pin mux from DIU to LBC whene
Dear Timur Tabi,
In message <4c928998.4040...@freescale.com> you wrote:
>
> >> +/**
> >> + * set_mux_to_lbc - disable the DIU so that we can read/write to elbc
> >
> > Incorrect multiline comment format. Please check and fix globally.
>
> Can you be more specific? Is it the "**"?
Yes.
> > "#
Dear John Tobias,
In message you
wrote:
>
> How do you debug x-loader?. I have a new custom board based on OMAP and when
> I boot the board using sdcard, I have no idea if the ROM code is reading the
> MLO or not. Assume, it's loading I am not sure what's the error in x-loader.
Use your JTAG d
Dear Timur Tabi,
In message <1284667916-11233-1-git-send-email-ti...@freescale.com> you wrote:
> On the Freescale P1022, the DIU and the LBC share address pins, which means
> that when the DIU is active (e.g. the console is on the DVI display), NOR
> flash
> cannot be accessed. So we use the wea
Dear Albert ARIBAUD,
In message <4c927c0c.1080...@free.fr> you wrote:
>
> I did not write 'the goal of using fPIC in u-boot', I wrote 'the goal of
> fPIC', and as such, I think I read it right. I do agree though (and I
> think I made it clear further in my post) that u-boot images are linked
>
Wolfgang Denk wrote:
> I think the description is wrong - don't you switch from DIU to LBC
> for flash access?
Ugh, yes. I was getting bug-eyed working on this code.
>> +/* Variables used by the DIU/LBC switching code. It's safe to makes these
>> + * global, because the DIU requires DDR, so we
Dear Timur Tabi,
In message <1284667695-10887-1-git-send-email-ti...@freescale.com> you wrote:
> On the Freescale P1022, the DIU and the LBC share address pins, which means
> that when the DIU is active (e.g. the console is on the DVI display), NOR
> flash
> cannot be accessed. So we use the wea
Hi,
How do you debug x-loader?. I have a new custom board based on OMAP and when
I boot the board using sdcard, I have no idea if the ROM code is reading the
MLO or not. Assume, it's loading I am not sure what's the error in x-loader.
Any idea?
Thanks,
John
_
On the Freescale P1022, the DIU and the LBC share address pins, which means
that when the DIU is active (e.g. the console is on the DVI display), NOR flash
cannot be accessed. So we use the weak accessor function feature of the CFI
flash code to temporarily switch the pin mux from LBC to DIU whene
Le 16/09/2010 13:29, Wolfgang Denk a écrit :
> Dear Albert ARIBAUD,
>
> In message<4c91f659.7020...@free.fr> you wrote:
>>
>> Well, the main goal of -fPIC is that the code should be able to run from
>> anywhere, so it should be able to run from anywhere in FLASH. Besides,
>
> You misread that. We
On the Freescale P1022, the DIU and the LBC share address pins, which means
that when the DIU is active (e.g. the console is on the DVI display), NOR flash
cannot be accessed. So we use the weak accessor function feature of the CFI
flash code to temporarily switch the pin mux from LBC to DIU whene
Hi,
I've been away for some time and I wonder if there has been any progress on
the u-boot USB branch.
What I want to do is upgrade my kernel and rootfs via USB. I'm using an Atmel
SAM9.
I wonder about the status and if any additional work is needed I'm willing to
help with the project of cou
> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Wolfgang Denk
> Sent: Friday, September 10, 2010 4:43 PM
> To: Amit Kucheria
> Cc: u-boot@lists.denx.de; r65...@freescale.com
> Subject: Re: [U-Boot] status of patch to store env
By default the trace broadcast is enabled on 44x systems.
To reduce power consumption when instruction tracing is
not needed, disable trace broadcast.
Check External Debug Mode (EDM) bit to detect if it should be
disabled or not.
Resetting system via a debugger will set the DBCR0[EDM] bit.
Reset
On Thursday, September 16, 2010 11:44:57 Premi, Sanjeev wrote:
> But, wanted to share my experience on the same topic. Posed with
> same problem, I had looked at minimizing the u-boot binary and
> had managed to reach 29-30KB
the Blackfin one is in the range of 200-600 bytes. i don
On Thu, 16 Sep 2010 21:14:57 +0530
"Premi, Sanjeev" wrote:
> [sp] I was pointed to this thread through another discussion. I did
> see (almost) an agreement reached here.
>
> But, wanted to share my experience on the same topic. Posed with
> same problem, I had looked at minimizin
This patch fixes lib_arm/board.c build errors.
The combination of "weak" alias and "inline" attributes
lead to a compile time error when using gcc version 4.4 and above.
Signed-off-by: Stanislav O. Bezzubtsev
---
lib_arm/board.c | 18 +-
1 files changed, 9 insertions(+), 9 dele
On Thu, 16 Sep 2010 09:42:07 +0200
Reda MIMOUNE wrote:
> So in my both cases, what you said explains that the case I met. I will put
> this flag and check if it
> is present in my 1.3.4 version.
My expense request for a time machine was denied, so we can't go back
and put new features in old ve
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Kyungmin Park
> Sent: Tuesday, September 14, 2010 7:48 PM
> To: Stefan Roese
> Cc: u-boot@lists.denx.de; Shiraz HASHIM
> Subject: Re: [U-Boot] Multiple binaries built through u-bo
Signed-off-by: Stefan Roese
---
v2:
- Removed all non-PPC4xx related files. Sorry for this.
arch/powerpc/cpu/ppc4xx/cpu_init.c |2 +-
arch/powerpc/cpu/ppc4xx/gpio.c |2 +-
arch/powerpc/include/asm/{gpio.h => ppc4xx-gpio.h} |0
board/amcc/acadia/mem
On 2010/09/16 5:10 PM, Stefan Roese wrote:
> Hi Rogan,
>
> On Thursday 16 September 2010 16:21:05 Rogan Dawes wrote:
>> Have you had any thoughts about what the CONFIG_CFI option should be
>> called for the odd flash arrangement on my DNS323? If you let me know
>> what to call it, I'll submit a pa
Hi Rogan,
On Thursday 16 September 2010 16:21:05 Rogan Dawes wrote:
> Have you had any thoughts about what the CONFIG_CFI option should be
> called for the odd flash arrangement on my DNS323? If you let me know
> what to call it, I'll submit a patch.
Sorry, but no, I have no idea right now. IIRC,
Dear ethan paddloch,
In message <20605.87096...@web120208.mail.ne1.yahoo.com> you wrote:
> I have seen that for the mpc8323e bsp, the RAM memory is just defined as 64Mb
> by means to set the MPC8323ERDB.h. I would like to use the get_ram_size()
> function found in memsize.c source by including i
Dear Kumar Gala,
In message <2f551a4a-1f16-465a-b9f5-46e973a27...@kernel.crashing.org> you wrote:
> This topics has come up in the past and I was wondering if this was a general
> direction we want to go towards and try and solve?
Yes, we do.
Best regards,
Wolfgang Denk
--
DENX Software Engi
On 2010/09/16 4:18 PM, Stefan Roese wrote:
> On Tuesday 31 August 2010 13:33:23 Stefan Roese wrote:
>> following are a few patches with minor code clean-up and simplification for
>> the cfi_flash driver. Especially the usage of
>> CONFIG_SYS_MAX_FLASH_BANKS_DETECT to support dynamic flash bank numb
The following changes since commit 55340878385db4c87b89b147d3197a46e25b03ef:
Merge branch 'master' into next (2010-09-13 13:16:34 +0200)
are available in the git repository at:
git://www.denx.de/git/u-boot-cfi-flash.git next
Stefan Roese (4):
cfi_flash: Simplify flash_get_info()
On Tuesday 31 August 2010 13:33:23 Stefan Roese wrote:
> following are a few patches with minor code clean-up and simplification for
> the cfi_flash driver. Especially the usage of
> CONFIG_SYS_MAX_FLASH_BANKS_DETECT to support dynamic flash bank number
> detection is reworked a bit. Additionally,
Hi Wolfgang,
On Thursday 16 September 2010 14:27:23 Wolfgang Denk wrote:
> > Yes, I remember. I'm "on the way" to using this common driver. But the
> > PPC4xx one currently has quite a lot of special handling cases, like
> > this SOFTWARE_FIFO stuff, which I first need to sort out.
>
> Are any of
Hi Detlev,
On Thursday 16 September 2010 15:00:05 Detlev Zundel wrote:
> > Please note that I plan to stay with this "asm/ppc4xx-gpio.h" name
> > instead of "asm/gpio.h", since there are many other PowerPC variants out
> > there.
>
> I have to admit that I don't like this.
>
> Hm, while you are
I have seen that for the mpc8323e bsp, the RAM memory is just defined as 64Mb
by means to set the MPC8323ERDB.h. I would like to use the get_ram_size()
function found in memsize.c source by including it on the mpc8323erdb. source.
Could anyone tell me what is the procedure to make this modificat
This topics has come up in the past and I was wondering if this was a general
direction we want to go towards and try and solve?
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Hi Stefan,
> Ups. No, I totally missed this. Thanks for spotting. Will fix soon.
Ok.
> Please note that I plan to stay with this "asm/ppc4xx-gpio.h" name instead of
> "asm/gpio.h", since there are many other PowerPC variants out there.
I have to admit that I don't like this.
Hm, while you are
Hi Wolfgang,
On Thursday 16 September 2010 14:44:07 Wolfgang Denk wrote:
> > This function will be called to fixup size of the "reg" property of the
> > NOR flash device tree nodes. Ebony can't use the weak default, since
> > it has a special chip-select to bank-number binding.
> >
> > Signed-off
Dear Stefan Roese,
In message <1284639795-6702-1-git-send-email...@denx.de> you wrote:
> This function will be called to fixup size of the "reg" property of the
> NOR flash device tree nodes. Ebony can't use the weak default, since
> it has a special chip-select to bank-number binding.
>
> Signed
Signed-off-by: Daniel Hobi
---
v2:
- print a hint to --help before returning
tools/env/fw_env_main.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
Hi Wolfgang,
On 15.09.2010 21:18, Wolfgang Denk wrote:
> In message <1284572787-9842-2-git-send-email-daniel.h...@schmid-telecom.
Dear Stefan Roese,
In message <201009161416.34827...@denx.de> you wrote:
>
> Yes, I remember. I'm "on the way" to using this common driver. But the PPC4xx
> one currently has quite a lot of special handling cases, like this
> SOFTWARE_FIFO stuff, which I first need to sort out.
Are any of thes
This function will be called to fixup size of the "reg" property of the
NOR flash device tree nodes. Ebony can't use the weak default, since
it has a special chip-select to bank-number binding.
Signed-off-by: Stefan Roese
---
board/amcc/ebony/flash.c | 31 +++
1 fil
This patch changes the behaviour of the fdt_fixup_nor_flash_node()
function. Now it doesn't patch the size of the "reg" property with the
chip-select size, but with the size returned from the new function
flash_get_bank_size(). This function will return per weak default the
flash size of the bank (
Hi Detlev,
On Thursday 16 September 2010 14:05:08 Detlev Zundel wrote:
> > +++ b/arch/blackfin/cpu/cmd_gpio.c
> > @@ -10,7 +10,7 @@
> >
> > #include
> >
> > #include
> >
> > -#include
> > +#include
>
> This really defeats the symlinking of the asm directory and using
> generic names. I
Hi Detlev,
On Thursday 16 September 2010 14:12:28 Detlev Zundel wrote:
> > This patch changes the PPC4xx UART driver to use the NS16550 struct
> > instead of macros for the register offsets.
>
> Dumb question - can't you reuse drivers/serial/ns16550.c completely?
> This would be even better. It
Hi Stefan,
> This patch removes the completely unused CONFIG_SERIAL_SOFTWARE_FIFO
> feature from U-Boot. It has only been implemented for PPC4xx and was not
> used at all. So let's remove it and make the code smaller and cleaner.
>
> Signed-off-by: Stefan Roese
Acked-by: Detlev Zundel
Cheers
Hi Stefan,
> This patch changes the PPC4xx UART driver to use the NS16550 struct
> instead of macros for the register offsets.
Dumb question - can't you reuse drivers/serial/ns16550.c completely?
This would be even better. It worked for me on the vct boards,
remember?
Cheers
Detlev
--
:!em
Hi Stefan,
> Signed-off-by: Stefan Roese
> ---
> arch/blackfin/cpu/cmd_gpio.c |2 +-
> arch/blackfin/cpu/gpio.c |2 +-
> arch/powerpc/cpu/ppc4xx/cpu_init.c |2 +-
> arch/powerpc/cpu/ppc4xx/gpio.c |
Hi Peter,
> I agree we should be using main() as the entry point either way. I'll
> add that to the TODO list. If we did go with -fno-toplevel-reorder I
> could add the following to each application to make it clear what's
> going on:
> /* Define main() protoype first to ensure its the first fun
Dear Wolfgang Denk,
On Thu, Sep 16, 2010 at 01:06:01PM +0200, Wolfgang Denk wrote:
> Dear Wolfgang Wegner,
>
> In message <20100916101810.gh25...@leila.ping.de> you wrote:
[...]
> > struggle with debugging tools that are either plain too stupid to
> > program some flash devices or are much slower
Dear Prafulla Wadaskar,
In message <1284648724-6871-1-git-send-email-prafu...@marvell.com> you wrote:
> Earlier Device Identification register was used to detect
> the type for SoC, considering 88F6282 support to be added,
> It is not possible to detect the same using current
> algorithm.
>
> Wit
Dear Albert ARIBAUD,
In message <4c91f659.7020...@free.fr> you wrote:
>
> Well, the main goal of -fPIC is that the code should be able to run from
> anywhere, so it should be able to run from anywhere in FLASH. Besides,
You misread that. We actually make no attempts that the code can be
run from
Shawn Jin wrote:
> Hi,
>
> I have a cuImage kernel in order to support legacy u-boot and a
> ramdisk image. Kernel boots fine if these two images are separate and
> "bootm $kernel $ramdisk" is used. But I can not make it to work using
> a single multi image that contains the kernel and ramdisk ima
> -Original Message-
> From: u-boot-boun...@lists.denx.de
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud
> Sent: Wednesday, September 08, 2010 11:01 PM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH V3] mvsata_ide: adjust port init sequence
>
> mvsata_ide_in
Dear Wolfgang Wegner,
In message <20100916101810.gh25...@leila.ping.de> you wrote:
>
> I see this feature not only nice to speed up development, sometimes
> it also comes in really handy for production, too - if you have to
I think we all agree that this would be a nice-to-have feature.
> strugg
Hi Prafulla,
Le 16/09/2010 16:52, Prafulla Wadaskar a écrit :
> diff --git a/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
b/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
> index 82c978b..5feb0b5 100644
> --- a/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
> +++ b/arch/arm/cpu/arm926ejs/kirkwood/cpu.c
> @@ -271,2
Le 16/09/2010 07:09, Heiko Schocher a écrit :
> Hello Albert,
>
> Albert ARIBAUD wrote:
>> Le 11/08/2010 20:16, Heiko Schocher a écrit :
>>
>>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
>>> index 54519b0..88c6427 100644
>>> --- a/arch/arm/lib/board.c
>>> +++ b/arch/arm/lib/board.c
>>
Le 16/09/2010 12:18, Wolfgang Wegner a écrit :
> On Thu, Sep 16, 2010 at 07:54:03PM +1000, Graeme Russ wrote:
> [...]
>> I have a 'cold-boot' parameter which is set by the reset vector code. I can
>> use this to selectively skip 'once-only' initialisation
> [...]
>> I don't doubt that you are entir
Earlier Device Identification register was used to detect
the type for SoC, considering 88F6282 support to be added,
It is not possible to detect the same using current
algorithm.
With this patch, device ID is being read using PCIE devid
register, also valid chip revision ID will also be read and
On Thu, Sep 16, 2010 at 07:54:03PM +1000, Graeme Russ wrote:
[...]
> I have a 'cold-boot' parameter which is set by the reset vector code. I can
> use this to selectively skip 'once-only' initialisation
[...]
> I don't doubt that you are entirely correct. But there are many ways to
> skin a cat. My
On 16/09/10 18:23, Wolfgang Denk wrote:
> Dear Graeme Russ,
>
> In message you
> wrote:
>>
>>> I agree that it would be nice to have U-Boot completely position-
>>> independent and completelky restartable, but this would be a new
>>> feature, which newer existed before.
>>>
>>
>> x86 has a nice
Dear Graeme Russ,
In message you
wrote:
>
> > I agree that it would be nice to have U-Boot completely position-
> > independent and completelky restartable, but this would be a new
> > feature, which newer existed before.
> >
>
> x86 has a nice feature whereby I can build two images that differ
> Try the following steps:
> --
> 1. cp arch/powerpc/boot/ramdisk.image.gz
> 2. make cuImage.initrd.
>
> You can get one Image, cuImage.initrd., including kernel and
> ramdisk.
Cool! Thanks a lot, Tiejun.
-Shawn.
___
U-Boot mailing list
U-Boot@lis
Hi,
I have a strange problem that causes a lot of difficulties to our production
.
My aim is to burn the Kernel.
On some boards in the production there's this problem:
If I write to the command line: nand erase 0x40 0x20
and then tftp and then write the Kernel to the NAND it works fine.
Hi Scott.
Thank you for your answer.
>You can use CONFIG_ENV_RANGE to declare a multi-block range, larger than
>the environment size, to allow bad blocks to be skipped.
>You need to use CONFIG_ENV_RANGE and keep the environment the same size
>-- otherwise it thinks you really want two blocks of e
On Thu, Sep 16, 2010 at 5:06 PM, Wolfgang Denk wrote:
> Dear Alessandro Rubini,
>
> I agree that it would be nice to have U-Boot completely position-
> independent and completelky restartable, but this would be a new
> feature, which newer existed before.
>
x86 has a nice feature whereby I can bu
Dear manojatl,
In message <29725451.p...@talk.nabble.com> you wrote:
>
> We are using tool chain gnuarm 3.4.3 to compile U-Boot 1.1.6 for SMDK2400
> board (ARM 9). The commands were as follows.
GCC 3.4.3 was released 6.5 years ago. U-Boot 1.1.6 was released 4.5
years ago.
These versions are ex
On Thu, Sep 16, 2010 at 4:48 PM, manojatl wrote:
>
> We are using tool chain gnuarm 3.4.3 to compile U-Boot 1.1.6 for SMDK2400
> board (ARM 9). The commands were as follows.
>
>
>make distclean
>make smdk2400_config
>make
>
> We are able to success
Dear Alessandro Rubini,
In message <20100916062347.ga25...@morgana.i.gnudd.com> you wrote:
>
> One of the things I love(d) with u-boot (at least the ARM one) is that
> I could place it in flash at any address and it would just work. So
> when I have a new binary I first write it to another flash
74 matches
Mail list logo
