Re: [U-Boot] [PATCH] trats: Enable EXT4 and EFI partitions support on Samsung's Trats board

[Lukasz Majewski]

Hi Minkyu,

> Dear Lukasz,
> 
> On 4 October 2012 18:27, Lukasz Majewski 
> wrote:
> > Signed-off-by: Lukasz Majewski 
> > Signed-off-by: Kyungmin Park 
> > ---
> >  include/configs/trats.h |6 +-
> >  1 files changed, 5 insertions(+), 1 deletions(-)
> >
> > diff --git a/include/configs/trats.h b/include/configs/trats.h
> > index b3b5a3d..aaf64eb 100644
> > --- a/include/configs/trats.h
> > +++ b/include/configs/trats.h
> > @@ -104,6 +104,9 @@
> >  #define CONFIG_CMD_FAT
> >  #define CONFIG_FAT_WRITE
> 
> So, do we need to keep FAT related features?

Since the ext4 is not fully stabilized - I would opt for keeping the
FAT support for default (mainline) trats configuration.
> 
> >
> > +/* EXT4 */
> > +#define CONFIG_CMD_EXT4
> > +
> >  /* USB Composite download gadget - g_dnl */
> >  #define CONFIG_USBDOWNLOAD_GADGET
> >  #define CONFIG_DFU_FUNCTION
> > @@ -167,7 +170,7 @@
> > "meminfo=crashkernel=32M@0x5000\0" \
> > "nfsroot=/nfsroot/arm\0" \
> > "bootblock=" CONFIG_BOOTBLOCK "\0" \
> > -   "loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x40007FC0
> > uImage\0" \
> > +   "loaduimage=ext4load mmc ${mmcdev}:${mmcbootpart}
> > 0x40007FC0 uImage\0" \ "mmcdev=0\0" \
> > "mmcbootpart=2\0" \
> > "mmcrootpart=3\0" \
> > @@ -208,6 +211,7 @@
> >  #define CONFIG_ENV_OFFSET  ((32 - 4) << 10) /* 32KiB -
> > 4KiB */
> >
> >  #define CONFIG_DOS_PARTITION
> 
> also dos partition.

EFI patches are on the way to mainline, but aren't accepted. I would
like to keep DOS partitions support at least until EFI support is done.

> 
> > +#define CONFIG_EFI_PARTITION
> >
> 
> Thanks
> Minkyu Kang.



-- 
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] EXYNOS: Add Exynos4 I2C spacing

[Piotr Wilczek]

Dear Minkyu and Joonyoung,

> -Original Message-
> From: Minkyu Kang [mailto:proms...@gmail.com]
> Sent: Friday, October 12, 2012 7:26 AM
> To: Joonyoung Shim
> Cc: Piotr Wilczek; u-boot@lists.denx.de; Kyungmin Park
> Subject: Re: [U-Boot] [PATCH 2/5] EXYNOS: Add Exynos4 I2C spacing
> 
> Dear Joonyoung,
> 
> On 12 October 2012 12:29, Joonyoung Shim  wrote:
> > Hi,
> >
> > 2012/10/12 Minkyu Kang :
> >> Dear Piotr and Joonyoung,
> >>
> >> On 11 October 2012 17:14, Piotr Wilczek 
> wrote:
> >>> Hi Joonyoung,
> >>>
>  -Original Message-
>  From: Joonyoung Shim [mailto:dofm...@gmail.com]
>  Sent: Thursday, October 11, 2012 3:11 AM
>  To: Piotr Wilczek
>  Cc: u-boot@lists.denx.de; Kyungmin Park
>  Subject: Re: [U-Boot] [PATCH 2/5] EXYNOS: Add Exynos4 I2C spacing
> 
>  Hi, Protr.
> 
>  2012/9/24 Piotr Wilczek :
>  > This patch add the spacing for i2c for Exynos4
>  >
>  > Signed-off-by: Piotr Wilczek 
>  > Signed-off-by: Kyungmin Park 
>  > CC: Minkyu Kang 
>  > ---
>  >  arch/arm/include/asm/arch-exynos/cpu.h |2 ++
>  >  1 files changed, 2 insertions(+), 0 deletions(-)
>  >
>  > diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
>  > b/arch/arm/include/asm/arch-exynos/cpu.h
>  > index 5056b37..b70273c 100644
>  > --- a/arch/arm/include/asm/arch-exynos/cpu.h
>  > +++ b/arch/arm/include/asm/arch-exynos/cpu.h
>  > @@ -28,6 +28,8 @@
>  >  #define EXYNOS4_ADDR_BASE  0x1000
>  >
>  >  /* EXYNOS4 */
>  > +#define EXYNOS4_I2C_SPACING0x1
>  > +
> 
>  Also EXYNOS5_I2C_SPACING is 0x1, so how about define just
>  EXYNOS_I2C_SPACING for both EXYNOS4 and EXYNOS5?
> >>> I agree it would simplify the code (s3c24x0_i2c driver). On the
> >>> other hand, for code readability, maybe it is better to keep them
> >>> separate as we do so with all defines for each Exynos.
> >>>
> >
> > OK, but already s3c24x0_i2c driver has too many #ifdef statements, so
> > i just concern it. We may need to use cpu_is_xxx to remove #ifdef.
> >
> 
> Right.
> We should do cleanup.
> Actually, I don't want to use such a define and ifdefs.. like other
> devices.
> I think, we can solve this problem by separate i2c driver from s3c24x0.
> How you think?

I agree that the driver is too complicated and we should separate i2c from
s3c24x0. I just thought it could be done in a separate patchset. However, if
you think it should be done now, I will do so.

> 
> --
> from. prom.
> www.promsoft.net

Best regards,
Piotr Wilczek



___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master to u-boot/master

[Minkyu Kang]

On 12 October 2012 14:55, Albert ARIBAUD  wrote:
> On Fri, 12 Oct 2012 07:36:20 +0200, Albert ARIBAUD
>  wrote:
>
>> Hi Tom,
>>
>> On Thu, 11 Oct 2012 11:45:35 -0700, Tom Rini  wrote:
>>
>> > On Thu, Oct 11, 2012 at 06:51:30PM +0200, Albert ARIBAUD wrote:
>> >
>> > > Hi Tom,
>> > >
>> > > The following changes since commit
>> > > 28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad:
>> > >
>> > >   arm: armv7: temporarily set -mno-unaligned-access (2012-10-05
>> > >   21:24:22 +0200)
>> > >
>> > > are available in the git repository at:
>> > >
>> > >   git://git.denx.de/u-boot-arm master
>> > >
>> > > for you to fetch changes up to 9b5dba537473578153961ee96ed23e37e1fde3f7:
>> > >
>> > >   exynos4: universal_C210: use software SPI (2012-10-10 20:37:39 +0900)
>> > >
>> > > 
>> > > Chander Kashyap (1):
>> > >   Exynos5250: Enable PXE Support
>> > >
>> > > Piotr Wilczek (9):
>> > >   arm:exynos4:trats: Correct SDRAM configuration for trats
>> > >   arm:exynos4:trats: Fix SDRAM size
>> > >   arm:exynos4:pinmux: Modify the gpio function for mmc
>> > >   arm:exynos4:trats: Use pinmux for mmc configuration
>> > >   arm:exynos4:universal: Use pinmux for mmc configuration
>> > >   arm:exynos4:universal: Eliminated low level init
>> > >   arm: trats: Power down core 1
>> > >   drivers: spi: modify soft spi driver
>> > >   exynos4: universal_C210: use software SPI
>> > >
>> > > ??ukasz Majewski (1):
>> > >   gpio:fix: Proper handling of GPIO subsystem parts at Samsung
>> > > devices
>> > >
>> > >  arch/arm/cpu/armv7/exynos/pinmux.c   |   58 
>> > >  arch/arm/include/asm/arch-exynos/gpio.h  |   19 ++
>> > >  arch/arm/include/asm/arch-exynos/periph.h|1 +
>> > >  arch/arm/include/asm/arch-s5pc1xx/gpio.h |7 +-
>> > >  board/samsung/trats/trats.c  |   80 ++
>> > >  board/samsung/universal_c210/Makefile|1 -
>> > >  board/samsung/universal_c210/lowlevel_init.S |  395
>> > >  --
>> > >  board/samsung/universal_c210/universal.c |  116 
>> > >  drivers/gpio/s5p_gpio.c  |6 +-
>> > >  drivers/spi/soft_spi.c   |3 +
>> > >  include/configs/s5pc210_universal.h  |   21 ++
>> > >  include/configs/smdk5250.h   |6 +
>> > >  include/configs/trats.h  |   17 +- 13 files
>> > >  changed, 209 insertions(+), 521 deletions(-) delete mode 100644
>> > >  board/samsung/universal_c210/lowlevel_init.S
>> >
>> > NAK, sorry.  We have a two problems now:
>> > - On PowerPC we have  which takes  but
>> >   boards which do use soft_spi.c and now fail (taihu sacsng)
>> > - zipitz2 has the same problem (cc'ing Marek)
>>
>> Now that's very weird. I *know* I had issues with zipitz2 among others
>> when I git am'd the commits while the git server was down; then when
>> I could fetch u-boot/samsung I re-tested u-boot-samsung/master in
>> itself then merged into u-boot-arm/master, and I *know* those ran
>> fine... And now they don't. Something's fishy in my git repo. :(
>>
>> In any case: NAK fully understood and agreed upon, in my capacity as a
>> custodian, back-ported into ARM repo, i.e. I've rolled back ARM master
>> to where it was before the (ff) merge.
>>
>> Also, actually CC:ing Marek, as well as Minkyu.
>
> *Actually* CC:ing Minkyu...
>

CC:ing Piotr.


-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ARM] [STATUS] ATTENTION: Uu-boot-arm/master branch ROLLBACK to 28e5ac2d

[Minkyu Kang]

On 12 October 2012 15:39, Minkyu Kang  wrote:
> Dear Albert,
>
> On 12 October 2012 14:53, Albert ARIBAUD  wrote:
>> Hi all,
>>
>> I am sending this notice because I have force-pushed a rollback of
>> u-boot-arm/master.
>>
>> This is due to the recently submitted u-boot-arm/master pull request
>> being NAKed by Tom: the content of this pull req was exactly that of
>> the latest u-boot-samsung/master pull req and was a fast forward from
>> previous u-boot-arm/master (28e5ac2d) which had received extensive
>> testing from Tom.
>>
>> Therefore, as a roll back of u-boot-arm/master was both easy to perform
>> and safe(r) from a release perspective, I decided to stray from formal
>> master branch management rules and force it back to 28e5ac2d.
>>
>> All: if you intend to send a pull request to u-boot-arm/master, please
>> rework this request to take this rollback into account.
>>
>> Minkyu: for the reasons above, I suggest you roll u-boot-samsung/master
>> back to 28e5ac2d before building and sending an amended pull req, but of
>> course the choice is yours.
>>
>
> OK. I'll revert soft i2c patches and send new pull request at next Monday.

sorry. spi, not i2c.

> Is it OK?




-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [ARM] [STATUS] ATTENTION: Uu-boot-arm/master branch ROLLBACK to 28e5ac2d

[Minkyu Kang]

Dear Albert,

On 12 October 2012 14:53, Albert ARIBAUD  wrote:
> Hi all,
>
> I am sending this notice because I have force-pushed a rollback of
> u-boot-arm/master.
>
> This is due to the recently submitted u-boot-arm/master pull request
> being NAKed by Tom: the content of this pull req was exactly that of
> the latest u-boot-samsung/master pull req and was a fast forward from
> previous u-boot-arm/master (28e5ac2d) which had received extensive
> testing from Tom.
>
> Therefore, as a roll back of u-boot-arm/master was both easy to perform
> and safe(r) from a release perspective, I decided to stray from formal
> master branch management rules and force it back to 28e5ac2d.
>
> All: if you intend to send a pull request to u-boot-arm/master, please
> rework this request to take this rollback into account.
>
> Minkyu: for the reasons above, I suggest you roll u-boot-samsung/master
> back to 28e5ac2d before building and sending an amended pull req, but of
> course the choice is yours.
>

OK. I'll revert soft i2c patches and send new pull request at next Monday.
Is it OK?

Thanks.
Minkyu Kang.
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master to u-boot/master

[Albert ARIBAUD]

On Fri, 12 Oct 2012 07:36:20 +0200, Albert ARIBAUD
 wrote:

> Hi Tom,
> 
> On Thu, 11 Oct 2012 11:45:35 -0700, Tom Rini  wrote:
> 
> > On Thu, Oct 11, 2012 at 06:51:30PM +0200, Albert ARIBAUD wrote:
> > 
> > > Hi Tom,
> > > 
> > > The following changes since commit
> > > 28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad:
> > > 
> > >   arm: armv7: temporarily set -mno-unaligned-access (2012-10-05
> > >   21:24:22 +0200)
> > > 
> > > are available in the git repository at:
> > > 
> > >   git://git.denx.de/u-boot-arm master
> > > 
> > > for you to fetch changes up to 9b5dba537473578153961ee96ed23e37e1fde3f7:
> > > 
> > >   exynos4: universal_C210: use software SPI (2012-10-10 20:37:39 +0900)
> > > 
> > > 
> > > Chander Kashyap (1):
> > >   Exynos5250: Enable PXE Support
> > > 
> > > Piotr Wilczek (9):
> > >   arm:exynos4:trats: Correct SDRAM configuration for trats
> > >   arm:exynos4:trats: Fix SDRAM size
> > >   arm:exynos4:pinmux: Modify the gpio function for mmc
> > >   arm:exynos4:trats: Use pinmux for mmc configuration
> > >   arm:exynos4:universal: Use pinmux for mmc configuration
> > >   arm:exynos4:universal: Eliminated low level init
> > >   arm: trats: Power down core 1
> > >   drivers: spi: modify soft spi driver
> > >   exynos4: universal_C210: use software SPI
> > > 
> > > ??ukasz Majewski (1):
> > >   gpio:fix: Proper handling of GPIO subsystem parts at Samsung
> > > devices
> > > 
> > >  arch/arm/cpu/armv7/exynos/pinmux.c   |   58 
> > >  arch/arm/include/asm/arch-exynos/gpio.h  |   19 ++
> > >  arch/arm/include/asm/arch-exynos/periph.h|1 +
> > >  arch/arm/include/asm/arch-s5pc1xx/gpio.h |7 +-
> > >  board/samsung/trats/trats.c  |   80 ++
> > >  board/samsung/universal_c210/Makefile|1 -
> > >  board/samsung/universal_c210/lowlevel_init.S |  395
> > >  --
> > >  board/samsung/universal_c210/universal.c |  116 
> > >  drivers/gpio/s5p_gpio.c  |6 +-
> > >  drivers/spi/soft_spi.c   |3 +
> > >  include/configs/s5pc210_universal.h  |   21 ++
> > >  include/configs/smdk5250.h   |6 +
> > >  include/configs/trats.h  |   17 +- 13 files
> > >  changed, 209 insertions(+), 521 deletions(-) delete mode 100644
> > >  board/samsung/universal_c210/lowlevel_init.S
> > 
> > NAK, sorry.  We have a two problems now:
> > - On PowerPC we have  which takes  but
> >   boards which do use soft_spi.c and now fail (taihu sacsng)
> > - zipitz2 has the same problem (cc'ing Marek)
> 
> Now that's very weird. I *know* I had issues with zipitz2 among others
> when I git am'd the commits while the git server was down; then when
> I could fetch u-boot/samsung I re-tested u-boot-samsung/master in
> itself then merged into u-boot-arm/master, and I *know* those ran
> fine... And now they don't. Something's fishy in my git repo. :(
> 
> In any case: NAK fully understood and agreed upon, in my capacity as a
> custodian, back-ported into ARM repo, i.e. I've rolled back ARM master
> to where it was before the (ff) merge.
> 
> Also, actually CC:ing Marek, as well as Minkyu.

*Actually* CC:ing Minkyu...

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [ARM] [STATUS] ATTENTION: Uu-boot-arm/master branch ROLLBACK to 28e5ac2d

[Albert ARIBAUD]

Hi all,

I am sending this notice because I have force-pushed a rollback of
u-boot-arm/master.

This is due to the recently submitted u-boot-arm/master pull request
being NAKed by Tom: the content of this pull req was exactly that of
the latest u-boot-samsung/master pull req and was a fast forward from
previous u-boot-arm/master (28e5ac2d) which had received extensive
testing from Tom.

Therefore, as a roll back of u-boot-arm/master was both easy to perform
and safe(r) from a release perspective, I decided to stray from formal
master branch management rules and force it back to 28e5ac2d.

All: if you intend to send a pull request to u-boot-arm/master, please
rework this request to take this rollback into account.

Minkyu: for the reasons above, I suggest you roll u-boot-samsung/master
back to 28e5ac2d before building and sending an amended pull req, but of
course the choice is yours.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master to u-boot/master

[Albert ARIBAUD]

Hi Tom,

On Thu, 11 Oct 2012 11:45:35 -0700, Tom Rini  wrote:

> On Thu, Oct 11, 2012 at 06:51:30PM +0200, Albert ARIBAUD wrote:
> 
> > Hi Tom,
> > 
> > The following changes since commit
> > 28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad:
> > 
> >   arm: armv7: temporarily set -mno-unaligned-access (2012-10-05
> >   21:24:22 +0200)
> > 
> > are available in the git repository at:
> > 
> >   git://git.denx.de/u-boot-arm master
> > 
> > for you to fetch changes up to 9b5dba537473578153961ee96ed23e37e1fde3f7:
> > 
> >   exynos4: universal_C210: use software SPI (2012-10-10 20:37:39 +0900)
> > 
> > 
> > Chander Kashyap (1):
> >   Exynos5250: Enable PXE Support
> > 
> > Piotr Wilczek (9):
> >   arm:exynos4:trats: Correct SDRAM configuration for trats
> >   arm:exynos4:trats: Fix SDRAM size
> >   arm:exynos4:pinmux: Modify the gpio function for mmc
> >   arm:exynos4:trats: Use pinmux for mmc configuration
> >   arm:exynos4:universal: Use pinmux for mmc configuration
> >   arm:exynos4:universal: Eliminated low level init
> >   arm: trats: Power down core 1
> >   drivers: spi: modify soft spi driver
> >   exynos4: universal_C210: use software SPI
> > 
> > ??ukasz Majewski (1):
> >   gpio:fix: Proper handling of GPIO subsystem parts at Samsung
> > devices
> > 
> >  arch/arm/cpu/armv7/exynos/pinmux.c   |   58 
> >  arch/arm/include/asm/arch-exynos/gpio.h  |   19 ++
> >  arch/arm/include/asm/arch-exynos/periph.h|1 +
> >  arch/arm/include/asm/arch-s5pc1xx/gpio.h |7 +-
> >  board/samsung/trats/trats.c  |   80 ++
> >  board/samsung/universal_c210/Makefile|1 -
> >  board/samsung/universal_c210/lowlevel_init.S |  395
> >  --
> >  board/samsung/universal_c210/universal.c |  116 
> >  drivers/gpio/s5p_gpio.c  |6 +-
> >  drivers/spi/soft_spi.c   |3 +
> >  include/configs/s5pc210_universal.h  |   21 ++
> >  include/configs/smdk5250.h   |6 +
> >  include/configs/trats.h  |   17 +- 13 files
> >  changed, 209 insertions(+), 521 deletions(-) delete mode 100644
> >  board/samsung/universal_c210/lowlevel_init.S
> 
> NAK, sorry.  We have a two problems now:
> - On PowerPC we have  which takes  but
>   boards which do use soft_spi.c and now fail (taihu sacsng)
> - zipitz2 has the same problem (cc'ing Marek)

Now that's very weird. I *know* I had issues with zipitz2 among others
when I git am'd the commits while the git server was down; then when
I could fetch u-boot/samsung I re-tested u-boot-samsung/master in
itself then merged into u-boot-arm/master, and I *know* those ran
fine... And now they don't. Something's fishy in my git repo. :(

In any case: NAK fully understood and agreed upon, in my capacity as a
custodian, back-ported into ARM repo, i.e. I've rolled back ARM master
to where it was before the (ff) merge.

Also, actually CC:ing Marek, as well as Minkyu.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] please pull u-boot-samsung master

[Albert ARIBAUD]

Hi Albert,

On Thu, 11 Oct 2012 18:50:23 +0200, Albert ARIBAUD
 wrote:

> Hi Minkyu,
> 
> On Wed, 10 Oct 2012 21:16:16 +0900, Minkyu Kang 
> wrote:
> 
> > Dear Albert,
> > 
> > The following changes since commit 28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad:
> > 
> >   arm: armv7: temporarily set -mno-unaligned-access (2012-10-05 21:24:22 
> > +0200)
> > 
> > are available in the git repository at:
> > 
> >   git://git.denx.de/u-boot-samsung master
> > 
> > for you to fetch changes up to 9b5dba537473578153961ee96ed23e37e1fde3f7:
> > 
> >   exynos4: universal_C210: use software SPI (2012-10-10 20:37:39 +0900)
> > 
> > 
> > Chander Kashyap (1):
> >   Exynos5250: Enable PXE Support
> > 
> > Piotr Wilczek (9):
> >   arm:exynos4:trats: Correct SDRAM configuration for trats
> >   arm:exynos4:trats: Fix SDRAM size
> >   arm:exynos4:pinmux: Modify the gpio function for mmc
> >   arm:exynos4:trats: Use pinmux for mmc configuration
> >   arm:exynos4:universal: Use pinmux for mmc configuration
> >   arm:exynos4:universal: Eliminated low level init
> >   arm: trats: Power down core 1
> >   drivers: spi: modify soft spi driver
> >   exynos4: universal_C210: use software SPI
> > 
> > Łukasz Majewski (1):
> >   gpio:fix: Proper handling of GPIO subsystem parts at Samsung devices
> > 
> >  arch/arm/cpu/armv7/exynos/pinmux.c   |   58 
> >  arch/arm/include/asm/arch-exynos/gpio.h  |   19 ++
> >  arch/arm/include/asm/arch-exynos/periph.h|1 +
> >  arch/arm/include/asm/arch-s5pc1xx/gpio.h |7 +-
> >  board/samsung/trats/trats.c  |   80 ++
> >  board/samsung/universal_c210/Makefile|1 -
> >  board/samsung/universal_c210/lowlevel_init.S |  395 
> > --
> >  board/samsung/universal_c210/universal.c |  116 
> >  drivers/gpio/s5p_gpio.c  |6 +-
> >  drivers/spi/soft_spi.c   |3 +
> >  include/configs/s5pc210_universal.h  |   21 ++
> >  include/configs/smdk5250.h   |6 +
> >  include/configs/trats.h  |   17 +-
> >  13 files changed, 209 insertions(+), 521 deletions(-)
> >  delete mode 100644 board/samsung/universal_c210/lowlevel_init.S
> > 
> 
> Applied to u-boot-arm/master, thanks!

... then reverted; see NAK from Tom of u-boot-arm pull req.

> Amicalement,

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Stefan Roese]

On 10/11/2012 08:30 PM, Scott Wood wrote:
>> But, yes, it bears more thinking if we want the next branch open for
>> longer than it has historically been, if we want that.  And we have at
>> least historically been saying that next can and will be rebased.
> 
> IMHO it would be nice for the next branch to open immediately after the  
> merge window closes, and be kept up to date except during the merge  
> window.  Historically the next branch has opened when someone requests  
> a pull into it, but how do I make a sane pull request when the next  
> branch has been untouched since the last release?

This has been discussed on the U-Boot BoF in Geneva a few months ago.
And it was generally agreed upon that opening the next branch earlier
(best directly after the merge window) would be a big plus.

IIRC, then Tom did exactly this in this release cycle.

Thanks,
Stefan

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] EXYNOS: Add Exynos4 I2C spacing

[Minkyu Kang]

Dear Joonyoung,

On 12 October 2012 12:29, Joonyoung Shim  wrote:
> Hi,
>
> 2012/10/12 Minkyu Kang :
>> Dear Piotr and Joonyoung,
>>
>> On 11 October 2012 17:14, Piotr Wilczek  wrote:
>>> Hi Joonyoung,
>>>
 -Original Message-
 From: Joonyoung Shim [mailto:dofm...@gmail.com]
 Sent: Thursday, October 11, 2012 3:11 AM
 To: Piotr Wilczek
 Cc: u-boot@lists.denx.de; Kyungmin Park
 Subject: Re: [U-Boot] [PATCH 2/5] EXYNOS: Add Exynos4 I2C spacing

 Hi, Protr.

 2012/9/24 Piotr Wilczek :
 > This patch add the spacing for i2c for Exynos4
 >
 > Signed-off-by: Piotr Wilczek 
 > Signed-off-by: Kyungmin Park 
 > CC: Minkyu Kang 
 > ---
 >  arch/arm/include/asm/arch-exynos/cpu.h |2 ++
 >  1 files changed, 2 insertions(+), 0 deletions(-)
 >
 > diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
 > b/arch/arm/include/asm/arch-exynos/cpu.h
 > index 5056b37..b70273c 100644
 > --- a/arch/arm/include/asm/arch-exynos/cpu.h
 > +++ b/arch/arm/include/asm/arch-exynos/cpu.h
 > @@ -28,6 +28,8 @@
 >  #define EXYNOS4_ADDR_BASE  0x1000
 >
 >  /* EXYNOS4 */
 > +#define EXYNOS4_I2C_SPACING0x1
 > +

 Also EXYNOS5_I2C_SPACING is 0x1, so how about define just
 EXYNOS_I2C_SPACING for both EXYNOS4 and EXYNOS5?
>>> I agree it would simplify the code (s3c24x0_i2c driver). On the other hand,
>>> for code readability, maybe it is better to keep them separate as we do so
>>> with all defines for each Exynos.
>>>
>
> OK, but already s3c24x0_i2c driver has too many #ifdef statements, so i
> just concern it. We may need to use cpu_is_xxx to remove #ifdef.
>

Right.
We should do cleanup.
Actually, I don't want to use such a define and ifdefs.. like other devices.
I think, we can solve this problem by separate i2c driver from s3c24x0.
How you think?

-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/5] input: Use finer grain udelays while waitng for the i8042 keyboard buffer to empty

[Graeme Russ]

Hi Simon,

On Fri, Oct 12, 2012 at 12:15 PM, Simon Glass  wrote:

> diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
> index c3bc536..99254e4 100644
> --- a/drivers/input/i8042.c
> +++ b/drivers/input/i8042.c
> @@ -607,11 +607,10 @@ static void kbd_led_set(void)
>
>  static int kbd_input_empty(void)
>  {
> -   int kbdTimeout = KBD_TIMEOUT;
> +   int kbdTimeout = KBD_TIMEOUT * 1000;
>
> -   /* wait for input buf empty */
> while ((in8(I8042_STATUS_REG) & 0x02) && kbdTimeout--)

I know this magic number was already here, but later patches introduce
even more. Any chance these can be cleaned up as well?

Regards,

Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] EXYNOS: Add Exynos4 I2C spacing

[Joonyoung Shim]

Hi,

2012/10/12 Minkyu Kang :
> Dear Piotr and Joonyoung,
>
> On 11 October 2012 17:14, Piotr Wilczek  wrote:
>> Hi Joonyoung,
>>
>>> -Original Message-
>>> From: Joonyoung Shim [mailto:dofm...@gmail.com]
>>> Sent: Thursday, October 11, 2012 3:11 AM
>>> To: Piotr Wilczek
>>> Cc: u-boot@lists.denx.de; Kyungmin Park
>>> Subject: Re: [U-Boot] [PATCH 2/5] EXYNOS: Add Exynos4 I2C spacing
>>>
>>> Hi, Protr.
>>>
>>> 2012/9/24 Piotr Wilczek :
>>> > This patch add the spacing for i2c for Exynos4
>>> >
>>> > Signed-off-by: Piotr Wilczek 
>>> > Signed-off-by: Kyungmin Park 
>>> > CC: Minkyu Kang 
>>> > ---
>>> >  arch/arm/include/asm/arch-exynos/cpu.h |2 ++
>>> >  1 files changed, 2 insertions(+), 0 deletions(-)
>>> >
>>> > diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
>>> > b/arch/arm/include/asm/arch-exynos/cpu.h
>>> > index 5056b37..b70273c 100644
>>> > --- a/arch/arm/include/asm/arch-exynos/cpu.h
>>> > +++ b/arch/arm/include/asm/arch-exynos/cpu.h
>>> > @@ -28,6 +28,8 @@
>>> >  #define EXYNOS4_ADDR_BASE  0x1000
>>> >
>>> >  /* EXYNOS4 */
>>> > +#define EXYNOS4_I2C_SPACING0x1
>>> > +
>>>
>>> Also EXYNOS5_I2C_SPACING is 0x1, so how about define just
>>> EXYNOS_I2C_SPACING for both EXYNOS4 and EXYNOS5?
>> I agree it would simplify the code (s3c24x0_i2c driver). On the other hand,
>> for code readability, maybe it is better to keep them separate as we do so
>> with all defines for each Exynos.
>>

OK, but already s3c24x0_i2c driver has too many #ifdef statements, so i
just concern it. We may need to use cpu_is_xxx to remove #ifdef.

Thanks.

>
> I agreed with Piotr.
>
> Thanks
> Minkyu Kang.
> --
> from. prom.
> www.promsoft.net

-- 
- Joonyoung Shim
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] trats: Enable EXT4 and EFI partitions support on Samsung's Trats board

[Minkyu Kang]

Dear Lukasz,

On 4 October 2012 18:27, Lukasz Majewski  wrote:
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> ---
>  include/configs/trats.h |6 +-
>  1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/include/configs/trats.h b/include/configs/trats.h
> index b3b5a3d..aaf64eb 100644
> --- a/include/configs/trats.h
> +++ b/include/configs/trats.h
> @@ -104,6 +104,9 @@
>  #define CONFIG_CMD_FAT
>  #define CONFIG_FAT_WRITE

So, do we need to keep FAT related features?

>
> +/* EXT4 */
> +#define CONFIG_CMD_EXT4
> +
>  /* USB Composite download gadget - g_dnl */
>  #define CONFIG_USBDOWNLOAD_GADGET
>  #define CONFIG_DFU_FUNCTION
> @@ -167,7 +170,7 @@
> "meminfo=crashkernel=32M@0x5000\0" \
> "nfsroot=/nfsroot/arm\0" \
> "bootblock=" CONFIG_BOOTBLOCK "\0" \
> -   "loaduimage=fatload mmc ${mmcdev}:${mmcbootpart} 0x40007FC0 uImage\0" 
> \
> +   "loaduimage=ext4load mmc ${mmcdev}:${mmcbootpart} 0x40007FC0 
> uImage\0" \
> "mmcdev=0\0" \
> "mmcbootpart=2\0" \
> "mmcrootpart=3\0" \
> @@ -208,6 +211,7 @@
>  #define CONFIG_ENV_OFFSET  ((32 - 4) << 10) /* 32KiB - 4KiB */
>
>  #define CONFIG_DOS_PARTITION

also dos partition.

> +#define CONFIG_EFI_PARTITION
>

Thanks
Minkyu Kang.
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] EXYNOS: Add Exynos4 I2C spacing

[Minkyu Kang]

Dear Piotr and Joonyoung,

On 11 October 2012 17:14, Piotr Wilczek  wrote:
> Hi Joonyoung,
>
>> -Original Message-
>> From: Joonyoung Shim [mailto:dofm...@gmail.com]
>> Sent: Thursday, October 11, 2012 3:11 AM
>> To: Piotr Wilczek
>> Cc: u-boot@lists.denx.de; Kyungmin Park
>> Subject: Re: [U-Boot] [PATCH 2/5] EXYNOS: Add Exynos4 I2C spacing
>>
>> Hi, Protr.
>>
>> 2012/9/24 Piotr Wilczek :
>> > This patch add the spacing for i2c for Exynos4
>> >
>> > Signed-off-by: Piotr Wilczek 
>> > Signed-off-by: Kyungmin Park 
>> > CC: Minkyu Kang 
>> > ---
>> >  arch/arm/include/asm/arch-exynos/cpu.h |2 ++
>> >  1 files changed, 2 insertions(+), 0 deletions(-)
>> >
>> > diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
>> > b/arch/arm/include/asm/arch-exynos/cpu.h
>> > index 5056b37..b70273c 100644
>> > --- a/arch/arm/include/asm/arch-exynos/cpu.h
>> > +++ b/arch/arm/include/asm/arch-exynos/cpu.h
>> > @@ -28,6 +28,8 @@
>> >  #define EXYNOS4_ADDR_BASE  0x1000
>> >
>> >  /* EXYNOS4 */
>> > +#define EXYNOS4_I2C_SPACING0x1
>> > +
>>
>> Also EXYNOS5_I2C_SPACING is 0x1, so how about define just
>> EXYNOS_I2C_SPACING for both EXYNOS4 and EXYNOS5?
> I agree it would simplify the code (s3c24x0_i2c driver). On the other hand,
> for code readability, maybe it is better to keep them separate as we do so
> with all defines for each Exynos.
>

I agreed with Piotr.

Thanks
Minkyu Kang.
-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] m28: Properly configure the SPI flash chipselect

[Marek Vasut]

Dear Tom Rini,

> The SPI flash is not properly detected by plain "sf probe" due to
> it being located on different bus and different chipselect. Fix
> this problem.
> 
> Signed-off-by: Marek Vasut 
> Cc: Stefano Babic 
> Cc: Tom Rini 
[...]

Please apply for .10 release, this is an important bugfix. Tested by DUTS as of 
now.

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v5 1/2] qi_lb60: add nand spl support

[xiangfu]

From: Xiangfu 

  The JZ4740 CPU can load 8KB from two different addresses:
   1. the normal area up to 8KB starting from NAND flash address 0x
   2. the backup area up to 8KB starting from NAND flash address 0x2000

  After create u-boot-spl.bin. it needs those 4 commands create final image for 
jz4740 cpu.
  
dd if=spl/u-boot-spl.bin of=u-boot-nand.bin conv=sync bs=8192 count=1
dd if=spl/u-boot-spl.bin of=u-boot-nand.bin conv=sync,notrunc oflag=append 
bs=8192 count=1
tr '\0' '\377' < /dev/zero | dd of=u-boot-nand.bin conv=sync,notrunc 
oflag=append bs=16384 count=1
cat u-boot-nand.bin u-boot.bin > u-boot-nand-final.bin
  

Signed-off-by: Xiangfu 
---
 arch/mips/cpu/xburst/Makefile |7 +-
 arch/mips/cpu/xburst/cpu.c|4 +
 arch/mips/cpu/xburst/jz4740.c |   84 +++---
 arch/mips/cpu/xburst/spl/Makefile |   47 ++
 arch/mips/cpu/xburst/spl/start.S  |   63 +
 board/qi/qi_lb60/Makefile |5 ++
 board/qi/qi_lb60/qi_lb60-spl.c|   30 +++
 board/qi/qi_lb60/qi_lb60.c|8 +-
 board/qi/qi_lb60/u-boot-spl.lds   |   62 +
 drivers/mtd/nand/jz4740_nand.c|   39 -
 include/configs/qi_lb60.h |  175 ++---
 11 files changed, 377 insertions(+), 147 deletions(-)
 create mode 100644 arch/mips/cpu/xburst/spl/Makefile
 create mode 100644 arch/mips/cpu/xburst/spl/start.S
 create mode 100644 board/qi/qi_lb60/qi_lb60-spl.c
 create mode 100644 board/qi/qi_lb60/u-boot-spl.lds

diff --git a/arch/mips/cpu/xburst/Makefile b/arch/mips/cpu/xburst/Makefile
index b1f2ae4..ec35e55 100644
--- a/arch/mips/cpu/xburst/Makefile
+++ b/arch/mips/cpu/xburst/Makefile
@@ -24,9 +24,12 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(CPU).o
 
+COBJS-y= cpu.o jz_serial.o
+
+ifneq ($(CONFIG_SPL_BUILD),y)
 START  = start.o
-SOBJS-y=
-COBJS-y= cpu.o timer.o jz_serial.o
+COBJS-y += timer.o
+endif
 
 COBJS-$(CONFIG_JZ4740) += jz4740.o
 
diff --git a/arch/mips/cpu/xburst/cpu.c b/arch/mips/cpu/xburst/cpu.c
index ddcbfaa..1432838 100644
--- a/arch/mips/cpu/xburst/cpu.c
+++ b/arch/mips/cpu/xburst/cpu.c
@@ -42,6 +42,8 @@
:   \
: "i" (op), "R" (*(unsigned char *)(addr)))
 
+#ifndef CONFIG_SPL_BUILD
+
 void __attribute__((weak)) _machine_restart(void)
 {
struct jz4740_wdt *wdt = (struct jz4740_wdt *)JZ4740_WDT_BASE;
@@ -109,6 +111,8 @@ void invalidate_dcache_range(ulong start_addr, ulong stop)
cache_op(Hit_Invalidate_D, addr);
 }
 
+#endif
+
 void flush_icache_all(void)
 {
u32 addr, t = 0;
diff --git a/arch/mips/cpu/xburst/jz4740.c b/arch/mips/cpu/xburst/jz4740.c
index c0b9817..1e874ee 100644
--- a/arch/mips/cpu/xburst/jz4740.c
+++ b/arch/mips/cpu/xburst/jz4740.c
@@ -32,31 +32,19 @@ int disable_interrupts(void)
return 0;
 }
 
-/*
- * PLL output clock = EXTAL * NF / (NR * NO)
- * NF = FD + 2, NR = RD + 2
- * NO = 1 (if OD = 0), NO = 2 (if OD = 1 or 2), NO = 4 (if OD = 3)
- */
 void pll_init(void)
 {
struct jz4740_cpm *cpm = (struct jz4740_cpm *)JZ4740_CPM_BASE;
 
-   register unsigned int cfcr, plcr1;
-   int n2FR[33] = {
-   0, 0, 1, 2, 3, 0, 4, 0, 5, 0, 0, 0, 6, 0, 0, 0,
-   7, 0, 0, 0, 0, 0, 0, 0, 8, 0, 0, 0, 0, 0, 0, 0,
-   9
-   };
-   int div[5] = {1, 3, 3, 3, 3}; /* divisors of I:S:P:L:M */
-   int nf, pllout2;
+   register unsigned int cfcr, plcr;
+   unsigned int nf, pllout2;
 
cfcr =  CPM_CPCCR_CLKOEN |
-   CPM_CPCCR_PCS |
-   (n2FR[div[0]] << CPM_CPCCR_CDIV_BIT) |
-   (n2FR[div[1]] << CPM_CPCCR_HDIV_BIT) |
-   (n2FR[div[2]] << CPM_CPCCR_PDIV_BIT) |
-   (n2FR[div[3]] << CPM_CPCCR_MDIV_BIT) |
-   (n2FR[div[4]] << CPM_CPCCR_LDIV_BIT);
+   (0 << CPM_CPCCR_CDIV_BIT) |
+   (2 << CPM_CPCCR_HDIV_BIT) |
+   (2 << CPM_CPCCR_PDIV_BIT) |
+   (2 << CPM_CPCCR_MDIV_BIT) |
+   (2 << CPM_CPCCR_LDIV_BIT);
 
pllout2 = (cfcr & CPM_CPCCR_PCS) ?
CONFIG_SYS_CPU_SPEED : (CONFIG_SYS_CPU_SPEED / 2);
@@ -65,15 +53,18 @@ void pll_init(void)
writel(pllout2 / 4800 - 1, &cpm->uhccdr);
 
nf = CONFIG_SYS_CPU_SPEED * 2 / CONFIG_SYS_EXTAL;
-   plcr1 = ((nf - 2) << CPM_CPPCR_PLLM_BIT) | /* FD */
+   plcr = ((nf - 2) << CPM_CPPCR_PLLM_BIT) | /* FD */
(0 << CPM_CPPCR_PLLN_BIT) | /* RD=0, NR=2 */
(0 << CPM_CPPCR_PLLOD_BIT) |/* OD=0, NO=1 */
-   (0x20 << CPM_CPPCR_PLLST_BIT) | /* PLL stable time */
+   (0x32 << CPM_CPPCR_PLLST_BIT) | /* PLL stable time */
CPM_CPPCR_PLLEN;/* enable PLL */
 
/* init PLL */
writel(cfcr, &cpm->cpccr);
-   writel(plcr1, &cpm->cppcr);
+   writel(plcr, &cpm->cppcr);
+
+   while (!(readl(&cpm->c

[U-Boot] [PATCH v5 2/2] qi_lb60: add software usbboot support

[xiangfu]

From: Xiangfu 

  JZ4740 CPU have a internal ROM have such kind of code, that make
  JZ4740 can boot from USB

  usbboot.S can downloads user program from the USB port to internal
  SRAM and branches to the internal SRAM to execute the program

Signed-off-by: Xiangfu 
---
 board/qi/qi_lb60/qi_lb60-spl.c |   20 +
 board/qi/qi_lb60/usbboot.S |  838 
 2 files changed, 858 insertions(+)
 create mode 100644 board/qi/qi_lb60/usbboot.S

diff --git a/board/qi/qi_lb60/qi_lb60-spl.c b/board/qi/qi_lb60/qi_lb60-spl.c
index 3fe3fa3..aea459c 100644
--- a/board/qi/qi_lb60/qi_lb60-spl.c
+++ b/board/qi/qi_lb60/qi_lb60-spl.c
@@ -12,6 +12,24 @@
 #include 
 #include 
 
+#define KEY_U_OUT   (32 * 2 + 16)
+#define KEY_U_IN(32 * 3 + 19)
+
+extern void usb_boot(void);
+
+static void check_usb_boot(void)
+{
+   __gpio_as_input(KEY_U_IN);
+   __gpio_enable_pull(KEY_U_IN);
+   __gpio_as_output(KEY_U_OUT);
+   __gpio_clear_pin(KEY_U_OUT);
+
+   if (!__gpio_get_pin(KEY_U_IN)) {
+   puts("[U] pressed, goto USBBOOT mode\n");
+   usb_boot();
+   }
+}
+
 void nand_spl_boot(void)
 {
__gpio_as_sdram_16bit_4720();
@@ -23,6 +41,8 @@ void nand_spl_boot(void)
pll_init();
sdram_init();
 
+   check_usb_boot();
+
nand_init();
 
puts("\nQi LB60 SPL: Starting U-Boot ...\n");
diff --git a/board/qi/qi_lb60/usbboot.S b/board/qi/qi_lb60/usbboot.S
new file mode 100644
index 000..c872266
--- /dev/null
+++ b/board/qi/qi_lb60/usbboot.S
@@ -0,0 +1,838 @@
+/*
+ *  for jz4740 usb boot
+ *
+ *  Copyright (c) 2009 Author: 
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+.set noreorder
+.globl usb_boot
+.text
+
+/*
+ * Both NAND and USB boot load data to D-Cache first, then transfer
+ * data from D-Cache to I-Cache, and jump to execute the code in I-Cache.
+ * So init caches first and then dispatch to a proper boot routine.
+ */
+
+.macro load_addr reg addr
+   li \reg, 0x8000
+   addiu \reg, \reg, \addr
+   la $2, usbboot_begin
+   subu \reg, \reg, $2
+.endm
+
+usb_boot:
+   /* Initialize PLL: set ICLK to 84MHz and HCLK to 42MHz. */
+   la  $9, 0xB000  /* CPCCR: Clock Control Register */
+   la  $8, 0x42041110  /* I:S:M:P=1:2:2:2 */
+   sw  $8, 0($9)
+
+   la  $9, 0xB010  /* CPPCR: PLL Control Register */
+   la  $8, 0x06000120  /* M=12 N=0 D=0 CLK=12*(M+2)/(N+2) */
+   sw  $8, 0($9)
+
+   mtc0$0, $26 /* CP0_ERRCTL, restore WST reset state */
+   nop
+
+   mtc0$0, $16 /* CP0_CONFIG */
+   nop
+
+   /* Relocate code to beginning of the ram */
+
+   la $2, usbboot_begin
+   la $3, usbboot_end
+   li $4, 0x8000
+
+1:
+   lw $5, 0($2)
+   sw $5, 0($4)
+   addiu $2, $2, 4
+   bne $2, $3, 1b
+   addiu $4, $4, 4
+
+   li $2, 0x8000
+   ori $3, $2, 0
+   addiu $3, $3, usbboot_end
+   la $4, usbboot_begin
+   subu $3, $3, $4
+
+
+2:
+   cache   0x0, 0($2)  /* Index_Invalidate_I */
+   cache   0x1, 0($2)  /* Index_Writeback_Inv_D */
+   addiu   $2, $2, 32
+   subu $4, $3, $2
+   bgtz$4, 2b
+   nop
+
+   load_addr $3, usb_boot_return
+
+   jr $3
+
+usbboot_begin:
+
+init_caches:
+   li  $2, 3   /* cacheable for kseg0 access */
+   mtc0$2, $16 /* CP0_CONFIG */
+   nop
+
+   li  $2, 0x2000  /* enable idx-store-data cache insn */
+   mtc0$2, $26 /* CP0_ERRCTL */
+
+   ori $2, $28, 0  /* start address */
+   ori $3, $2, 0x3fe0  /* end address, total 16KB */
+   mtc0$0, $28, 0  /* CP0_TAGLO */
+   mtc0$0, $28, 1  /* CP0_DATALO */
+cache_clear_a_line:
+   cache   0x8, 0($2)  /* Index_Store_Tag_I */
+   cache   0x9, 0($2)  /* Index_Store_Tag_D */
+   bne $2, $3, cache_clear_a_line
+   addiu   $2, $2, 32  /* increment CACHE_LINE_SIZE */
+
+   ori $2, $28

[U-Boot] [PATCH v5 0/2] qi_lb60(Ben NanoNote): add nand spl and usbboot support

[xiangfu]

From: Xiangfu 

Big thanks to Tom Rini and Daniel Schwierzeck for feedback.

V5:
  * use puts instread of serial_puts (enable CONFIG_SPL_LIBCOMMON_SUPPORT)
  * update my email address
  * fix compiles warnings

V4:
  * split to 2 patches (nand spl/usbbot)
  * remove use define string.c using CONFIG_SPL_LIBGENERIC_SUPPORT
  * fix checkputch.pl warnings

V3:
  * add simpile string.c to mips/lib
  * some cleanup on jz4740.c
  * move to new spl/ structure 
  * support software usbboot mode

Xiangfu (2):
  qi_lb60: add nand spl support
  qi_lb60: add software usbboot support

 arch/mips/cpu/xburst/Makefile |7 +-
 arch/mips/cpu/xburst/cpu.c|4 +
 arch/mips/cpu/xburst/jz4740.c |   84 ++--
 arch/mips/cpu/xburst/spl/Makefile |   47 +++
 arch/mips/cpu/xburst/spl/start.S  |   63 +++
 board/qi/qi_lb60/Makefile |5 +
 board/qi/qi_lb60/qi_lb60-spl.c|   50 +++
 board/qi/qi_lb60/qi_lb60.c|8 +-
 board/qi/qi_lb60/u-boot-spl.lds   |   62 +++
 board/qi/qi_lb60/usbboot.S|  838 +
 drivers/mtd/nand/jz4740_nand.c|   39 +-
 include/configs/qi_lb60.h |  175 
 12 files changed, 1235 insertions(+), 147 deletions(-)
 create mode 100644 arch/mips/cpu/xburst/spl/Makefile
 create mode 100644 arch/mips/cpu/xburst/spl/start.S
 create mode 100644 board/qi/qi_lb60/qi_lb60-spl.c
 create mode 100644 board/qi/qi_lb60/u-boot-spl.lds
 create mode 100644 board/qi/qi_lb60/usbboot.S

-- 
1.7.9.5

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] m28: Properly configure the SPI flash chipselect

[Marek Vasut]

The SPI flash is not properly detected by plain "sf probe" due to
it being located on different bus and different chipselect. Fix
this problem.

Signed-off-by: Marek Vasut 
Cc: Stefano Babic 
Cc: Tom Rini 
---
 include/configs/m28evk.h |8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/include/configs/m28evk.h b/include/configs/m28evk.h
index 9eb2a54..bdbb820 100644
--- a/include/configs/m28evk.h
+++ b/include/configs/m28evk.h
@@ -246,18 +246,20 @@
 #defineCONFIG_MXS_SPI_DMA_ENABLE
 #defineCONFIG_SPI_HALF_DUPLEX
 #defineCONFIG_DEFAULT_SPI_BUS  2
+#defineCONFIG_DEFAULT_SPI_CS   0
 #defineCONFIG_DEFAULT_SPI_MODE SPI_MODE_0
 
 /* SPI FLASH */
 #ifdef CONFIG_CMD_SF
 #defineCONFIG_SPI_FLASH
 #defineCONFIG_SPI_FLASH_STMICRO
-#defineCONFIG_SF_DEFAULT_CS2
-#defineCONFIG_SF_DEFAULT_MODE  SPI_MODE_0
+#defineCONFIG_SF_DEFAULT_BUS   2
+#defineCONFIG_SF_DEFAULT_CS0
 #defineCONFIG_SF_DEFAULT_SPEED 4000
+#defineCONFIG_SF_DEFAULT_MODE  SPI_MODE_0
 
-#defineCONFIG_ENV_SPI_CS   0
 #defineCONFIG_ENV_SPI_BUS  2
+#defineCONFIG_ENV_SPI_CS   0
 #defineCONFIG_ENV_SPI_MAX_HZ   4000
 #defineCONFIG_ENV_SPI_MODE SPI_MODE_0
 #endif
-- 
1.7.10.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 5/5] input: Add ANSI 3.64 escape sequence generation.

[Simon Glass]

From: Hung-Te Lin 

To support Non-ASCII keys (ex, Fn, PgUp/Dn, arrow keys, ...), we need to
translate key code into escape sequence.

(Updated by s...@chromium.org to move away from a function to store
keycodes, so we can easily record how many were sent. We now need to
return this from input_send_keycodes() so we know whether keys were
generated.)

Signed-off-by: Hung-Te Lin 
Signed-off-by: Simon Glass 
---
 drivers/input/input.c |  102 +---
 include/input.h   |2 +
 2 files changed, 89 insertions(+), 15 deletions(-)

diff --git a/drivers/input/input.c b/drivers/input/input.c
index 5b2b4b0..9800667 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -93,6 +93,22 @@ static unsigned char kbd_ctrl_xlate[] = {
'\r', 0xff, 0xff
 };
 
+/*
+ * Scan key code to ANSI 3.64 escape sequence table.  This table is
+ * incomplete in that it does not include all possible extra keys.
+ */
+static struct {
+   int kbd_scan_code;
+   char *escape;
+} kbd_to_ansi364[] = {
+   { KEY_UP, "\033[A"},
+   { KEY_DOWN, "\033[B"},
+   { KEY_RIGHT, "\033[C"},
+   { KEY_LEFT, "\033[D"},
+};
+
+/* Maximum number of output characters that an ANSI sequence expands to */
+#define ANSI_CHAR_MAX  3
 
 int input_queue_ascii(struct input_config *config, int ch)
 {
@@ -289,24 +305,67 @@ static int input_check_keycodes(struct input_config 
*config,
 }
 
 /**
+ * Checks and converts a special key code into ANSI 3.64 escape sequence.
+ *
+ * @param config   Input state
+ * @param keycode  Key code to examine
+ * @param output_chBuffer to place output characters into. It should
+ * be at least ANSI_CHAR_MAX bytes long, to allow for
+ * an ANSI sequence.
+ * @param max_charsMaximum number of characters to add to output_ch
+ * @return number of characters output, if the key was converted, otherwise 0.
+ * This may be larger than max_chars, in which case the overflow
+ * characters are not output.
+ */
+static int input_keycode_to_ansi364(struct input_config *config,
+   int keycode, char output_ch[], int max_chars)
+{
+   const char *escape;
+   int ch_count;
+   int i;
+
+   for (i = ch_count = 0; i < ARRAY_SIZE(kbd_to_ansi364); i++) {
+   if (keycode != kbd_to_ansi364[i].kbd_scan_code)
+   continue;
+   for (escape = kbd_to_ansi364[i].escape; *escape; escape++) {
+   if (ch_count < max_chars)
+   output_ch[ch_count] = *escape;
+   ch_count++;
+   }
+   return ch_count;
+   }
+
+   return 0;
+}
+
+/**
+ * Converts and queues a list of key codes in escaped ASCII string form
  * Convert a list of key codes into ASCII
  *
  * You must call input_check_keycodes() before this. It turns the keycode
- * list into a list of ASCII characters which are ready to send to the
- * input layer.
+ * list into a list of ASCII characters and sends them to the input layer.
  *
  * Characters which were seen last time do not generate fresh ASCII output.
+ * The output (calls to queue_ascii) may be longer than num_keycodes, if the
+ * keycode contains special keys that was encoded to longer escaped sequence.
  *
  * @param config   Input state
  * @param keycode  List of key codes to examine
  * @param num_keycodes Number of key codes
+ * @param output_chBuffer to place output characters into. It should
+ * be at last ANSI_CHAR_MAX * num_keycodes, to allow for
+ * ANSI sequences.
+ * @param max_charsMaximum number of characters to add to output_ch
  * @param same Number of key codes which are the same
+ * @return number of characters written into output_ch, or -1 if we would
+ * exceed max_chars chars.
  */
 static int input_keycodes_to_ascii(struct input_config *config,
-   int keycode[], int num_keycodes, char output_ch[], int same)
+   int keycode[], int num_keycodes, char output_ch[],
+   int max_chars, int same)
 {
struct input_key_xlate *table;
-   int ch_count;
+   int ch_count = 0;
int i;
 
table = &config->table[0];
@@ -321,19 +380,31 @@ static int input_keycodes_to_ascii(struct input_config 
*config,
}
}
 
-   /* now find normal keys */
-   for (i = ch_count = 0; i < num_keycodes; i++) {
+   /* Start conversion by looking for the first new keycode (by same). */
+   for (i = same; i < num_keycodes; i++) {
int key = keycode[i];
+   int ch = (key < table->num_entries) ? table->xlate[key] : 0xff;
 
-   if (key < table->num_entries && i >= same) {
-   int ch = table->xlate[key];
-
-   /* If a normal key with an ASCII value, add it! */
-   if (ch != 0xff)
-  

[U-Boot] [PATCH 4/5] input: Fix i8042 keyboard reset

[Simon Glass]

From: Marc Jones 

The i8042 keyboard reset was not checking the results of the output
buffer after the reset command. This can jam up some KBC/keyboards.
Also, remove a write to the wrong register and the CONFIG setting
around the incorrect write.

Signed-off-by: Marc Jones 
Signed-off-by: Simon Glass 
---
 drivers/input/i8042.c |   32 +++-
 1 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index 6b51eb5..65611ec 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -666,31 +666,53 @@ static int kbd_input_empty(void)
 
 
/**/
 
+static int wait_until_kbd_output_full(void)
+{
+   int kbdTimeout = KBD_TIMEOUT * 1000;
+
+   while (((in8(I8042_STATUS_REG) & 0x01) == 0) && kbdTimeout--)
+   udelay(1);
+
+   return kbdTimeout != -1;
+}
+
+/**/
+
 static int kbd_reset(void)
 {
+   /* KB Reset */
if (kbd_input_empty() == 0)
return -1;
 
out8(I8042_DATA_REG, 0xff);
 
+   if (wait_until_kbd_output_full() == 0)
+   return -1;
+
+   if (in8(I8042_DATA_REG) != 0xfa) /* ACK */
+   return -1;
+
+   if (wait_until_kbd_output_full() == 0)
+   return -1;
+
+   if (in8(I8042_DATA_REG) != 0xaa) /* Test Pass*/
+   return -1;
+
if (kbd_input_empty() == 0)
return -1;
 
-#ifdef CONFIG_USE_CPCIDVI
+   /* Set KBC mode */
out8(I8042_COMMAND_REG, 0x60);
-#else
-   out8(I8042_DATA_REG, 0x60);
-#endif
 
if (kbd_input_empty() == 0)
return -1;
 
out8(I8042_DATA_REG, 0x45);
 
-
if (kbd_input_empty() == 0)
return -1;
 
+   /* Enable Keyboard */
out8(I8042_COMMAND_REG, 0xae);
 
if (kbd_input_empty() == 0)
-- 
1.7.7.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/5] input: Provide a board specific mechanism to decide whether to skip i8042 init

[Simon Glass]

From: Gabe Black 

This change adds a board overridable function which can be used to decide
whether or not to initialize the i8042 keyboard controller. On systems where
it isn't actually connected to anything, this can save a significant amount of
boot time.

On Stumpy, this saves about 200ms on boot.

Signed-off-by: Gabe Black 
Signed-off-by: Simon Glass 
---
 drivers/input/i8042.c |   13 -
 1 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index 99254e4..cae2d0a 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -320,6 +320,17 @@ static int kbd_controller_present(void)
return in8(I8042_STATUS_REG) != 0xff;
 }
 
+/*
+ * Implement a weak default function for boards that optionally
+ * need to skip the i8042 initialization.
+ */
+int __board_i8042_skip(void)
+{
+   /* As default, don't skip */
+   return 0;
+}
+int board_i8042_skip(void) __attribute__((weak, alias("__board_i8042_skip")));
+
 
/***
  *
  * i8042_kbd_init - reset keyboard and init state flags
@@ -329,7 +340,7 @@ int i8042_kbd_init(void)
int keymap, try;
char *penv;
 
-   if (!kbd_controller_present())
+   if (!kbd_controller_present() || board_i8042_skip())
return -1;
 
 #ifdef CONFIG_USE_CPCIDVI
-- 
1.7.7.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/5] input: i8042: Provide feature to disable keyboard before booting kernel

[Simon Glass]

From: Louis Yung-Chieh Lo 

The BIOS leaves the keyboard enabled during boot time so that any
keystroke would interfere kernel driver initialization.

Add a way to disable the keyboard to make sure no scancode will be
generated during the boot time. Note that the keyboard will be
re-enabled again after the kernel driver is up.

This code can be called from the board functions.
Signed-off-by: Louis Yung-Chieh Lo 

Signed-off-by: Louis Yung-Chieh Lo 
Signed-off-by: Simon Glass 
---
 drivers/input/i8042.c |   38 ++
 include/i8042.h   |   13 +
 2 files changed, 51 insertions(+), 0 deletions(-)

diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index cae2d0a..6b51eb5 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -331,6 +331,44 @@ int __board_i8042_skip(void)
 }
 int board_i8042_skip(void) __attribute__((weak, alias("__board_i8042_skip")));
 
+void i8042_flush(void)
+{
+   int timeout;
+
+   /*
+* The delay is to give the keyboard controller some time to fill the
+* next byte.
+*/
+   while (1) {
+   timeout = 100;  /* wait for no longer than 100us */
+   while (timeout > 0 && !(in8(I8042_STATUS_REG) & 0x01)) {
+   udelay(1);
+   timeout--;
+   }
+
+   /* Try to pull next byte if not timeout. */
+   if (in8(I8042_STATUS_REG) & 0x01)
+   in8(I8042_DATA_REG);
+   else
+   break;
+   }
+}
+
+int i8042_disable(void)
+{
+   if (kbd_input_empty() == 0)
+   return -1;
+
+   /* Disable keyboard */
+   out8(I8042_COMMAND_REG, 0xad);
+
+   if (kbd_input_empty() == 0)
+   return -1;
+
+   return 0;
+}
+
+
 
/***
  *
  * i8042_kbd_init - reset keyboard and init state flags
diff --git a/include/i8042.h b/include/i8042.h
index 1395289..c3e4e02 100644
--- a/include/i8042.h
+++ b/include/i8042.h
@@ -69,6 +69,19 @@
 
 /* exports */
 
+/**
+ * Flush all buffer from keyboard controller to host.
+ */
+void i8042_flush(void);
+
+/**
+ * Disables the keyboard so that key strokes no longer generate scancodes to
+ * the host.
+ *
+ * @return 0 if ok, -1 if keyboard input was found while disabling
+ */
+int i8042_disable(void);
+
 int i8042_kbd_init(void);
 int i8042_tstc(void);
 int i8042_getc(void);
-- 
1.7.7.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/5] input: Use finer grain udelays while waitng for the i8042 keyboard buffer to empty

[Simon Glass]

From: Gabe Black 

On x86, the i8042 keyboard controller driver frequently waits for the keyboard
input buffer to be empty to make sure the controller has had a chance to
process the data it was given. The way the delay loop was structured, if the
controller hadn't cleared the corresponding status bit immediately, it would
wait 1ms before checking again. If the keyboard responded quickly but not
instantly, the driver would still wait a full 1ms when perhaps 1us would have
been sufficient. Because udelay is a busy wait anyway, this change decreases
the delay between checks to 1us.

Also, this change gets rid of a hardcoded 250ms delay.

On Stumpy, this saves 100-150ms during boot.

Signed-off-by: Gabe Black 
Signed-off-by: Simon Glass 
---
 drivers/input/i8042.c |7 ++-
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/drivers/input/i8042.c b/drivers/input/i8042.c
index c3bc536..99254e4 100644
--- a/drivers/input/i8042.c
+++ b/drivers/input/i8042.c
@@ -607,11 +607,10 @@ static void kbd_led_set(void)
 
 static int kbd_input_empty(void)
 {
-   int kbdTimeout = KBD_TIMEOUT;
+   int kbdTimeout = KBD_TIMEOUT * 1000;
 
-   /* wait for input buf empty */
while ((in8(I8042_STATUS_REG) & 0x02) && kbdTimeout--)
-   udelay(1000);
+   udelay(1);
 
return kbdTimeout != -1;
 }
@@ -625,8 +624,6 @@ static int kbd_reset(void)
 
out8(I8042_DATA_REG, 0xff);
 
-   udelay(25);
-
if (kbd_input_empty() == 0)
return -1;
 
-- 
1.7.7.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/10] x86: Change board baud_rate to ulong

[Simon Glass]

Hi Graham,

On Thu, Oct 11, 2012 at 6:00 PM, Graeme Russ  wrote:
> Hi Simon,
>
> On Fri, Oct 12, 2012 at 11:55 AM, Simon Glass  wrote:
>> Hi,
>>
>> On Thu, Oct 11, 2012 at 5:51 PM, Graeme Russ  wrote:
>>> Hi Simon,
>>>
>>> On Fri, Oct 12, 2012 at 11:46 AM, Simon Glass  wrote:
 Hi Wolfgang,

 On Thu, Oct 11, 2012 at 12:32 AM, Wolfgang Denk  wrote:
> Dear Simon Glass,
>
> In message <1349910781-32088-2-git-send-email-...@chromium.org> you wrote:
>> This is a ulong for some architectures and just unsigned for others.
>> Change x86 to be consistent.
>
> Given the limited range for this variable it makes no sense to use a
> long for this.  Please fix this the other way round, i. e. change the
> architectures that use a long.

 OK I will send out a series that changes them to unsigned long.
>>>
>>> Should we just change them all to u32 to be clear on the value range?
>>
>> Sorry, I meant unsigned int.
>>
>> Are there architectures in U-Boot which use a 16-bit int?
>
> The C standard does not guarantee unsigned int will be at least
> 32-bits. It is possible (although I have not checked it) that
> compiling 'real-mode' x86 code can produce 16-bit ints (not that we do
> that in U-Boot)
>
> using u32 will always guarantee a 32-bit unsigned value - better to be
> safe than sorry
>

That's fine, but what about all the other fields? Does the same apply
here? It seems that everything uses 'unsigned int' for u32:

arch/nds32/include/asm/types.h:47:typedef unsigned int u32;
arch/avr32/include/asm/types.h:65:typedef unsigned int u32;
arch/arm/include/asm/types.h:37:typedef unsigned int u32;
arch/sandbox/include/asm/types.h:59:typedef unsigned int u32;
arch/blackfin/include/asm/types.h:70:typedef unsigned int u32;
arch/openrisc/include/asm/types.h:64:typedef unsigned int u32;
arch/mips/include/asm/types.h:62:typedef unsigned int u32;
arch/x86/include/asm/types.h:37:typedef unsigned int u32;
arch/nios2/include/asm/types.h:45:typedef unsigned int u32;
arch/sh/include/asm/types.h:46:typedef unsigned int u32;
arch/microblaze/include/asm/types.h:45:typedef unsigned int u32;
arch/powerpc/include/asm/types.h:37:typedef unsigned int u32;
arch/m68k/include/asm/types.h:37:typedef unsigned int u32;
arch/sparc/include/asm/types.h:58:typedef unsigned int u32;


I wonder then if we need to decide which to use (int or long). I
presume 'long' was used to cope with 16-bit machines, but we don't
actually have any (which is presumably Wolfgang's point). If we don't
have any, then 'int' is safe. I'm just a bit unsure about changing a
single field in these two structures to u32, when all the others are
unsigned long/short.

For example:

typedef struct bd_info {
int bi_baudrate;/* serial console baudrate */
ulong   bi_arch_number; /* unique id for this board */
ulong   bi_boot_params; /* where this board expects params */
unsigned long   bi_arm_freq; /* arm frequency */
unsigned long   bi_dsp_freq; /* dsp core frequency */
unsigned long   bi_ddr_freq; /* ddr frequency */
struct  /* RAM configuration */
{
ulong start;
ulong size;
}   bi_dram[CONFIG_NR_DRAM_BANKS];
} bd_t;


typedef struct  global_data {
bd_t*bd;
unsigned long   flags;
unsigned long   baudrate;
unsigned long   have_console;   /* serial_init() was called */
#ifdef CONFIG_PRE_CONSOLE_BUFFER
unsigned long   precon_buf_idx; /* Pre-Console buffer index */
#endif
unsigned long   env_addr;   /* Address  of Environment struct */
unsigned long   env_valid;  /* Checksum of Environment valid? */
unsigned long   fb_base;/* base address of frame buffer */
#ifdef CONFIG_FSL_ESDHC
unsigned long   sdhc_clk;
#endif
#ifdef CONFIG_AT91FAMILY
/* "static data" needed by at91's clock.c */
unsigned long   cpu_clk_rate_hz;
unsigned long   main_clk_rate_hz;
unsigned long   mck_rate_hz;
unsigned long   plla_rate_hz;
unsigned long   pllb_rate_hz;
unsigned long   at91_pllb_usb_init;
#endif
#ifdef CONFIG_ARM
/* "static data" needed by most of timer.c on ARM platforms */
unsigned long   timer_rate_hz;
unsigned long   tbl;
unsigned long   tbu;
unsigned long long  timer_reset_value;
unsigned long   lastinc;


Guidance appreciated!



> Regards,
>
> Graeme

Regards,
Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/10] x86: Change board baud_rate to ulong

[Graeme Russ]

Hi Simon,

On Fri, Oct 12, 2012 at 11:55 AM, Simon Glass  wrote:
> Hi,
>
> On Thu, Oct 11, 2012 at 5:51 PM, Graeme Russ  wrote:
>> Hi Simon,
>>
>> On Fri, Oct 12, 2012 at 11:46 AM, Simon Glass  wrote:
>>> Hi Wolfgang,
>>>
>>> On Thu, Oct 11, 2012 at 12:32 AM, Wolfgang Denk  wrote:
 Dear Simon Glass,

 In message <1349910781-32088-2-git-send-email-...@chromium.org> you wrote:
> This is a ulong for some architectures and just unsigned for others.
> Change x86 to be consistent.

 Given the limited range for this variable it makes no sense to use a
 long for this.  Please fix this the other way round, i. e. change the
 architectures that use a long.
>>>
>>> OK I will send out a series that changes them to unsigned long.
>>
>> Should we just change them all to u32 to be clear on the value range?
>
> Sorry, I meant unsigned int.
>
> Are there architectures in U-Boot which use a 16-bit int?

The C standard does not guarantee unsigned int will be at least
32-bits. It is possible (although I have not checked it) that
compiling 'real-mode' x86 code can produce 16-bit ints (not that we do
that in U-Boot)

using u32 will always guarantee a 32-bit unsigned value - better to be
safe than sorry

Regards,

Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/10] x86: Change board baud_rate to ulong

[Simon Glass]

Hi,

On Thu, Oct 11, 2012 at 5:51 PM, Graeme Russ  wrote:
> Hi Simon,
>
> On Fri, Oct 12, 2012 at 11:46 AM, Simon Glass  wrote:
>> Hi Wolfgang,
>>
>> On Thu, Oct 11, 2012 at 12:32 AM, Wolfgang Denk  wrote:
>>> Dear Simon Glass,
>>>
>>> In message <1349910781-32088-2-git-send-email-...@chromium.org> you wrote:
 This is a ulong for some architectures and just unsigned for others.
 Change x86 to be consistent.
>>>
>>> Given the limited range for this variable it makes no sense to use a
>>> long for this.  Please fix this the other way round, i. e. change the
>>> architectures that use a long.
>>
>> OK I will send out a series that changes them to unsigned long.
>
> Should we just change them all to u32 to be clear on the value range?

Sorry, I meant unsigned int.

Are there architectures in U-Boot which use a 16-bit int?

Regards,
Simon

>
> Regards,
>
> Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/10] x86: Change board baud_rate to ulong

[Graeme Russ]

Hi Simon,

On Fri, Oct 12, 2012 at 11:46 AM, Simon Glass  wrote:
> Hi Wolfgang,
>
> On Thu, Oct 11, 2012 at 12:32 AM, Wolfgang Denk  wrote:
>> Dear Simon Glass,
>>
>> In message <1349910781-32088-2-git-send-email-...@chromium.org> you wrote:
>>> This is a ulong for some architectures and just unsigned for others.
>>> Change x86 to be consistent.
>>
>> Given the limited range for this variable it makes no sense to use a
>> long for this.  Please fix this the other way round, i. e. change the
>> architectures that use a long.
>
> OK I will send out a series that changes them to unsigned long.

Should we just change them all to u32 to be clear on the value range?

Regards,

Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/10] x86: Change board baud_rate to ulong

[Simon Glass]

Hi Wolfgang,

On Thu, Oct 11, 2012 at 12:32 AM, Wolfgang Denk  wrote:
> Dear Simon Glass,
>
> In message <1349910781-32088-2-git-send-email-...@chromium.org> you wrote:
>> This is a ulong for some architectures and just unsigned for others.
>> Change x86 to be consistent.
>
> Given the limited range for this variable it makes no sense to use a
> long for this.  Please fix this the other way round, i. e. change the
> architectures that use a long.

OK I will send out a series that changes them to unsigned long.

This sort of thing relates to the unified board init series I was
working on earlier it the year, since then all archs can use the same
structures for generic fields like baud rate. I hope to get back to
that one day.

Regards,
Simon

>
> Thanks.
>
> Best regards,
>
> Wolfgang Denk
>
> --
> DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
> Always try to do things in chronological order; it's  less  confusing
> that way.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush

[Scott Wood]

On 10/11/2012 06:37:40 PM, Albert ARIBAUD wrote:

Hi Scott,

On Thu, 11 Oct 2012 15:21:28 -0500, Scott Wood
 wrote:

> > http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm
> >
> > "If your assembler instructions access memory in an unpredictable
> > fashion, add `memory' to the list of clobbered registers. This  
will

> > cause GCC to not keep memory values cached in registers across the
> > assembler instruction and not optimize stores or loads to that  
memory.
> > You will also want to add the volatile keyword if the memory  
affected

> > is not listed in the inputs or outputs of the asm, as the `memory'
> > clobber does not count as a side-effect of the asm".
>
> "and not optimize stores or loads to that memory".  It's not clear  
what
> "that" refers to, since the memory clobber does not refer to  
specific
> memory, but given that the purpose is "if your assembler  
instructions
> access memory in an unpredictable fashion", I don't see how it  
could be
> interpreted as anything other than "any memory which could possibly  
be

> modified by the program".  So it excludes constant data, but that's
> about it.

It does not necessarily include "all memory". Besides, "that"  -- to  
me
-- cleary means "the memory mentioned in the statement, for instance  
in

the inputs or outputs.


The whole point of the memory clobber is for when you can't easily  
express the memory in terms of input/output constraints.



> The only reference to volatile is to tell you to add it to the asm
> statement (not to other memory accesses) so that the asm statement  
does

> not get removed altogether.

The memory clobber definition says no memory values are kept cached
in registers across the instruction, that implies that if a volatile
access was prepared (a memory value was cached in a register) it is
finished before the asm statement executes, and similarly, since the
desciption says "across" the instruction, volatiles reads or writes
located after the instruction won't have been started before ithe
instruction executest, or they would have needed to cache the value,
which is contrary to the memory clobber definition.

This is not to say that only volatiles are affected by the barrier;  
but

volatiles certainly are.


Sure, but that first paragraph without the second is misleading as it  
implies that it is only volatiles that are affected.  Maybe not in  
terms of logical inference, but in terms of natural language and the  
meaning people are likely to take from it.



Regarding Linux spinlocks vs these patches: it's not the same
situation. spinlock functions are inlined, as you noted, thus a code
sequence that takes a spinlock, does some accesses, then releases the
spinlock ends up as a long sequence of instructions. On the contrary,
the cache functions (which are not going to be inlined any time soon  
as

they are strong versions of weak symbols, incompatible with inlining)
contain a single asm statement, thus adding a memory clobber to this
statement won't have any effect for lack of preceding or following
instructions to (not) reorder.


Fine.  I still think it's good practice to always use the memory  
clobber in these situations, as it doesn't hurt anything, and if  
nothing else you'd be setting a good example for others in situations  
that may not be as inline-averse -- but such style issues are up to you  
as maintainer.


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2] net: Add tftp speed indication

[Simon Glass]

This prints a tftp speed indication after the download completes. This
is the 3.6 MiB/s indicator below.

Tegra2 (SeaBoard) # tftp ...
Using asx0 device
TFTP from server 172.22.72.144; our IP address is 172.22.73.81
Filename '/tftpboot/uImage-user-seaboard-1'.
Load address: 0x408000
Loading: #
 3.6 MiB/s
done

Signed-off-by: Simon Glass 
---
Changes in v2:
- Make this feature unconditional (remove need for CONFIG_TFTP_SPEED)
- Display speed on the next line instead of same line

 net/tftp.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/net/tftp.c b/net/tftp.c
index 59a8ebb..09790eb 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -40,6 +40,7 @@
 
 static ulong TftpTimeoutMSecs = TIMEOUT;
 static int TftpTimeoutCountMax = TIMEOUT_COUNT;
+static ulong time_start;   /* Record time we started tftp */
 
 /*
  * These globals govern the timeout behavior when attempting a connection to a
@@ -299,6 +300,12 @@ static void tftp_complete(void)
TftpNumchars++;
}
 #endif
+   time_start = get_timer(time_start);
+   if (time_start > 0) {
+   puts("\n\t ");  /* Line up with "Loading: " */
+   print_size(NetBootFileXferSize /
+   time_start * 1000, "/s");
+   }
puts("\ndone\n");
net_set_state(NETLOOP_SUCCESS);
 }
@@ -775,6 +782,7 @@ void TftpStart(enum proto_t protocol)
TftpState = STATE_SEND_RRQ;
}
 
+   time_start = get_timer(0);
TftpTimeoutCountMax = TftpRRQTimeoutCountMax;
 
NetSetTimeout(TftpTimeoutMSecs, TftpTimeout);
-- 
1.7.7.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush

[Albert ARIBAUD]

Hi Scott,

On Thu, 11 Oct 2012 15:21:28 -0500, Scott Wood
 wrote:

> > Scott, I think you should not mistake as condescension what is just
> > humo(u)r. What I wrote above is a quotation from a (light, quite
> > humorous and above all, self-mocking) movie, meant to be read by, but  
> > in
> > no way directed against, Marex.
> 
> Sure, it just seemed an odd way to resume a conversation that had  
> already begun on the topic.

It felt odd to you obviously. But does oddity imply condescension?
Seems to me like you're assuming a lot on what or how I think.

> > > > A memory barrier's effect is only that all of the volatile  
> > accesses
> > > > placed before it in the source code finish when the barrier  
> > executes,
> > > > and that none of the volatile accesses placed after it in the  
> > source
> > > > code starts before the barrier has executed.
> > >
> > > Cite from official GCC documentation please, or example code that  
> > shows
> > > a problem.
> > 
> > http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm
> > 
> > "If your assembler instructions access memory in an unpredictable
> > fashion, add `memory' to the list of clobbered registers. This will
> > cause GCC to not keep memory values cached in registers across the
> > assembler instruction and not optimize stores or loads to that memory.
> > You will also want to add the volatile keyword if the memory affected
> > is not listed in the inputs or outputs of the asm, as the `memory'
> > clobber does not count as a side-effect of the asm".
> 
> "and not optimize stores or loads to that memory".  It's not clear what  
> "that" refers to, since the memory clobber does not refer to specific  
> memory, but given that the purpose is "if your assembler instructions  
> access memory in an unpredictable fashion", I don't see how it could be  
> interpreted as anything other than "any memory which could possibly be  
> modified by the program".  So it excludes constant data, but that's  
> about it.

It does not necessarily include "all memory". Besides, "that"  -- to me
-- cleary means "the memory mentioned in the statement, for instance in
the inputs or outputs.

> The only reference to volatile is to tell you to add it to the asm  
> statement (not to other memory accesses) so that the asm statement does  
> not get removed altogether.

The memory clobber definition says no memory values are kept cached
in registers across the instruction, that implies that if a volatile
access was prepared (a memory value was cached in a register) it is
finished before the asm statement executes, and similarly, since the
desciption says "across" the instruction, volatiles reads or writes
located after the instruction won't have been started before ithe
instruction executest, or they would have needed to cache the value,
which is contrary to the memory clobber definition.

This is not to say that only volatiles are affected by the barrier; but
volatiles certainly are.

> > > We've use memory barriers like this all the time.  It works and is
> > > standard practice.  If it doesn't work like that it needs to be  
> > fixed.
> > 
> > I have used memory barriers too, and I've already seen some weird
> > things happening because they were used in ways that did not match
> > their effects. Particularly, we did not use memory clobbers on cache
> > flush or invalidate operations, we used them on actual barrier
> > operations -- dsb, dmb and their cp15 incarnations.
> 
> What specifically did you see the compiler do?

I'll have to look up the repositories. I'll keep you posted once I find
back examples.

> > > That AVR/ARM example you showed on IRC is special because it's  
> > calling
> > > a libgcc function and GCC knows that the function doesn't access  
> > memory
> > > (loading constant data for the argument doesn't count).  I couldn't  
> > get
> > > the same thing to happen with a normal function, even when declared
> > > with __attribute__((const)).  Yes, it's a problem for ordering code  
> > in
> > > general and thus keeping slow stuff out of critical sections, but it
> > > shouldn't be a problem for ordering memory accesses.
> > 
> > Can you *guarantee* that no valid C code will ever let a non-volatile
> > write slip across a memory clobber?
> > 
> > Memory clobbers do not guarantee this, at least not explicitly in  
> > their
> > description, whereas C sequence points do. For instance, the call to a
> > function is a sequence point, reached only after its arguments have
> > been evaluated.
> 
> I don't know GCC internals, so I personally can't guarantee anything.   
> What I know is that they're used for this purpose all over the place,  
> and if there really is a problem it needs to be fixed.  If the use in  
> this patch is wrong, then so are Linux synchronization primitives, for  
> example.  How would you make a spinlock?  Certainly you can't insist  
> that all the variables protected by the lock be volatile.

My point is that memory clobbers 

Re: [U-Boot] [PATCH V3 17/32] imximage.cfg: run files through C preprocessor

[Tom Rini]

On Fri, Oct 12, 2012 at 12:27:09AM +0200, stefano babic wrote:

[snip]
> One reason to move into the board directory is that there was a decision
> to move rules related to only one arch or SOC where they belong to, that
> is in the corresponding arch/ or board/ directory.

I'll admit that maybe my make-fu is off, but that idea doesn't work, at
least for SPL.  So I'd really like someone to make that work first.

> > 2. Easy to clean the temporary generated file. The main Makefile
> > deletes files with .pcfgtmp extension.
> > 
> > 3. The file referred to by boards.cfg actually exists before the build
> > starts.
> 
> This is true, but I do not understand which is the advantage. A lot of
> files are generated, also .c or .S files. If it exists or not, it does
> not matter.
> 
> > 
> > 4. The temporary file can be placed in an out-of-tree directory for
> > make -O builds
> > 
> > Using the file extension to determine whether to use the preprocessor is
> > also
> > what gcc uses to preprocess ".S" files while skipping this for ".s" files.
> > 
> > I believe that at least other mx6 boards will quickly change to using
> > the preprocessor
> > as well to add support for solo/duallite, so total line count should
> > eventually be
> > less with changes to the main makefile.
> 
> Ok, but if this true, the rule should be moved to the mx6 directory, and
> should not be valid for other i.MX that do not need it.

Introducing slight differences to the image generation rules per family
generation when we could just have one rule that works fine for all
generations is one worry I have about the notion of moving things out of
a top level Makefile and putting them elsewhere.

> > Having said that, I really have no problem going your route, I just
> > don't prefer it.
> > Let me know.
> 
> Let's wait to know Tom's opinion.

How about this, if we convert the existing cfg files to '@' comments and
use the LDSCRIPT style preprocessor rule instead of another one?  I
assume there's improvements that could be done to the mx5 ones if we
preprocessed them.  Or no?  I'm looking for opinions here myself still..

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush

[Albert ARIBAUD]

Hi Scott,

On Thu, 11 Oct 2012 16:09:28 -0500, Scott Wood
 wrote:

> On 10/11/2012 03:01:32 PM, Albert ARIBAUD wrote:
> > Hi Mark,
> > 
> > Thanks for your example.
> > 
> > > My understanding of gcc is that global memory accesses are meant to
> > > stay on the correct side of an asm with a "memory" clobber.  The gcc
> > > manual states that if you use a memory clobber, the asm should also
> > > be volatile.
> > 
> > Not exactly. It states that you need to add volatile if you cannot  
> > tell
> > where in memory your instruction will write; if you can tell (by
> > specifying "m" as an output of the asm) then volatile is not
> > needed -- simply because the compiler can tell where in memory the
> > write will happen, and will thus not eliminate the asm statement as
> > long as the destination memory is not optimized out.
> 
> You're confusing the part about adding volatile to the asm statement to  
> keep it from being completely removed, from anything to do with  
> ordering or clobbers.

*Please* stop pretending I am saying things I haven't.

All I said in the above answer is that contrary to what Mark said about
the doc, it does not require adding volatile to memory clobbers: 'You
will also want to add the volatile keyword if the memory affected is
not listed in the inputs or outputs of the asm, as the `memory' clobber
does not count as a side-effect of the asm'.

*Nowhere* in my answer above did I state anything related to ordering.

> -Scott

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] microblaze: Fix byteorder for microblaze

[Stephan Linz]

Am Freitag, den 05.10.2012, 14:58 +0200 schrieb Michal Simek: 
> Just remove ancient code.
> 
> Signed-off-by: Michal Simek 
> ---
>  arch/microblaze/include/asm/byteorder.h |   23 ---
>  1 files changed, 0 insertions(+), 23 deletions(-)
> 
> diff --git a/arch/microblaze/include/asm/byteorder.h 
> b/arch/microblaze/include/asm/byteorder.h
> index b2757a4..f3a471d 100644
> --- a/arch/microblaze/include/asm/byteorder.h
> +++ b/arch/microblaze/include/asm/byteorder.h
> @@ -20,29 +20,6 @@
>  
>  #ifdef __GNUC__
>  
> -/* This is effectively a dupe of the arch-independent byteswap
> -   code in include/linux/byteorder/swab.h, however we force a cast
> -   of the result up to 32 bits.  This in turn forces the compiler
> -   to explicitly clear the high 16 bits, which it wasn't doing otherwise.
> -
> -   I think this is a symptom of a bug in mb-gcc.  JW 20040303
> -*/
> -
> -
> -static __inline__ __u16 ___arch__swab16 (__u16 half_word)
> -{
> - /* 32 bit temp to cast result, forcing clearing of high word */
> - __u32 temp;
> -
> - temp = ((half_word & 0x00FFU) << 8) | ((half_word & 0xFF00U) >> 8);
> -
> - return (__u16) temp;
> -}
> -
> -#define __arch__swab16(x) ___arch__swab16(x)
> -
> -/* Microblaze has no arch-specific endian conversion insns */
> -

Acked-by: Stephan Linz 

> 
>  #if !defined(__STRICT_ANSI__) || defined(__KERNEL__)
>  #  define __BYTEORDER_HAS_U64__
>  #  define __SWAB_64_THRU_32__


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] microblaze: Fix compilation warning in ext2_find_next_zero_bit

[Stephan Linz]

Am Freitag, den 05.10.2012, 14:58 +0200 schrieb Michal Simek: 
> ext2_find_next_zero_bit must be also static if __swab32 is also static.
> 
> Warning:
> include/asm/bitops.h:369:22: warning: '__fswab32' is static but
> used in inline function 'ext2_find_next_zero_bit'
> which is not static [enabled by default]
> 
> Signed-off-by: Michal Simek 
> ---
>  arch/microblaze/include/asm/bitops.h |3 ++-
>  1 files changed, 2 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/microblaze/include/asm/bitops.h 
> b/arch/microblaze/include/asm/bitops.h
> index e8c835f..eafa2b5 100644
> --- a/arch/microblaze/include/asm/bitops.h
> +++ b/arch/microblaze/include/asm/bitops.h
> @@ -319,7 +319,8 @@ extern __inline__ int ext2_test_bit(int nr, const 
> volatile void * addr)
>  #define ext2_find_first_zero_bit(addr, size) \
>   ext2_find_next_zero_bit((addr), (size), 0)
>  
> -extern __inline__ unsigned long ext2_find_next_zero_bit(void *addr, unsigned 
> long size, unsigned long offset)
> +static inline unsigned long ext2_find_next_zero_bit(void *addr,
> + unsigned long size, unsigned long offset)

Acked-by: Stephan Linz 

> {
>   unsigned long *p = ((unsigned long *) addr) + (offset >> 5);
>   unsigned long result = offset & ~31UL;

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 17/32] imximage.cfg: run files through C preprocessor

[stefano babic]

Am 11/10/2012 22:33, schrieb Troy Kisky:
> On 10/11/2012 4:11 AM, Stefano Babic wrote:
>> Does it work something more direct (I have not tested, really...) ?
>>
>> In board Makefile, for example board/freescale/mx6qsabrelite, a rule for
>> the imximage file:
>>
>> $(CONFIG_IMX_CONFIG): 
>> $(CC) -E -x c $< -I./include -o $@
>>
>> And let unchanged in the main Makefile. So CONFIG_IMX_CONFIG is produced
>> and you do not need to change logic in the main Makefile.
>>
>> Regards,
>> Stefano
>>
> 
> The advantages I see of changing the main Makefile are
> 1. Easy for other boards to use the preprocessor. You merely
> need to change the file extension to pcfg.

I set Tom in CC, because changing the main Makefile is more related to
the whole project, and not only for the i.MX.

One reason to move into the board directory is that there was a decision
to move rules related to only one arch or SOC where they belong to, that
is in the corresponding arch/ or board/ directory.

> 
> 2. Easy to clean the temporary generated file. The main Makefile
> deletes files with .pcfgtmp extension.
> 
> 3. The file referred to by boards.cfg actually exists before the build
> starts.

This is true, but I do not understand which is the advantage. A lot of
files are generated, also .c or .S files. If it exists or not, it does
not matter.

> 
> 4. The temporary file can be placed in an out-of-tree directory for
> make -O builds
> 
> Using the file extension to determine whether to use the preprocessor is
> also
> what gcc uses to preprocess ".S" files while skipping this for ".s" files.
> 
> I believe that at least other mx6 boards will quickly change to using
> the preprocessor
> as well to add support for solo/duallite, so total line count should
> eventually be
> less with changes to the main makefile.

Ok, but if this true, the rule should be moved to the mx6 directory, and
should not be valid for other i.MX that do not need it.

> Having said that, I really have no problem going your route, I just
> don't prefer it.
> Let me know.

Let's wait to know Tom's opinion.

Regards,
Stefano

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80  Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] add nand spl boot for qi_lb60 board

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/10/12 20:19, Xiangfu Liu wrote:
> Hi Tom Rini
> 
> I cannot easy find a way to use 'puts' instead 'serial_puts' in my
>  code. any advise will be great.

You should be able to use CONFIG_SPL_LIBCOMMON_SUPPORT without
CONFIG_SPL_FRAMEWORK and get 'puts'.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQd0bGAAoJENk4IS6UOR1Wl6EP/ip/TVA/lLHYv+rcZuu8oJyZ
fh5rYYaprLsIzt9esQ9lBjhxFsEvmofGYzFLyMR318Z2cyxTAdOYWLRD+JkFLZAJ
nd5SB5Co8mKUBXxpnGN8k0dUT00G+dZvgYE1BM37uC+fLpaZXqrncn+4O4xU2GP/
tsbAXUG1K+KmEB8B1xKSrsrKU6CCfh8bbZZaj541mFRHcgjF+ZWIoWFoTR7HedgZ
LLcY+LSMxXntK/P5jH8mq9feLU7fPqVo9jxUBlkF35IQTAI3+1X88tkwzObYD8az
c2sRgACQh+pgoY2VA6t2YhUp+gFOiHxGUqr+xiFndQhKFs+LNsziNbT4ddptKTb7
3SZi8roOifxc1/K6vW7rxs5F5AOzYajstTDepgHCHeW/zks3NZq0qFNSZAK9GS/C
Sh0Q9Uxo9FqW7LpXtSXTj9AUJ5TRD4pKZYcTEBETlZqqWfqTUMJkhV/KEEq0IxRR
NJctAVYq5clDl/Jq12F5YygTpA7o7OCGT0EIPsTudpijbkjnEA7FT1F0Y6oQV6+z
0ibshUuty1FVcIJ/ccJPChPSQqFfXZqrf6SOiEU1exe4ap/nC0MtBOGhcs7lkYzr
com4uYPPeVqogcLAxJwMTz/qaAzEdLWo09Qi4vLt2O/YUB9KHKy/9hyzMo63P2xM
IkT2O2SxNONOZfhXlhMd
=yBoD
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush

[Scott Wood]

On 10/11/2012 03:01:32 PM, Albert ARIBAUD wrote:

Hi Mark,

Thanks for your example.

> My understanding of gcc is that global memory accesses are meant to
> stay on the correct side of an asm with a "memory" clobber.  The gcc
> manual states that if you use a memory clobber, the asm should also
> be volatile.

Not exactly. It states that you need to add volatile if you cannot  
tell

where in memory your instruction will write; if you can tell (by
specifying "m" as an output of the asm) then volatile is not
needed -- simply because the compiler can tell where in memory the
write will happen, and will thus not eliminate the asm statement as
long as the destination memory is not optimized out.


You're confusing the part about adding volatile to the asm statement to  
keep it from being completely removed, from anything to do with  
ordering or clobbers.


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 17/32] imximage.cfg: run files through C preprocessor

[Troy Kisky]

On 10/11/2012 4:11 AM, Stefano Babic wrote:

Does it work something more direct (I have not tested, really...) ?

In board Makefile, for example board/freescale/mx6qsabrelite, a rule for
the imximage file:

$(CONFIG_IMX_CONFIG): 
$(CC) -E -x c $< -I./include -o $@

And let unchanged in the main Makefile. So CONFIG_IMX_CONFIG is produced
and you do not need to change logic in the main Makefile.

Regards,
Stefano



The advantages I see of changing the main Makefile are
1. Easy for other boards to use the preprocessor. You merely
need to change the file extension to pcfg.

2. Easy to clean the temporary generated file. The main Makefile
deletes files with .pcfgtmp extension.

3. The file referred to by boards.cfg actually exists before the build 
starts.


4. The temporary file can be placed in an out-of-tree directory for
make -O builds

Using the file extension to determine whether to use the preprocessor is 
also

what gcc uses to preprocess ".S" files while skipping this for ".s" files.

I believe that at least other mx6 boards will quickly change to using 
the preprocessor
as well to add support for solo/duallite, so total line count should 
eventually be

less with changes to the main makefile.


Having said that, I really have no problem going your route, I just 
don't prefer it.

Let me know.


Thanks
Troy

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush

[Scott Wood]

On 10/11/2012 03:03:29 PM, Albert ARIBAUD wrote:

Hi Scott,

On Thu, 11 Oct 2012 13:03:13 -0500, Scott Wood
 wrote:

> On 10/11/2012 12:31:46 AM, Albert ARIBAUD wrote:
> > Hi Marek,
> >
> > On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut   
wrote:

> >
> > > Add memory barrier to cache invalidate and flush calls.
> >
> > Memory barrier...
> >
> > "You keep using that word. I do not think it means what you think  
it

> > means." :)
>
> Could we wait on the condescension until your assertion of what a
> memory clobber does and does not do is resolved?

Scott, I think you should not mistake as condescension what is just
humo(u)r. What I wrote above is a quotation from a (light, quite
humorous and above all, self-mocking) movie, meant to be read by, but  
in

no way directed against, Marex.


Sure, it just seemed an odd way to resume a conversation that had  
already begun on the topic.


> > A memory barrier's effect is only that all of the volatile  
accesses
> > placed before it in the source code finish when the barrier  
executes,
> > and that none of the volatile accesses placed after it in the  
source

> > code starts before the barrier has executed.
>
> Cite from official GCC documentation please, or example code that  
shows

> a problem.

http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm

"If your assembler instructions access memory in an unpredictable
fashion, add `memory' to the list of clobbered registers. This will
cause GCC to not keep memory values cached in registers across the
assembler instruction and not optimize stores or loads to that memory.
You will also want to add the volatile keyword if the memory affected
is not listed in the inputs or outputs of the asm, as the `memory'
clobber does not count as a side-effect of the asm".


"and not optimize stores or loads to that memory".  It's not clear what  
"that" refers to, since the memory clobber does not refer to specific  
memory, but given that the purpose is "if your assembler instructions  
access memory in an unpredictable fashion", I don't see how it could be  
interpreted as anything other than "any memory which could possibly be  
modified by the program".  So it excludes constant data, but that's  
about it.


The only reference to volatile is to tell you to add it to the asm  
statement (not to other memory accesses) so that the asm statement does  
not get removed altogether.



> We've use memory barriers like this all the time.  It works and is
> standard practice.  If it doesn't work like that it needs to be  
fixed.


I have used memory barriers too, and I've already seen some weird
things happening because they were used in ways that did not match
their effects. Particularly, we did not use memory clobbers on cache
flush or invalidate operations, we used them on actual barrier
operations -- dsb, dmb and their cp15 incarnations.


What specifically did you see the compiler do?

> That AVR/ARM example you showed on IRC is special because it's  
calling
> a libgcc function and GCC knows that the function doesn't access  
memory
> (loading constant data for the argument doesn't count).  I couldn't  
get

> the same thing to happen with a normal function, even when declared
> with __attribute__((const)).  Yes, it's a problem for ordering code  
in

> general and thus keeping slow stuff out of critical sections, but it
> shouldn't be a problem for ordering memory accesses.

Can you *guarantee* that no valid C code will ever let a non-volatile
write slip across a memory clobber?

Memory clobbers do not guarantee this, at least not explicitly in  
their

description, whereas C sequence points do. For instance, the call to a
function is a sequence point, reached only after its arguments have
been evaluated.


I don't know GCC internals, so I personally can't guarantee anything.   
What I know is that they're used for this purpose all over the place,  
and if there really is a problem it needs to be fixed.  If the use in  
this patch is wrong, then so are Linux synchronization primitives, for  
example.  How would you make a spinlock?  Certainly you can't insist  
that all the variables protected by the lock be volatile.


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush

[Albert ARIBAUD]

Hi Scott,

On Thu, 11 Oct 2012 13:03:13 -0500, Scott Wood
 wrote:

> On 10/11/2012 12:31:46 AM, Albert ARIBAUD wrote:
> > Hi Marek,
> > 
> > On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut  wrote:
> > 
> > > Add memory barrier to cache invalidate and flush calls.
> > 
> > Memory barrier...
> > 
> > "You keep using that word. I do not think it means what you think it
> > means." :)
> 
> Could we wait on the condescension until your assertion of what a  
> memory clobber does and does not do is resolved?

Scott, I think you should not mistake as condescension what is just
humo(u)r. What I wrote above is a quotation from a (light, quite
humorous and above all, self-mocking) movie, meant to be read by, but in
no way directed against, Marex. Besides, since you followed the IRC
discussion, you knew the actual exact meanings of "memory barrier" and
of the "memory" clobber are not that easy to grasp, which makes the
quotation quite appropriate without necessarily.

> > A memory barrier's effect is only that all of the volatile accesses
> > placed before it in the source code finish when the barrier executes,
> > and that none of the volatile accesses placed after it in the source
> > code starts before the barrier has executed.
> 
> Cite from official GCC documentation please, or example code that shows  
> a problem.

http://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Extended-Asm

"If your assembler instructions access memory in an unpredictable
fashion, add `memory' to the list of clobbered registers. This will
cause GCC to not keep memory values cached in registers across the
assembler instruction and not optimize stores or loads to that memory.
You will also want to add the volatile keyword if the memory affected
is not listed in the inputs or outputs of the asm, as the `memory'
clobber does not count as a side-effect of the asm".

> We've use memory barriers like this all the time.  It works and is  
> standard practice.  If it doesn't work like that it needs to be fixed.

I have used memory barriers too, and I've already seen some weird
things happening because they were used in ways that did not match
their effects. Particularly, we did not use memory clobbers on cache
flush or invalidate operations, we used them on actual barrier
operations -- dsb, dmb and their cp15 incarnations.

> That AVR/ARM example you showed on IRC is special because it's calling  
> a libgcc function and GCC knows that the function doesn't access memory  
> (loading constant data for the argument doesn't count).  I couldn't get  
> the same thing to happen with a normal function, even when declared  
> with __attribute__((const)).  Yes, it's a problem for ordering code in  
> general and thus keeping slow stuff out of critical sections, but it  
> shouldn't be a problem for ordering memory accesses.

Can you *guarantee* that no valid C code will ever let a non-volatile
write slip across a memory clobber?

Memory clobbers do not guarantee this, at least not explicitly in their
description, whereas C sequence points do. For instance, the call to a
function is a sequence point, reached only after its arguments have
been evaluated.

> -Scott

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush

[Albert ARIBAUD]

Hi Mark,

Thanks for your example.

> My understanding of gcc is that global memory accesses are meant to 
> stay on the correct side of an asm with a "memory" clobber.  The gcc 
> manual states that if you use a memory clobber, the asm should also 
> be volatile.

Not exactly. It states that you need to add volatile if you cannot tell
where in memory your instruction will write; if you can tell (by
specifying "m" as an output of the asm) then volatile is not
needed -- simply because the compiler can tell where in memory the
write will happen, and will thus not eliminate the asm statement as
long as the destination memory is not optimized out.

> I'm not sure if adding the memory clobber is enough, but it's certainly a 
> help.

memory clobber can help, but I don't think it helps, and I know it does
not help enough, in the patch's case.

> Regards,
> 
> Mark M.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 3/3] fs: add partition switch libary, implement ls and fsload commands

[Benoît Thébaudeau]

Hi Stephen,

On Thursday, October 11, 2012 8:59:29 PM, Stephen Warren wrote:
> From: Stephen Warren 
> 
> Implement "ls" and "fsload" commands that act like
> {fat,ext2}{ls,load},
> and transparently handle either file-system. This scheme could easily
> be
> extended to other filesystem types; I only didn't do it for zfs
> because
> I don't have any filesystems of that type to test with.
> 
> Signed-off-by: Stephen Warren 
> ---
> v2:
> * Build cmd_fs.c when CONFIG_CMD_FS_GENERIC not always.
> * Use new CONFIG_FS_{FAT,EXT4} rather than CONFIG_CMD_{FAT,EXT2}.
> * Implemented fs_close() and call it from the tail of fs_ls() and
> fs_read().
>   This ensures that any other usage of e.g. the ext4 library between
>   fs_*()
>   calls, then the two usages won't interfere.
> * Re-organized fs.c to reduce the number of ifdef blocks.
> * Added argc checking to do_ls().
> ---
>  Makefile|3 +-
>  common/Makefile |1 +
>  common/cmd_fs.c |   89 ++
>  fs/Makefile |   47 +++
>  fs/fs.c |  227
>  +++
>  include/fs.h|   49 
>  6 files changed, 415 insertions(+), 1 deletions(-)
>  create mode 100644 common/cmd_fs.c
>  create mode 100644 fs/Makefile
>  create mode 100644 fs/fs.c
>  create mode 100644 include/fs.h
> 
> diff --git a/Makefile b/Makefile
> index d7e2c2f..0b50eb7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -242,7 +242,8 @@ LIBS-y += drivers/net/npe/libnpe.o
>  endif
>  LIBS-$(CONFIG_OF_EMBED) += dts/libdts.o
>  LIBS-y += arch/$(ARCH)/lib/lib$(ARCH).o
> -LIBS-y += fs/cramfs/libcramfs.o \
> +LIBS-y += fs/libfs.o \
> + fs/cramfs/libcramfs.o \
>   fs/ext4/libext4fs.o \
>   fs/fat/libfat.o \
>   fs/fdos/libfdos.o \
> diff --git a/common/Makefile b/common/Makefile
> index 125b2be..c6c31f7 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -103,6 +103,7 @@ COBJS-$(CONFIG_CMD_FLASH) += cmd_flash.o
>  ifdef CONFIG_FPGA
>  COBJS-$(CONFIG_CMD_FPGA) += cmd_fpga.o
>  endif
> +COBJS-$(CONFIG_CMD_FS_GENERIC) += cmd_fs.o
>  COBJS-$(CONFIG_CMD_GPIO) += cmd_gpio.o
>  COBJS-$(CONFIG_CMD_I2C) += cmd_i2c.o
>  COBJS-$(CONFIG_CMD_IDE) += cmd_ide.o
> diff --git a/common/cmd_fs.c b/common/cmd_fs.c
> new file mode 100644
> index 000..9df0a66
> --- /dev/null
> +++ b/common/cmd_fs.c
> @@ -0,0 +1,89 @@
> +/*
> + * Copyright (c) 2012, NVIDIA CORPORATION.  All rights reserved.
> + *
> + * Inspired by cmd_ext_common.c, cmd_fat.c.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
> License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see
> .
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +int do_fsload(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> argv[])
> +{
> + unsigned long addr;
> + unsigned long bytes;
> + unsigned long pos;
> + int len_read;
> + char buf[12];
> +
> + if (argc < 5)
> + return CMD_RET_USAGE;
> +
> + if (fs_set_blk_dev(argv[1], argv[2]))
> + return 1;
> +
> + addr = simple_strtoul(argv[3], NULL, 0);
> + if (argc >= 6)
> + bytes = simple_strtoul(argv[5], NULL, 0);
> + else
> + bytes = 0;
> + if (argc >= 7)
> + pos = simple_strtoul(argv[6], NULL, 0);
> + else
> + pos = 0;
> +
> + len_read = fs_read(argv[4], addr, pos, bytes);
> + if (len_read <= 0)
> + return 1;
> +
> + sprintf(buf, "0x%x", (unsigned int)len_read);
> + setenv("filesize", buf);
> +
> + return 0;
> +}
> +
> +U_BOOT_CMD(
> + fsload, 7,  0,  do_fsload,
> + "load binary file from a filesystem",
> + " []   [bytes [pos]]\n"
> + "- Load binary file 'filename' from partition 'part' on
> device\n"
> + "   type 'interface' instance 'dev' to address 'addr' in
> memory.\n"
> + "  'bytes' gives the size to load in bytes.\n"
> + "  If 'bytes' is 0 or omitted, the file is read until the
> end.\n"
> + "  'pos' gives the file byte position to start reading from.\n"
> + "  If 'pos' is 0 or omitted, the file is read from the start."
> +);
> +
> +int do_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
> +{
> + if (argc < 2)
> + return CMD_RET_USAGE;
> +
> + if (fs_set_blk_dev(argv[1], (argc >= 3) ? argv[2] : NULL))
> + return 1;
> +
> + if (fs_ls(argc == 4 ? argv[3] : "/"))
> + return 1;
> +
> + return 0;
> +}
> +
>

[U-Boot] Pull request: u-boot-staging/next

[Anatolij Gustschin]

Hi Tom,

The following changes since commit 221953d41dea8dce027b9ce6beee700d97ac2c83:

  Prepare v2012.10-rc2 (2012-10-01 09:41:10 -0700)

are available in the git repository at:
  git://git.denx.de/u-boot-staging.git ag...@denx.de-next

Simon Glass (6):
  bootstage: Export bootstage_add_record() function
  bootstage: Add time accumulation feature
  bootstage: Store boot timings in device tree
  bootstage: Add feature to stash/unstash bootstage info
  bootstage: Add bootstage command
  bootstage: Add new bootstage IDs for board, LCD

 README |   25 
 arch/arm/lib/bootm.c   |3 +
 common/Makefile|1 +
 common/bootstage.c |  306 +---
 common/cmd_bootstage.c |  116 ++
 include/bootstage.h|   85 +
 6 files changed, 517 insertions(+), 19 deletions(-)
 create mode 100644 common/cmd_bootstage.c

Please pull. Thanks!

Anatolij
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Scott Wood]

On 10/11/2012 01:45:02 PM, Albert ARIBAUD wrote:

Hi Scott,

On Thu, 11 Oct 2012 13:13:33 -0500, Scott Wood
 wrote:

> FWIW I think putting policy documents in a wiki, without any
> guidance on who's supposed to edit it or how changes get approved,  
is a

> bad idea.  Why not put policy documents in the git-managed source
> tree?  And changes would be
> proposed, discussed, and accepted/rejected like any other change.   
Plus

> there'd be at least a chance of a commit message showing rationale.

While I can see the benefits you find in this, is it not based on
the unspoken axiom that the project's policies should necessarily be
subject to a democratic process?


Process is othogonal to revision control.  We could vote on whether a  
policy patch gets applied, though I do not think U-Boot is currently  
democraticly run, except to the extent that Wolfgang sometimes changes  
his mind if enough people complain.  I do not know of any existing  
democratic process for approving a wiki update, and would hesitate to  
just go make a change.


As for the merits of the policy itself, I find maintainer signoffs to  
be useful, for example to distinguish a patch that I've applied locally  
versus one that I've fetched from upstream.


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2 3/3] fs: add partition switch libary, implement ls and fsload commands

[Stephen Warren]

From: Stephen Warren 

Implement "ls" and "fsload" commands that act like {fat,ext2}{ls,load},
and transparently handle either file-system. This scheme could easily be
extended to other filesystem types; I only didn't do it for zfs because
I don't have any filesystems of that type to test with.

Signed-off-by: Stephen Warren 
---
v2:
* Build cmd_fs.c when CONFIG_CMD_FS_GENERIC not always.
* Use new CONFIG_FS_{FAT,EXT4} rather than CONFIG_CMD_{FAT,EXT2}.
* Implemented fs_close() and call it from the tail of fs_ls() and fs_read().
  This ensures that any other usage of e.g. the ext4 library between fs_*()
  calls, then the two usages won't interfere.
* Re-organized fs.c to reduce the number of ifdef blocks.
* Added argc checking to do_ls().
---
 Makefile|3 +-
 common/Makefile |1 +
 common/cmd_fs.c |   89 ++
 fs/Makefile |   47 +++
 fs/fs.c |  227 +++
 include/fs.h|   49 
 6 files changed, 415 insertions(+), 1 deletions(-)
 create mode 100644 common/cmd_fs.c
 create mode 100644 fs/Makefile
 create mode 100644 fs/fs.c
 create mode 100644 include/fs.h

diff --git a/Makefile b/Makefile
index d7e2c2f..0b50eb7 100644
--- a/Makefile
+++ b/Makefile
@@ -242,7 +242,8 @@ LIBS-y += drivers/net/npe/libnpe.o
 endif
 LIBS-$(CONFIG_OF_EMBED) += dts/libdts.o
 LIBS-y += arch/$(ARCH)/lib/lib$(ARCH).o
-LIBS-y += fs/cramfs/libcramfs.o \
+LIBS-y += fs/libfs.o \
+   fs/cramfs/libcramfs.o \
fs/ext4/libext4fs.o \
fs/fat/libfat.o \
fs/fdos/libfdos.o \
diff --git a/common/Makefile b/common/Makefile
index 125b2be..c6c31f7 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -103,6 +103,7 @@ COBJS-$(CONFIG_CMD_FLASH) += cmd_flash.o
 ifdef CONFIG_FPGA
 COBJS-$(CONFIG_CMD_FPGA) += cmd_fpga.o
 endif
+COBJS-$(CONFIG_CMD_FS_GENERIC) += cmd_fs.o
 COBJS-$(CONFIG_CMD_GPIO) += cmd_gpio.o
 COBJS-$(CONFIG_CMD_I2C) += cmd_i2c.o
 COBJS-$(CONFIG_CMD_IDE) += cmd_ide.o
diff --git a/common/cmd_fs.c b/common/cmd_fs.c
new file mode 100644
index 000..9df0a66
--- /dev/null
+++ b/common/cmd_fs.c
@@ -0,0 +1,89 @@
+/*
+ * Copyright (c) 2012, NVIDIA CORPORATION.  All rights reserved.
+ *
+ * Inspired by cmd_ext_common.c, cmd_fat.c.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+
+int do_fsload(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   unsigned long addr;
+   unsigned long bytes;
+   unsigned long pos;
+   int len_read;
+   char buf[12];
+
+   if (argc < 5)
+   return CMD_RET_USAGE;
+
+   if (fs_set_blk_dev(argv[1], argv[2]))
+   return 1;
+
+   addr = simple_strtoul(argv[3], NULL, 0);
+   if (argc >= 6)
+   bytes = simple_strtoul(argv[5], NULL, 0);
+   else
+   bytes = 0;
+   if (argc >= 7)
+   pos = simple_strtoul(argv[6], NULL, 0);
+   else
+   pos = 0;
+
+   len_read = fs_read(argv[4], addr, pos, bytes);
+   if (len_read <= 0)
+   return 1;
+
+   sprintf(buf, "0x%x", (unsigned int)len_read);
+   setenv("filesize", buf);
+
+   return 0;
+}
+
+U_BOOT_CMD(
+   fsload, 7,  0,  do_fsload,
+   "load binary file from a filesystem",
+   " []   [bytes [pos]]\n"
+   "- Load binary file 'filename' from partition 'part' on device\n"
+   "   type 'interface' instance 'dev' to address 'addr' in memory.\n"
+   "  'bytes' gives the size to load in bytes.\n"
+   "  If 'bytes' is 0 or omitted, the file is read until the end.\n"
+   "  'pos' gives the file byte position to start reading from.\n"
+   "  If 'pos' is 0 or omitted, the file is read from the start."
+);
+
+int do_ls(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   if (argc < 2)
+   return CMD_RET_USAGE;
+
+   if (fs_set_blk_dev(argv[1], (argc >= 3) ? argv[2] : NULL))
+   return 1;
+
+   if (fs_ls(argc == 4 ? argv[3] : "/"))
+   return 1;
+
+   return 0;
+}
+
+U_BOOT_CMD(
+   ls, 4,  1,  do_ls,
+   "list files in a directory (default /)",
+   " [] [directory]\n"
+   "- List files in directory 'directory' of partition 'part' on\n"
+   "  device type 'interface' instance 'dev'."
+);
diff --git a/fs/Makefile b/fs/Makefile
new fi

[U-Boot] [PATCH V2 2/3] fs: separate CONFIG_FS_{FAT, EXT4} from CONFIG_CMD_{FAT, EXT*}

[Stephen Warren]

From: Stephen Warren 

This makes the FAT and ext4 filesystem implementations build if
CONFIG_FS_{FAT,EXT4} are defined, rather than basing the build on
whether CONFIG_CMD_{FAT,EXT*} are defined. This will allow the
filesystems to be built separately from the filesystem-specific commands
that use them. This paves the way for the creation of filesystem-generic
commands that used the filesystems, without requiring the filesystem-
specific commands.

Minor documentation changes are made for this change.

The new config options are automatically selected by the old config
options to retain backwards-compatibility.

Signed-off-by: Stephen Warren 
---
v2: New patch.
---
 README |4 +++-
 doc/README.ext4|   13 +
 fs/ext4/Makefile   |7 ++-
 fs/ext4/ext4_common.c  |2 +-
 fs/ext4/ext4_common.h  |4 ++--
 fs/ext4/ext4fs.c   |2 +-
 fs/fat/Makefile|4 ++--
 include/config_fallbacks.h |   13 +
 include/ext4fs.h   |2 +-
 9 files changed, 38 insertions(+), 13 deletions(-)

diff --git a/README b/README
index 4901710..d86068d 100644
--- a/README
+++ b/README
@@ -799,9 +799,11 @@ The following options need to be configured:
CONFIG_CMD_EEPROM   * EEPROM read/write support
CONFIG_CMD_ELF  * bootelf, bootvx
CONFIG_CMD_EXPORTENV* export the environment
+   CONFIG_CMD_EXT2 * ext2 command support
+   CONFIG_CMD_EXT4 * ext4 command support
CONFIG_CMD_SAVEENVsaveenv
CONFIG_CMD_FDC  * Floppy Disk Support
-   CONFIG_CMD_FAT  * FAT partition support
+   CONFIG_CMD_FAT  * FAT command support
CONFIG_CMD_FDOS * Dos diskette Support
CONFIG_CMD_FLASH  flinfo, erase, protect
CONFIG_CMD_FPGA   FPGA device initialization support
diff --git a/doc/README.ext4 b/doc/README.ext4
index b3ea8b7..b7d0ad3 100644
--- a/doc/README.ext4
+++ b/doc/README.ext4
@@ -1,15 +1,28 @@
 This patch series adds support for ext4 ls,load and write features in uboot
 Journaling is supported for write feature.
 
+To enable support for the ext4 (and ext2) filesystem implementation,
+#define CONFIG_FS_EXT4
+
+If you want write support,
+#define CONFIG_EXT4_WRITE
+
 To Enable ext2 ls and load commands, modify the board specific config file with
 #define CONFIG_CMD_EXT2
+This automatically defines CONFIG_FS_EXT4 for you.
 
 To Enable ext4 ls and load commands, modify the board specific config file with
 #define CONFIG_CMD_EXT4
+This automatically defines CONFIG_FS_EXT4 for you.
 
 To enable ext4 write command, modify the board specific config file with
 #define CONFIG_CMD_EXT4
 #define CONFIG_CMD_EXT4_WRITE
+These automatically define CONFIG_FS_EXT4 and CONFIG_EXT4_WRITE for you.
+
+Also relevant are the generic filesystem commands,
+#define CONFIG_CMD_FS_GENERIC
+This does not automatically enable EXT4 support for you.
 
 Steps to test:
 
diff --git a/fs/ext4/Makefile b/fs/ext4/Makefile
index 82cd9ae..bb801f9 100644
--- a/fs/ext4/Makefile
+++ b/fs/ext4/Makefile
@@ -30,11 +30,8 @@ include $(TOPDIR)/config.mk
 LIB= $(obj)libext4fs.o
 
 AOBJS  =
-COBJS-$(CONFIG_CMD_EXT4) := ext4fs.o ext4_common.o dev.o
-ifndef CONFIG_CMD_EXT4
-COBJS-$(CONFIG_CMD_EXT2) := ext4fs.o ext4_common.o dev.o
-endif
-COBJS-$(CONFIG_CMD_EXT4_WRITE) += ext4_journal.o crc16.o
+COBJS-$(CONFIG_FS_EXT4) := ext4fs.o ext4_common.o dev.o
+COBJS-$(CONFIG_EXT4_WRITE) += ext4_journal.o crc16.o
 
 SRCS   := $(AOBJS:.o=.S) $(COBJS-y:.o=.c)
 OBJS   := $(addprefix $(obj),$(AOBJS) $(COBJS-y))
diff --git a/fs/ext4/ext4_common.c b/fs/ext4/ext4_common.c
index 3deffd5..1083813 100644
--- a/fs/ext4/ext4_common.c
+++ b/fs/ext4/ext4_common.c
@@ -56,7 +56,7 @@ int ext4fs_indir3_blkno = -1;
 struct ext2_inode *g_parent_inode;
 static int symlinknest;
 
-#if defined(CONFIG_CMD_EXT4_WRITE)
+#if defined(CONFIG_EXT4_WRITE)
 uint32_t ext4fs_div_roundup(uint32_t size, uint32_t n)
 {
uint32_t res = size / n;
diff --git a/fs/ext4/ext4_common.h b/fs/ext4/ext4_common.h
index f728134..87cab16 100644
--- a/fs/ext4/ext4_common.h
+++ b/fs/ext4/ext4_common.h
@@ -37,7 +37,7 @@
 #include 
 #include 
 #include 
-#if defined(CONFIG_CMD_EXT4_WRITE)
+#if defined(CONFIG_EXT4_WRITE)
 #include "ext4_journal.h"
 #include "crc16.h"
 #endif
@@ -71,7 +71,7 @@ int ext4fs_find_file(const char *path, struct ext2fs_node 
*rootnode,
 int ext4fs_iterate_dir(struct ext2fs_node *dir, char *name,
struct ext2fs_node **fnode, int *ftype);
 
-#if defined(CONFIG_CMD_EXT4_WRITE)
+#if defined(CONFIG_EXT4_WRITE)
 uint32_t ext4fs_div_roundup(uint32_t size, uint32_t n);
 int ext4fs_checksum_update(unsigned int i);
 int ext4fs_get_parent_inode_num(const char *dirname, char *dname, int flags);
diff --git a/fs/ext4/ext4fs.c b/fs/ext4/ext4fs.c
index 93dcb7

[U-Boot] [PATCH V2 1/3] fs: delete unused Makefile

[Stephen Warren]

From: Stephen Warren 

fs/Makefile is unused. The top-level Makefile sets LIBS-y += fs/xxx and
hence causes make to directly descend two directory levels into each
individual filesystem, and it never descends into fs/ itself.

So, delete this useless file.

Signed-off-by: Stephen Warren 
---
v2: No change.

This series is based on all the disk/fs/FAT patches I have posted before,
as an FYI. Once I know exactly which of the bugfix patches made it into
the release, and u-boot/next works for Tegra, I can re-send a patch bomb
with all those and these patches in one go directly on top of u-boot/next
if you want.
---
 fs/Makefile |   42 --
 1 files changed, 0 insertions(+), 42 deletions(-)
 delete mode 100644 fs/Makefile

diff --git a/fs/Makefile b/fs/Makefile
deleted file mode 100644
index 901e189..000
--- a/fs/Makefile
+++ /dev/null
@@ -1,42 +0,0 @@
-#
-# (C) Copyright 2000-2006
-# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
-#
-# See file CREDITS for list of people who contributed to this
-# project.
-#
-# This program is free software; you can redistribute it and/or
-# modify it under the terms of the GNU General Public License as
-# published by the Free Software Foundation; either version 2 of
-# the License, or (at your option) any later version.
-#
-# This program is distributed in the hope that it will be useful,
-# but WITHOUT ANY WARRANTY; without even the implied warranty of
-# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
-# GNU General Public License for more details.
-#
-# You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
-# MA 02111-1307 USA
-#
-#
-
-subdirs-$(CONFIG_CMD_CRAMFS) := cramfs
-subdirs-$(CONFIG_CMD_EXT4) += ext4
-ifndef CONFIG_CMD_EXT4
-subdirs-$(CONFIG_CMD_EXT2) += ext4
-endif
-subdirs-$(CONFIG_CMD_FAT) += fat
-subdirs-$(CONFIG_CMD_FDOS) += fdos
-subdirs-$(CONFIG_CMD_JFFS2) += jffs2
-subdirs-$(CONFIG_CMD_REISER) += reiserfs
-subdirs-$(CONFIG_YAFFS2) += yaffs2
-subdirs-$(CONFIG_CMD_UBIFS) += ubifs
-subdirs-$(CONFIG_CMD_ZFS) += zfs
-
-SUBDIRS:= $(subdirs-y)
-
-$(obj).depend all:
-   @for dir in $(SUBDIRS) ; do \
-   $(MAKE) -C $$dir $@ ; done
-- 
1.7.0.4

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: u-boot-arm/master to u-boot/master

[Tom Rini]

On Thu, Oct 11, 2012 at 06:51:30PM +0200, Albert ARIBAUD wrote:

> Hi Tom,
> 
> The following changes since commit
> 28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad:
> 
>   arm: armv7: temporarily set -mno-unaligned-access (2012-10-05
>   21:24:22 +0200)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arm master
> 
> for you to fetch changes up to 9b5dba537473578153961ee96ed23e37e1fde3f7:
> 
>   exynos4: universal_C210: use software SPI (2012-10-10 20:37:39 +0900)
> 
> 
> Chander Kashyap (1):
>   Exynos5250: Enable PXE Support
> 
> Piotr Wilczek (9):
>   arm:exynos4:trats: Correct SDRAM configuration for trats
>   arm:exynos4:trats: Fix SDRAM size
>   arm:exynos4:pinmux: Modify the gpio function for mmc
>   arm:exynos4:trats: Use pinmux for mmc configuration
>   arm:exynos4:universal: Use pinmux for mmc configuration
>   arm:exynos4:universal: Eliminated low level init
>   arm: trats: Power down core 1
>   drivers: spi: modify soft spi driver
>   exynos4: universal_C210: use software SPI
> 
> ??ukasz Majewski (1):
>   gpio:fix: Proper handling of GPIO subsystem parts at Samsung
> devices
> 
>  arch/arm/cpu/armv7/exynos/pinmux.c   |   58 
>  arch/arm/include/asm/arch-exynos/gpio.h  |   19 ++
>  arch/arm/include/asm/arch-exynos/periph.h|1 +
>  arch/arm/include/asm/arch-s5pc1xx/gpio.h |7 +-
>  board/samsung/trats/trats.c  |   80 ++
>  board/samsung/universal_c210/Makefile|1 -
>  board/samsung/universal_c210/lowlevel_init.S |  395
>  --
>  board/samsung/universal_c210/universal.c |  116 
>  drivers/gpio/s5p_gpio.c  |6 +-
>  drivers/spi/soft_spi.c   |3 +
>  include/configs/s5pc210_universal.h  |   21 ++
>  include/configs/smdk5250.h   |6 +
>  include/configs/trats.h  |   17 +- 13 files
>  changed, 209 insertions(+), 521 deletions(-) delete mode 100644
>  board/samsung/universal_c210/lowlevel_init.S

NAK, sorry.  We have a two problems now:
- On PowerPC we have  which takes  but
  boards which do use soft_spi.c and now fail (taihu sacsng)
- zipitz2 has the same problem (cc'ing Marek)

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Albert ARIBAUD]

Hi Scott,

On Thu, 11 Oct 2012 13:13:33 -0500, Scott Wood
 wrote:

> FWIW I think putting policy documents in a wiki, without any  
> guidance on who's supposed to edit it or how changes get approved, is a  
> bad idea.  Why not put policy documents in the git-managed source  
> tree?  And changes would be
> proposed, discussed, and accepted/rejected like any other change.  Plus  
> there'd be at least a chance of a commit message showing rationale.

While I can see the benefits you find in this, is it not based on
the unspoken axiom that the project's policies should necessarily be
subject to a democratic process? Plus... in order for this process to
be put in place, a process should be defined for discussing this
process... argh. :)


> In any case, if this is the policy, we should not be saying that we  
> follow the Linux policy.

Agreed -- see Stephen's reply rightly correcting me re Linux.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Scott Wood]

On 10/11/2012 12:27:57 PM, Tom Rini wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/11/12 10:16, Scott Wood wrote:
> On 10/11/2012 11:38:00 AM, Tom Rini wrote:
>> On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
>>> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren
>>> wrote:
>> [snip]
 The problem with rebasing when pulling is that git commit
 IDs change, so it's much more difficult to determine when a
 commit is merged into a parent tree; one has to search by
 commit subject rather than just executing e.g. git branch -a
 --contains XXX. I thought Albert just agreed to use merges
 rather than rebases for u-boot-arm for this and perhaps
 other reasons.
>>>
>>> The short answer is that right now, u-boot/next follows the
>>> linux-next model and we rebase as needed.
>>
>> I'm going to reply to myself, in hopes of clearing things up.
>> We don't follow the linux-next model, really, I miss-spoke.
>>
>> History is important.  But so is getting the amount of process
>> for the size of the project.  The other thing is that we're
>> doing simultaneous development for both the current release and
>> the next release.
>>
>> So for the master branch of the master repo, it must never
>> rebase.  And as Wolfgang encourages users to use the custodian
>> repository of mainline isn't quite up to what they need,
>> custodian repositories must also keep their master branch
>> un-rebased as much as humanly possible (my rule of thumb would
>> be once it's been in the wild for a few days, it's too late).
>>
>> The next branch however can be rebased, as needed.
>
> Why is the next branch any different?  Users and custodians will
> both be affected by any rebase, just as if a master branch gets
> rebased.  This hybrid of the Linux approach and what was described
> in this thread as the U-Boot approach is worse than consistently
> doing one or the other IMHO.

The number of people working on next should be small and manageable.


More people likely use next than some custodian branches, and those are  
supposed to be rebase-free...


Wouldn't anyone developing code for the next merge window be working on  
next,

at least when it's not out of date?


But, yes, it bears more thinking if we want the next branch open for
longer than it has historically been, if we want that.  And we have at
least historically been saying that next can and will be rebased.


IMHO it would be nice for the next branch to open immediately after the  
merge window closes, and be kept up to date except during the merge  
window.  Historically the next branch has opened when someone requests  
a pull into it, but how do I make a sane pull request when the next  
branch has been untouched since the last release?


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Albert ARIBAUD]

Hi Stephen,

On Thu, 11 Oct 2012 11:26:45 -0600, Stephen Warren
 wrote:

> On 10/11/2012 11:16 AM, Albert ARIBAUD wrote:
> > Hi Scott,
> > 
> > On Thu, 11 Oct 2012 11:54:46 -0500, Scott Wood
> >  wrote:
> > 
> >> On 10/10/2012 01:40:54 PM, Albert ARIBAUD wrote:
> > Re committer identity, I don't see the relationship with "by"  
> >>> tags, and
> > especially with Singed-off-by, since the sign-off is not and must  
> >>> not
> > be related to the committer of the patch, but to its author(s).
> 
>  At least the way the Linux kernel uses the tag, both the original  
> >>> author
>  of the patch /and/ anyone who applies the patch, cherry-picks the  
> >>> patch,
>  ... must add their S-o-b line. I think U-Boot isn't using that part  
> >>> of
>  the model.
> >>>
> >>> No, it isn't. IIUC, U-Boot's "Signed-off-by" is supposed to mean "I
> >>> am (one of) the autor(s) of this patch".
> >>
> >> Is this documented anywhere?
> >>
> >> http://www.denx.de/wiki/U-Boot/DevelopmentProcess says, "U-Boot has  
> >> adopted the Linux kernel signoff policy".
> > 
> > Please do read the Linux kernel signoff policy as laid out in
> > Documentation/SubmittingPatches. Branch or subsystem maintainers should
> > add their Signed-off-by only if they made modifications to the original
> > patch in the process of applying it.
> 
> That's certainly not what I understand from reading that document. Can
> you please point out the part the states that policy?
> 
> (The part I think you may be talking about is that when you edit a
> patch, it is polite to add a note indicating what you changed *in
> addition* to adding your Signed-off-by tag):
> 
> Quoting that doc:
> 
> > If you are a subsystem or branch maintainer, sometimes you need to slightly
> > modify patches you receive in order to merge them, because the code is not
> > exactly the same in your tree and the submitters'. If you stick strictly to
> > rule (c), you should ask the submitter to rediff, but this is a totally
> > counter-productive waste of time and energy. Rule (b) allows you to adjust
> > the code, but then it is very impolite to change one submitter's code and
> > make him endorse your bugs. To solve this problem, it is recommended that
> > you add a line between the last Signed-off-by header and yours, indicating
> > the nature of your changes. While there is nothing mandatory about this, it
> > seems like prepending the description with your mail and/or name, all
> > enclosed in square brackets, is noticeable enough to make it obvious that
> > you are responsible for last-minute changes. Example :
> > 
> > Signed-off-by: Random J Developer 
> > [lu...@maintainer.example.org: struct foo moved from foo.c to foo.h]
> > Signed-off-by: Lucky K Maintainer 
> 
> and in particular, the following parts of that doc is what tells me that
> committers should always add S-o-b even if the commit didn't change:
> 
> > Developer's Certificate of Origin 1.1
> > 
> > By making a contribution to this project, I certify that:
> ...
> > (c) The contribution was provided directly to me by some other
> > person who certified (a), (b) or (c) and I have not modified
> > it.
> 
> > The Signed-off-by: tag indicates that the signer was involved in the
> > development of the patch, or that he/she was in the patch's delivery path.

My bad. I've indeed misread the Linux doc. However, the U-Boot doc is
clearly on the side of "no Signed-off-by from custodians".

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Scott Wood]

On 10/11/2012 12:16:58 PM, Albert ARIBAUD wrote:

Hi Scott,

On Thu, 11 Oct 2012 11:54:46 -0500, Scott Wood
 wrote:

> On 10/10/2012 01:40:54 PM, Albert ARIBAUD wrote:
> > > > Re committer identity, I don't see the relationship with "by"
> > tags, and
> > > > especially with Singed-off-by, since the sign-off is not and  
must

> > not
> > > > be related to the committer of the patch, but to its  
author(s).

> > >
> > > At least the way the Linux kernel uses the tag, both the  
original

> > author
> > > of the patch /and/ anyone who applies the patch, cherry-picks  
the

> > patch,
> > > ... must add their S-o-b line. I think U-Boot isn't using that  
part

> > of
> > > the model.
> >
> > No, it isn't. IIUC, U-Boot's "Signed-off-by" is supposed to mean  
"I

> > am (one of) the autor(s) of this patch".
>
> Is this documented anywhere?
>
> http://www.denx.de/wiki/U-Boot/DevelopmentProcess says, "U-Boot has
> adopted the Linux kernel signoff policy".

Please do read the Linux kernel signoff policy as laid out in
Documentation/SubmittingPatches.


You want me to read the Linux policy for documentation of how U-Boot  
deviates from Linux policy?



Branch or subsystem maintainers should
add their Signed-off-by only if they made modifications to the  
original

patch in the process of applying it.


That's not what it says.


Then read http://www.denx.de/wiki/U-Boot/Patches: "the Signed-off-by:
is a line at the end of the commit message by which the signer
certifies that he was involved in the development of the patch and  
that

he accepts the Developer's Certificate of Origin (see
SubmittingPatches).

In U-Boot, we typically do not add a Signed-off-by: if we just pass on
a patch without any changes".


Thanks.  FWIW I think putting policy documents in a wiki, without any  
guidance on who's supposed to edit it or how changes get approved, is a  
bad idea.  Why not put policy documents in the git-managed source  
tree?  And changes would be
proposed, discussed, and accepted/rejected like any other change.  Plus  
there'd be at least a chance of a commit message showing rationale.


In any case, if this is the policy, we should not be saying that we  
follow the Linux policy.



(the "Certificate of Origin" is laid out in the "SubmittingPatches"
documentation file from Linux)

> Actual behavior is probably inconsistent between custodians.

I haven't seen such inconsistency and certainly don't want to see any,
at least in ARM trees from which I have to pull.


I've been signing off patches I apply to the NAND tree.  I recall  
stopping at one point in the past because someone complained, and then  
starting again -- not sure if someone else complained about doing it  
*that* way, or if I just noticed others doing it.


Looking through the history I see others that seems to be doing the  
same (outside ARMland), though I can't say for sure without  
investigating whether the patch was "passed on without any changes" in  
each instance.


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush

[Scott Wood]

On 10/11/2012 12:31:46 AM, Albert ARIBAUD wrote:

Hi Marek,

On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut  wrote:

> Add memory barrier to cache invalidate and flush calls.

Memory barrier...

"You keep using that word. I do not think it means what you think it
means." :)


Could we wait on the condescension until your assertion of what a  
memory clobber does and does not do is resolved?



A memory barrier's effect is only that all of the volatile accesses
placed before it in the source code finish when the barrier executes,
and that none of the volatile accesses placed after it in the source
code starts before the barrier has executed.


Cite from official GCC documentation please, or example code that shows  
a problem.


We've use memory barriers like this all the time.  It works and is  
standard practice.  If it doesn't work like that it needs to be fixed.


That AVR/ARM example you showed on IRC is special because it's calling  
a libgcc function and GCC knows that the function doesn't access memory  
(loading constant data for the argument doesn't count).  I couldn't get  
the same thing to happen with a normal function, even when declared  
with __attribute__((const)).  Yes, it's a problem for ordering code in  
general and thus keeping slow stuff out of critical sections, but it  
shouldn't be a problem for ordering memory accesses.


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot on my board freescale P1010RDB is erased

[Scott Wood]

On 10/10/2012 07:26:50 AM, randriamanjaka franky wrote:


Hi,
The u-boot on my board freescale P1010RDB  is erased.There was a  
problem when i want to reflash it.


Is there a tool from freescale to put the first u-boot from nand on  
my board freescale P1010RDB  ?


Is there a bootable image in NOR flash?

If not, you'll need some sort of JTAG.  The Freescale tool would be one  
of our JTAG devices plus CodeWarrior -- or you can use a third party  
JTAG if it has support for this board.  Depending on the tool, you may  
have to first put an image into NOR flash rather than rewrite NAND  
directly.


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] h2200: Make use of default_serial_console

[Albert ARIBAUD]

On Thu, 11 Oct 2012 19:40:08 +0200, Albert ARIBAUD
 wrote:

> Hi Lukasz,
> 
> On Wed, 10 Oct 2012 02:09:59 +0200, Lukasz Dalek 
> wrote:
> 
> > Define CONFIG_CONS_INDEX to use ffuart as default console and fix
> > compilation error related to undefined CONFIG_CONS_INDEX.
> > 
> > Signed-off-by: Lukasz Dalek 
> > ---
> >  include/configs/h2200.h |1 +
> >  1 files changed, 1 insertions(+), 0 deletions(-)
> > 
> > diff --git a/include/configs/h2200.h b/include/configs/h2200.h
> > index de5299b..ef14dd3 100644
> > --- a/include/configs/h2200.h
> > +++ b/include/configs/h2200.h
> > @@ -124,6 +124,7 @@
> >  
> >  #define CONFIG_PXA_SERIAL
> >  #define CONFIG_FFUART
> > +#define CONFIG_CONS_INDEX  3
> >  
> >  #define CONFIG_BAUDRATE115200
> >  #define CONFIG_SYS_BAUDRATE_TABLE  { 9600, 38400, 115200 }
> 
> This is actually a second patch, applying only above the first h2200
> patch, which was removed from next because it did not build. If I
> accepted that second patch, then I'd have to accept the first one,
> which is precisely what I did not do, because I did not want the
> first commit introducing h2200 to be non-buildable. :(
> 
> Therefore I'd prefer that you squash both patches "h2200: Add support
> for iPAQ h2200" and "h2200: Make use of default_serial_console"
> together and post the result as "[PATCH V2] h2200: Add support for iPAQ
> h2200" with adequate version history, so that the commit in U-Boot which
> introduces h2200 actually builds successfully.

... plus you can add the missing MAINTAINERS entry. :)

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 2/2] fs: add partition switch libary, implement ls and fsload commands

[Benoît Thébaudeau]

On Thursday, October 11, 2012 7:05:37 PM, Tom Rini wrote:
> On 10/11/12 09:57, Stephen Warren wrote:
> > On 10/11/2012 10:47 AM, Tom Rini wrote:
> >> On 10/10/12 17:05, Stephen Warren wrote:
> >>> From: Stephen Warren 
> >> 
> >>> Implement "ls" and "fsload" commands that act like
> >>> {fat,ext2}{ls,load}, and transparently handle either
> >>> file-system. This scheme could easily be extended to other
> >>> filesystem types; I only didn't do it for zfs because I don't
> >>> have any filesystems of that type.
> >> 
> >>> Signed-off-by: Stephen Warren  --- There
> >>> are a couple FIXMEs in here:
> >> 
> >>> 1) In fs/fs.c, code is ifdef on CONFIG_CMD_FAT or
> >>> CONFIG_CMD_EXT2. This means that the new commands and code can
> >>>  only be enabled if the "legacy" {fat,ext2}{ls,load} are
> >>> enabled. What we really want is CONFIG_FS_FAT and
> >>> CONFIG_FS_EXT2 to enable the filesystem code, and then
> >>> CONFIG_CMD_FAT, CONFIG_CMD_EXT2, CONFIG_CMD_FS to only affect
> >>> the command implementations. However, that would require
> >>> making every include/config/*.h that sets the current defines
> >>> also set more. I suppose that's a fairly mechanical change
> >>> though, so easy enough to implement. Does that seem like a
> >>> reasonable approach to people?
> >> 
> >> How about a new CONFIG_CMD_GENERIC_FS for the new ls/fsload (and
> >>  any later commands like write that get added) and once most
> >> filesystems are converted we can think about a transition plan?
> > 
> > Certainly.
> > 
> > The issue is that the filesystem code itself is conditionally
> > included based on CONFIG_CMD_FAT and CONFIG_CMD_EXT4. This would
> > require that in order to use the new generic commands, you also
> > had to support the old non-generic commands in order to get a
> > linkable result. Perhaps that's fine for now, but by separating the
> > existing CONFIG_CMD_FAT into two (CONFIG_CMD_FAT, CONFIG_FS_FAT),
> > we could avoid that requirement. As Benoit mentioned, perhaps we
> > could arrange that CONFIG_CMD_FAT selects CONFIG_FS_FAT somehow,
> > although I haven't looked at U-Boot's configuration system to see
> > if that's possible yet.
> 
> Since we don't have Kconfig right now, it's not really easy to do
> that
> kind of thing.  I think once we have more filesystems converted we
> can
> work out doing the mechanical separate of fs/ from common/ for fs
> code.

This does not require Kconfig. include/config_fallbacks.h is already made for
automatic config fixups. The following lines could simply be added to it:

#if defined(CONFIG_CMD_FAT) && !defined(CONFIG_FS_FAT)
#define CONFIG_FS_FAT
#endif

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] h2200: Make use of default_serial_console

[Albert ARIBAUD]

Hi Lukasz,

On Wed, 10 Oct 2012 02:09:59 +0200, Lukasz Dalek 
wrote:

> Define CONFIG_CONS_INDEX to use ffuart as default console and fix
> compilation error related to undefined CONFIG_CONS_INDEX.
> 
> Signed-off-by: Lukasz Dalek 
> ---
>  include/configs/h2200.h |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/include/configs/h2200.h b/include/configs/h2200.h
> index de5299b..ef14dd3 100644
> --- a/include/configs/h2200.h
> +++ b/include/configs/h2200.h
> @@ -124,6 +124,7 @@
>  
>  #define CONFIG_PXA_SERIAL
>  #define CONFIG_FFUART
> +#define CONFIG_CONS_INDEX3
>  
>  #define CONFIG_BAUDRATE  115200
>  #define CONFIG_SYS_BAUDRATE_TABLE{ 9600, 38400, 115200 }

This is actually a second patch, applying only above the first h2200
patch, which was removed from next because it did not build. If I
accepted that second patch, then I'd have to accept the first one,
which is precisely what I did not do, because I did not want the
first commit introducing h2200 to be non-buildable. :(

Therefore I'd prefer that you squash both patches "h2200: Add support
for iPAQ h2200" and "h2200: Make use of default_serial_console"
together and post the result as "[PATCH V2] h2200: Add support for iPAQ
h2200" with adequate version history, so that the commit in U-Boot which
introduces h2200 actually builds successfully.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/11/12 10:16, Scott Wood wrote:
> On 10/11/2012 11:38:00 AM, Tom Rini wrote:
>> On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
>>> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren 
>>> wrote:
>> [snip]
 The problem with rebasing when pulling is that git commit
 IDs change, so it's much more difficult to determine when a 
 commit is merged into a parent tree; one has to search by 
 commit subject rather than just executing e.g. git branch -a 
 --contains XXX. I thought Albert just agreed to use merges 
 rather than rebases for u-boot-arm for this and perhaps
 other reasons.
>>> 
>>> The short answer is that right now, u-boot/next follows the 
>>> linux-next model and we rebase as needed.
>> 
>> I'm going to reply to myself, in hopes of clearing things up.
>> We don't follow the linux-next model, really, I miss-spoke.
>> 
>> History is important.  But so is getting the amount of process 
>> for the size of the project.  The other thing is that we're
>> doing simultaneous development for both the current release and
>> the next release.
>> 
>> So for the master branch of the master repo, it must never 
>> rebase.  And as Wolfgang encourages users to use the custodian 
>> repository of mainline isn't quite up to what they need, 
>> custodian repositories must also keep their master branch 
>> un-rebased as much as humanly possible (my rule of thumb would
>> be once it's been in the wild for a few days, it's too late).
>> 
>> The next branch however can be rebased, as needed.
> 
> Why is the next branch any different?  Users and custodians will 
> both be affected by any rebase, just as if a master branch gets 
> rebased.  This hybrid of the Linux approach and what was described 
> in this thread as the U-Boot approach is worse than consistently 
> doing one or the other IMHO.

The number of people working on next should be small and manageable.
But, yes, it bears more thinking if we want the next branch open for
longer than it has historically been, if we want that.  And we have at
least historically been saying that next can and will be rebased.

>> In the case of post-v2012.10, it will be rebased as we want the 
>> commit to change how ARM and unaligned accesses are handled to
>> be the first thing.
> 
> Any particular reason, short of telling people whose patches have 
> already been accepted that they need to respin them?

That is the primary reason, yes.  U-Boot doesn't, I feel, have the
clout that the kernel does to tell people to keep re-basing their work
until the window in master is open.

>> I don't think "perfect" "changes A-G were done in repository X 
>> against tree Y" is the most useful bit of information.  When we 
>> rebase we may lose that boards 1/2/3 worked at point Y but we 
>> gain change D is when board 2 broke as part of being merged with 
>> other changes.
> 
> I don't follow.

It's a little bit me ranting.  I'm trying to bisect a problem in the
kernel right now and I swear I must be doing something wrong, or the
merge commits just aren't helping me.

- -- 
Tom
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQdwGdAAoJENk4IS6UOR1Wlr0P/2EYAeeEgGxW50Nltgx2XLC3
EcHEg+IguY1PAuvjvN8FZnV4GsUGhYhGXW3TzQdVwXjyYXxYJJbDYsP2G+8dyMzs
IU4KzP3AcyNv6VuU5abJpuIagDoUtkcHKvFh+7UMRQIdQXfaDrztvf3PsGITH0pQ
QNeKFfwGkz7Gn7sUrnms6zXOA9JNPbyInG5R4C6nAY2SlKiNjd49TpvAfgPMhKzi
BJMPjStK4lMxgURJtbqYGDzZQehYY0xvW+36dw36POYINbGLV1hLxVaCyK9tffKq
YLw532a+utnygkHnsUAhH02QIzz1nQholjWoWwG2gpNlIPiAQuYHfMjwUmGpujvK
Rnql4Vm9ecgcrWV5aR5+L8QpIhF7TrqTPKK05chDGDwbTOhTPfdVwDWqnzyMfnoQ
CHjs5pmSgDviEH5uT+azdBlve/iuJlc4dcFzonNsLi7Q19ELS2i6lTbZdkuW7v9r
jNOv+qnObVfb8hGEhQWOZmLMesMio7YL5SySp+W7VFXbzZt2PSmiC3Tjjz1xdTKe
p06BhachZlZ+tEG3L+cULuYeKdOMFCjelB4xsGfZa/afPYOBQsf6nj/vyPTTsO+w
DAjUoE99df9/Uo++xWx8ZmBFbx0QTd7UMITE9IcTXpTbF4flEb+dKQ6JtCkLcngO
GjqJsPeqBjguozwGUIyH
=siLe
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Stephen Warren]

On 10/11/2012 11:16 AM, Albert ARIBAUD wrote:
> Hi Scott,
> 
> On Thu, 11 Oct 2012 11:54:46 -0500, Scott Wood
>  wrote:
> 
>> On 10/10/2012 01:40:54 PM, Albert ARIBAUD wrote:
> Re committer identity, I don't see the relationship with "by"  
>>> tags, and
> especially with Singed-off-by, since the sign-off is not and must  
>>> not
> be related to the committer of the patch, but to its author(s).

 At least the way the Linux kernel uses the tag, both the original  
>>> author
 of the patch /and/ anyone who applies the patch, cherry-picks the  
>>> patch,
 ... must add their S-o-b line. I think U-Boot isn't using that part  
>>> of
 the model.
>>>
>>> No, it isn't. IIUC, U-Boot's "Signed-off-by" is supposed to mean "I
>>> am (one of) the autor(s) of this patch".
>>
>> Is this documented anywhere?
>>
>> http://www.denx.de/wiki/U-Boot/DevelopmentProcess says, "U-Boot has  
>> adopted the Linux kernel signoff policy".
> 
> Please do read the Linux kernel signoff policy as laid out in
> Documentation/SubmittingPatches. Branch or subsystem maintainers should
> add their Signed-off-by only if they made modifications to the original
> patch in the process of applying it.

That's certainly not what I understand from reading that document. Can
you please point out the part the states that policy?

(The part I think you may be talking about is that when you edit a
patch, it is polite to add a note indicating what you changed *in
addition* to adding your Signed-off-by tag):

Quoting that doc:

> If you are a subsystem or branch maintainer, sometimes you need to slightly
> modify patches you receive in order to merge them, because the code is not
> exactly the same in your tree and the submitters'. If you stick strictly to
> rule (c), you should ask the submitter to rediff, but this is a totally
> counter-productive waste of time and energy. Rule (b) allows you to adjust
> the code, but then it is very impolite to change one submitter's code and
> make him endorse your bugs. To solve this problem, it is recommended that
> you add a line between the last Signed-off-by header and yours, indicating
> the nature of your changes. While there is nothing mandatory about this, it
> seems like prepending the description with your mail and/or name, all
> enclosed in square brackets, is noticeable enough to make it obvious that
> you are responsible for last-minute changes. Example :
> 
> Signed-off-by: Random J Developer 
> [lu...@maintainer.example.org: struct foo moved from foo.c to foo.h]
> Signed-off-by: Lucky K Maintainer 

and in particular, the following parts of that doc is what tells me that
committers should always add S-o-b even if the commit didn't change:

> Developer's Certificate of Origin 1.1
> 
> By making a contribution to this project, I certify that:
...
> (c) The contribution was provided directly to me by some other
> person who certified (a), (b) or (c) and I have not modified
> it.

> The Signed-off-by: tag indicates that the signer was involved in the
> development of the patch, or that he/she was in the patch's delivery path.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Stephen Warren]

On 10/11/2012 11:16 AM, Scott Wood wrote:
> On 10/11/2012 11:38:00 AM, Tom Rini wrote:
>> On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
...
>> In the case of post-v2012.10, it will be rebased as we want the commit
>> to change how
>> ARM and unaligned accesses are handled to be the first thing.
> 
> Any particular reason, short of telling people whose patches have
> already been accepted that they need to respin them?

(I'm really replying to Tom here not Scott)

As I understand it, the process for getting u-boot/next into
u-boot/master is perhaps:

1) tag u-boot/master for the release
2) merge u-boot/next into u-boot/master (or perhaps you're proposing
rebase u-boot/next onto u-boot/master and then fast-forward merge it).

I think the solution to getting patches into u-boot/master first is
therefore:

1) tag u-boot/master for the release
2) apply, cherry-pick, or merge a branch with just the early commits
into u-boot/master
3) merge u-boot/next into u-boot/master

(hopefully (3) doesn't contain duplicated commits with (2)... the beauty
of the Linux kernel's model is that it wouldn't, and even with U-Boot's
model it wouldn't with sufficient planning)

That way, everything can still be merges, and hence preserve commit IDs,
but we also get any early commits in early.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Albert ARIBAUD]

Hi Scott,

On Thu, 11 Oct 2012 11:54:46 -0500, Scott Wood
 wrote:

> On 10/10/2012 01:40:54 PM, Albert ARIBAUD wrote:
> > > > Re committer identity, I don't see the relationship with "by"  
> > tags, and
> > > > especially with Singed-off-by, since the sign-off is not and must  
> > not
> > > > be related to the committer of the patch, but to its author(s).
> > >
> > > At least the way the Linux kernel uses the tag, both the original  
> > author
> > > of the patch /and/ anyone who applies the patch, cherry-picks the  
> > patch,
> > > ... must add their S-o-b line. I think U-Boot isn't using that part  
> > of
> > > the model.
> > 
> > No, it isn't. IIUC, U-Boot's "Signed-off-by" is supposed to mean "I
> > am (one of) the autor(s) of this patch".
> 
> Is this documented anywhere?
> 
> http://www.denx.de/wiki/U-Boot/DevelopmentProcess says, "U-Boot has  
> adopted the Linux kernel signoff policy".

Please do read the Linux kernel signoff policy as laid out in
Documentation/SubmittingPatches. Branch or subsystem maintainers should
add their Signed-off-by only if they made modifications to the original
patch in the process of applying it.

Then read http://www.denx.de/wiki/U-Boot/Patches: "the Signed-off-by:
is a line at the end of the commit message by which the signer
certifies that he was involved in the development of the patch and that
he accepts the Developer's Certificate of Origin (see
SubmittingPatches).

In U-Boot, we typically do not add a Signed-off-by: if we just pass on
a patch without any changes".

(the "Certificate of Origin" is laid out in the "SubmittingPatches"
documentation file from Linux)

> Actual behavior is probably inconsistent between custodians.

I haven't seen such inconsistency and certainly don't want to see any,
at least in ARM trees from which I have to pull.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model (was: Re: [PULL] u-boot-usb/next)

[Scott Wood]

On 10/11/2012 11:38:00 AM, Tom Rini wrote:

On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
[snip]
> > The problem with rebasing when pulling is that git commit IDs  
change,
> > so it's much more difficult to determine when a commit is merged  
into
> > a parent tree; one has to search by commit subject rather than  
just

> > executing e.g. git branch -a --contains XXX. I thought Albert just
> > agreed to use merges rather than rebases for u-boot-arm for this  
and

> > perhaps other reasons.
>
> The short answer is that right now, u-boot/next follows the  
linux-next

> model and we rebase as needed.

I'm going to reply to myself, in hopes of clearing things up.  We  
don't

follow the linux-next model, really, I miss-spoke.

History is important.  But so is getting the amount of process for the
size of the project.  The other thing is that we're doing simultaneous
development for both the current release and the next release.

So for the master branch of the master repo, it must never rebase.   
And
as Wolfgang encourages users to use the custodian repository of  
mainline
isn't quite up to what they need, custodian repositories must also  
keep

their master branch un-rebased as much as humanly possible (my rule of
thumb would be once it's been in the wild for a few days, it's too
late).

The next branch however can be rebased, as needed.


Why is the next branch any different?  Users and custodians will both  
be affected by any rebase, just as if a master branch gets rebased.   
This hybrid of the Linux approach and what was described in this thread  
as the U-Boot approach is worse than consistently doing one or the  
other IMHO.


In the case of post-v2012.10, it will be rebased as we want the  
commit to change how

ARM and unaligned accesses are handled to be the first thing.


Any particular reason, short of telling people whose patches have  
already been accepted that they need to respin them?



I don't
think "perfect" "changes A-G were done in repository X against tree Y"
is the most useful bit of information.  When we rebase we may lose  
that

boards 1/2/3 worked at point Y but we gain change D is when board 2
broke as part of being merged with other changes.


I don't follow.

-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/4] poweprc/85xx: add QMan frequency info and fdt fixup.

[York Sun]

From: Haiying Wang 

Starting from QMan3.0, the QMan clock cycle needs be exposed so that the kernel
driver can use it to calculate the shaper prescaler and rate.

Signed-off-by: Haiying Wang 
---
 arch/powerpc/cpu/mpc85xx/cpu.c   |4 
 arch/powerpc/cpu/mpc85xx/fdt.c   |5 +
 arch/powerpc/cpu/mpc85xx/speed.c |4 
 include/e500.h   |3 +++
 4 files changed, 16 insertions(+)

diff --git a/arch/powerpc/cpu/mpc85xx/cpu.c b/arch/powerpc/cpu/mpc85xx/cpu.c
index 24a572c..149040d 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu.c
@@ -217,6 +217,10 @@ int checkcpu (void)
}
 #endif
 
+#ifdef CONFIG_SYS_DPAA_QBMAN
+   printf("   QMAN:  %s MHz\n", strmhz(buf1, sysinfo.freqQMAN));
+#endif
+
 #ifdef CONFIG_SYS_DPAA_PME
printf("   PME:   %s MHz\n", strmhz(buf1, sysinfo.freqPME));
 #endif
diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index a364ef2..ab09330 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -411,6 +411,11 @@ static void ft_fixup_dpaa_clks(void *blob)
 #endif
 #endif
 
+#ifdef CONFIG_SYS_DPAA_QBMAN
+   do_fixup_by_compat_u32(blob, "fsl,qman",
+   "clock-frequency", sysinfo.freqQMAN, 1);
+#endif
+
 #ifdef CONFIG_SYS_DPAA_PME
do_fixup_by_compat_u32(blob, "fsl,pme",
"clock-frequency", sysinfo.freqPME, 1);
diff --git a/arch/powerpc/cpu/mpc85xx/speed.c b/arch/powerpc/cpu/mpc85xx/speed.c
index 8bbf0bc..c55f1d3 100644
--- a/arch/powerpc/cpu/mpc85xx/speed.c
+++ b/arch/powerpc/cpu/mpc85xx/speed.c
@@ -167,6 +167,10 @@ void get_sys_info (sys_info_t * sysInfo)
}
 #endif
 
+#ifdef CONFIG_SYS_DPAA_QBMAN
+   sysInfo->freqQMAN = sysInfo->freqSystemBus / 2;
+#endif
+
 #ifdef CONFIG_SYS_DPAA_FMAN
switch ((rcw_tmp & FM1_CLK_SEL) >> FM1_CLK_SHIFT) {
case 1:
diff --git a/include/e500.h b/include/e500.h
index e1708b9..0ff8e89 100644
--- a/include/e500.h
+++ b/include/e500.h
@@ -18,6 +18,9 @@ typedef struct
 #ifdef CONFIG_SYS_DPAA_FMAN
   unsigned long freqFMan[CONFIG_SYS_NUM_FMAN];
 #endif
+#ifdef CONFIG_SYS_DPAA_QBMAN
+  unsigned long freqQMAN;
+#endif
 #ifdef CONFIG_SYS_DPAA_PME
   unsigned long freqPME;
 #endif
-- 
1.7.9.5


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/4] mpc85xx/portals: Add qman and bman ip_cfg field into portal info

[York Sun]

From: Haiying Wang 

Because QMan3.0 and BMan2.1 used ip_cfg in ip_rev_2 register to differ the
total portal number, buffer pool number etc, we can use this info to limit
those resources in kernel driver.

Signed-off-by: Haiying Wang 
---
 arch/powerpc/cpu/mpc85xx/portals.c |   13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/portals.c 
b/arch/powerpc/cpu/mpc85xx/portals.c
index 6199633..b59ef69 100644
--- a/arch/powerpc/cpu/mpc85xx/portals.c
+++ b/arch/powerpc/cpu/mpc85xx/portals.c
@@ -182,14 +182,18 @@ void fdt_fixup_qportals(void *blob)
 {
int off, err;
unsigned int maj, min;
+   unsigned int ip_cfg;
u32 rev_1 = in_be32(&qman->ip_rev_1);
+   u32 rev_2 = in_be32(&qman->ip_rev_2);
char compat[64];
int compat_len;
 
maj = (rev_1 >> 8) & 0xff;
min = rev_1 & 0xff;
+   ip_cfg = rev_2 & 0xff;
 
-   compat_len = sprintf(compat, "fsl,qman-portal-%u.%u", maj, min) + 1;
+   compat_len = sprintf(compat, "fsl,qman-portal-%u.%u.%u",
+   maj, min, ip_cfg) + 1;
compat_len += sprintf(compat + compat_len, "fsl,qman-portal") + 1;
 
off = fdt_node_offset_by_compatible(blob, -1, "fsl,qman-portal");
@@ -267,14 +271,19 @@ void fdt_fixup_bportals(void *blob)
 {
int off, err;
unsigned int maj, min;
+   unsigned int ip_cfg;
u32 rev_1 = in_be32(&bman->ip_rev_1);
+   u32 rev_2 = in_be32(&bman->ip_rev_2);
char compat[64];
int compat_len;
 
maj = (rev_1 >> 8) & 0xff;
min = rev_1 & 0xff;
 
-   compat_len = sprintf(compat, "fsl,bman-portal-%u.%u", maj, min) + 1;
+   ip_cfg = rev_2 & 0xff;
+
+   compat_len = sprintf(compat, "fsl,bman-portal-%u.%u.%u",
+maj, min, ip_cfg) + 1;
compat_len += sprintf(compat + compat_len, "fsl,bman-portal") + 1;
 
off = fdt_node_offset_by_compatible(blob, -1, "fsl,bman-portal");
-- 
1.7.9.5


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 2/2] fs: add partition switch libary, implement ls and fsload commands

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/11/12 09:57, Stephen Warren wrote:
> On 10/11/2012 10:47 AM, Tom Rini wrote:
>> On 10/10/12 17:05, Stephen Warren wrote:
>>> From: Stephen Warren 
>> 
>>> Implement "ls" and "fsload" commands that act like 
>>> {fat,ext2}{ls,load}, and transparently handle either 
>>> file-system. This scheme could easily be extended to other 
>>> filesystem types; I only didn't do it for zfs because I don't 
>>> have any filesystems of that type.
>> 
>>> Signed-off-by: Stephen Warren  --- There 
>>> are a couple FIXMEs in here:
>> 
>>> 1) In fs/fs.c, code is ifdef on CONFIG_CMD_FAT or 
>>> CONFIG_CMD_EXT2. This means that the new commands and code can
>>>  only be enabled if the "legacy" {fat,ext2}{ls,load} are 
>>> enabled. What we really want is CONFIG_FS_FAT and 
>>> CONFIG_FS_EXT2 to enable the filesystem code, and then 
>>> CONFIG_CMD_FAT, CONFIG_CMD_EXT2, CONFIG_CMD_FS to only affect 
>>> the command implementations. However, that would require
>>> making every include/config/*.h that sets the current defines
>>> also set more. I suppose that's a fairly mechanical change
>>> though, so easy enough to implement. Does that seem like a
>>> reasonable approach to people?
>> 
>> How about a new CONFIG_CMD_GENERIC_FS for the new ls/fsload (and
>>  any later commands like write that get added) and once most 
>> filesystems are converted we can think about a transition plan?
> 
> Certainly.
> 
> The issue is that the filesystem code itself is conditionally 
> included based on CONFIG_CMD_FAT and CONFIG_CMD_EXT4. This would 
> require that in order to use the new generic commands, you also
> had to support the old non-generic commands in order to get a
> linkable result. Perhaps that's fine for now, but by separating the
> existing CONFIG_CMD_FAT into two (CONFIG_CMD_FAT, CONFIG_FS_FAT),
> we could avoid that requirement. As Benoit mentioned, perhaps we
> could arrange that CONFIG_CMD_FAT selects CONFIG_FS_FAT somehow,
> although I haven't looked at U-Boot's configuration system to see
> if that's possible yet.

Since we don't have Kconfig right now, it's not really easy to do that
kind of thing.  I think once we have more filesystems converted we can
work out doing the mechanical separate of fs/ from common/ for fs code.

- -- 
Tom

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQdvxhAAoJENk4IS6UOR1WOFIP/0VjExqx5FZ+Lau4wFtV8dI0
v5+jfwDUtG0L3h/lTv9NJkX5j9duXJVOcAkB4hVeWFAqd/fSdI0mlajPvR1rpS/J
luYFvR/XdlIoQe65CbrKhFEzHH3pwcbYXd/Zz9wx2cvxmTz7NvbM3KZsvECPpYtO
CEqNClM2e5Q0ebE/XKZ5xG8qJVWZbs48i8kkmgHQHsiplGEdf7IzNgOqiSFL5rgF
DT6oRacoAzOLBwMo5/ssIiT04GgM+3Nac1UV/4GPKiNt62k4p6OfniUN4sL6N6Yl
oq8aFR3ZWGZgHdHO+y+pp+4MLAlvbv8PxMXHhw/ZCCHgLR9sodvWQl/Pn3C9TFTC
0LdYgMvft5FBBqffI+XuPMomdKYLmmHtAhlh7lly9L5GQYw8iU25cfXP8ZeBUOX+
aY4nX/Wp2s+vtXawWUVv01r0HRZZp3r6FJNAXWvE9m2cB+7HiZQD+nJvkV7ZZk7E
6WRdRlI8NTLn6Sfh42d6AzigsYfAm2Xwp6B1/gGix075E30yhB1KGdxs/SpQW+0+
tdtFXij/jtxAyabTLNTivAXO44l6IBurtlAZqXeI1ur6gEJa0L1Ju0Mi6rFO/Vrg
aQ/KBo+1DM4QgXxYkcYPxJ+KIJKQdsmIWEmpni+sgaLBgO43Ebh+lkLKHCm5NB0l
kaIgld2V1OQQDmg/j4yW
=Tegq
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Stephen Warren]

On 10/11/2012 01:19 AM, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <5075f48a.2080...@wwwdotorg.org> you wrote:
>>
>> I believe that's (part of) why Linux is tending towards pull requests of
>> a (signed) tag rather than a branch, since the tag always points at a
>> specific commit, and incremental pull requests can just create a new tag
>> name. Of course, the ability to sign tags also also a motivator.
> 
> I tend to disagree here. Tags can easily be removed. As such, they
> are in no way different from or better than a specific commit in a
> branch that does not get rebased.

True, tags can be moved. However, the point wasn't that they're
immutable, but that using them can decouple the pull process from the
commit process. For example, I could:

git checkout -b foo bar
git am
git am
git am
git tag -s tag1 foo
send pull request
not wait for pull to complete
git am
git am
git am
git tag -s tag2 foo
send pull request

So, I can still apply stuff to a branch even in parallel with committing
new stuff. IIRC, the point I was originally responding to above was the
issue that by sending pull requests for somebody to pull a branch, if
you added commits to it before the pull was complete, they'd be pulled
in too. With tags, you can avoid that (or by creating a new branch too,
but anyway)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 2/2] fs: add partition switch libary, implement ls and fsload commands

[Stephen Warren]

On 10/11/2012 10:47 AM, Tom Rini wrote:
> On 10/10/12 17:05, Stephen Warren wrote:
>> From: Stephen Warren 
> 
>> Implement "ls" and "fsload" commands that act like 
>> {fat,ext2}{ls,load}, and transparently handle either file-system.
>>  This scheme could easily be extended to other filesystem types;
>> I only didn't do it for zfs because I don't have any filesystems
>> of that type.
> 
>> Signed-off-by: Stephen Warren  --- There are
>> a couple FIXMEs in here:
> 
>> 1) In fs/fs.c, code is ifdef on CONFIG_CMD_FAT or
>> CONFIG_CMD_EXT2. This means that the new commands and code can
>> only be enabled if the "legacy" {fat,ext2}{ls,load} are enabled.
>> What we really want is CONFIG_FS_FAT and CONFIG_FS_EXT2 to enable
>> the filesystem code, and then CONFIG_CMD_FAT, CONFIG_CMD_EXT2,
>> CONFIG_CMD_FS to only affect the command implementations.
>> However, that would require making every include/config/*.h that
>> sets the current defines also set more. I suppose that's a fairly
>> mechanical change though, so easy enough to implement. Does that
>> seem like a reasonable approach to people?
> 
> How about a new CONFIG_CMD_GENERIC_FS for the new ls/fsload (and
> any later commands like write that get added) and once most
> filesystems are converted we can think about a transition plan?

Certainly.

The issue is that the filesystem code itself is conditionally included
based on CONFIG_CMD_FAT and CONFIG_CMD_EXT4. This would require that
in order to use the new generic commands, you also had to support the
old non-generic commands in order to get a linkable result. Perhaps
that's fine for now, but by separating the existing CONFIG_CMD_FAT
into two (CONFIG_CMD_FAT, CONFIG_FS_FAT), we could avoid that
requirement. As Benoit mentioned, perhaps we could arrange that
CONFIG_CMD_FAT selects CONFIG_FS_FAT somehow, although I haven't
looked at U-Boot's configuration system to see if that's possible yet.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Scott Wood]

On 10/10/2012 01:40:54 PM, Albert ARIBAUD wrote:
> > Re committer identity, I don't see the relationship with "by"  
tags, and
> > especially with Singed-off-by, since the sign-off is not and must  
not

> > be related to the committer of the patch, but to its author(s).
>
> At least the way the Linux kernel uses the tag, both the original  
author
> of the patch /and/ anyone who applies the patch, cherry-picks the  
patch,
> ... must add their S-o-b line. I think U-Boot isn't using that part  
of

> the model.

No, it isn't. IIUC, U-Boot's "Signed-off-by" is supposed to mean "I
am (one of) the autor(s) of this patch".


Is this documented anywhere?

http://www.denx.de/wiki/U-Boot/DevelopmentProcess says, "U-Boot has  
adopted the Linux kernel signoff policy".


Actual behavior is probably inconsistent between custodians.

> > But that's not making the point (IMO) that we should have a  
flurry of

> > branch names.
>
> True, that's an entirely orthogonal issue. I mainly raised that  
point as

> an example from the kernel. What I really started this conversation
> about was not using rebases in either master or next, and the
> conversation has started to concentrate more on other things.

However, there are times when rebasing, and reordering even, might be
required -- think, for instance, of an important patch that should be
placed as early as possible in the next release, or inversely, a patch
that was put in next release and now sits in the middle of other
commits, but reveals faulty. There would be cause to pick this commit
out of the next tree before it becomes master.


It's a tradeoff between preserving history and preserving  
bisectability.  I wouldn't say it's ever really required except when  
there's a legal issue with carrying certain code in the history.


-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Stephen Warren]

On 10/11/2012 01:28 AM, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <50759a75.8060...@wwwdotorg.org> you wrote:
>>
>> Do note that linux-next doesn't become the next Linux kernel version
>> either; it's just a preview of the merges Linus will do. Linus re-does
>> all the merges based on the pull requests people actually send him. So,
>> the model is very different to u-boot/next.
> 
> Yes. And experience has shown that linux-next may be useful for
> specific testing, but it is utterly useless as base for any
> development work.

My experience doesn't agree. I almost exclusively use linux-next as the
underlying branch for all my development work. Now and then I do suffer
from finding the occasional problem, but it's better to find them and
fix them early rather than not seeing them until Linus merges everything
and having to debug through a couple months of history to find the bug,
so overall even that extra effort works out to be a net gain.

> When you need a tree which has all the latest and
> greatest commits (which have already been accepted for inclusion into
> the next release), then next is not your choice, because it will
> crumble below your fingers.

(I assume that in "then next is not your choice" above, "next" is
referring to a linux-next style model)

Yes, with U-Boot's next model (or what I understand it to be...) a
linux-next style branch/model/.. is indeed not needed; just use
u-boot/next instead. At least, I think that's what you're saying.

>> If I run "git log u-boot-xxx/master", and look backwards through the
>> list of commits, looking for those committed by the owner of u-boot-xxx,
> 
> Who cares about the comitter?  This is just a technical act.  It makes
> zero difference whether I apply a patch or somebody else applies the
> same.

Well, if git tells me someone committed something, it should be right. I
could apply just the same argument to writing the code; who cares who
wrote it so long as it's in the code-base?

Your assertion is probably coupled with U-Boot's interpretation of the
Signed-off-by tag too. Linux requires both the original author and each
committer/cherry-picker to sign-off the commit to document the entire
path the commit went through, In that scenario, a commit that has the
git committer field set to some value yet the last Signed-off-by entry
isn't that person is a red flag. Hence, the git committer field is
important.

However, U-Boot is reported to only use Signed-off to indicate the
original author(s), so I can see how the git committer field isn't
considered important in U-Boot. I'm not convinced it's a good idea to be
so cavalier about git metadata though; wouldn't it be better to take
simple steps (never rebase any other committer's commits) so that the
metadata is always correct?

>> and stop when I see a commit by someone else, I'll end up stopping at
>> the merge commit where u-boot/master was merged back down. If there
>> commits to u-boot-xxx/master between the point where u-boot/master
>> merged u-boot-xxx/master and where u-boot-xxx/master merged
>> u-boot/master back down, then they'll be hidden before that merge point.
> 
> I have to admit that I never ever cared about any merges before.  For
> me they happen because of that's the way how development goes, i. e.
> they cannot be avoided, but that's all.   I have only been interested
> in which commits have ben included, not which branch or repository
> these have been coming from.
> 
> Why would I need to know that?

Personally I believe it's a good idea to document the whole commit/merge
process fully. That's for all the same reasons that git contains
metadata for author, committer, datestamps, log messages, etc. The whole
point of source control is to document the development process;
otherwise, we could just publish the latest .tar and ignore git entirely.

...
>> Since u-boot/next appears to be a rolling/parallel model, where changes
>> can be pulled into it at arbitrary times even when u-boot/master is
>> being used to stabilize a release, the way to resolve conflicts for
>> U-Boot is simply to have the branch containing the dependency push their
>> /next into u-boot/next, then the branch needing the dependency to branch
>> from or merge u-boot/next into their /next, then apply the patch with
>> the dependency.
> 
> Sorry, I cannot parse this.

If you have two commits or series that depend on each-other, e.g. series
A introduces a new feature and series B makes use of that new feature,
and those two series must be applied to different downstream trees for
some reason, then the process would be:

1) commit series A to downstream branch X
2) pull downstream branch X into u-boot/next
3) either re-create downstream branch Y from u-boot/next, or merge
u-boot/next into existing downstream branch Y
4) commit series B to downstream branch Y

The thing that makes this work easily in U-Boot is that the pull request
into u-boot/next in (2) above can basically happen any time, so it's a
v

[U-Boot] Pull request: u-boot-arm/master to u-boot/master

[Albert ARIBAUD]

Hi Tom,

The following changes since commit
28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad:

  arm: armv7: temporarily set -mno-unaligned-access (2012-10-05
  21:24:22 +0200)

are available in the git repository at:

  git://git.denx.de/u-boot-arm master

for you to fetch changes up to 9b5dba537473578153961ee96ed23e37e1fde3f7:

  exynos4: universal_C210: use software SPI (2012-10-10 20:37:39 +0900)


Chander Kashyap (1):
  Exynos5250: Enable PXE Support

Piotr Wilczek (9):
  arm:exynos4:trats: Correct SDRAM configuration for trats
  arm:exynos4:trats: Fix SDRAM size
  arm:exynos4:pinmux: Modify the gpio function for mmc
  arm:exynos4:trats: Use pinmux for mmc configuration
  arm:exynos4:universal: Use pinmux for mmc configuration
  arm:exynos4:universal: Eliminated low level init
  arm: trats: Power down core 1
  drivers: spi: modify soft spi driver
  exynos4: universal_C210: use software SPI

Łukasz Majewski (1):
  gpio:fix: Proper handling of GPIO subsystem parts at Samsung
devices

 arch/arm/cpu/armv7/exynos/pinmux.c   |   58 
 arch/arm/include/asm/arch-exynos/gpio.h  |   19 ++
 arch/arm/include/asm/arch-exynos/periph.h|1 +
 arch/arm/include/asm/arch-s5pc1xx/gpio.h |7 +-
 board/samsung/trats/trats.c  |   80 ++
 board/samsung/universal_c210/Makefile|1 -
 board/samsung/universal_c210/lowlevel_init.S |  395
 --
 board/samsung/universal_c210/universal.c |  116 
 drivers/gpio/s5p_gpio.c  |6 +-
 drivers/spi/soft_spi.c   |3 +
 include/configs/s5pc210_universal.h  |   21 ++
 include/configs/smdk5250.h   |6 +
 include/configs/trats.h  |   17 +- 13 files
 changed, 209 insertions(+), 521 deletions(-) delete mode 100644
 board/samsung/universal_c210/lowlevel_init.S

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] please pull u-boot-samsung master

[Albert ARIBAUD]

Hi Minkyu,

On Wed, 10 Oct 2012 21:16:16 +0900, Minkyu Kang 
wrote:

> Dear Albert,
> 
> The following changes since commit 28e5ac2d974547bde0c72aa0c1d66fd22c6ef3ad:
> 
>   arm: armv7: temporarily set -mno-unaligned-access (2012-10-05 21:24:22 
> +0200)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-samsung master
> 
> for you to fetch changes up to 9b5dba537473578153961ee96ed23e37e1fde3f7:
> 
>   exynos4: universal_C210: use software SPI (2012-10-10 20:37:39 +0900)
> 
> 
> Chander Kashyap (1):
>   Exynos5250: Enable PXE Support
> 
> Piotr Wilczek (9):
>   arm:exynos4:trats: Correct SDRAM configuration for trats
>   arm:exynos4:trats: Fix SDRAM size
>   arm:exynos4:pinmux: Modify the gpio function for mmc
>   arm:exynos4:trats: Use pinmux for mmc configuration
>   arm:exynos4:universal: Use pinmux for mmc configuration
>   arm:exynos4:universal: Eliminated low level init
>   arm: trats: Power down core 1
>   drivers: spi: modify soft spi driver
>   exynos4: universal_C210: use software SPI
> 
> Łukasz Majewski (1):
>   gpio:fix: Proper handling of GPIO subsystem parts at Samsung devices
> 
>  arch/arm/cpu/armv7/exynos/pinmux.c   |   58 
>  arch/arm/include/asm/arch-exynos/gpio.h  |   19 ++
>  arch/arm/include/asm/arch-exynos/periph.h|1 +
>  arch/arm/include/asm/arch-s5pc1xx/gpio.h |7 +-
>  board/samsung/trats/trats.c  |   80 ++
>  board/samsung/universal_c210/Makefile|1 -
>  board/samsung/universal_c210/lowlevel_init.S |  395 
> --
>  board/samsung/universal_c210/universal.c |  116 
>  drivers/gpio/s5p_gpio.c  |6 +-
>  drivers/spi/soft_spi.c   |3 +
>  include/configs/s5pc210_universal.h  |   21 ++
>  include/configs/smdk5250.h   |6 +
>  include/configs/trats.h  |   17 +-
>  13 files changed, 209 insertions(+), 521 deletions(-)
>  delete mode 100644 board/samsung/universal_c210/lowlevel_init.S
> 

Applied to u-boot-arm/master, thanks!

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 2/2] fs: add partition switch libary, implement ls and fsload commands

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/10/12 17:05, Stephen Warren wrote:
> From: Stephen Warren 
> 
> Implement "ls" and "fsload" commands that act like 
> {fat,ext2}{ls,load}, and transparently handle either file-system. 
> This scheme could easily be extended to other filesystem types; I 
> only didn't do it for zfs because I don't have any filesystems of 
> that type.
> 
> Signed-off-by: Stephen Warren  --- There are a
>  couple FIXMEs in here:
> 
> 1) In fs/fs.c, code is ifdef on CONFIG_CMD_FAT or CONFIG_CMD_EXT2.
>  This means that the new commands and code can only be enabled if 
> the "legacy" {fat,ext2}{ls,load} are enabled. What we really want 
> is CONFIG_FS_FAT and CONFIG_FS_EXT2 to enable the filesystem code,
>  and then CONFIG_CMD_FAT, CONFIG_CMD_EXT2, CONFIG_CMD_FS to only 
> affect the command implementations. However, that would require 
> making every include/config/*.h that sets the current defines also
>  set more. I suppose that's a fairly mechanical change though, so 
> easy enough to implement. Does that seem like a reasonable approach
> to people?

How about a new CONFIG_CMD_GENERIC_FS for the new ls/fsload (and any
later commands like write that get added) and once most filesystems
are converted we can think about a transition plan?

> 2) In common/Makefile, I need to make this conditional upon 
> CONFIG_CMD_FS or similar.
> 
> Also, I wonder if the fs/* and common/* should be two separate 
> patches or not?

One is fine.

- -- 
Tom

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQdvgNAAoJENk4IS6UOR1Wx3gP/iRvYq0khe6ZPRbUcPyTg0r8
tkNJGfglXba52GHjU6URwSrPbN9qOHzh6fD0x26jOdj1vWlMv6nvwmyo3ttvyRLe
4VF7tvTRp3Zv461vGwm8XwAXlDXVrnsWeC4veWxo+/ptFaq2FTWYTVNo2MsqHSIN
VNnxMdgtqUIU2kgx0uJst1Fl3olDaRlQmyf88SiRE2et21FQytk/LxAc50zmNr5J
UWgVgzoUP+RnZwnZK2CWL9cAuGbEyLjQvoKK8V72dMvKzZgMFpyMEdk0+onKFYe1
Byai7INodWIhWrtQj4nGC/1WQC+kCteMvF3OTjuGY/bfDPqLYx3071kocrgYWSW4
URvvdv6hn1l+evN5BQ1erwAekwfgrfcKkavJwmuVES3ZESrEyComqWEjajqeTe/6
uIpZo58oFGojJZK1HcDmaVFyj7nxAzXloupmHiKq+xfXHbv60ZUZO6InEos/ZCjZ
bpT92wyyqTeiD70glLvLRyStKzZidqeoVTkbGM0XUCA3d3RvxXdB4zfgIqDlhhCT
EfhxKVkAZAzjsEn+U1/y5RWEEdD+Zaqi2xKwA+Ken9TJ4LFsjcOiQDPVZYklD7qu
Xmte9GdxL4tSipu0hWxrkRjO7ap09wUoEk1d0jNSrwNbJALnUUkT4qfpYXcMaAhe
okjWSANQaBZxbM0ziEoT
=AnRj
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model (was: Re: [PULL] u-boot-usb/next)

[Tom Rini]

On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
[snip]
> > The problem with rebasing when pulling is that git commit IDs change,
> > so it's much more difficult to determine when a commit is merged into
> > a parent tree; one has to search by commit subject rather than just
> > executing e.g. git branch -a --contains XXX. I thought Albert just
> > agreed to use merges rather than rebases for u-boot-arm for this and
> > perhaps other reasons.
> 
> The short answer is that right now, u-boot/next follows the linux-next
> model and we rebase as needed.

I'm going to reply to myself, in hopes of clearing things up.  We don't
follow the linux-next model, really, I miss-spoke.

History is important.  But so is getting the amount of process for the
size of the project.  The other thing is that we're doing simultaneous
development for both the current release and the next release.

So for the master branch of the master repo, it must never rebase.  And
as Wolfgang encourages users to use the custodian repository of mainline
isn't quite up to what they need, custodian repositories must also keep
their master branch un-rebased as much as humanly possible (my rule of
thumb would be once it's been in the wild for a few days, it's too
late).

The next branch however can be rebased, as needed.  In the case of
post-v2012.10, it will be rebased as we want the commit to change how
ARM and unaligned accesses are handled to be the first thing.  I don't
think "perfect" "changes A-G were done in repository X against tree Y"
is the most useful bit of information.  When we rebase we may lose that
boards 1/2/3 worked at point Y but we gain change D is when board 2
broke as part of being merged with other changes.

-- 
Tom


signature.asc
Description: Digital signature
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Albert ARIBAUD]

Hi Scott,

On Wed, 10 Oct 2012 17:02:18 -0500, Scott Wood
 wrote:

> Ideally once a pull request happens the pull happens quickly.  If that  
> doesn't happen, you could reply to the pull request asking that it be  
> ignored in favor of a new pull request, or create a new temporary  
> branch.  IMHO pull requests ought to request a pull of a specific SHA1  
> along with the branch name (it'd be nice if the command to pull could  
> verify that the SHA1 is in the history of the branch name, and include  
> the branch name in the commit message, but merge based on the SHA1).

Note that for recent enough versions of git, request-pull will indicate
the last commit ID to pull, which makes it possible for them to keep
on adding to their branch once their PR is out. Not all U-Boot ARM
custodians have a recent enough git, mind.

Amicalement,
-- 
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc85xx debug TLB entry

[Scott Wood]

On 10/11/2012 04:01:27 AM, Prabhakar Kushwaha wrote:

On 10/11/2012 05:51 AM, Scott Wood wrote:
I'm debugging some SPL changes and am still having a hard time  
following the initial TLB flow.  We seem to be creating an entry in  
AS0 -- how is that not conflicting with the TLB entry we're running  
from?


The behaviour of overlapping TLB entries is undefined for e500v2  
processor.
Luckily it is working for P1010RDB, P1020RDB, P2020RDB-PC and  
BSC9131RDB.



Why is the debug TLB 256K?  Why is it not aligned to 256K?


Temp TLB  is created because label "nexti"  resize  the current TLB  
to 4K. So create one for debugging with CONFIG_SYS_MONITOR_BASE.
Although we are creating TLB entry for 0x11001000 but actual TLB  
entry is created with 0x1100,256K aligned. Same is verified from  
debugger.


You shouldn't rely on the hardware to ignore the lower bits of the  
address.


Why does it need to be 256K?

How do you know that MAS2_I is correct (it should be cacheable in  
the loaded-by-spl case)?


I set it as MAS2_I because same is done while creating AS1 TLB  
entries for CONFIG_SYS_MONITOR_BASE during CONFIG_SYS_RAMBOOT.




I'm trying to get the p2020rdb-pca SPL payload to run out of L2  
SRAM, and I see weird TLB behavior causing a hang if I don't comment  
out the debug TLB.




is the root cause MAS2_I or 256K TLB entries created?


It's not MAS2_I, as it happens even when I have all the other SRAM  
mappings cache inhibited.  I don't know what the root cause is.


The proper solution would be to create temp Debug TLB for  
CONFIG_SYS_RAMBOOT after resizing current TLB to 4K.

Please suggest.


I suggest you do so. :-)

In the meantime, I'll remove it for RAMBOOT/SPL as it's broken.

-Scott
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC PATCH 2/2] fs: add partition switch libary, implement ls and fsload commands

[Benoît Thébaudeau]

Hi Stephen,

On Thursday, October 11, 2012 2:05:07 AM, Stephen Warren wrote:
> Implement "ls" and "fsload" commands that act like
> {fat,ext2}{ls,load},
> and transparently handle either file-system. This scheme could easily
> be
> extended to other filesystem types; I only didn't do it for zfs
> because
> I don't have any filesystems of that type.
> 
> Signed-off-by: Stephen Warren 
> ---
> There are a couple FIXMEs in here:
> 
> 1) In fs/fs.c, code is ifdef on CONFIG_CMD_FAT or CONFIG_CMD_EXT2.
> This
> means that the new commands and code can only be enabled if the
> "legacy"
> {fat,ext2}{ls,load} are enabled. What we really want is CONFIG_FS_FAT
> and
> CONFIG_FS_EXT2 to enable the filesystem code, and then
> CONFIG_CMD_FAT,
> CONFIG_CMD_EXT2, CONFIG_CMD_FS to only affect the command
> implementations.
> However, that would require making every include/config/*.h that sets
> the
> current defines also set more. I suppose that's a fairly mechanical
> change
> though, so easy enough to implement. Does that seem like a reasonable
> approach to people?

What about making CONFIG_CMD_ auto-define CONFIG_FS_, just like with a
Kconfig select?

> 2) In common/Makefile, I need to make this conditional upon
> CONFIG_CMD_FS
> or similar.
> 
> Also, I wonder if the fs/* and common/* should be two separate
> patches or
> not?

For me, it's fine as a single patch.

>  Makefile|3 +-
>  common/Makefile |2 +
>  common/cmd_fs.c |   86 ++
>  fs/Makefile |   47 
>  fs/fs.c |  216
>  +++
>  include/fs.h|   49 +
>  6 files changed, 402 insertions(+), 1 deletions(-)
>  create mode 100644 common/cmd_fs.c
>  create mode 100644 fs/Makefile
>  create mode 100644 fs/fs.c
>  create mode 100644 include/fs.h
> 
> diff --git a/Makefile b/Makefile
> index d7e2c2f..0b50eb7 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -242,7 +242,8 @@ LIBS-y += drivers/net/npe/libnpe.o
>  endif
>  LIBS-$(CONFIG_OF_EMBED) += dts/libdts.o
>  LIBS-y += arch/$(ARCH)/lib/lib$(ARCH).o
> -LIBS-y += fs/cramfs/libcramfs.o \
> +LIBS-y += fs/libfs.o \
> + fs/cramfs/libcramfs.o \
>   fs/ext4/libext4fs.o \
>   fs/fat/libfat.o \
>   fs/fdos/libfdos.o \
> diff --git a/common/Makefile b/common/Makefile
> index 125b2be..4f2d944 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -103,6 +103,8 @@ COBJS-$(CONFIG_CMD_FLASH) += cmd_flash.o
>  ifdef CONFIG_FPGA
>  COBJS-$(CONFIG_CMD_FPGA) += cmd_fpga.o
>  endif
> +# FIXME: Need to make this conditional
> +COBJS-y += cmd_fs.o
>  COBJS-$(CONFIG_CMD_GPIO) += cmd_gpio.o
>  COBJS-$(CONFIG_CMD_I2C) += cmd_i2c.o
>  COBJS-$(CONFIG_CMD_IDE) += cmd_ide.o
> diff --git a/common/cmd_fs.c b/common/cmd_fs.c
> new file mode 100644
> index 000..948a5e0
> --- /dev/null
> +++ b/common/cmd_fs.c
> @@ -0,0 +1,86 @@
> +/*
> + * Copyright (c) 2012, NVIDIA CORPORATION.  All rights reserved.
> + *
> + * Inspired by cmd_ext_common.c, cmd_fat.c.
> + *
> + * This program is free software; you can redistribute it and/or
> modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope it will be useful, but
> WITHOUT
> + * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or
> + * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
> License for
> + * more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see
> .
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +int do_fsload(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> argv[])
> +{
> + unsigned long addr;
> + unsigned long bytes;
> + unsigned long pos;
> + int len_read;
> + char buf[12];
> +
> + if (argc < 5)
> + return -1;

What about "return CMD_RET_USAGE;"?

> +
> + if (fs_set_blk_dev(argv[1], argv[2]))
> + return 1;
> +
> + addr = simple_strtoul(argv[3], NULL, 0);
> + if (argc >= 6)
> + bytes = simple_strtoul(argv[5], NULL, 0);
> + else
> + bytes = 0;
> + if (argc >= 7)
> + pos = simple_strtoul(argv[6], NULL, 0);
> + else
> + pos = 0;
> +
> + len_read = fs_read(argv[4], addr, pos, bytes);
> + if (len_read <= 0)
> + return 1;
> +
> + sprintf(buf, "0x%x", (unsigned int)len_read);
> + setenv("filesize", buf);
> +
> + return 0;
> +}
> +
> +U_BOOT_CMD(
> + fsload, 7,  0,  do_fsload,
> + "load binary file from a filesystem",
> + " []   [bytes [pos]]\n"
> + "- Load binary file 'filename' from partition 'part' on
> device\n"
> + "   type 'interface' instance 'dev' to address 'addr' in
> memory.\n"
> + "  'bytes' gives the size to load in bytes.\n"
> + "  If 'bytes' is 0 or om

Re: [U-Boot] U-Boot git usage model

[Jason Cooper]

On Thu, Oct 11, 2012 at 09:19:22AM +0200, Wolfgang Denk wrote:
> Dear Stephen Warren,
> 
> In message <5075f48a.2080...@wwwdotorg.org> you wrote:
> >
> > I believe that's (part of) why Linux is tending towards pull requests of
> > a (signed) tag rather than a branch, since the tag always points at a
> > specific commit, and incremental pull requests can just create a new tag
> > name. Of course, the ability to sign tags also also a motivator.
> 
> I tend to disagree here. Tags can easily be removed. As such, they
> are in no way different from or better than a specific commit in a
> branch that does not get rebased.

I agree with Wolfgang, I move signed tags around all the time _before_ I
push to a public branch.  That tends to happen because I'm still
learning the process, *not* as a part of a proper workflow.

For me, signed tags serve two purposes.  The first is sub-maintainer
verification.  Arnd Bergmann and Olof Johansson both signed my gpg key
at the last Kernel Summit.  So, when they pull a branch, they know I
created it.  Second, using git v1.7.9 and newer, request-pull will
insert the tag message into the body of the pull-request.  This provides
a nice summary of the branch in the email, as opposed to the branch-name
chaos we see now.  This summary, stays with the branch regardless of the
number of times the maintainer merges it.

I suppose there is a third advantage.  The signed tag is attached to a
specific sha1 commit.  If a maintainer inadvertently changes the commit
history of a branch by doing a rebase or similar, the tag would
disappear from the tip of the branch.  Kind of like the canary in the
mine.

Which brings me to another point I haven't seen mentioned in this thread
yet, git-rerere (1).  Arnd and Olof make extensive use of this command
to remember how they have resolved merge conflicts.  afaict, since I
don't need it at my level, they are continuously merging branches over
and over again.  Against new branches, new versions of widespread
changes (iomem, platform_data in the last window).  rerere makes that
workload possible.

hth,

Jason.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM926: Add mb to the cache invalidate/flush

[Marek Vasut]

Dear Albert ARIBAUD,

> Hi Marek,
> 
> On Wed, 10 Oct 2012 00:44:29 +0200, Marek Vasut  wrote:
> > Add memory barrier to cache invalidate and flush calls.
> 
> Memory barrier...
> 
> "You keep using that word. I do not think it means what you think it
> means." :)
> 
> A memory barrier's effect is only that all of the volatile accesses
> placed before it in the source code finish when the barrier executes,
> and that none of the volatile accesses placed after it in the source
> code starts before the barrier has executed.
> 
> Non-volatile accesses are not guaranteed to stay on one side of the
> barrier, and the barrier itself is not guaranteed to stay put during
> optimizations.
> 
> If what you intended was to ensure that e.g. all writes be finished
> when a flush occurs

Yes, that's pretty much it. To ensure that all writes to the flushed memory 
area 
are finished before the flushing happens.

> or that no read happens before an invalide has
> executed, then adding memory clobbers is not an adequate solution.

What do you suggest?

> If you were aiming for something else entirely, please don't hesitate
> to develop a description of the problem you wish to solve.
> 
> Amicalement,

Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V3 17/32] imximage.cfg: run files through C preprocessor

[Stefano Babic]

Am 10/10/2012 04:03, schrieb Troy Kisky:
> On 10/8/2012 6:38 AM, Stefano Babic wrote:
>> On 04/10/2012 03:47, Troy Kisky wrote:
>>> The '#' used as comments in the files cause the preprocessor
>>> trouble, so change to /* */.
>>>
>>> Signed-off-by: Troy Kisky 
>>> ---
>> Hi Troy,
>>
>>>   Makefile |3 +-
>>>   board/esg/ima3-mx53/imximage.cfg |  120 ++-
>>>   board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg |   90 
>>>   board/freescale/mx25pdk/imximage.cfg |   77 +++
>>>   board/freescale/mx51evk/imximage.cfg |  114 +-
>>>   board/freescale/mx53ard/imximage_dd3.cfg |   83 
>>>   board/freescale/mx53evk/imximage.cfg |   86 
>>>   board/freescale/mx53loco/imximage.cfg|   83 
>>>   board/freescale/mx53smd/imximage.cfg |   83 
>>>   board/freescale/mx6qarm2/imximage.cfg|   88 
>>>   board/genesi/mx51_efikamx/imximage_mx.cfg|  132 ++--
>>>   board/genesi/mx51_efikamx/imximage_sb.cfg|  126 +--
>>>   board/ttcontrol/vision2/imximage_hynix.cfg   |  295
>>> ++
>>>   13 files changed, 727 insertions(+), 653 deletions(-)
>>>
>> I see the C preprocessor as an optional feature, instead of a rule
>> everybody must follow.
>>
>>> diff --git a/Makefile b/Makefile
>>> index a40d4cc..64ff1b8 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -431,7 +431,8 @@ $(obj)u-boot.img:$(obj)u-boot.bin
>>>   -d $< $@
>>> $(obj)u-boot.imx:   $(obj)u-boot.bin
>>> -$(obj)tools/mkimage -n  $(CONFIG_IMX_CONFIG) -T imximage \
>>> +$(CC) -E -x c $(CONFIG_IMX_CONFIG) -I./include -o
>>> $(obj)imxcfg.imx
>>> +$(obj)tools/mkimage -n  $(obj)imxcfg.imx -T imximage \
>>>   -e $(CONFIG_SYS_TEXT_BASE) -d $< $@
>> In fact, adding this rule here requires that each board configuration
>> must be changed. And for all of them, running the preprocessor is
>> unnnecessary.
>>
>> What about to add this rule only to the Makefile of the boards that
>> require preprocessing ?
>>
>> Best regards,
>> Stefano Babic
>>
> How about this to do the job
> 
> 
> 
> 
> 
> Subject: [PATCH 17/32] boards.cfg: run mx6q_4x_mt41j128.pcfg through C
>  preprocessor
> 
> The '#' used as comments in the cfg file cause the preprocessor
> trouble, so change to /* */. Also, rename mx6q_4x_mt41j128.cfg
> to mx6q_4x_mt41j128.pcfg.
> 
> Files with extension of .pcfg are run through the preprocessor
> before being given to mkimage.
> 
> Signed-off-by: Troy Kisky 
> 
> ---
> v4: Don't run every file through preprocessor, only .pcfg files
> ---
>  .gitignore |1 +
>  Makefile   |   16 +++-
>  ...{mx6q_4x_mt41j128.cfg => mx6q_4x_mt41j128.pcfg} |   90
> ++--
>  boards.cfg |4 +-
>  4 files changed, 63 insertions(+), 48 deletions(-)
>  rename board/freescale/imx/ddr/{mx6q_4x_mt41j128.cfg =>
> mx6q_4x_mt41j128.pcfg} (65%)
> 
> diff --git a/.gitignore b/.gitignore
> index d91e91b..e5273bd 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -15,6 +15,7 @@
>  *.swp
>  *.patch
>  *.bin
> +*.pcfgtmp
> 
>  # Build tree
>  /build-*
> diff --git a/Makefile b/Makefile
> index a40d4cc..99666b9 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -430,8 +430,17 @@ $(obj)u-boot.img:  $(obj)u-boot.bin
> sed -e 's/"[ ]*$$/ for $(BOARD) board"/') \
> -d $< $@
> 
> -$(obj)u-boot.imx:   $(obj)u-boot.bin
> -   $(obj)tools/mkimage -n  $(CONFIG_IMX_CONFIG) -T imximage \
> +ifeq ($(suffix $(patsubst "%",%,$(CONFIG_IMX_CONFIG))),.pcfg)
> +$(obj)$(patsubst "%",%,$(CONFIG_IMX_CONFIG))tmp: %.pcfgtmp : %.pcfg
> +   $(CC) -E -x c $< -I./include -o $@
> +
> +$(obj)u-boot.imx: %.imx : %.bin $(obj)$(patsubst
> "%",%,$(CONFIG_IMX_CONFIG))tmp
> +else
> +$(obj)u-boot.imx: %.imx : %.bin $(patsubst "%",%,$(CONFIG_IMX_CONFIG))
> +endif
> +
> +$(obj)u-boot.imx:
> +   $(obj)tools/mkimage -n  $(filter-out %.bin,$^) -T
> imximage \
> -e $(CONFIG_SYS_TEXT_BASE) -d $< $@
> 

Does it work something more direct (I have not tested, really...) ?

In board Makefile, for example board/freescale/mx6qsabrelite, a rule for
the imximage file:

$(CONFIG_IMX_CONFIG): 
$(CC) -E -x c $< -I./include -o $@

And let unchanged in the main Makefile. So CONFIG_IMX_CONFIG is produced
and you do not need to change logic in the main Makefile.

Regards,
Stefano

-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
_

Re: [U-Boot] [PATCH] net: Add tftp speed indication

[Igor Grinberg]

On 10/11/12 02:03, Simon Glass wrote:
> This prints a tftp speed indication after the download completes. This
> is the 3.6 MiB/s indicator below.
> 
> To enable this, define CONFIG_TFTP_SPEED in your board config.

This is relatively small (and nice) addition to the tftpboot command.
Do we really need to introduce yet another config option for this?
Can this be just added with no need to specify the config option?

> 
> Tegra2 (SeaBoard) # tftp ...
> Using asx0 device
> TFTP from server 172.22.72.144; our IP address is 172.22.73.81
> Filename '/tftpboot/uImage-user-seaboard-1'.
> Load address: 0x408000
> Loading: #  3.6 MiB/s
> done
> 
> Signed-off-by: Simon Glass 
> ---
>  README |9 +
>  net/tftp.c |   15 +++
>  2 files changed, 24 insertions(+), 0 deletions(-)
> 
> diff --git a/README b/README
> index 0d17e7d..f754bd5 100644
> --- a/README
> +++ b/README
> @@ -2349,6 +2349,15 @@ The following options need to be configured:
>   A better solution is to properly configure the firewall,
>   but sometimes that is not allowed.
>  
> +- TFTP Speed:
> + CONFIG_TFTP_SPEED
> +
> + If this is defined, the approximate download speed of the
> + tftp operation will be displayed after the # progress
> + markers, like this:
> +
> + Loading: ### (more #)   3.6 MiB/s
> +
>  - Show boot progress:
>   CONFIG_SHOW_BOOT_PROGRESS
>  
> diff --git a/net/tftp.c b/net/tftp.c
> index 59a8ebb..59161db 100644
> --- a/net/tftp.c
> +++ b/net/tftp.c
> @@ -41,6 +41,10 @@
>  static ulong TftpTimeoutMSecs = TIMEOUT;
>  static int TftpTimeoutCountMax = TIMEOUT_COUNT;
>  
> +#ifdef CONFIG_TFTP_SPEED
> +static ulong time_start;   /* Record time we started tftp */
> +#endif
> +
>  /*
>   * These globals govern the timeout behavior when attempting a connection to 
> a
>   * TFTP server. TftpRRQTimeoutMSecs specifies the number of milliseconds to
> @@ -299,6 +303,14 @@ static void tftp_complete(void)
>   TftpNumchars++;
>   }
>  #endif
> +#ifdef CONFIG_TFTP_SPEED
> + time_start = get_timer(time_start);
> + if (time_start > 0) {
> + puts("  ");
> + print_size(NetBootFileXferSize /
> + time_start * 1000, "/s");
> + }
> +#endif
>   puts("\ndone\n");
>   net_set_state(NETLOOP_SUCCESS);
>  }
> @@ -775,6 +787,9 @@ void TftpStart(enum proto_t protocol)
>   TftpState = STATE_SEND_RRQ;
>   }
>  
> +#ifdef CONFIG_TFTP_SPEED
> + time_start = get_timer(0);
> +#endif
>   TftpTimeoutCountMax = TftpRRQTimeoutCountMax;
>  
>   NetSetTimeout(TftpTimeoutMSecs, TftpTimeout);

-- 
Regards,
Igor.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/3] mx25pdk: Add esdhc support

[Benoît Thébaudeau]

On Thursday, October 11, 2012 9:17:46 AM, Stefano Babic wrote:
> Am 11/10/2012 05:58, schrieb Fabio Estevam:
> > From: Fabio Estevam 
> > 
> > mx25pdk has a SD/MMC slot connected to esdhc1.
> > 
> > Add support for it and allow the environment variables to be saved
> > into SD/MMC.
> > 
> > Signed-off-by: Fabio Estevam 
> > ---
> 
> Hi Fabio,
> 
> >  board/freescale/mx25pdk/mx25pdk.c |   51
> >  +
> >  include/configs/mx25pdk.h |   16 +++-
> >  2 files changed, 66 insertions(+), 1 deletion(-)
> > 
> > diff --git a/board/freescale/mx25pdk/mx25pdk.c
> > b/board/freescale/mx25pdk/mx25pdk.c
> > index 4a8352f..e850b3e 100644
> > --- a/board/freescale/mx25pdk/mx25pdk.c
> > +++ b/board/freescale/mx25pdk/mx25pdk.c
> > @@ -19,12 +19,23 @@
> >  
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> > +#include 
> > +
> > +#define CARD_DETECTIMX_GPIO_NR(2, 1)
> >  
> >  DECLARE_GLOBAL_DATA_PTR;
> >  
> > +#ifdef CONFIG_FSL_ESDHC
> > +struct fsl_esdhc_cfg esdhc_cfg[1] = {
> > +   {IMX_MMC_SDHC1_BASE},
> > +};
> > +#endif
> > +
> >  int dram_init(void)
> >  {
> > /* dram_init must store complete ramsize in gd->ram_size */
> > @@ -48,6 +59,46 @@ int board_init(void)
> > return 0;
> >  }
> >  
> > +#ifdef CONFIG_FSL_ESDHC
> > +int board_mmc_getcd(struct mmc *mmc)
> > +{
> > +   struct iomuxc_mux_ctl *muxctl;
> > +   struct iomuxc_pad_ctl *padctl;
> > +   u32 gpio_mux_mode = MX25_PIN_MUX_MODE(5);
> > +
> > +   /*
> > +* Set up the Card Detect pin.
> > +*
> > +* SD1_GPIO_CD: gpio2_1 is ALT 5 mode of pin A15
> > +*
> > +*/
> > +   muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
> > +   padctl = (struct iomuxc_pad_ctl *)IMX_IOPADCTL_BASE;
> > +
> > +   writel(gpio_mux_mode, &muxctl->pad_a15);
> > +   writel(0x0, &padctl->pad_a15);
> > +
> > +   gpio_direction_input(CARD_DETECT);
> > +   return !gpio_get_value(CARD_DETECT);
> > +}
> > +
> > +int board_mmc_init(bd_t *bis)
> > +{
> > +   struct iomuxc_mux_ctl *muxctl;
> > +   u32 sdhc1_mux_mode = MX25_PIN_MUX_MODE(0) | MX25_PIN_MUX_SION;
> > +
> > +   muxctl = (struct iomuxc_mux_ctl *)IMX_IOPADMUX_BASE;
> > +   writel(sdhc1_mux_mode, &muxctl->pad_sd1_cmd);
> > +   writel(sdhc1_mux_mode, &muxctl->pad_sd1_clk);
> > +   writel(sdhc1_mux_mode, &muxctl->pad_sd1_data0);
> > +   writel(sdhc1_mux_mode, &muxctl->pad_sd1_data1);
> > +   writel(sdhc1_mux_mode, &muxctl->pad_sd1_data2);
> > +   writel(sdhc1_mux_mode, &muxctl->pad_sd1_data3);
> > +
> 
> You need also to set up the SDHC clock. This comes after merging:
> 
>   http://patchwork.ozlabs.org/patch/188329/
> 
> Adding
>   esdhc_cfg.sdhc_clk = mxc_get_clock(MXC_ESDHC1_CLK);
> 
> before calling fsl_esdhc_initialize() should be enough.

Adding
#include 
is also needed.

Best regards,
Benoît
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot git usage model

[Albert ARIBAUD]

Hi Stephen,

> >> It provides documentation in the git history of when merges were made,
> >> and what the source of the merge was (at least using the remote name
> >> that the merger has configured, which is better than nothing).
> > 
> > This is what it provides, but this does not tell me why it is a good
> > thing. My own use of git history is to find out which (local or remote)
> > branch --contains a given commit, and this is insensitive to allowing
> > ff merges or not.
> 
> The documentation of merge commits seems good to me just in an of itself.

"It's intrinsically good" sounds like a circular or axiomatic
justification to me.

> >> Related, not rebasing when merging a branch into upstream makes
> >> validating Signed-off-by a lot easier; when a patch is directly applied,
> >> it should be Signed-off-by the person who applied it. When a person does
> >> a rebase rather than a merge, the git committer for the commits is
> >> re-written as if the person doing the rebase applied the patch. Instead
> >> when merging (and disallowing fast-forward) a merge commit is always
> >> created so it's obvious where S-o-b should be applied (direct patch
> >> application) and where not (to commits that are merged).
> > 
> > I think we've got several things running here: merges with or without
> > ffs, hiding patches inside a merge (IIUC) and committer identity.
> > 
> > Re hiding patches in a merge if that's really what you mean, I agree
> 
> Hiding patches within merges wasn't something I'd considered at all; I
> just assumed that would never happen.

Good. Since we agree that patches never get hidden in merge commits,
then each patch always has its own commit with its "by" tags.

> ...
> > Re committer identity, I don't see the relationship with "by" tags, and
> > especially with Singed-off-by, since the sign-off is not and must not
> > be related to the committer of the patch, but to its author(s).
> 
> At least the way the Linux kernel uses the tag, both the original author
> of the patch /and/ anyone who applies the patch, cherry-picks the patch,
> ... must add their S-o-b line. I think U-Boot isn't using that part of
> the model.

No, it isn't. IIUC, U-Boot's "Signed-off-by" is supposed to mean "I
am (one of) the autor(s) of this patch".

> ...
> >>> Re merging from upstream back into downstream branches, I tend to think
> >>> that must be allowed considering custodian trees are supposed to be
> >>> useable, and as such may need to merge back from mainline.
> >>
> >> Why is that required for downstream trees to be usable? What is the
> >> definition of "usable" you're using?
> > 
> > See
> > :
> > 
> > "My idea of a custodian repository is that it is more than just a
> > working tool for collecting patches and preparing these for merge into
> > mainline. My idea is instead that these are pretty much independent
> > incarnations of U-Boot source trees which users (note: users, not only
> > developers) with specific needs or interests can refer to."
> 
> Hmmm. That makes custodian trees very multi-purpose; they have to both:
> 
> a) Be used for feeding patches upstream.
> b) Be a useful independent version of U-Boot.
> 
> That seems like conflating two pretty different requirements. I'm
> personally not sure that's a good idea.

Actually, b) is correct but a) is not how I would have expressed it, if
only because u-boot itself is a custodian tree, and u-boot-arm is both
feeding mainline and fed by other trees. How I would express it is that
a custodian tree:

a) feeds *from* patches and pulls (actually, fetches) from other
custodian trees;

b) is a useful independent (i.e. functional) U-Boot tree.

> Now, obviously the custodian trees should be buildable and run fine on
> all platforms; patches shouldn't break functionality. But, I don't think
> that any tree either that u-boot.git should be seen as somewhere you'd
> expect to be able to use a combination of features from different
> custodian trees before they're merged into u-boot.git, which is what the
> description above implies to me.

You're overspecifying the definition I showed you. It does not say
custodian trees should provide "a combination of features from
different custodian trees before they're merged into u-boot.git"; it
only says they should be "independent incarnations of U-Boot source
trees which users (note: users, not only developers) with specific
needs or interests can refer to". Not a word about having to combine
features. This you /can/ do, of course, in a custodian tree; but they
are not done for this purpose.

> ...
> > You may be making the point that next should be handled just as master
> > as far as the process I laid out can apply to next as well as master
> > only one release further -- and I might understand this. "Master" for
> > coming release, "next" for next release when merge window is closed,
> > and unruly topical branches for anythingth

Re: [U-Boot] mpc85xx debug TLB entry

[Prabhakar Kushwaha]

On 10/11/2012 05:51 AM, Scott Wood wrote:
I'm debugging some SPL changes and am still having a hard time 
following the initial TLB flow.  We seem to be creating an entry in 
AS0 -- how is that not conflicting with the TLB entry we're running from? 


The behaviour of overlapping TLB entries is undefined for e500v2 processor.
Luckily it is working for P1010RDB, P1020RDB, P2020RDB-PC and BSC9131RDB.

Why is the debug TLB 256K?  Why is it not aligned to 256K? 


Temp TLB  is created because label "nexti"  resize  the current TLB to 
4K. So create one for debugging with CONFIG_SYS_MONITOR_BASE.
Although we are creating TLB entry for 0x11001000 but actual TLB entry 
is created with 0x1100,256K aligned. Same is verified from debugger.


How do you know that MAS2_I is correct (it should be cacheable in the 
loaded-by-spl case)?


I set it as MAS2_I because same is done while creating AS1 TLB entries 
for CONFIG_SYS_MONITOR_BASE during CONFIG_SYS_RAMBOOT.




I'm trying to get the p2020rdb-pca SPL payload to run out of L2 SRAM, 
and I see weird TLB behavior causing a hang if I don't comment out the 
debug TLB.




is the root cause MAS2_I or 256K TLB entries created?

The proper solution would be to create temp Debug TLB for 
CONFIG_SYS_RAMBOOT after resizing current TLB to 4K.

Please suggest.

Regards,
Prabhakar




___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] mpc85xx debug TLB entry

[Prabhakar Kushwaha]

On 10/11/2012 05:51 AM, Scott Wood wrote:

I'm debugging some SPL changes and am still having a hard time
following the initial TLB flow.  We seem to be creating an entry in
AS0 -- how is that not conflicting with the TLB entry we're running from?


The behaviour of overlapping TLB entries is undefined for e500v2 processor.
Luckily it is working for P1010RDB, P1020RDB, P2020RDB-PC and BSC9131RDB.


Why is the debug TLB 256K?  Why is it not aligned to 256K?


Temp TLB  is created because label "nexti"  resize  the current TLB to 
4K. So create one for debugging with CONFIG_SYS_MONITOR_BASE.
Although we are creating TLB entry for 0x11001000 but actual TLB entry 
is created with 0x1100,256K aligned. Same is verified from debugger.



How do you know that MAS2_I is correct (it should be cacheable in the
loaded-by-spl case)?


I set it as MAS2_I because same is done while creating AS1 TLB entries 
for CONFIG_SYS_MONITOR_BASE during CONFIG_SYS_RAMBOOT.




I'm trying to get the p2020rdb-pca SPL payload to run out of L2 SRAM,
and I see weird TLB behavior causing a hang if I don't comment out the
debug TLB.



is the root cause MAS2_I or 256K TLB entries created?

The proper solution would be to create temp Debug TLB for 
CONFIG_SYS_RAMBOOT after resizing current TLB to 4K.

Please suggest.

Regards,
Prabhakar




___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/10] x86: Change board baud_rate to ulong

[Graeme Russ]

Hi Wolfgang,

On Oct 11, 2012 6:32 PM, "Wolfgang Denk"  wrote:
>
> Dear Simon Glass,
>
> In message <1349910781-32088-2-git-send-email-...@chromium.org> you wrote:
> > This is a ulong for some architectures and just unsigned for others.
> > Change x86 to be consistent.
>
> Given the limited range for this variable it makes no sense to use a
> long for this.  Please fix this the other way round, i. e. change the
> architectures that use a long.

Will unsigned hold 115200?

Regards,

Graeme
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/5] EXYNOS: Add Exynos4 I2C spacing

[Piotr Wilczek]

Hi Joonyoung,

> -Original Message-
> From: Joonyoung Shim [mailto:dofm...@gmail.com]
> Sent: Thursday, October 11, 2012 3:11 AM
> To: Piotr Wilczek
> Cc: u-boot@lists.denx.de; Kyungmin Park
> Subject: Re: [U-Boot] [PATCH 2/5] EXYNOS: Add Exynos4 I2C spacing
> 
> Hi, Protr.
> 
> 2012/9/24 Piotr Wilczek :
> > This patch add the spacing for i2c for Exynos4
> >
> > Signed-off-by: Piotr Wilczek 
> > Signed-off-by: Kyungmin Park 
> > CC: Minkyu Kang 
> > ---
> >  arch/arm/include/asm/arch-exynos/cpu.h |2 ++
> >  1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/arm/include/asm/arch-exynos/cpu.h
> > b/arch/arm/include/asm/arch-exynos/cpu.h
> > index 5056b37..b70273c 100644
> > --- a/arch/arm/include/asm/arch-exynos/cpu.h
> > +++ b/arch/arm/include/asm/arch-exynos/cpu.h
> > @@ -28,6 +28,8 @@
> >  #define EXYNOS4_ADDR_BASE  0x1000
> >
> >  /* EXYNOS4 */
> > +#define EXYNOS4_I2C_SPACING0x1
> > +
> 
> Also EXYNOS5_I2C_SPACING is 0x1, so how about define just
> EXYNOS_I2C_SPACING for both EXYNOS4 and EXYNOS5?
I agree it would simplify the code (s3c24x0_i2c driver). On the other hand,
for code readability, maybe it is better to keep them separate as we do so
with all defines for each Exynos.

> 
> >  #define EXYNOS4_GPIO_PART3_BASE0x0386
> >  #define EXYNOS4_PRO_ID 0x1000
> >  #define EXYNOS4_SYSREG_BASE0x1001
> > --
> > 1.7.5.4
> >
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot
> 
> 
> --
> - Joonyoung Shim

Best regards,
Piotr Wilczek


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 4/6] mpc83xx: add support for mpc8309

[Gerlando Falauto]

This processor, though very similar to other members of the
PowerQUICC II Pro family (namely 8308, 8360 and 832x), provides
yet another feature set than any supported sibling.

Signed-off-by: Gerlando Falauto 
---
 arch/powerpc/cpu/mpc83xx/cpu.c |1 +
 arch/powerpc/cpu/mpc83xx/cpu_init.c|3 +
 arch/powerpc/cpu/mpc83xx/speed.c   |   16 
 arch/powerpc/include/asm/global_data.h |2 +
 arch/powerpc/include/asm/immap_83xx.h  |   61 +
 arch/powerpc/include/asm/immap_qe.h|2 +-
 drivers/qe/qe.c|   21 +++--
 include/mpc83xx.h  |  153 
 8 files changed, 249 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/cpu.c b/arch/powerpc/cpu/mpc83xx/cpu.c
index 6635109..e64b0c3 100644
--- a/arch/powerpc/cpu/mpc83xx/cpu.c
+++ b/arch/powerpc/cpu/mpc83xx/cpu.c
@@ -56,6 +56,7 @@ int checkcpu(void)
u32 partid;
} cpu_type_list [] = {
CPU_TYPE_ENTRY(8308),
+   CPU_TYPE_ENTRY(8309),
CPU_TYPE_ENTRY(8311),
CPU_TYPE_ENTRY(8313),
CPU_TYPE_ENTRY(8314),
diff --git a/arch/powerpc/cpu/mpc83xx/cpu_init.c 
b/arch/powerpc/cpu/mpc83xx/cpu_init.c
index 76afba5..20d0600 100644
--- a/arch/powerpc/cpu/mpc83xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc83xx/cpu_init.c
@@ -268,6 +268,9 @@ void cpu_init_f (volatile immap_t * im)
 #ifdef CONFIG_SYS_SICRL
__raw_writel(CONFIG_SYS_SICRL, &im->sysconf.sicrl);
 #endif
+#ifdef CONFIG_SYS_GPR1
+   __raw_writel(CONFIG_SYS_GPR1, &im->sysconf.gpr1);
+#endif
 #ifdef CONFIG_SYS_DDRCDR /* DDR control driver register */
__raw_writel(CONFIG_SYS_DDRCDR, &im->sysconf.ddrcdr);
 #endif
diff --git a/arch/powerpc/cpu/mpc83xx/speed.c b/arch/powerpc/cpu/mpc83xx/speed.c
index 4ad3ec3..fb0f7aa 100644
--- a/arch/powerpc/cpu/mpc83xx/speed.c
+++ b/arch/powerpc/cpu/mpc83xx/speed.c
@@ -105,6 +105,8 @@ int get_clocks(void)
u32 tsec1_clk;
u32 tsec2_clk;
u32 usbdr_clk;
+#elif defined(CONFIG_MPC8309)
+   u32 usbdr_clk;
 #endif
 #ifdef CONFIG_MPC834x
u32 usbmph_clk;
@@ -120,7 +122,9 @@ int get_clocks(void)
 #if defined(CONFIG_FSL_ESDHC)
u32 sdhc_clk;
 #endif
+#if !defined(CONFIG_MPC8309)
u32 enc_clk;
+#endif
u32 lbiu_clk;
u32 lclk_clk;
u32 mem_clk;
@@ -263,6 +267,7 @@ int get_clocks(void)
return -6;
}
 #endif
+#if !defined(CONFIG_MPC8309)
switch ((sccr & SCCR_ENCCM) >> SCCR_ENCCM_SHIFT) {
case 0:
enc_clk = 0;
@@ -280,6 +285,7 @@ int get_clocks(void)
/* unkown SCCR_ENCCM value */
return -7;
}
+#endif
 
 #if defined(CONFIG_FSL_ESDHC)
switch ((sccr & SCCR_SDHCCM) >> SCCR_SDHCCM_SHIFT) {
@@ -332,6 +338,8 @@ int get_clocks(void)
i2c1_clk = sdhc_clk;
 #elif defined(CONFIG_MPC837x)
i2c1_clk = enc_clk;
+#elif defined(CONFIG_MPC8309)
+   i2c1_clk = csb_clk;
 #endif
 #if !defined(CONFIG_MPC832x)
i2c2_clk = csb_clk; /* i2c-2 clk is equal to csb clk */
@@ -460,6 +468,8 @@ int get_clocks(void)
gd->tsec1_clk = tsec1_clk;
gd->tsec2_clk = tsec2_clk;
gd->usbdr_clk = usbdr_clk;
+#elif defined(CONFIG_MPC8309)
+   gd->usbdr_clk = usbdr_clk;
 #endif
 #if defined(CONFIG_MPC834x)
gd->usbmph_clk = usbmph_clk;
@@ -475,7 +485,9 @@ int get_clocks(void)
 #if !defined(CONFIG_MPC832x)
gd->i2c2_clk = i2c2_clk;
 #endif
+#if !defined(CONFIG_MPC8309)
gd->enc_clk = enc_clk;
+#endif
gd->lbiu_clk = lbiu_clk;
gd->lclk_clk = lclk_clk;
gd->mem_clk = mem_clk;
@@ -536,7 +548,9 @@ int do_clocks (cmd_tbl_t * cmdtp, int flag, int argc, char 
* const argv[])
 #if defined(CONFIG_MPC8360)
printf("  DDR Secondary:   %-4s MHz\n", strmhz(buf, 
gd->mem_sec_clk));
 #endif
+#if !defined(CONFIG_MPC8309)
printf("  SEC: %-4s MHz\n", strmhz(buf, gd->enc_clk));
+#endif
printf("  I2C1:%-4s MHz\n", strmhz(buf, gd->i2c1_clk));
 #if !defined(CONFIG_MPC832x)
printf("  I2C2:%-4s MHz\n", strmhz(buf, gd->i2c2_clk));
@@ -552,6 +566,8 @@ int do_clocks (cmd_tbl_t * cmdtp, int flag, int argc, char 
* const argv[])
printf("  TSEC1:   %-4s MHz\n", strmhz(buf, gd->tsec1_clk));
printf("  TSEC2:   %-4s MHz\n", strmhz(buf, gd->tsec2_clk));
printf("  USB DR:  %-4s MHz\n", strmhz(buf, gd->usbdr_clk));
+#elif defined(CONFIG_MPC8309)
+   printf("  USB DR:  %-4s MHz\n", strmhz(buf, gd->usbdr_clk));
 #endif
 #if defined(CONFIG_MPC834x)
printf("  USB MPH: %-4s MHz\n", strmhz(buf, 
gd->usbmph_clk));
diff --git a/arch/powerpc/include/asm/global_data.h 
b/arch/powerpc/include/asm/global_data.h
index 5a5877f..cd4a54a 100644
--- a/arch/powerpc/include/asm/global_data.h
+++ b/arch/powerpc/include/asm/global_data.h
@@ 

[U-Boot] [PATCH v2 6/6] km83xx: add kmvect1 board

[Gerlando Falauto]

Add support for the new kmvect1 board powered by the mpc8309 processor.
As this board is very similar to the existing suvd3, instead of adding a
new config header file, just add a new config option to suvd3.h

Signed-off-by: Gerlando Falauto 
---
 boards.cfg  |3 ++-
 include/configs/suvd3.h |   15 ---
 2 files changed, 14 insertions(+), 4 deletions(-)

diff --git a/boards.cfg b/boards.cfg
index 7c1fc74..6781969 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -676,7 +676,8 @@ MVBLM7   powerpc mpc83xx mvblm7 
 matrix_
 SIMPC8313_LP powerpc mpc83xx simpc8313   
sheldon-   SIMPC8313:NAND_LP
 SIMPC8313_SP powerpc mpc83xx simpc8313   
sheldon-   SIMPC8313:NAND_SP
 TQM834x  powerpc mpc83xx tqm834x tqc
-suvd3powerpc mpc83xx km83xx  
keymile
+suvd3powerpc mpc83xx km83xx  
keymile-   suvd3:SUVD3
+kmvect1  powerpc mpc83xx km83xx  
keymile-   suvd3:KMVECT1
 tuge1powerpc mpc83xx km83xx  
keymile-   tuxx1:KM_DISABLE_APP2,TUGE1
 tuxx1powerpc mpc83xx km83xx  
keymile
 kmsupx5  powerpc mpc83xx km83xx  
keymile-   tuxx1:KM_DISABLE_APP2,KMSUPX5
diff --git a/include/configs/suvd3.h b/include/configs/suvd3.h
index 68680c5..c50832c 100644
--- a/include/configs/suvd3.h
+++ b/include/configs/suvd3.h
@@ -23,14 +23,23 @@
 /*
  * High Level Configuration Options
  */
-#define CONFIG_SUVD3   /* SUVD3 board specific */
-#define CONFIG_HOSTNAMEsuvd3
-#define CONFIG_KM_BOARD_NAME   "suvd3"
 
+/* This needs to be set prior to including km/km83xx-common.h */
 #defineCONFIG_SYS_TEXT_BASE0xF000
 
+#if defined(CONFIG_SUVD3)  /* SUVD3 board specific */
+#define CONFIG_HOSTNAMEsuvd3
+#define CONFIG_KM_BOARD_NAME   "suvd3"
 /* include common defines/options for all 8321 Keymile boards */
 #include "km/km8321-common.h"
+#elif defined(CONFIG_KMVECT1)   /* VECT1 board specific */
+#define CONFIG_HOSTNAMEkmvect1
+#define CONFIG_KM_BOARD_NAME   "kmvect1"
+/* include common defines/options for all 8309 Keymile boards */
+#include "km/km8309-common.h"
+#else
+#error Supported boards are: SUVD3, KMVECT1
+#endif
 
 #define CONFIG_SYS_APP1_BASE   0xA000
 #define CONFIG_SYS_APP1_SIZE   256 /* Megabytes */
-- 
1.7.10.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 5/6] km83xx: add common support for km8309 boards

[Gerlando Falauto]

Add support for Keymile boards based on mpc8309
(it would be only kmvect1 for now)

Signed-off-by: Gerlando Falauto 
---
 board/keymile/km83xx/km83xx.c  |2 +-
 include/configs/km/km8309-common.h |  176 
 include/configs/km/km83xx-common.h |6 ++
 3 files changed, 183 insertions(+), 1 deletion(-)
 create mode 100644 include/configs/km/km8309-common.h

diff --git a/board/keymile/km83xx/km83xx.c b/board/keymile/km83xx/km83xx.c
index e01a633..0d59ce6 100644
--- a/board/keymile/km83xx/km83xx.c
+++ b/board/keymile/km83xx/km83xx.c
@@ -56,7 +56,7 @@ const qe_iop_conf_t qe_iop_conf_tab[] = {
{5,  2, 1, 0, 1}, /* UART2_RTS */
{5,  3, 2, 0, 2}, /* UART2_SIN */
{5,  1, 2, 0, 3}, /* UART2_CTS */
-#else
+#elseif !defined(CONFIG_MPC8309)
/* Local Bus */
{0, 16, 1, 0, 3}, /* LA00 */
{0, 17, 1, 0, 3}, /* LA01 */
diff --git a/include/configs/km/km8309-common.h 
b/include/configs/km/km8309-common.h
new file mode 100644
index 000..b36e892
--- /dev/null
+++ b/include/configs/km/km8309-common.h
@@ -0,0 +1,176 @@
+/*
+ * Copyright (C) 2012 Keymile AG
+ *Gerlando Falauto 
+ *
+ * Based on km8321-common.h, see respective copyright notice for credits
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ */
+
+#ifndef __CONFIG_KM8309_COMMON_H
+#define __CONFIG_KM8309_COMMON_H
+
+/*
+ * High Level Configuration Options
+ */
+#define CONFIG_E3001   /* E300 family */
+#define CONFIG_QE  1   /* Has QE */
+#define CONFIG_MPC83xx 1   /* MPC83xx family */
+#define CONFIG_MPC830x 1   /* MPC830x family */
+#define CONFIG_MPC8309 1   /* MPC8309 CPU specific */
+
+#define CONFIG_KM_DEF_ARCH "arch=ppc_8xx\0"
+#define CONFIG_CMD_DIAG1
+
+/* include common defines/options for all 83xx Keymile boards */
+#include "km83xx-common.h"
+
+/* QE microcode/firmware address */
+#define CONFIG_SYS_QE_FMAN_FW_IN_NOR
+/* at end of uboot partition, before env */
+#define CONFIG_SYS_QE_FMAN_FW_ADDR   0xF00B
+
+#define CONFIG_MISC_INIT_R
+
+/*
+ * System IO Config
+ */
+/* 0x14000180 SICR_1 */
+#define CONFIG_SYS_SICRL (0\
+   | SICR_1_UART1_UART1RTS \
+   | SICR_1_I2C_CKSTOP \
+   | SICR_1_IRQ_A_IRQ  \
+   | SICR_1_IRQ_B_IRQ  \
+   | SICR_1_GPIO_A_GPIO\
+   | SICR_1_GPIO_B_GPIO\
+   | SICR_1_GPIO_C_GPIO\
+   | SICR_1_GPIO_D_GPIO\
+   | SICR_1_GPIO_E_GPIO\
+   | SICR_1_GPIO_F_GPIO\
+   | SICR_1_USB_A_UART2S   \
+   | SICR_1_USB_B_UART2RTS \
+   | SICR_1_FEC1_FEC1  \
+   | SICR_1_FEC2_FEC2  \
+   )
+
+/* 0x00080400 SICR_2 */
+#define CONFIG_SYS_SICRH (0\
+   | SICR_2_FEC3_FEC3  \
+   | SICR_2_HDLC1_A_HDLC1  \
+   | SICR_2_ELBC_A_LA  \
+   | SICR_2_ELBC_B_LCLK\
+   | SICR_2_HDLC2_A_HDLC2  \
+   | SICR_2_USB_D_GPIO \
+   | SICR_2_PCI_PCI\
+   | SICR_2_HDLC1_B_HDLC1  \
+   | SICR_2_HDLC1_C_HDLC1  \
+   | SICR_2_HDLC2_B_GPIO   \
+   | SICR_2_HDLC2_C_HDLC2  \
+   | SICR_2_QUIESCE_B  \
+   )
+
+/* GPR_1 */
+#define CONFIG_SYS_GPR1  0x50008060
+
+#define CONFIG_SYS_GP1DIR 0x
+#define CONFIG_SYS_GP1ODR 0x
+#define CONFIG_SYS_GP2DIR 0xFF00
+#define CONFIG_SYS_GP2ODR 0x
+
+/*
+ * Hardware Reset Configuration Word
+ */
+#define CONFIG_SYS_HRCW_LOW (\
+   HRCWL_LCL_BUS_TO_SCB_CLK_1X1 | \
+   HRCWL_DDR_TO_SCB_CLK_2X1 | \
+   HRCWL_CSB_TO_CLKIN_2X1 | \
+   HRCWL_CORE_TO_CSB_2X1 | \
+   HRCWL_CE_PLL_VCO_DIV_2 | \
+   HRCWL_CE_TO_PLL_1X3)
+
+#define CONFIG_SYS_HRCW_HIGH (\
+   HRCWH_PCI_AGENT | \
+   HRCWH_PCI_ARBITER_DISABLE | \
+   HRCWH_CORE_ENABLE | \
+   HRCWH_FROM_0X0100 | \
+   HRCWH_BOOTSEQ_DISABLE | \
+   HRCWH_SW_WATCHDOG_DISABLE | \
+   HRCWH_ROM_LOC_LOCAL_16BIT | \
+   HRCWH_BIG_ENDIAN | \
+   HRCWH_LALE_NORMAL)
+
+#define CONFIG_SYS_DDR_CS0_BNDS0x007f
+#define CONFIG_SYS_DDR_SDRAM_CFG   (SDRAM_CFG_SDRAM_TYPE_DDR2 | \
+SDRAM_CFG_32_BE | \
+SDRAM_CFG_SREN | \
+SDRAM_CFG_HSE)
+
+#de

[U-Boot] [PATCH v2 2/6] cleanup: use CONFIG_QE instead of CONFIG_MPC8360 || CONFIG_MPC832x

[Gerlando Falauto]

simplify #if defined(CONFIG_MPC8360) || defined(CONFIG_MPC832x)
for qe variables
with #if defined(CONFIG_QE)

Signed-off-by: Gerlando Falauto 
---
 arch/powerpc/cpu/mpc83xx/speed.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/speed.c b/arch/powerpc/cpu/mpc83xx/speed.c
index f78099d..3383568 100644
--- a/arch/powerpc/cpu/mpc83xx/speed.c
+++ b/arch/powerpc/cpu/mpc83xx/speed.c
@@ -127,7 +127,7 @@ int get_clocks(void)
 #if defined(CONFIG_MPC8360)
u32 mem_sec_clk;
 #endif
-#if defined(CONFIG_MPC8360) || defined(CONFIG_MPC832x)
+#if defined(CONFIG_QE)
u32 qepmf;
u32 qepdf;
u32 qe_clk;
@@ -444,7 +444,7 @@ int get_clocks(void)
return -13;
}
 
-#if defined(CONFIG_MPC8360) || defined(CONFIG_MPC832x)
+#if defined(CONFIG_QE)
qepmf = (im->clk.spmr & SPMR_CEPMF) >> SPMR_CEPMF_SHIFT;
qepdf = (im->clk.spmr & SPMR_CEPDF) >> SPMR_CEPDF_SHIFT;
qe_clk = (pci_sync_in * qepmf) / (1 + qepdf);
@@ -479,7 +479,7 @@ int get_clocks(void)
 #if defined(CONFIG_MPC8360)
gd->mem_sec_clk = mem_sec_clk;
 #endif
-#if defined(CONFIG_MPC8360) || defined(CONFIG_MPC832x)
+#if defined(CONFIG_QE)
gd->qe_clk = qe_clk;
gd->brg_clk = brg_clk;
 #endif
@@ -523,7 +523,7 @@ int do_clocks (cmd_tbl_t * cmdtp, int flag, int argc, char 
* const argv[])
printf("Clock configuration:\n");
printf("  Core:%-4s MHz\n", strmhz(buf, gd->core_clk));
printf("  Coherent System Bus: %-4s MHz\n", strmhz(buf, gd->csb_clk));
-#if defined(CONFIG_MPC8360) || defined(CONFIG_MPC832x)
+#if defined(CONFIG_QE)
printf("  QE:  %-4s MHz\n", strmhz(buf, gd->qe_clk));
printf("  BRG: %-4s MHz\n", strmhz(buf, gd->brg_clk));
 #endif
-- 
1.7.10.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 1/6] cosmetic: suvd3: align #defines

[Gerlando Falauto]

Signed-off-by: Gerlando Falauto 
---
 include/configs/km/km8321-common.h |2 +-
 include/configs/suvd3.h|4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/km/km8321-common.h 
b/include/configs/km/km8321-common.h
index 580b72f..8ad6fc3 100644
--- a/include/configs/km/km8321-common.h
+++ b/include/configs/km/km8321-common.h
@@ -115,7 +115,7 @@
 #define CONFIG_SYS_DDR_TIMING_30x
 
 #define CONFIG_SYS_KMBEC_FPGA_BASE 0xE800
-#defineCONFIG_SYS_KMBEC_FPGA_SIZE  128
+#define CONFIG_SYS_KMBEC_FPGA_SIZE 128
 
 /* EEprom support */
 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
diff --git a/include/configs/suvd3.h b/include/configs/suvd3.h
index ae19701..68680c5 100644
--- a/include/configs/suvd3.h
+++ b/include/configs/suvd3.h
@@ -33,9 +33,9 @@
 #include "km/km8321-common.h"
 
 #define CONFIG_SYS_APP1_BASE   0xA000
-#defineCONFIG_SYS_APP1_SIZE256 /* Megabytes */
+#define CONFIG_SYS_APP1_SIZE   256 /* Megabytes */
 #define CONFIG_SYS_APP2_BASE   0xB000
-#defineCONFIG_SYS_APP2_SIZE256 /* Megabytes */
+#define CONFIG_SYS_APP2_SIZE   256 /* Megabytes */
 
 /* EEprom support */
 #define CONFIG_SYS_I2C_EEPROM_ADDR_LEN 1
-- 
1.7.10.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 3/6] cleanup: introduce CONFIG_MPC830x

[Gerlando Falauto]

Introduce a new configuration token CONFIG_MPC830x to be shared among
mpc8308 and mpc8309. Define it for existing 8308 boards, and refactor
existing common code so to make future introduction of 8309 simpler.

Signed-off-by: Gerlando Falauto 
---
 arch/powerpc/cpu/mpc83xx/speed.c  |3 +++
 arch/powerpc/include/asm/immap_83xx.h |4 ++--
 include/configs/MPC8308RDB.h  |1 +
 include/configs/mpc8308_p1m.h |1 +
 include/mpc83xx.h |2 +-
 5 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/cpu/mpc83xx/speed.c b/arch/powerpc/cpu/mpc83xx/speed.c
index 3383568..4ad3ec3 100644
--- a/arch/powerpc/cpu/mpc83xx/speed.c
+++ b/arch/powerpc/cpu/mpc83xx/speed.c
@@ -185,7 +185,10 @@ int get_clocks(void)
/* unkown SCCR_TSEC1CM value */
return -2;
}
+#endif
 
+#if defined(CONFIG_MPC830x) || defined(CONFIG_MPC831x) || \
+   defined(CONFIG_MPC834x) || defined(CONFIG_MPC837x)
switch ((sccr & SCCR_USBDRCM) >> SCCR_USBDRCM_SHIFT) {
case 0:
usbdr_clk = 0;
diff --git a/arch/powerpc/include/asm/immap_83xx.h 
b/arch/powerpc/include/asm/immap_83xx.h
index 2ba502a..b7d4c59 100644
--- a/arch/powerpc/include/asm/immap_83xx.h
+++ b/arch/powerpc/include/asm/immap_83xx.h
@@ -73,8 +73,8 @@ typedef struct sysconf83xx {
u32 obir;   /* Output Buffer Impedance Register */
u8 res8[0xC];
u32 pecr1;  /* PCI Express control register 1 */
-#ifdef CONFIG_MPC8308
-   u32 sdhccr; /* eSDHC Control Registers for MPC8308 */
+#if defined(CONFIG_MPC830x)
+   u32 sdhccr; /* eSDHC Control Registers for MPC830x */
 #else
u32 pecr2;  /* PCI Express control register 2 */
 #endif
diff --git a/include/configs/MPC8308RDB.h b/include/configs/MPC8308RDB.h
index 2d48dde..ed62608 100644
--- a/include/configs/MPC8308RDB.h
+++ b/include/configs/MPC8308RDB.h
@@ -30,6 +30,7 @@
  */
 #define CONFIG_E3001 /* E300 family */
 #define CONFIG_MPC83xx 1 /* MPC83xx family */
+#define CONFIG_MPC830x 1 /* MPC830x family */
 #define CONFIG_MPC8308 1 /* MPC8308 CPU specific */
 #define CONFIG_MPC8308RDB  1 /* MPC8308RDB board specific */
 
diff --git a/include/configs/mpc8308_p1m.h b/include/configs/mpc8308_p1m.h
index 806ed64..dd249b0 100644
--- a/include/configs/mpc8308_p1m.h
+++ b/include/configs/mpc8308_p1m.h
@@ -30,6 +30,7 @@
  */
 #define CONFIG_E3001 /* E300 family */
 #define CONFIG_MPC83xx 1 /* MPC83xx family */
+#define CONFIG_MPC830x 1 /* MPC830x family */
 #define CONFIG_MPC8308 1 /* MPC8308 CPU specific */
 #define CONFIG_MPC8308_P1M 1 /* mpc8308_p1m board specific */
 
diff --git a/include/mpc83xx.h b/include/mpc83xx.h
index a78f1a2..7a19740 100644
--- a/include/mpc83xx.h
+++ b/include/mpc83xx.h
@@ -969,7 +969,7 @@
  */
 #define CSCONFIG_EN0x8000
 #define CSCONFIG_AP0x0080
-#if defined(CONFIG_MPC8308) || defined(CONFIG_MPC831x)
+#if defined(CONFIG_MPC830x) || defined(CONFIG_MPC831x)
 #define CSCONFIG_ODT_RD_NEVER  0x
 #define CSCONFIG_ODT_RD_ONLY_CURRENT   0x0010
 #define CSCONFIG_ODT_RD_ONLY_OTHER_CS  0x0020
-- 
1.7.10.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v2 0/6] introducing vect1: mpc8309 keymile board

[Gerlando Falauto]

This patch series adds support for VECT1, an mpc8309-powered Keymile board.
MPC8309 is not currently supported by u-boot, so we first add support for
this processor.
VECT1 is somewhat similar to suvd3, albeit powered by a different processor,
so we use its config file as opposed to introducing a new one.

Difference from v1:
 - added preliminary cleanup patches #2/3 to simplify #if conditions in speed.c
 - fixed #ifdef so to restore code block assigning to usbdr_clk
 - removed checkpatch errors

Gerlando Falauto (6):
  cosmetic: suvd3: align #defines
  cleanup: use CONFIG_QE instead of CONFIG_MPC8360 || CONFIG_MPC832x
  cleanup: introduce CONFIG_MPC830x
  mpc83xx: add support for mpc8309
  km83xx: add common support for km8309 boards
  km83xx: add kmvect1 board

 arch/powerpc/cpu/mpc83xx/cpu.c |1 +
 arch/powerpc/cpu/mpc83xx/cpu_init.c|3 +
 arch/powerpc/cpu/mpc83xx/speed.c   |   27 -
 arch/powerpc/include/asm/global_data.h |2 +
 arch/powerpc/include/asm/immap_83xx.h  |   65 +++-
 arch/powerpc/include/asm/immap_qe.h|2 +-
 board/keymile/km83xx/km83xx.c  |2 +-
 boards.cfg |3 +-
 drivers/qe/qe.c|   21 ++--
 include/configs/MPC8308RDB.h   |1 +
 include/configs/km/km8309-common.h |  176 
 include/configs/km/km8321-common.h |2 +-
 include/configs/km/km83xx-common.h |6 ++
 include/configs/mpc8308_p1m.h  |1 +
 include/configs/suvd3.h|   19 +++-
 include/mpc83xx.h  |  155 +++-
 16 files changed, 461 insertions(+), 25 deletions(-)
 create mode 100644 include/configs/km/km8309-common.h

-- 
1.7.10.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 09/21] pmic: Extend struct pmic to support battery and charger related operations

[Stefano Babic]

Am 05/10/2012 10:16, schrieb Lukasz Majewski:
> Now it is possible to provide specific function per PMIC/power
> device instance.
> 
> Signed-off-by: Lukasz Majewski 
> Signed-off-by: Kyungmin Park 
> ---
> Changes for v2:
> - New at patch v2
> ---

Hi Lucasz,

>  include/power/battery.h |   38 ++
>  include/power/pmic.h|   23 ++-
>  2 files changed, 60 insertions(+), 1 deletions(-)
>  create mode 100644 include/power/battery.h
> 
> diff --git a/include/power/battery.h b/include/power/battery.h
> new file mode 100644
> index 000..e2fec68
> --- /dev/null
> +++ b/include/power/battery.h
> @@ -0,0 +1,38 @@
> +/*
> + *  Copyright (C) 2012 Samsung Electronics
> + *  Lukasz Majewski 
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#ifndef __POWER_BATTERY_H_
> +#define __POWER_BATTERY_H_
> +
> +struct battery {
> + unsigned int version;
> + unsigned int state_of_chrg;
> + unsigned int time_to_empty;
> + unsigned int capacity;
> + unsigned int voltage_uV;
> +
> + unsigned int state;
> +};
> +
> +int power_bat_init(unsigned char bus);
> +#endif /* __POWER_BATTERY_H_ */
> diff --git a/include/power/pmic.h b/include/power/pmic.h
> index 3583342..5ec7bae 100644
> --- a/include/power/pmic.h
> +++ b/include/power/pmic.h
> @@ -27,8 +27,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
> -enum { PMIC_I2C, PMIC_SPI, };
> +enum { PMIC_I2C, PMIC_SPI, PMIC_NONE};
>  enum { I2C_PMIC, I2C_NUM, };
>  enum { PMIC_READ, PMIC_WRITE, };
>  enum { PMIC_BYTE_ORDER_REVERSED, PMIC_BYTE_ORDER_NORMAL, };
> @@ -48,6 +49,21 @@ struct p_spi {
>   u32 (*prepare_tx)(u32 reg, u32 *val, u32 write);
>  };
>  
> +struct pmic;
> +struct power_battery {
> + struct battery *bat;
> +
> + int (*fg_battery_check) (struct pmic *p, struct pmic *bat);
> + int (*fg_battery_update) (struct pmic *p, struct pmic *bat);
> +
> + int (*chrg_type) (struct pmic *p);
> + int (*chrg_bat_present) (struct pmic *p);
> + int (*chrg_state) (struct pmic *p, int state, int current);
> +
> + /* Keep info about power devices involved with battery operation */
> + struct pmic *chrg, *fg, *muic;
> +};
> +
>  struct pmic {
>   const char *name;
>   unsigned char bus;
> @@ -59,6 +75,11 @@ struct pmic {
>   struct p_spi spi;
>   } hw;
>  
> + struct power_battery *pwr_bat;
> + int (*battery_init) (struct pmic *p, struct pmic *bat);

If we add entry points to the pmic structure, I do not expect to pass
the pointer of the structure itself, or I could call the function with
another pointer:

p->battery_init(p1, bat);

So p should be hide, stored during the initialization of PMIC itself.

> + int (*battery_charge) (struct pmic *bat);
> + void (*low_power_mode) (void);
> +
>   struct list_head list;
>  };
>  

I have some concerns regarding this structure. It seems to me very
coupled to the PMIC you are using.

Reading this and the next patches it seems to me that is due because
your PMIC includes other three PMICs. However, IMHO the interface
presented before this patch is very clear.

I have expected something as:

P = get_pmic("CHRG");
p->chrg_state(current);

And if the problem is that this PMIC really descend from another one, we
could add a "struct pmic *parent" in the pmic itself. You already
introduced lists, and we can work with pointer instead of hard-code the
subpmics as in :
struct pmic *chrg, *fg, *muic;

In this case, if we have a pmic that logically can be seen with a
different number of pmics, we can still support.
You introduce PMIC_NONE to tell that this pmic does not have an own data
transfer and rely on another one. But again, this could be solved using

if (p->parent)
p->i2c

or something like this to use the transfer method of the "main" PMIC.

Best regards,
Stefano Babic


-- 
=
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 

Re: [U-Boot] [PATCH v2 07/10] x86: coreboot: Modify u-boot code to allow building coreboot payload

[Graeme Russ]

Hi Simon,

On Thu, Oct 11, 2012 at 10:12 AM, Simon Glass  wrote:
> From: Vadim Bendebury 
>
> This prevents the preprocessor from complaining when processing
> variadic macros
>
> Signed-off-by: Vadim Bendebury 
> Signed-off-by: Simon Glass 
> ---
>
>  board/chromebook-x86/coreboot/config.mk |   37 
> +++
>  1 files changed, 37 insertions(+), 0 deletions(-)
>  create mode 100644 board/chromebook-x86/coreboot/config.mk
>
> diff --git a/board/chromebook-x86/coreboot/config.mk 
> b/board/chromebook-x86/coreboot/config.mk
> new file mode 100644
> index 000..f720851
> --- /dev/null
> +++ b/board/chromebook-x86/coreboot/config.mk
> @@ -0,0 +1,37 @@
> +#
> +# Copyright (c) 2011 The Chromium OS Authors. All rights reserved.
> +# Use of this source code is governed by a BSD-style license that can be
> +# found in the LICENSE file.
> +#
> +# Redistribution and use in source and binary forms, with or without
> +# modification, are permitted provided that the following conditions are
> +# met:
> +#
> +# * Redistributions of source code must retain the above copyright
> +# notice, this list of conditions and the following disclaimer.
> +# * Redistributions in binary form must reproduce the above
> +# copyright notice, this list of conditions and the following disclaimer
> +# in the documentation and/or other materials provided with the
> +# distribution.
> +# * Neither the name of Google Inc. nor the names of its
> +# contributors may be used to endorse or promote products derived from
> +# this software without specific prior written permission.
> +#
> +# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
> +# "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
> +# LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
> +# A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
> +# OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
> +# SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
> +# LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
> +# DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
> +# THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> +# (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
> +# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
> +#
> +# Alternatively, this software may be distributed under the terms of the
> +# GNU General Public License ("GPL") version 2 as published by the Free
> +# Software Foundation.
> +#
> +
> +HOSTCFLAGS_autoconf.mk.dep = -Wno-variadic-macros
> --
> 1.7.7.3
>

Acked-by: Graeme Russ 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 06/10] x86: coreboot: Tell u-boot about PCI bus 0 when initializing

[Graeme Russ]

Hi Simon,

On Thu, Oct 11, 2012 at 10:12 AM, Simon Glass  wrote:
> From: Gabe Black 
>
> U-boot needs a host controller or "hose" to interact with the PCI busses
> behind them. This change installs a host controller during initialization of
> the coreboot "board" which implements some of X86's basic PCI semantics. This
> relies on some existing generic code, but also duplicates a little bit of code
> from the sc520 implementation. Ideally we'd eliminate that duplication at some
> point.
>
> It looks like in order to scan buses beyond bus 0, we'll need to tell u-boot's
> generic PCI configuration code what to do if it encounters a bridge,
> specifically to scan the bus on the other side of it.
>
> Signed-off-by: Gabe Black 
> Signed-off-by: Simon Glass 
> ---
>
>  arch/x86/cpu/coreboot/pci.c |   15 +++
>  arch/x86/include/asm/pci.h  |2 +-
>  2 files changed, 16 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/cpu/coreboot/pci.c b/arch/x86/cpu/coreboot/pci.c
> index 732ca3c..0ddc975 100644
> --- a/arch/x86/cpu/coreboot/pci.c
> +++ b/arch/x86/cpu/coreboot/pci.c
> @@ -25,6 +25,21 @@
>   * MA 02111-1307 USA
>   */
>
> +#include 
> +#include 
> +#include 
> +
> +static struct pci_controller coreboot_hose;
> +
>  void pci_init_board(void)
>  {
> +   coreboot_hose.first_busno = 0;
> +   coreboot_hose.last_busno = 0xff;
> +   coreboot_hose.region_count = 0;
> +
> +   pci_setup_type1(&coreboot_hose);
> +
> +   pci_register_hose(&coreboot_hose);
> +
> +   coreboot_hose.last_busno = pci_hose_scan(&coreboot_hose);
>  }
> diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
> index 37cc7e3..6d68ab6 100644
> --- a/arch/x86/include/asm/pci.h
> +++ b/arch/x86/include/asm/pci.h
> @@ -24,7 +24,7 @@
>   */
>
>  #ifndef _PCI_I386_H_
> -#define _PCI_I386_H_   1
> +#define _PCI_I386_H_
>
>  #define DEFINE_PCI_DEVICE_TABLE(_table) \
> const struct pci_device_id _table[]
> --
> 1.7.7.3
>

Acked-by: Graeme Russ 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 01/10] x86: Change board baud_rate to ulong

[Wolfgang Denk]

Dear Simon Glass,

In message <1349910781-32088-2-git-send-email-...@chromium.org> you wrote:
> This is a ulong for some architectures and just unsigned for others.
> Change x86 to be consistent.

Given the limited range for this variable it makes no sense to use a
long for this.  Please fix this the other way round, i. e. change the
architectures that use a long.

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Always try to do things in chronological order; it's  less  confusing
that way.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot