Re: [U-Boot] [PATCH v2 05/21] pmic: Introduce power_board_init() method at ./lib/board.c file

[Lukasz Majewski]

Hi Tom,

> On Tue, Oct 09, 2012 at 01:34:35PM +0200, Stefano Babic wrote:
> > On 09/10/2012 12:25, Lukasz Majewski wrote:
> [snip]
> > >> We use often the "weak" mechanism to avoid that a board
> > >> maintainer is constrained to implement an empty function only to
> > >> make happy the linker. It is better to declare the function as
> > >> weak and call it with the same schema, such as
> > >> board_power_init() (several board_* are weak)
> > > 
> > > Correct me if I'm wrong, but weren't we recently trying to remove
> > > functions defined as weak?
> > 
> > I am not aware of it. I see several patches in last days adding weak
> > function. Several weak function are present in the recent added SPL
> > framework.
> 
> We should use weak functions when we can provide a functioning in many
> cases default but need to allow for overrides in some cases.  We
> shouldn't use them when everyone needs to define the function and it
> has to do something.
> 

Ok, thanks for clarification :-).

I will define and use board_power_init() as a __weak function.


-- 
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 3/4] EXYNOS: additional Exynos4 SoC series support

[Minkyu Kang]

Dear Jeong-Hyeon Kim,

On 29 August 2012 12:28,   wrote:
> From: Jeong-Hyeon Kim 
>
> - Fixed MPLL register address
>   It's different between Exynos4210 and Exynos4412.
>
> - Added pinmux functions for Exynos4
>
> - Added extended gpios for Exynos4412
>   Exynos4412 has more gpios than Exynos4210.
>
> Signed-off-by: Jeong-Hyeon Kim 
> ---
>  arch/arm/cpu/armv7/exynos/clock.c|   67 
>  arch/arm/cpu/armv7/exynos/pinmux.c   |  241 
> ++
>  arch/arm/include/asm/arch-exynos/clock.h |  240 +
>  arch/arm/include/asm/arch-exynos/cpu.h   |   14 ++-
>  arch/arm/include/asm/arch-exynos/gpio.h  |   21 +++-
>  5 files changed, 578 insertions(+), 5 deletions(-)
>
>

Chander posted similar patch for support the exynos4x12.
So, please kindly check his patch and update your patch.

http://patchwork.ozlabs.org/patch/188437/
http://patchwork.ozlabs.org/patch/188438/
http://patchwork.ozlabs.org/patch/188511/
http://patchwork.ozlabs.org/patch/188512/
http://patchwork.ozlabs.org/patch/188513/
http://patchwork.ozlabs.org/patch/189809/

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] U-Boot git usage model

[Albert ARIBAUD]

Hi Stephen,

On Tue, 09 Oct 2012 17:04:06 -0600, Stephen Warren
 wrote:

> On 10/09/2012 04:19 PM, Albert ARIBAUD wrote:

> > Apart from this, I'm not sure why forbidding fast-forward is a good
> > thing, but if there are benefits, why not.
> 
> 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.

> 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
that no merge should contains a hidden patch application or removal.
If this (sensible IMO) rule is followed, then necessarily, any patch
exists as a commit and its Signed-off-by (aong with any other "by" tag)
is there for all to see and easy to find.

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).

Note that neither of these two issues is related to non-fast-forwarding
of merges, as the only thing a non-ff merge does is create a commit
that, by definition, will not add any content and not affect any
existing commit, less so its "by" tags.

> > 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."

> Say 2012.10 is released. We assume that is usable.
> 
> Now, someone creates some ARM patches for the next release. As ARM
> maintainer you do e.g.:
> 
> git checkout -b for-201304 v2012.10
> git am ...
>
> Now, there's a branch with a bunch of ARM patches applied. Presumably
> none of those patches are supposed to break anything, and hence this
> branch is also still usable?

Not sur I follow you reasonning. My personal approach is, once a patch
for ARM (but not for an ARM platform for which there is a more specific
custodian) is reviewed positively, I do "git checkout master", git am
(or rather, pwclient git-am) and run ad hoc and general tests. If this
succeeds, I push master (and fetch it back for local personal
consistency).

> Perhaps the issue is that say a new SoC or feature is added, and some of
> the patches go through the ARM tree, and some drivers through the USB,
> I2C, video, ... trees. In that case, in order to use all of those
> features at once, somebody might have to:

Usually in mixed-repo patch series, a main custodian takes ownership of
the series and gets approval from other custodians.

> git checkout -b tmp v2012.10
> git merge u-boot-arm/next
> git merge u-boot-i2c/next
> ...
> 
> This requirement is I think one of the main reasons that linux-next
> exists; to provide a place where all features can be tested at once
> after having been integrated together. linux-next also allows early
> detection of merge conflicts that will happen when u-boot-*/next are
> sent to the maintainer of u-boot/master to be merged.
> 
> Now, perhaps you're thinking that in this scenario that u-boot-arm/next
> can simply merge in u-boot-usb/next, u-boot-i2c/next, u-boot-video/next,
> etc. in order to create a fully working system. But, wouldn't it be
> better if all those merges happened only in u-boot.git in a co-ordinated
> fashion once? After all, perhaps the I2C maintainer also wants his/her
> branch to be usable on that new platform, and does the reverse merges.
> Then you end up with spaghetti and unparsable merge history.

You may be making the

Re: [U-Boot] [PATCH] arm: trats: Power down core 1

[Kyungmin Park]

FYI: Piotr and Lukasz are working together for samsung board.

Minkyu, can you pick up this patch?

Thank you,
Kyungmin Park

> -Original Message-
> From: Albert ARIBAUD [mailto:albert.u.b...@aribaud.net]
> Sent: Wednesday, October 10, 2012 2:07 AM
> To: Piotr Wilczek
> Cc: u-boot@lists.denx.de; Kyungmin Park; Lukasz Majewski
> Subject: Re: [U-Boot] [PATCH] arm: trats: Power down core 1
> 
> Hi Piotr,
> 
> On Tue, 09 Oct 2012 08:45:42 +0200, Piotr Wilczek 
> wrote:
> 
> > This patch turns power down for unused core 1
> >
> > Signed-off-by: Piotr Wilczek 
> > Signed-off-by: Kyungmin Park 
> > CC: Minkyu Kang 
> > ---
> >  board/samsung/trats/trats.c |4 
> >  1 files changed, 4 insertions(+), 0 deletions(-)
> >
> > diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
> > index 57400ce..d5c681c 100644
> > --- a/board/samsung/trats/trats.c
> > +++ b/board/samsung/trats/trats.c
> > @@ -321,6 +321,10 @@ static void board_power_init(void)
> > writel(0, (unsigned int)&pwr->lcd1_configuration);
> > writel(0, (unsigned int)&pwr->gps_configuration);
> > writel(0, (unsigned int)&pwr->gps_alive_configuration);
> > +
> > +   /* It is necessary to power down core 1 */
> > +   /* to successfully boot CPU1 in kernel */
> > +   writel(0, (unsigned int)&pwr->arm_core1_configuration);
> >  }
> >
> >  static void board_uart_init(void)
> 
> Cc:ing trats maintainer.
> 
> Amicalement,
> --
> Albert.

___
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/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 $< $@

 $(obj)u-boot.kwb:   $(obj)u-boot.bin
@@ -794,7 +803,8 @@ clean:
@rm -f $(TIMESTAMP_FILE) $(VERSION_FILE)
@find $(OBJTREE) -type f \
\( -name 'core' -o -name '*.bak' -o -name '*~' -o -name 
'*.su' \

-   -o -name '*.o'  -o -name '*.a' -o -name '*.exe' \) -print \
+   -o -name '*.o'  -o -name '*.a' -o -name '*.exe' \
+   -o -name '*.pcfgtmp' \) -print \
| xargs rm -f

 # Removes everything not needed for testing u-boot
diff --git a/board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg 
b/board/freescale/imx/ddr/mx6q_4x_mt41j128.pcfg

similarity index 65%
rename from board/freescale/imx/ddr/mx6q_4x_mt41j128.cfg
rename to board/freescale/imx/ddr/mx6q_4x_mt41j128.pcfg
diff --git a/boards.cfg b/boards.cfg
index e9e073e..677beac 100644
--- a/boards.cfg
+++ b/boards.cfg
@@ -232,8 +232,8 @@ ima3-mx53arm armv7   
ima3-mx53   esg
 vision2  arm armv7 vision2 
ttcontrol  mx5 vision2:IMX_CONFIG=board/ttcontrol/vision2/imx

Re: [U-Boot] [PATCH v2 0/3] Enable MMC support for at91sam9x5ek board.

[Josh Wu]

Hi, Andreas

On 10/10/2012 5:51 AM, Andreas Bießmann wrote:

Hi Josh,

On 09.10.12 12:11, Josh Wu wrote:

Hi, Andreas

Any feedback of these patches?

short answer: no ;)

I think they could go into next (no obvious objections), but I would
like to do some runtime tests on avr32 before. Beside that, if you do
not insist on applying them ASAP to next I would like to wait until the
release next Monday and apply the patches to u-boot-atmel/master then.
Is that OK for you?


Yes, I'm fine with this. thank you.

Best Regards,
Josh Wu



Best regards

Andreas Bießmann


Best Regards,
Josh Wu

On 9/14/2012 4:22 PM, Josh Wu wrote:

This patch series enable MCI0 solt in at91sam9x5ek board.

Josh Wu (3):
mmc: at91: add multi block read/write support.
ARM: at91sam9x5: enable MCI0 support for 9x5ek board.
mmc: at91: use max timeout value. It will avoid some situation that
  timeout happened.

   arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c |   15 +++
   board/atmel/at91sam9x5ek/at91sam9x5ek.c  |   10 ++
   drivers/mmc/gen_atmel_mci.c  |   15 +--
   include/atmel_mci.h  |7 ++-
   include/configs/at91sam9x5ek.h   |   10 ++
   5 files changed, 54 insertions(+), 3 deletions(-)



___
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

[Marek Vasut]

Dear Lukasz Dalek,

> 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 

Acked-by: Marek Vasut 

> ---
>  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 }

Best regards,
Marek Vasut
___
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/09/2012 06:25:47 PM, Stephen Warren wrote:

On 10/09/2012 05:00 PM, Scott Wood wrote:
> On 10/09/2012 05:14:23 PM, Stephen Warren wrote:
>> I don't quite follow that; linux-next is also purely merge-based.  
Are

>> you referring to the fact that it's re-created every day, and the
>> source branches that go into the merge can be rebased if needed?
>
> What's the difference between "re-created every day" and "rebased  
every

> day"?

The linux-next model (and what I mean by "re-created every day") is
roughly the following approximately daily:

git fetch --all
git branch -D tmp
git checkout -b tmp u-boot/master # or latest rc in fact
git merge u-boot-arm/next
git merge u-boot-i2c/next
git merge u-boot-video/next
etc.
git tag next-${datestamp}

I'm not sure what "rebased every day means"; perhaps it's running the
following on u-boot/next every day?

git rebase u-boot/master

That doesn't pull in any new commits from child trees though.


By "rebasing" I was referring to rewriting history in any form.  It  
looks like the difference is that linux-next gives the result a new  
name each time, instead of working a branch with a fixed name.



> How does merging back down prevent incremental pull requests?

It doesn't prevent incremental pull requests, but it does pollute the
history if you merge back down. Instead of a fairly simple:

(M* == main branch, B* == side branch)

B1-B2-B3-B4-B5-B6
   /   \\
M1-M2-M3-M4-M4-M5-M6-M7

you might end up with:

B1-B2-B3-B4-X1-B6
   /   \/\
M1-M2-M3-M4-M4-M5-M6-M7

... where X1 is the merge back from main to the side-branch. That
doesn't look a lot more complex, but once there are many  
side-branches,

and the master branch ends up merging a whole bunch of side-branches
between M4 and M5 above, the commits in B* that add actual new work  
are

split between a point before the X1 merge-back and after it. This can
make tracking down what exactly will get merged into M* when B* is
re-merged a bit trickier. git log M..B can probably show it fine, but  
if

you start looking at gitk it'll look quite complex.


I don't use gitk much, but wouldn't it just show the mergeback as  
another edge in the graph (plus the merge commit itself of course)?  It  
doesn't seem like a big deal.



>> >> Or often when u-boot/master has made a complete new release
>> >> does:
>> >>
>> >> b) Creates a new branch based on the latest rc or release from
>> >> u-boot/master.
>
> That's a rebase.  How is that better than a (likely fast-forward)  
merge?


No, that's not a rebase.


Fine, a reset.  Or a new branch name, which in practice is the same  
thing except with a much more cluttered branch list, unless you have a  
specific need to refer to an older iteration of this process.



Rebase is when you take some existing commits
based on one commit and apply them to a different baseline commit
instead. If you're creating a new branch to take commits for a new
release, you're simply not applying the commits for release N+1 until
there's a branch ready to take them.


There is a branch ready to take them -- the custodian tree.  Why wait  
until there's an upstream tree ready to pull?


>> >> (in practice, downstream branches typically end up with  
something

>> >> like for-3.5 based on v3.4-rcN, for-3.6 based on v3.5-rcN,
>> >> for-3.7 based on v3.6-rcN, some running in parallel containing
>> >> either important bugfixes for the release or new development as
>> >> determined by the current state of the various releases in the
>> >> mainline tree).
>
> I thought you said your way was less work? :-)

And I believe it is; no rebasing required.
The difference probably isn't
that big though I admit. Still, creating a fresh branch from scratch  
for

each release one time and only then applying patches for that release
seems a lot simpler that constantly rebasing stuff all over the place.


We've already dropped the rebasing.  I'd rather do merges than  
constantly create new branches.



>> but with the Linux model, you simply:
>>
>> a) Send pull request.
>>
>> Admittedly the recipient then might need to resolve some merge
>> conflicts. However, hopefully people have been planning for these  
and

>> have avoided them.
>
> How do you plan for them and avoid them, and how is that less work  
that

> what we do now?

People have to be aware what is going on.

If you're submitting a bunch of patches which depend on each-other,  
the

submitter had better call that out when sending the patch series.


Sometimes it's not obvious in advance.  Not all conflicts (whether they  
be merge conflicts, build breaks, or runtime failures) come from  
intrusive tree-wide changes.


> I especially do not want to have to work with some artificially  
chosen

> old tree as my base.  I also do not want to create a bunch of named
> branches for each

Linux requires that branches be based only on rc or release tags in  
the

equivalent of u-boot/master.


So how do you sort out dependenci

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

[Lukasz Dalek]

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 }
-- 
1.7.8.6

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

Re: [U-Boot] h2200 fails to build on current u-boot/next

[Łukasz Dałek]

On 10.10.2012 00:27, Albert ARIBAUD wrote:

Hi Łukasz,

On Tue, 9 Oct 2012 14:45:33 -0700, Tom Rini  wrote:


On Tue, Oct 09, 2012 at 05:34:13PM +0200, Albert ARIBAUD wrote:


Hi Tom,

The following changes since commit 661c21dd46e857b74682b0610d83cfea7f3ac3c2:

   usb.h: Add udc_disconnect prototype to usb.h (2012-10-08 18:01:17 -0700)

are available in the git repository at:

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

for you to fetch changes up to 0d6b8f29a3c59306d6cd8f2baa92897f56b06695:

   configs: mx6qsabre_common.h: Use default clock definitions (2012-10-09 
16:52:18 +0200)

[snip]

Lukasz Dalek (2):
   h2200: Add support for iPAQ h2200 palmtop

This doesn't compile in next due to not having been updated for the
serial changes:
serial_pxa.c:297:2: error: #error "Bad CONFIG_CONS_INDEX."

Do you want me to pull or do you want to fix this first?  Thanks.

Cc:ing Marek as PXA custodian and serial patcher...

Łukasz, can you have a look at why h2200 above u-boot/next fails to
build, and can you quickly provide a new patch version to fix it?

Amicalement,

Yes, I will prepare patch soon.

Łukasz Dałek
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V2 3/3] FAT: implement fat_set_blk_dev(), convert cmd_fat.c

[Stephen Warren]

On 10/09/2012 05:06 PM, Benoît Thébaudeau wrote:
> Hi Stephen,
> 
> See my comments inlined below.
> 
> On Tuesday, October 9, 2012 10:41:41 PM, Stephen Warren wrote:
>> This makes the FAT filesystem API more consistent with other
>> block-based
>> filesystems. If in the future standard multi-filesystem commands such as
>> "ls" or "load" are implemented, having FAT work the same way as other
>> filesystems will be necessary.
>>
>> Convert cmd_fat.c to the new API, so the code looks more like other files
>> implementing the same commands for other filesystems.

>> diff --git a/fs/fat/fat.c b/fs/fat/fat.c

>> +int fat_register_device(block_dev_desc_t *dev_desc, int part_no)
>> +{
>> +disk_partition_t info;
>> +
>> +/* First close any currently found FAT filesystem */
>> +cur_dev = NULL;
>> +
>> +/* Read the partition table, if present */
>> +if (get_partition_info(dev_desc, part_no, &info)) {
>> +if (part_no != 0) {
>> +printf("** Partition %d not valid on device %d **\n",
>> +part_no, dev_desc->dev);
>> +return -1;
>> +}
>> +
>> +info.part = 0;
>> +info.start = 0;
>> +info.size = dev_desc->lba;
>> +info.blksz = dev_desc->blksz;
>> +memset(info.name, 0, sizeof(info.name));
>> +memset(info.type, 0, sizeof(info.type));
>> +#ifdef CONFIG_PARTITION_UUIDS
>> +memset(info.uuid, 0, sizeof(info.uuid));
>> +#endif
>> +info.bootable = 0;
> 
> Sorry for pointing this out only now, but now that cmd_fat.c has been switched
> to fat_set_blk_dev(), the code above is handled for this file by
> get_device_and_partition():
> ---
>   info->start = 0;
>   info->size = (*dev_desc)->lba;
>   info->blksz = (*dev_desc)->blksz;
>   info->bootable = 0;
> #ifdef CONFIG_PARTITION_UUIDS
>   info->uuid[0] = 0;
> #endif
> ---
> 
> This code does not initialize the fields part, name and type, and it clears 
> only
> the 1st byte of the uuid field. Is this on purpose for some reason, or is this
> an issue?

get_device_and_partition() should set indeed set info->part in the
whole-disk case; I'll fix that.

I think get_device_and_partition() never cleared name or type in this
case; I guess that's a pre-existing inconsistency between the two pieces
of code? I'll have a look and add a cleanup patch to make the code
consistent.

The uuid field is a string, so clearing just the first byte is fine; I
ended up using memset in the new code in this patch since the existing
fat_register_device() implementation used memset() on name and type;
something I imagine is not strictly necessary. Since the function is
being re-written anyway, I'll take a look to make sure that clearing
only the first byte is fine, and remove all the memsets and just zero
out the first byte.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] KernelDoc

[Marek Vasut]

Dear Tom Rini,

> On Mon, Oct 01, 2012 at 12:37:26PM +0200, Marek Vasut wrote:
> > Dear Wolfgang Denk,
> > 
> > > Dear Marek Vasut,
> > > 
> > > In message <201210011107.45164.ma...@denx.de> you wrote:
> > > > Agreed, not the whole file. But, can you check the rules I tried to
> > > > outline?
> > > 
> > > Is there a summary somewhere?  Something we could add to the wiki?
> > 
> > I sent this on friday:
> > 
> > So I've been hacking on it for a bit, see the first stab at [1]. As for
> > the ruleset, I propose this addition for the Wiki [2]:
> > 
> > -->8--
> > 
> > U-Boot code documentation
> > =
> > 
> > U-Boot adopted the kernel-doc annotation style, this is the only
> > exception from multi-line comment rule of Coding Style. While not
> > mandatory, adding documentation is strongly advised. The Linux kernel
> > kernel-doc document [3] appliest with no changes.
> > 
> > --8<--
> > 
> > [1] http://twilight.ponies.cz/kerneldoc/
> > [2] http://www.denx.de/wiki/U-Boot/CodingStyle
> > [3]
> > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f
> > =Documentation/kernel- doc-nano-HOWTO.txt
> 
> Make it so.

Let's wait for Wolfgang, I'd like to have his ACK on this please.

Best regards,
Marek Vasut
___
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/09/2012 05:00 PM, Scott Wood wrote:
> On 10/09/2012 05:14:23 PM, Stephen Warren wrote:
>> On 10/09/2012 03:32 PM, Tom Rini wrote:
>> > On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
>> >> On 10/09/2012 08:23 AM, Tom Rini wrote:
>> >>> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
>> >>>
>>  NOTE: I get a few more size issues with ELDK 4.2 on IXP
>>  (that big-endian ARM) after this patchset is applied. I
>>  wonder if we shouldn't just throw these away, since they're
>>  dead code mostly.
>> 
>>  The following changes since commit
>>  c7ee66a8222660b565e9240775efa4c82cb348c2:
>> 
>>  Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx
>>  into next (2012-10-02 10:16:40 -0700)
>> 
>>  are available in the git repository at:
>> 
>> 
>>  git://git.denx.de/u-boot-usb.git next
>> 
>>  for you to fetch changes up to
>>  f0ede0e8305bc3c959862446bce40cb028b36293:
>> 
>>  usb.h: Add udc_disconnect prototype to usb.h (2012-10-07
>>  02:08:48 +0200)
>> >>>
>> >>> I had to rebase this locally to merge (such is next), and now
>> >>> it's applied to u-boot/next, thanks!
>> >>
>> >> Hmm. Can't "git merge" solve merge conflicts just as well as "git
>> >> rebase"?
>> >>
>> >> 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 don't quite follow that; linux-next is also purely merge-based. Are
>> you referring to the fact that it's re-created every day, and the
>> source branches that go into the merge can be rebased if needed?
> 
> What's the difference between "re-created every day" and "rebased every
> day"?

The linux-next model (and what I mean by "re-created every day") is
roughly the following approximately daily:

git fetch --all
git branch -D tmp
git checkout -b tmp u-boot/master # or latest rc in fact
git merge u-boot-arm/next
git merge u-boot-i2c/next
git merge u-boot-video/next
etc.
git tag next-${datestamp}

I'm not sure what "rebased every day means"; perhaps it's running the
following on u-boot/next every day?

git rebase u-boot/master

That doesn't pull in any new commits from child trees though.

>> Instead, I think u-boot/next is just a place where patches get
>> applied, or branches get merged, before u-boot/master is open to
>> accept new patches for the next release. Unless I'm misunderstanding
>> it purpose of course...
> 
> That was my impression as well.
> 
>> Now, having a linux-next style daily merge of u-boot-*/next would be
>> pretty awesome.
> 
> Not really needed if the main next tree can permanently merge those
> branches.

Yes, if u-boot/next is the collection point where downstream branches
are permanently merged into, and once release N is made, u-boot/master
is reset to (or merged from) u-boot/next, then we effectively are
maintaining branches for two releases in parallel at once, with critical
bugfixes going into u-boot/master for the release, and everything else
going quickly into u-boot/next for the next release. That would
certainly avoid the need for "rebuilding" u-boot/next every day, since
u-boot/next would be very current already.

>> >> It would be awesome if U-Boot could adopt something more similar
>> >> to the Linux kernel's git usage model, namely:
>> >>
>> >> * All downstream branches are based off some known stable point
>> >> in the master branch (e.g. 2012.10-rc1). Before these branches
>> >> are merged into any other branch, they can be rebased if
>> >> absolutely needed, but preferably not.
>> >>
>> >> * Once a downstream branch is merged upwards, the downstream
>> >> branch doesn't merge upstream back down into the downstream
>> >> branch, but either:
>> >>
>> >> a) Keeps adding to the existing branch so that incremental pull
>> >> requests can be sent.
> 
> How does merging back down prevent incremental pull requests?

It doesn't prevent incremental pull requests, but it does pollute the
history if you merge back down. Instead of a fairly simple:

(M* == main branch, B* == side branch)

B1-B2-B3-B4-B5-B6
   /   \\
M1-M2-M3-M4-M4-M5-M6-M7

you might end up with:

B1-B2-B3-B4-X1-B6
   /   \/\
M1-M2-M3-M4-M4-M5-M6-M7

... where X1 is the merge back from main to the side-branch. That
doesn't look a lot more complex, but once there are many side-branches,
and the master branch ends up merging a whole bunch of side-branches
between M4 and M5 above, the commits in B* that add actual new work are
split between a point before the X1 merge-back and after it. 

Re: [U-Boot] [PATCH 3/9] x86: Allow excluding reset handling code from u-boot.

[Graeme Russ]

Hi Simon,

On Wed, Oct 10, 2012 at 10:11 AM, Simon Glass  wrote:

>
> Looks good - yes I will prepare a new series to send likely on Thursday.
>
> Not that it matters for now, but who will define INCLUDE_X86_RESET_VECTOR?

It's calculated in the Makefile as an inversion of  CONFIG_X86_NO_RESET_VECTOR

Regards,

Graeme
___
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

[Graeme Russ]

Hi Tom,

On Wed, Oct 10, 2012 at 9:59 AM, Tom Rini  wrote:
> On Tue, Oct 09, 2012 at 04:14:23PM -0600, Stephen Warren wrote:
>> On 10/09/2012 03:32 PM, Tom Rini wrote:
>> > On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
>> >> On 10/09/2012 08:23 AM, Tom Rini wrote:
>> >>> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
>> >>>
>>  NOTE: I get a few more size issues with ELDK 4.2 on IXP
>>  (that big-endian ARM) after this patchset is applied. I
>>  wonder if we shouldn't just throw these away, since they're
>>  dead code mostly.
>> 
>>  The following changes since commit
>>  c7ee66a8222660b565e9240775efa4c82cb348c2:
>> 
>>  Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx
>>  into next (2012-10-02 10:16:40 -0700)
>> 
>>  are available in the git repository at:
>> 
>> 
>>  git://git.denx.de/u-boot-usb.git next
>> 
>>  for you to fetch changes up to
>>  f0ede0e8305bc3c959862446bce40cb028b36293:
>> 
>>  usb.h: Add udc_disconnect prototype to usb.h (2012-10-07
>>  02:08:48 +0200)
>> >>>
>> >>> I had to rebase this locally to merge (such is next), and now
>> >>> it's applied to u-boot/next, thanks!
>> >>
>> >> Hmm. Can't "git merge" solve merge conflicts just as well as "git
>> >> rebase"?
>> >>
>> >> 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 don't quite follow that; linux-next is also purely merge-based. Are
>> you referring to the fact that it's re-created every day, and the
>> source branches that go into the merge can be rebased if needed?
>
> I'm referring to that it's always rebased on top of Linus' tree.  That's
> what caused the issue here, u-boot-usb was based on top of u-boot/next
> (which is may not have strictly needed to be) so I did the job of
> rebasing for Marek since it was an easy one.
>
>> Instead, I think u-boot/next is just a place where patches get
>> applied, or branches get merged, before u-boot/master is open to
>> accept new patches for the next release. Unless I'm misunderstanding
>> it purpose of course...
>>
>> Now, having a linux-next style daily merge of u-boot-*/next would be
>> pretty awesome.
>
> Well, it's a merge of what people want to get into the next merge
> window, as often as they're willing to submit if they are a custodian or
> as often as I can otherwise.  In fact, right now some pull requests need
> to be on top of next rather than a "stable" point because we're making
> some pretty big cleanups and changes in a few areas right now.

I'm no git guru, so this may not be sane, but here goes:

u-boot-master and $(repo)-master are parallel branches - $(repo)
maintainer merges u-boot-master regularly and applies $(repo) specific
patches to $(repo)-master during the merge window (and critical fixes
during the -rc cycle). Tom merges the various $(repo)-master's into
u-boot-master regularly.

u-boot-next and $(repo)-next are also parallel branches. $(repo)
maintainer merges u-boot-master and $(repo)-master regularly and
applies $(repo) specific patches to $(repo)-master during the -rc
cycle. Tom merges the various $(repo)-next's into u-boot-next
regularly.

Immediately following a release, Tom merges u-boot-next into u-boot-master

Yes, we get lots of merge commits, but the strategy is very straightforward...

One thing I don't know how to resolve is what happens when a
$(repo)-{master, next} does not merge cleanly into u-boot-{master,
next}...

Regards,

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

Re: [U-Boot] [PATCH 3/9] x86: Allow excluding reset handling code from u-boot.

[Simon Glass]

Hi Graeme,

On Tue, Oct 9, 2012 at 3:58 PM, Graeme Russ  wrote:
> Hi Simon,
>
> On Wed, Oct 10, 2012 at 8:15 AM, Simon Glass  wrote:
>
 diff --git a/arch/x86/cpu/resetvec.S b/arch/x86/cpu/resetvec.S
 index 44aee5f..5b359ff 100644
 --- a/arch/x86/cpu/resetvec.S
 +++ b/arch/x86/cpu/resetvec.S
 @@ -25,6 +25,10 @@

  /* Reset vector, jumps to start16.S */

 +#include 
 +
 +#ifndef CONFIG_NO_RESET_CODE
 +
  .extern start16

  .section .resetvec, "ax"
 @@ -36,3 +40,5 @@ reset_vector:

 .org 0xf
 nop
 +
 +#endif
>>>
>>> Condition it out in the Makefile instead
>>
>> I suspect the reason it was done here is these lines in the top-level 
>> Makefile.
>>
>> OBJS  = $(CPUDIR)/start.o
>> ifeq ($(CPU),x86)
>> OBJS += $(CPUDIR)/start16.o
>> OBJS += $(CPUDIR)/resetvec.o
>> endif
>
> I have often wondered about these lines in the top-level Makefile
> considering they are also in arch/x86/cpu/Makefile. I keep meaning to test
> if they are actually needed in the top-level Makefile but keep forgetting
>
> (I see why now - see below)
>
>> If we just take it out of the .lds file then start16.o and resetvec.o
>> are not included in the image. But they will still be built. We could
>> add an additional condition here perhaps, like:
>
> I don't see a huge problem with that. Yes, it's a waste of CPU cycles
> during the build but really, who cares.
>
>> OBJS  = $(CPUDIR)/start.o
>> ifeq ($(CPU),x86)
>> ifneq ($(CONFIG_NO_RESET_CODE),y)
>> OBJS += $(CPUDIR)/start16.o
>> OBJS += $(CPUDIR)/resetvec.o
>> endif
>> endif
>
> Looks good for the time being (again, see beloW).
>
>> Here is the menu as I see it - what would you prefer?
>> - top level Makefile change
>> - arch/arm/cpu/Makefile change (pointless if top level Makefile
>> includes these files anyway)
>> - building everything but removing unneeded object files in the link script
>
> Can we not invert the logic of CONFIG_X86_NO_RESET_VECTOR using some
> Makefile magic and then do this in arch/x86/cpu/Makefile:
>
> START-$(INCLUDE_X86_RESET_VECTOR) += resetvec.o
> START-y = start.o
> START-$(INCLUDE_X86_RESET_VECTOR) += start16.o
>
> Actuall, to be honest, it should be:
>
> SOBJS-y += start.o
>
> SOBJS16-$(INCLUDE_X86_RESET_VECTOR) += resetvec.o
> SOBJS16-$(INCLUDE_X86_RESET_VECTOR) += start16.o
>
> SRCS:= $(SOBJS16-y:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
> OBJS:= $(addprefix $(obj),$(SOBJS) $(COBJS))
> OBJS16  := $(addprefix $(obj),$(SOBJS16))
>
> all:$(obj).depend $(OBJS16) $(LIB)
>
> start.S is not at all related to the reset vector / protected mode switch,
> and so can safely be moved into the main (32-bit) lib. ENTRY(_start) in
> the linker script and:
>
> .section .text
> .code32
> .globl _start
> .type _start, @function  .globl _start
> .type _start, @function
>
> in start.S will always guarantee that the code in start.S appears first
> in u-boot.bin.
>
> Ah Ha! now I get it - Now I see why the top-level Makefile includes:
>
> OBJS  = $(CPUDIR)/start.o
> ifeq ($(CPU),x86)
> OBJS += $(CPUDIR)/start16.o
> OBJS += $(CPUDIR)/resetvec.o
> endif
>
> These files are not in $(CPUDIR)/lib$(CPU).o so they must be pulled in
> individually!
>
> OK, by moving start.o into the lib we can drop the first line...
>
> Now, if we create a 16-bit lib in arch/x86/cpu/Makefile:
>
> LIB = $(obj)lib$(CPU).o
> LIB16   = $(obj)lib16$(CPU).o
>
> SOBJS16-$(INCLUDE_X86_RESET_VECTOR) += resetvec.o
> SOBJS16-$(INCLUDE_X86_RESET_VECTOR) += start16.o
>
> SOBJS-y += start.o
> COBJS-y += cpu.o
> COBJS-y += interrupts.o
>
> SRCS:= $(SOBJS16-y:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
> OBJS16  := $(addprefix $(obj),$(SOBJS16))
> OBJS:= $(addprefix $(obj),$(SOBJS) $(COBJS))
>
> all:$(obj).depend $(LIB) $(LIB16)
>
> $(LIB): $(OBJS)
> $(call cmd_link_o_target, $(OBJS))
>
> $(LIB16): $(OBJS16)
> $(call cmd_link_o_target, $(OBJS16))
>
> And then in the top-level Makefile:
>
> LIBS-$(INCLUDE_X86_RESET_VECTOR) += $(CPUDIR)/lib16$(CPU).o
>
> Much cleaner :)
>
> (Hmmm, looking at arch/x86/lib/Makefile is appears that it is safe to mix
> 16- and 32-bit code in the same lib - maybe that is a better solution...)
>
> But don't worry too much about all that in these patches - Make the changes
> as you have already suggested and I will tweak the rest later

Looks good - yes I will prepare a new series to send likely on Thursday.

Not that it matters for now, but who will define INCLUDE_X86_RESET_VECTOR?

Regards,
Simon

>
> Regards,
>
> Graeme
___
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/09/2012 04:59 PM, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 04:14:23PM -0600, Stephen Warren wrote:
>> On 10/09/2012 03:32 PM, Tom Rini wrote:
>>> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren
>>> wrote:
 On 10/09/2012 08:23 AM, Tom Rini wrote:
> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut
> wrote:
> 
>> NOTE: I get a few more size issues with ELDK 4.2 on IXP 
>> (that big-endian ARM) after this patchset is applied. I 
>> wonder if we shouldn't just throw these away, since
>> they're dead code mostly.
>> 
>> The following changes since commit 
>> c7ee66a8222660b565e9240775efa4c82cb348c2:
>> 
>> Merge branch 'next' of
>> git://www.denx.de/git/u-boot-ppc4xx into next (2012-10-02
>> 10:16:40 -0700)
>> 
>> are available in the git repository at:
>> 
>> 
>> git://git.denx.de/u-boot-usb.git next
>> 
>> for you to fetch changes up to 
>> f0ede0e8305bc3c959862446bce40cb028b36293:
>> 
>> usb.h: Add udc_disconnect prototype to usb.h (2012-10-07 
>> 02:08:48 +0200)
> 
> I had to rebase this locally to merge (such is next), and
> now it's applied to u-boot/next, thanks!
 
 Hmm. Can't "git merge" solve merge conflicts just as well as
 "git rebase"?
 
 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 don't quite follow that; linux-next is also purely merge-based.
>> Are you referring to the fact that it's re-created every day, and
>> the source branches that go into the merge can be rebased if
>> needed?
> 
> I'm referring to that it's always rebased on top of Linus' tree.
> That's what caused the issue here, u-boot-usb was based on top of
> u-boot/next (which is may not have strictly needed to be) so I did
> the job of rebasing for Marek since it was an easy one.
> 
>> Instead, I think u-boot/next is just a place where patches get 
>> applied, or branches get merged, before u-boot/master is open to 
>> accept new patches for the next release. Unless I'm
>> misunderstanding it purpose of course...
>> 
>> Now, having a linux-next style daily merge of u-boot-*/next would
>> be pretty awesome.
> 
> Well, it's a merge of what people want to get into the next merge 
> window, as often as they're willing to submit if they are a
> custodian or as often as I can otherwise.  In fact, right now some
> pull requests need to be on top of next rather than a "stable"
> point because we're making some pretty big cleanups and changes in
> a few areas right now.

So, is u-boot/next purely incremental, or lets say something is merged
in there, then needs to be reworked because of some nasty git bisect
issue say, or some patches need to be taken through different trees
due to dependencies, can the already-merged patches be removed and
replaced with a completely new set, or can only incremental patches be
applied?

I assume u-boot/next isn't rebuilt using fresh merges each time, hence
isn't the linux-next model exactly?

___
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/09/2012 04:19 PM, Albert ARIBAUD wrote:
> Hi Tom,
> 
> On Tue, 9 Oct 2012 14:32:08 -0700, Tom Rini  wrote:
> 
>> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
>>> On 10/09/2012 08:23 AM, Tom Rini wrote:
 On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:

> NOTE: I get a few more size issues with ELDK 4.2 on IXP (that
> big-endian ARM) after this patchset is applied. I wonder if we
> shouldn't just throw these away, since they're dead code mostly.
>
> The following changes since commit
> c7ee66a8222660b565e9240775efa4c82cb348c2:
>
> Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx into
> next (2012-10-02 10:16:40 -0700)
>
> are available in the git repository at:
>
>
> git://git.denx.de/u-boot-usb.git next
>
> for you to fetch changes up to
> f0ede0e8305bc3c959862446bce40cb028b36293:
>
> usb.h: Add udc_disconnect prototype to usb.h (2012-10-07 02:08:48
> +0200)

 I had to rebase this locally to merge (such is next), and now it's 
 applied to u-boot/next, thanks!
>>>
>>> Hmm. Can't "git merge" solve merge conflicts just as well as "git rebase"?
>>>
>>> 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.
>>
>>> It would be awesome if U-Boot could adopt something more similar to
>>> the Linux kernel's git usage model, namely:
>>>
>>> * All downstream branches are based off some known stable point in the
>>> master branch (e.g. 2012.10-rc1). Before these branches are merged
>>> into any other branch, they can be rebased if absolutely needed, but
>>> preferably not.
>>>
>>> * Once a downstream branch is merged upwards, the downstream branch
>>> doesn't merge upstream back down into the downstream branch, but either:
>>>
>>> a) Keeps adding to the existing branch so that incremental pull
>>> requests can be sent.
>>>
>>> Or often when u-boot/master has made a complete new release does:
>>>
>>> b) Creates a new branch based on the latest rc or release from
>>> u-boot/master.
>>>
>>> (in practice, downstream branches typically end up with something like
>>> for-3.5 based on v3.4-rcN, for-3.6 based on v3.5-rcN, for-3.7 based on
>>> v3.6-rcN, some running in parallel containing either important
>>> bugfixes for the release or new development as determined by the
>>> current state of the various releases in the mainline tree).
>>>
>>> * When a branch is merged from a repo to a parent repo, it's always a
>>> git merge --no-ff; never a rebase or fast-forward.
>>>
>>> * In order to resolve merge conflicts/dependencies between different
>>> downstream branches, one of the following happens:
>>>
>>> 1)
>>>
>>> a) The first downstream branch gets merged into u-boot/master.
>>> b) The second downstream branch creates a new branch starting at an an
>>> rc or release in u-boot-master that contains it the required patches.
>>> c) The dependent patches are applied to the second downstream branch.
>>> d) The second downstream branch gets merged into u-boot/master.
>>>
>>> 2)
>>>
>>> All the patches that would usually be merged through downstream branch
>>> 2 actually get ack'd by the maintainer of downstream branch 2 and
>>> applied to downstream branch 1 after the patches they depend on. This
>>> is simplest, but may cause complications if both branches need to take
>>> patches that build on the merged patches they're merged into an rc or
>>> release in u-boot/master.
>>>
>>> 3)
>>>
>>> A topic branch is created by one of the downstream maintainers,
>>> branched from a u-boot/master rc or release, and containing just the
>>> patches that other patches depend on, and this topic branch gets
>>> merged into both the two downstream branches for further work.
>>>
>>> Yes, this does all take a little bit more thought, planning, and
>>> co-ordination, but I think having a simpler and more stable git
>>> history is worth it.
>>
>> Interesting.  As this is more work on the custodians end, what does
>> everyone else say?
> 
> IIUC the current rule for U-Boot is that master branches do not rebase
> while next branches can (as Tom said).
> 
> Apart from this, I'm not sure why forbidding fast-forward is a good
> thing, but if there are benefits, why not.

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).

Related, not rebasing when merging a branch into upstream makes
validating Signed-off-by a lot easier; when 

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

[Graeme Russ]

Hi Albert,

On Wed, Oct 10, 2012 at 9:43 AM, Albert ARIBAUD
 wrote:
> Hi Stephen,
>
> On Tue, 09 Oct 2012 16:14:23 -0600, Stephen Warren
>  wrote:
>
>> This actually turns out to be less work for custodians if there aren't
>> any dependencies between patch series, since whenever you send a pull
>> request right now, you do:
>>
>> a) Fetch latest upstream.
>> b) Rebase onto it.
>> c) Send pull request.
>
> Uh, no, you don't rebase. I've learnt that well. :)

Yes, I learn't that the hard way :)

> But I suspect the Wiki page is still lagging behind.

Yes because, to some extent at least, maintainers have a certain
amount of latitude in how they manage their own repository. The whole
rebase against master theory came about, I think, to avoid the
maintainer repositories being littered with merge commits (which I
assume adds more merge commits to mainline). I personally don't have
an issue with merge commits - YMMV

Regards,

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

Re: [U-Boot] [PATCH V2 3/3] FAT: implement fat_set_blk_dev(), convert cmd_fat.c

[Benoît Thébaudeau]

Hi Stephen,

See my comments inlined below.

On Tuesday, October 9, 2012 10:41:41 PM, Stephen Warren wrote:
> This makes the FAT filesystem API more consistent with other
> block-based
> filesystems. If in the future standard multi-filesystem commands such
> as
> "ls" or "load" are implemented, having FAT work the same way as other
> filesystems will be necessary.
> 
> Convert cmd_fat.c to the new API, so the code looks more like other
> files
> implementing the same commands for other filesystems.
> 
> Signed-off-by: Stephen Warren 
> ---
> v2: Fix inverted test of get_partition_info() result in
> fat_register_device().
> ---
>  common/cmd_fat.c |8 +++---
>  fs/fat/fat.c |   65
>  ++---
>  include/fat.h|1 +
>  3 files changed, 37 insertions(+), 37 deletions(-)
> 
> diff --git a/common/cmd_fat.c b/common/cmd_fat.c
> index 5a5698b..c38302d 100644
> --- a/common/cmd_fat.c
> +++ b/common/cmd_fat.c
> @@ -55,7 +55,7 @@ int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
>   return 1;
>  
>   dev = dev_desc->dev;
> - if (fat_register_device(dev_desc,part)!=0) {
> + if (fat_set_blk_dev(dev_desc, &info) != 0) {
>   printf("\n** Unable to use %s %d:%d for fatload **\n",
>   argv[1], dev, part);
>   return 1;
> @@ -111,7 +111,7 @@ int do_fat_ls (cmd_tbl_t *cmdtp, int flag, int
> argc, char * const argv[])
>   return 1;
>  
>   dev = dev_desc->dev;
> - if (fat_register_device(dev_desc,part)!=0) {
> + if (fat_set_blk_dev(dev_desc, &info) != 0) {
>   printf("\n** Unable to use %s %d:%d for fatls **\n",
>   argv[1], dev, part);
>   return 1;
> @@ -149,7 +149,7 @@ int do_fat_fsinfo (cmd_tbl_t *cmdtp, int flag,
> int argc, char * const argv[])
>   return 1;
>  
>   dev = dev_desc->dev;
> - if (fat_register_device(dev_desc,part)!=0) {
> + if (fat_set_blk_dev(dev_desc, &info) != 0) {
>   printf("\n** Unable to use %s %d:%d for fatinfo **\n",
>   argv[1], dev, part);
>   return 1;
> @@ -185,7 +185,7 @@ static int do_fat_fswrite(cmd_tbl_t *cmdtp, int
> flag,
>  
>   dev = dev_desc->dev;
>  
> - if (fat_register_device(dev_desc, part) != 0) {
> + if (fat_set_blk_dev(dev_desc, &info) != 0) {
>   printf("\n** Unable to use %s %d:%d for fatwrite **\n",
>   argv[1], dev, part);
>   return 1;
> diff --git a/fs/fat/fat.c b/fs/fat/fat.c
> index 1e0d2a3..79e66ce 100644
> --- a/fs/fat/fat.c
> +++ b/fs/fat/fat.c
> @@ -61,42 +61,12 @@ static int disk_read(__u32 block, __u32
> nr_blocks, void *buf)
>   cur_part_info.start + block, nr_blocks, buf);
>  }
>  
> -int fat_register_device(block_dev_desc_t * dev_desc, int part_no)
> +int fat_set_blk_dev(block_dev_desc_t *dev_desc, disk_partition_t
> *info)
>  {
>   ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
>  
> - /* First close any currently found FAT filesystem */
> - cur_dev = NULL;
> -
> -#if (defined(CONFIG_CMD_IDE) || \
> - defined(CONFIG_CMD_SATA) || \
> - defined(CONFIG_CMD_SCSI) || \
> - defined(CONFIG_CMD_USB) || \
> - defined(CONFIG_MMC) || \
> - defined(CONFIG_SYSTEMACE) )
> -
> - /* Read the partition table, if present */
> - if (!get_partition_info(dev_desc, part_no, &cur_part_info)) {
> - cur_dev = dev_desc;
> - }
> -#endif
> -
> - /* Otherwise it might be a superfloppy (whole-disk FAT filesystem)
> */
> - if (!cur_dev) {
> - if (part_no != 0) {
> - printf("** Partition %d not valid on device %d **\n",
> - part_no, dev_desc->dev);
> - return -1;
> - }
> -
> - cur_dev = dev_desc;
> - cur_part_info.part = 0;
> - cur_part_info.start = 0;
> - cur_part_info.size = dev_desc->lba;
> - cur_part_info.blksz = dev_desc->blksz;
> - memset(cur_part_info.name, 0, sizeof(cur_part_info.name));
> - memset(cur_part_info.type, 0, sizeof(cur_part_info.type));
> - }
> + cur_dev = dev_desc;
> + cur_part_info = *info;
>  
>   /* Make sure it has a valid FAT header */
>   if (disk_read(0, 1, buffer) != 1) {
> @@ -120,6 +90,35 @@ int fat_register_device(block_dev_desc_t *
> dev_desc, int part_no)
>   return -1;
>  }
>  
> +int fat_register_device(block_dev_desc_t *dev_desc, int part_no)
> +{
> + disk_partition_t info;
> +
> + /* First close any currently found FAT filesystem */
> + cur_dev = NULL;
> +
> + /* Read the partition table, if present */
> + if (get_partition_info(dev_desc, part_no, &info)) {
> + if (part_no != 0) {
> + printf("** Partition %d not valid on device %d **\n",
> + 

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

[Scott Wood]

On 10/09/2012 05:14:23 PM, Stephen Warren wrote:

On 10/09/2012 03:32 PM, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
>> On 10/09/2012 08:23 AM, Tom Rini wrote:
>>> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
>>>
 NOTE: I get a few more size issues with ELDK 4.2 on IXP
 (that big-endian ARM) after this patchset is applied. I
 wonder if we shouldn't just throw these away, since they're
 dead code mostly.

 The following changes since commit
 c7ee66a8222660b565e9240775efa4c82cb348c2:

 Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx
 into next (2012-10-02 10:16:40 -0700)

 are available in the git repository at:


 git://git.denx.de/u-boot-usb.git next

 for you to fetch changes up to
 f0ede0e8305bc3c959862446bce40cb028b36293:

 usb.h: Add udc_disconnect prototype to usb.h (2012-10-07
 02:08:48 +0200)
>>>
>>> I had to rebase this locally to merge (such is next), and now
>>> it's applied to u-boot/next, thanks!
>>
>> Hmm. Can't "git merge" solve merge conflicts just as well as "git
>> rebase"?
>>
>> 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 don't quite follow that; linux-next is also purely merge-based. Are
you referring to the fact that it's re-created every day, and the
source branches that go into the merge can be rebased if needed?


What's the difference between "re-created every day" and "rebased every  
day"?



Instead, I think u-boot/next is just a place where patches get
applied, or branches get merged, before u-boot/master is open to
accept new patches for the next release. Unless I'm misunderstanding
it purpose of course...


That was my impression as well.


Now, having a linux-next style daily merge of u-boot-*/next would be
pretty awesome.


Not really needed if the main next tree can permanently merge those  
branches.



>> It would be awesome if U-Boot could adopt something more similar
>> to the Linux kernel's git usage model, namely:
>>
>> * All downstream branches are based off some known stable point
>> in the master branch (e.g. 2012.10-rc1). Before these branches
>> are merged into any other branch, they can be rebased if
>> absolutely needed, but preferably not.
>>
>> * Once a downstream branch is merged upwards, the downstream
>> branch doesn't merge upstream back down into the downstream
>> branch, but either:
>>
>> a) Keeps adding to the existing branch so that incremental pull
>> requests can be sent.


How does merging back down prevent incremental pull requests?


>> Or often when u-boot/master has made a complete new release
>> does:
>>
>> b) Creates a new branch based on the latest rc or release from
>> u-boot/master.


That's a rebase.  How is that better than a (likely fast-forward) merge?


>> (in practice, downstream branches typically end up with something
>> like for-3.5 based on v3.4-rcN, for-3.6 based on v3.5-rcN,
>> for-3.7 based on v3.6-rcN, some running in parallel containing
>> either important bugfixes for the release or new development as
>> determined by the current state of the various releases in the
>> mainline tree).


I thought you said your way was less work? :-)


>> * When a branch is merged from a repo to a parent repo, it's
>> always a git merge --no-ff; never a rebase or fast-forward.
>>
>> * In order to resolve merge conflicts/dependencies between
>> different downstream branches, one of the following happens:
>>
>> 1)
>>
>> a) The first downstream branch gets merged into u-boot/master. b)
>> The second downstream branch creates a new branch starting at an
>> an rc or release in u-boot-master that contains it the required
>> patches. c) The dependent patches are applied to the second
>> downstream branch. d) The second downstream branch gets merged
>> into u-boot/master.
>>
>> 2)
>>
>> All the patches that would usually be merged through downstream
>> branch 2 actually get ack'd by the maintainer of downstream
>> branch 2 and applied to downstream branch 1 after the patches
>> they depend on. This is simplest, but may cause complications if
>> both branches need to take patches that build on the merged
>> patches they're merged into an rc or release in u-boot/master.
>>
>> 3)
>>
>> A topic branch is created by one of the downstream maintainers,
>> branched from a u-boot/master rc or release, and containing just
>> the patches that other patches depend on, and this topic branch
>> gets merged into both the two downstream branches for further
>> work.
>>
>> Yes,

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

[Tom Rini]

On Tue, Oct 09, 2012 at 04:14:23PM -0600, Stephen Warren wrote:
> On 10/09/2012 03:32 PM, Tom Rini wrote:
> > On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
> >> On 10/09/2012 08:23 AM, Tom Rini wrote:
> >>> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
> >>> 
>  NOTE: I get a few more size issues with ELDK 4.2 on IXP
>  (that big-endian ARM) after this patchset is applied. I
>  wonder if we shouldn't just throw these away, since they're
>  dead code mostly.
>  
>  The following changes since commit 
>  c7ee66a8222660b565e9240775efa4c82cb348c2:
>  
>  Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx
>  into next (2012-10-02 10:16:40 -0700)
>  
>  are available in the git repository at:
>  
>  
>  git://git.denx.de/u-boot-usb.git next
>  
>  for you to fetch changes up to 
>  f0ede0e8305bc3c959862446bce40cb028b36293:
>  
>  usb.h: Add udc_disconnect prototype to usb.h (2012-10-07
>  02:08:48 +0200)
> >>> 
> >>> I had to rebase this locally to merge (such is next), and now
> >>> it's applied to u-boot/next, thanks!
> >> 
> >> Hmm. Can't "git merge" solve merge conflicts just as well as "git
> >> rebase"?
> >> 
> >> 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 don't quite follow that; linux-next is also purely merge-based. Are
> you referring to the fact that it's re-created every day, and the
> source branches that go into the merge can be rebased if needed?

I'm referring to that it's always rebased on top of Linus' tree.  That's
what caused the issue here, u-boot-usb was based on top of u-boot/next
(which is may not have strictly needed to be) so I did the job of
rebasing for Marek since it was an easy one.

> Instead, I think u-boot/next is just a place where patches get
> applied, or branches get merged, before u-boot/master is open to
> accept new patches for the next release. Unless I'm misunderstanding
> it purpose of course...
> 
> Now, having a linux-next style daily merge of u-boot-*/next would be
> pretty awesome.

Well, it's a merge of what people want to get into the next merge
window, as often as they're willing to submit if they are a custodian or
as often as I can otherwise.  In fact, right now some pull requests need
to be on top of next rather than a "stable" point because we're making
some pretty big cleanups and changes in a few areas right now.

-- 
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 3/9] x86: Allow excluding reset handling code from u-boot.

[Graeme Russ]

Hi Simon,

On Wed, Oct 10, 2012 at 8:15 AM, Simon Glass  wrote:

>>> diff --git a/arch/x86/cpu/resetvec.S b/arch/x86/cpu/resetvec.S
>>> index 44aee5f..5b359ff 100644
>>> --- a/arch/x86/cpu/resetvec.S
>>> +++ b/arch/x86/cpu/resetvec.S
>>> @@ -25,6 +25,10 @@
>>>
>>>  /* Reset vector, jumps to start16.S */
>>>
>>> +#include 
>>> +
>>> +#ifndef CONFIG_NO_RESET_CODE
>>> +
>>>  .extern start16
>>>
>>>  .section .resetvec, "ax"
>>> @@ -36,3 +40,5 @@ reset_vector:
>>>
>>> .org 0xf
>>> nop
>>> +
>>> +#endif
>>
>> Condition it out in the Makefile instead
>
> I suspect the reason it was done here is these lines in the top-level 
> Makefile.
>
> OBJS  = $(CPUDIR)/start.o
> ifeq ($(CPU),x86)
> OBJS += $(CPUDIR)/start16.o
> OBJS += $(CPUDIR)/resetvec.o
> endif

I have often wondered about these lines in the top-level Makefile
considering they are also in arch/x86/cpu/Makefile. I keep meaning to test
if they are actually needed in the top-level Makefile but keep forgetting

(I see why now - see below)

> If we just take it out of the .lds file then start16.o and resetvec.o
> are not included in the image. But they will still be built. We could
> add an additional condition here perhaps, like:

I don't see a huge problem with that. Yes, it's a waste of CPU cycles
during the build but really, who cares.

> OBJS  = $(CPUDIR)/start.o
> ifeq ($(CPU),x86)
> ifneq ($(CONFIG_NO_RESET_CODE),y)
> OBJS += $(CPUDIR)/start16.o
> OBJS += $(CPUDIR)/resetvec.o
> endif
> endif

Looks good for the time being (again, see beloW).

> Here is the menu as I see it - what would you prefer?
> - top level Makefile change
> - arch/arm/cpu/Makefile change (pointless if top level Makefile
> includes these files anyway)
> - building everything but removing unneeded object files in the link script

Can we not invert the logic of CONFIG_X86_NO_RESET_VECTOR using some
Makefile magic and then do this in arch/x86/cpu/Makefile:

START-$(INCLUDE_X86_RESET_VECTOR) += resetvec.o
START-y = start.o
START-$(INCLUDE_X86_RESET_VECTOR) += start16.o

Actuall, to be honest, it should be:

SOBJS-y += start.o

SOBJS16-$(INCLUDE_X86_RESET_VECTOR) += resetvec.o
SOBJS16-$(INCLUDE_X86_RESET_VECTOR) += start16.o

SRCS:= $(SOBJS16-y:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS:= $(addprefix $(obj),$(SOBJS) $(COBJS))
OBJS16  := $(addprefix $(obj),$(SOBJS16))

all:$(obj).depend $(OBJS16) $(LIB)

start.S is not at all related to the reset vector / protected mode switch,
and so can safely be moved into the main (32-bit) lib. ENTRY(_start) in
the linker script and:

.section .text
.code32
.globl _start
.type _start, @function  .globl _start
.type _start, @function

in start.S will always guarantee that the code in start.S appears first
in u-boot.bin.

Ah Ha! now I get it - Now I see why the top-level Makefile includes:

OBJS  = $(CPUDIR)/start.o
ifeq ($(CPU),x86)
OBJS += $(CPUDIR)/start16.o
OBJS += $(CPUDIR)/resetvec.o
endif

These files are not in $(CPUDIR)/lib$(CPU).o so they must be pulled in
individually!

OK, by moving start.o into the lib we can drop the first line...

Now, if we create a 16-bit lib in arch/x86/cpu/Makefile:

LIB = $(obj)lib$(CPU).o
LIB16   = $(obj)lib16$(CPU).o

SOBJS16-$(INCLUDE_X86_RESET_VECTOR) += resetvec.o
SOBJS16-$(INCLUDE_X86_RESET_VECTOR) += start16.o

SOBJS-y += start.o
COBJS-y += cpu.o
COBJS-y += interrupts.o

SRCS:= $(SOBJS16-y:.o=.S) $(SOBJS-y:.o=.S) $(COBJS-y:.o=.c)
OBJS16  := $(addprefix $(obj),$(SOBJS16))
OBJS:= $(addprefix $(obj),$(SOBJS) $(COBJS))

all:$(obj).depend $(LIB) $(LIB16)

$(LIB): $(OBJS)
$(call cmd_link_o_target, $(OBJS))

$(LIB16): $(OBJS16)
$(call cmd_link_o_target, $(OBJS16))

And then in the top-level Makefile:

LIBS-$(INCLUDE_X86_RESET_VECTOR) += $(CPUDIR)/lib16$(CPU).o

Much cleaner :)

(Hmmm, looking at arch/x86/lib/Makefile is appears that it is safe to mix
16- and 32-bit code in the same lib - maybe that is a better solution...)

But don't worry too much about all that in these patches - Make the changes
as you have already suggested and I will tweak the rest later

Regards,

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

Re: [U-Boot] [PATCH 0/4 V2] Implant kernel-doc from Linux kernel

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/09/12 15:37, Marek Vasut wrote:
> Dear Tom Rini,
> 
>> On Sun, Sep 30, 2012 at 02:21:31AM +0200, Marek Vasut wrote:
>>> This patch series implants slightly modified kernel-doc 
>>> documentation generator from Linux kernel into U-Boot. First 
>>> patch pulls in all the necessary components with minor 
>>> modifications made to them to work with the layout of U-Boot 
>>> source tree and without kbuild.
>>> 
>>> Further patch implement CSS to make the HTML documentation
>>> look a bit nicer. This patch will eventually (hopefully) be
>>> further refined by someone more artistically capable than me
>>> ;-)
>>> 
>>> Next patch implements separate handling for "Example:"
>>> section, which in the original kernel-doc was in my opinion
>>> mistreated. The example section generated a block of code, but
>>> the indentation was removed. Thus this patch does avoid
>>> removing the indent.
>>> 
>>> Finally, the last patch implements example of how to use this 
>>> kernel-doc to generate U-Boot documentation by documenting the 
>>> Linker-Generated arrays.
>>> 
>>> NOTE: This patchset (last patch) has a cross-dependency on: 
>>> [PATCH 0/5] Linker-generated arrays (take 2)
>>> 
>>> V2: Add proper .gitignore entries, fix build issues (fix 
>>> Makefiles)
>> 
>> Applied to u-boot/next, thanks!
> 
> Good, now it is imperative to discuss the rules. Can you check my 
> proposal for wiki addendum?

Done, and for clarity I did apply the v3 series, not v2.  Just replied
to the wrong summary.

- -- 
Tom

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

iQIcBAEBAgAGBQJQdKpcAAoJENk4IS6UOR1WefEP/02YKDZmHMOydwCCmvQchCXY
+eaNjr+Ivp7D8q2IRNoXjNocPJJqwWP3OtOrjWkqMumFSXz8skbzHv88dtMEWEWr
V+2haSSLAv7+bcaNzKtNVokvifHOPv9BGKQ9reujFc3/K1qJvznqflORxj8pzMJb
IoyudOywLZpZnFE4C+TcoRlTlGZQyKiDka/fgAuW0B40+PU9E4XVrlWVuKW19jx2
h1vISn9/tzxMjzQNaDMt5q6gLXXQHxmx935BOdOvK6oy/et9fWiL/c+pjCCpOWSt
MOgrS3m//NI7l//mqK+v1HXRskAo0FOfQVDdXlIYZfrsy87der+6+51hq5ZBmZG3
ZeQX4hsX49iPNQUAL5oqgKzrT2DOcAfPYcO7Stvc5yDuMwcP5TZr4lM/byPsRt9t
t3A0FD9d1KHsUIXq9aoaagTOEGTIvIxafUsEpj2TeNx5hEkNJ+QvcR9kNOQPl7/5
Pw0MeG0lc/uCPoWfh+0l8aZQK62Nv73xPFhTjFjxuqyExkKZV+sblnTLxoHAK58n
iomFJuGEPkqfFxl8vciMSw4HtHljoiE7tPR/LQhUW0GLx/GPr17gFCrj8CGIRbcE
XXSzaZidubTldZHhLasvwcWq3dAdNS9rue39xk5LBDCMdnfBGrrOT+ET9RL9tw4m
aEULcH1AagfrnoB6fYLf
=K7hF
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] KernelDoc

[Tom Rini]

On Mon, Oct 01, 2012 at 12:37:26PM +0200, Marek Vasut wrote:
> Dear Wolfgang Denk,
> 
> > Dear Marek Vasut,
> > 
> > In message <201210011107.45164.ma...@denx.de> you wrote:
> > > Agreed, not the whole file. But, can you check the rules I tried to
> > > outline?
> > 
> > Is there a summary somewhere?  Something we could add to the wiki?
> 
> I sent this on friday:
> 
> So I've been hacking on it for a bit, see the first stab at [1]. As for the 
> ruleset, I propose this addition for the Wiki [2]:
> 
> -->8--
> 
> U-Boot code documentation
> =
> 
> U-Boot adopted the kernel-doc annotation style, this is the only exception 
> from 
> multi-line comment rule of Coding Style. While not mandatory, adding 
> documentation is strongly advised. The Linux kernel kernel-doc document [3] 
> appliest with no changes.
> 
> --8<--
> 
> [1] http://twilight.ponies.cz/kerneldoc/
> [2] http://www.denx.de/wiki/U-Boot/CodingStyle
> [3] 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/kernel-
> doc-nano-HOWTO.txt

Make it so.

-- 
Tom


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

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

[Marek Vasut]

Add memory barrier to cache invalidate and flush calls.

Signed-off-by: Marek Vasut 
CC: Albert Aribaud 
Cc: Fabio Estevam 
Cc: Otavio Salvador 
Cc: Stefano Babic 
---
 arch/arm/cpu/arm926ejs/cache.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c
index 2740ad7..1c67608 100644
--- a/arch/arm/cpu/arm926ejs/cache.c
+++ b/arch/arm/cpu/arm926ejs/cache.c
@@ -30,7 +30,7 @@
 
 void invalidate_dcache_all(void)
 {
-   asm volatile("mcr p15, 0, %0, c7, c6, 0\n" : : "r"(0));
+   asm volatile("mcr p15, 0, %0, c7, c6, 0\n" : : "r"(0) : "memory");
 }
 
 void flush_dcache_all(void)
@@ -67,7 +67,8 @@ void invalidate_dcache_range(unsigned long start, unsigned 
long stop)
return;
 
while (start < stop) {
-   asm volatile("mcr p15, 0, %0, c7, c6, 1\n" : : "r"(start));
+   asm volatile("mcr p15, 0, %0, c7, c6, 1\n"
+   : : "r"(start) : "memory");
start += CONFIG_SYS_CACHELINE_SIZE;
}
 }
@@ -78,11 +79,12 @@ void flush_dcache_range(unsigned long start, unsigned long 
stop)
return;
 
while (start < stop) {
-   asm volatile("mcr p15, 0, %0, c7, c14, 1\n" : : "r"(start));
+   asm volatile("mcr p15, 0, %0, c7, c14, 1\n"
+   : : "r"(start) : "memory");
start += CONFIG_SYS_CACHELINE_SIZE;
}
 
-   asm volatile("mcr p15, 0, %0, c7, c10, 4\n" : : "r"(0));
+   asm volatile("mcr p15, 0, %0, c7, c10, 4\n" : : "r"(0) : "memory");
 }
 
 void flush_cache(unsigned long start, unsigned long size)
-- 
1.7.10.4

___
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 Tue, 09 Oct 2012 16:14:23 -0600, Stephen Warren
 wrote:

> This actually turns out to be less work for custodians if there aren't
> any dependencies between patch series, since whenever you send a pull
> request right now, you do:
> 
> a) Fetch latest upstream.
> b) Rebase onto it.
> c) Send pull request.

Uh, no, you don't rebase. I've learnt that well. :)

But I suspect the Wiki page is still lagging behind.

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

[U-Boot] [PATCH] FEC: Rework RX buffer init

[Marek Vasut]

Rework the RX buffer init so that it's easier to understand.
Firstly, allocate the whole RX buffer as one large continuous
piece of memory. Also, drop all these writel() accessors used
on the FEC RX DMA descriptor, since it's all flat bogus.

Finally, this makes recoverable stalls of the FEC on i.MX28
disappear completely.

Also, it removes whole 80 bytes from the size of u-boot!
(Tested with Debian GCC 4.7.1-3)

Signed-off-by: Marek Vasut 
Cc: Fabio Estevam 
Cc: Joe Hershberger 
Cc: Otavio Salvador 
Cc: Stefano Babic 
---
 drivers/net/fec_mxc.c |   47 ---
 1 file changed, 20 insertions(+), 27 deletions(-)

diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 3e232c7..1897397 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -289,43 +289,36 @@ static int fec_tx_task_disable(struct fec_priv *fec)
  */
 static int fec_rbd_init(struct fec_priv *fec, int count, int dsize)
 {
+   struct fec_bd *rbd = fec->rbd_base;
uint32_t size;
+   void *mem;
int i;
 
-   /*
-* Allocate memory for the buffers. This allocation respects the
-* alignment
-*/
-   size = roundup(dsize, ARCH_DMA_MINALIGN);
+   if (!rbd->data_pointer) {
+   /*
+* Allocate memory for the buffers. This allocation
+* respects the alignment.
+*/
+   size = roundup(dsize, ARCH_DMA_MINALIGN);
+   mem = memalign(ARCH_DMA_MINALIGN, size * count);
+   if (!mem)
+   return -ENOMEM;
+
+   for (i = 0; i < count; i++)
+   rbd[i].data_pointer = (uint32_t)(mem + size * i);
+   }
+
for (i = 0; i < count; i++) {
-   uint32_t data_ptr = readl(&fec->rbd_base[i].data_pointer);
-   if (data_ptr == 0) {
-   uint8_t *data = memalign(ARCH_DMA_MINALIGN,
-size);
-   if (!data) {
-   printf("%s: error allocating rxbuf %d\n",
-  __func__, i);
-   goto err;
-   }
-   writel((uint32_t)data, &fec->rbd_base[i].data_pointer);
-   } /* needs allocation */
-   writew(FEC_RBD_EMPTY, &fec->rbd_base[i].status);
-   writew(0, &fec->rbd_base[i].data_length);
+   fec->rbd_base[i].status = FEC_RBD_EMPTY;
+   fec->rbd_base[i].data_length = 0;
}
 
/* Mark the last RBD to close the ring. */
-   writew(FEC_RBD_WRAP | FEC_RBD_EMPTY, &fec->rbd_base[i - 1].status);
+   fec->rbd_base[count - 1].status |= FEC_RBD_WRAP;
+
fec->rbd_index = 0;
 
return 0;
-
-err:
-   for (; i >= 0; i--) {
-   uint32_t data_ptr = readl(&fec->rbd_base[i].data_pointer);
-   free((void *)data_ptr);
-   }
-
-   return -ENOMEM;
 }
 
 /**
-- 
1.7.10.4

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

Re: [U-Boot] [PATCH 0/4 V2] Implant kernel-doc from Linux kernel

[Marek Vasut]

Dear Tom Rini,

> On Sun, Sep 30, 2012 at 02:21:31AM +0200, Marek Vasut wrote:
> > This patch series implants slightly modified kernel-doc documentation
> > generator from Linux kernel into U-Boot. First patch pulls in all the
> > necessary components with minor modifications made to them to work with
> > the layout of U-Boot source tree and without kbuild.
> > 
> > Further patch implement CSS to make the HTML documentation look a bit
> > nicer. This patch will eventually (hopefully) be further refined by
> > someone more artistically capable than me ;-)
> > 
> > Next patch implements separate handling for "Example:" section, which
> > in the original kernel-doc was in my opinion mistreated. The example
> > section generated a block of code, but the indentation was removed.
> > Thus this patch does avoid removing the indent.
> > 
> > Finally, the last patch implements example of how to use this kernel-doc
> > to generate U-Boot documentation by documenting the Linker-Generated
> > arrays.
> > 
> > NOTE: This patchset (last patch) has a cross-dependency on:
> > [PATCH 0/5] Linker-generated arrays (take 2)
> > 
> > V2: Add proper .gitignore entries, fix build issues (fix Makefiles)
> 
> Applied to u-boot/next, thanks!

Good, now it is imperative to discuss the rules. Can you check my proposal for 
wiki addendum?

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 0/4 V2] Implant kernel-doc from Linux kernel

[Tom Rini]

On Sun, Sep 30, 2012 at 02:21:31AM +0200, Marek Vasut wrote:

> This patch series implants slightly modified kernel-doc documentation
> generator from Linux kernel into U-Boot. First patch pulls in all the
> necessary components with minor modifications made to them to work with
> the layout of U-Boot source tree and without kbuild.
> 
> Further patch implement CSS to make the HTML documentation look a bit
> nicer. This patch will eventually (hopefully) be further refined by
> someone more artistically capable than me ;-)
> 
> Next patch implements separate handling for "Example:" section, which
> in the original kernel-doc was in my opinion mistreated. The example
> section generated a block of code, but the indentation was removed.
> Thus this patch does avoid removing the indent.
> 
> Finally, the last patch implements example of how to use this kernel-doc
> to generate U-Boot documentation by documenting the Linker-Generated
> arrays.
> 
> NOTE: This patchset (last patch) has a cross-dependency on:
> [PATCH 0/5] Linker-generated arrays (take 2)
> 
> V2: Add proper .gitignore entries, fix build issues (fix Makefiles)

Applied to u-boot/next, thanks!

-- 
Tom


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

[U-Boot] h2200 fails to build on current u-boot/next (was: Pull request: u-boot-arm/next into u-boot/next)

[Albert ARIBAUD]

Hi Łukasz,

On Tue, 9 Oct 2012 14:45:33 -0700, Tom Rini  wrote:

> On Tue, Oct 09, 2012 at 05:34:13PM +0200, Albert ARIBAUD wrote:
> 
> > Hi Tom,
> > 
> > The following changes since commit 661c21dd46e857b74682b0610d83cfea7f3ac3c2:
> > 
> >   usb.h: Add udc_disconnect prototype to usb.h (2012-10-08 18:01:17 -0700)
> > 
> > are available in the git repository at:
> > 
> >   git://git.denx.de/u-boot-arm next
> > 
> > for you to fetch changes up to 0d6b8f29a3c59306d6cd8f2baa92897f56b06695:
> > 
> >   configs: mx6qsabre_common.h: Use default clock definitions (2012-10-09 
> > 16:52:18 +0200)
> [snip]
> > Lukasz Dalek (2):
> >   h2200: Add support for iPAQ h2200 palmtop
> 
> This doesn't compile in next due to not having been updated for the
> serial changes:
> serial_pxa.c:297:2: error: #error "Bad CONFIG_CONS_INDEX."
> 
> Do you want me to pull or do you want to fix this first?  Thanks.

Cc:ing Marek as PXA custodian and serial patcher...

Łukasz, can you have a look at why h2200 above u-boot/next fails to
build, and can you quickly provide a new patch version to fix it?

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/next into u-boot/next

[Tom Rini]

On Tue, Oct 09, 2012 at 05:34:13PM +0200, Albert ARIBAUD wrote:

> Hi Tom,
> 
> The following changes since commit 661c21dd46e857b74682b0610d83cfea7f3ac3c2:
> 
>   usb.h: Add udc_disconnect prototype to usb.h (2012-10-08 18:01:17 -0700)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arm next
> 
> for you to fetch changes up to 0d6b8f29a3c59306d6cd8f2baa92897f56b06695:
> 
>   configs: mx6qsabre_common.h: Use default clock definitions (2012-10-09 
> 16:52:18 +0200)
> 
> 
> Beno??t Th??baudeau (26):
>   mx5/6: Define default SoC input clock frequencies
>   mx5 clocks: Cleanup
>   mx5: Use explicit clock gate names
>   mx5: Fix clock gate values
>   mx51: Fix USB PHY clocks
>   mx5 clocks: Add and use CCSR definitions
>   mx5 clocks: Fix get_lp_apm()
>   mx5 clocks: Fix get_periph_clk()
>   mx5 clocks: Fix get_ipg_per_clk()
>   mx5 clocks: Fix get_uart_clk()
>   mx5 clocks: Simplify imx_get_cspiclk()
>   mx5 clocks: Fix MXC_FEC_CLK
>   mx51: Fix I2C clock ID check
>   mx5/6 clocks: Fix SDHC clocks
>   mx25: Fix decode_pll
>   mx25: Clean up clock calculations
>   mx25: Define more standard clocks
>   mx25 clocks: Fix MXC_FEC_CLK
>   mx25: Clean up clocks API
>   mx25: Define cpu_eth_init() only if needed
>   mx25: Fix eSDHC support
>   mx5: Optimize lowlevel_init code size
>   mx31: Add more CCM access macros
>   mx35: Define MAX and AIPS registers
>   mx31: Fix PDR0_CSI_PODF
>   mx25: Clean up lowlevel_init
> 
> Eric Benard (1):
>   mx25: add CPU revision 1.2
> 
> Eric Nelson (7):
>   i.MX6: provide functional names for CCM_CCGR0-CCGR6 bit fields
>   i.MX6: change register name for CCM_CHSCCDR to match ref. manual
>   i.MX6: define bitfields for CHSCCDR register
>   i.MX6: define IOMUX_GPR3 register bitfields
>   i.MX6: Add ANATOP_PFD_480 bitfield constants
>   i.MX6: define struct iomuxc and IOMUX_GPR2 register bitfields
>   i.MX6: get rid of redundant struct src_regs (dupe of struct src)
> 
> Fabio Estevam (8):
>   mx6q: Factor out common DDR3 init code
>   mx6: Add basic support for mx6qsabresd board.
>   mx6qsabresd: Add Ethernet support
>   mx6qsabresd: Add 8-bit USDHC support
>   configs: mx6: Add a common config file
>   mx6q: Add basic support for mx6qsabreauto
>   mx6qsabreauto: Add Ethernet support
>   configs: mx6qsabre_common.h: Use default clock definitions
> 
> Lucas Stach (6):
>   tegra20: complete periph_id enum
>   tegra20: add clock_set_pllout function
>   tegra20: rework UART GPIO handling
>   tegra: add funcmux entry for NAND attached to KBC
>   tegra: clean up board include hell
>   tegra: nand: add board pinmux
> 
> Lukasz Dalek (2):
>   h2200: Add support for iPAQ h2200 palmtop
>   pxa: Add code to examine cpu model and revision
> 
> Matthias Weisser (1):
>   imx: Use MXC_I2C_CLK in imx i2c driver
> 
> Otavio Salvador (1):
>   mx6qsabreauto: Use ttymxc3 as console
> 
> Stephen Warren (1):
>   tegra: enable CONFIG_CMD_PART
> 
> Thierry Reding (2):
>   tegra: Update Avionic Design vendor prefix
>   tegra: Rename Medcom to Medcom-Wide
> 
> Tom Warren (2):
>   Tegra20: Move some code files to common directories for upcoming 
> Tegra30 patches.
>   Tegra20: Move some include files to arch-tegra for sharing with Tegra30
> 
>  MAINTAINERS|4 +-
>  Makefile   |2 +
>  arch/arm/cpu/arm1136/mx31/generic.c|1 +
>  arch/arm/cpu/arm1136/mx35/asm-offsets.c|   33 +-
>  arch/arm/cpu/arm1136/mx35/generic.c|1 +
>  arch/arm/cpu/arm720t/tegra-common/Makefile |   47 ++
>  .../cpu/arm720t/{tegra20 => tegra-common}/cpu.h|0
>  .../cpu/arm720t/{tegra20 => tegra-common}/spl.c|   18 +-
>  arch/arm/cpu/arm720t/tegra20/Makefile  |1 -
>  arch/arm/cpu/arm720t/tegra20/cpu.c |   12 +-
>  arch/arm/cpu/arm926ejs/mx25/generic.c  |   66 +--
>  arch/arm/cpu/armv7/mx5/clock.c |  454 
> +++-
>  arch/arm/cpu/armv7/mx5/lowlevel_init.S |  112 ++---
>  arch/arm/cpu/armv7/mx6/clock.c |   31 +-
>  arch/arm/cpu/armv7/mx6/soc.c   |2 +-
>  arch/arm/cpu/armv7/tegra-common/Makefile   |   48 +++
>  .../armv7/{tegra20 => tegra-common}/cmd_enterrcm.c |4 +-
>  arch/arm/cpu/armv7/tegra20/Makefile|1 -
>  arch/arm/cpu/armv7/tegra20/usb.c   |8 +-
>  arch/arm/cpu/pxa/cpuinfo.c |   11 +-
>  arch/arm/cpu/tegra-common/Makefile |   48 +++
>  .../{tegra20-common/ap20.c => tegra-common/ap.c}   |   12 +-
>  .../cpu/{tegra20-common => tegra-common}/board.c   |

Re: [U-Boot] [PATCH 67/72] serial: Unconditionally enable CONFIG_SERIAL_MULTI

[Allen Martin]

On Tue, Oct 09, 2012 at 03:15:40PM -0700, Stephen Warren wrote:
> On 10/09/2012 04:13 PM, Tom Rini wrote:
> > On 10/09/12 15:09, Stephen Warren wrote:
> >> On 10/09/2012 03:38 PM, Tom Rini wrote:
> >>> On Tue, Oct 09, 2012 at 02:33:51PM -0600, Stephen Warren wrote:
>  On 09/29/2012 03:53 PM, Marek Vasut wrote:
> > Enable CONFIG_SERIAL_MULTI for all builds of U-Boot. That 
> > includes both SPL builds and non-SPL builds, everything. To 
> > avoid poluting this patch with removal of ifdef-endif 
> > constructions containing CONFIG_SERIAL_MULTI, the 
> > CONFIG_SERIAL_MULTI is temporarily added into CPPFLAGS in 
> > config.mk . This will be again removed in following patch.
> 
>  Marek,
> 
>  This patch (at least, the version of it checked into
>  u-boot/next) breaks U-Boot on Tegra.
> 
>  I believe the reason is because nothing ever calls 
>  serial_initialize() in the SPL on Tegra. If I edit 
>  arch/arm/cpu/arm720t/tegra20/spl.c function 
>  preloader_console_init() to call serial_initialize() right
>  before it calls serial_init(), then everything works fine.
>  Without this, drivers/serial/serial.c is never initialised (not
>  even BSS cleared!) and so it's left set to some bogus value,
>  and so get_current() doesn't replace it with
>  default_serial_console(), so an invalid pointer is accessed,
>  causing a hang or crash.
> 
>  I'm not sure quite what the correct solution is here. Is
>  Tegra's custom spl.c doing too much; stuff that should come
>  from the common spl.c is cut/paste here? Or, is adding the call
>  to serial_initialize() the correct fix? Or, is the root-cause
>  of the problem that BSS (serial_current) isn't being cleared to
>  0?
> >>>
> >>> Tegra SPL needs to either be updated ala common/spl/ 
> >>> (preloader_console_init() calls serial_init()) or switched over
> >>> to it.
> > 
> >> Hmm, well it's already calling serial_init() just not 
> >> serial_initialize(). Perhaps the issue is the following code
> >> missing from Tegra's SPL:
> > 
> >> /* Clear the BSS. */ memset(__bss_start, 0, __bss_end__ -
> >> __bss_start);
> > 
> >> Anyway, I'll let Allen take a look at it, since he's most familiar 
> >> with Tegra SPL.
> > 
> > Yes, if SPL wasn't previously clearing the BSS, this would be a
> > problem now.
> 
> It was at least at some point in time; Tegra's spl.c does:
> 
> > /*
> >  * We call relocate_code() with relocation target same as the
> >  * CONFIG_SYS_SPL_TEXT_BASE. This will result in relocation getting
> >  * skipped. Instead, only .bss initialization will happen. That's
> >  * all we need
> >  */
> > debug(">>board_init_f()\n");
> > relocate_code(CONFIG_SPL_STACK, &gdata, CONFIG_SPL_TEXT_BASE);
> 
> Perhaps that call doesn't clear BSS any more?

The clear_bss() in arm720t/start.S is surrounded by "#ifndef
CONFIG_SPL_BUILD".  It was probably removed long ago, I just never
noticed because nothing in SPL was using any globals.

Moving to common spl.c definately seems like the right thing to do to
avoid this type of thing.  I'll work on it, but it probably won't be
until next week, is that ok?

-Allen

---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
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)

[Albert ARIBAUD]

Hi Tom,

On Tue, 9 Oct 2012 14:32:08 -0700, Tom Rini  wrote:

> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
> > On 10/09/2012 08:23 AM, Tom Rini wrote:
> > > On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
> > > 
> > >> NOTE: I get a few more size issues with ELDK 4.2 on IXP (that
> > >> big-endian ARM) after this patchset is applied. I wonder if we
> > >> shouldn't just throw these away, since they're dead code mostly.
> > >> 
> > >> The following changes since commit
> > >> c7ee66a8222660b565e9240775efa4c82cb348c2:
> > >> 
> > >> Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx into
> > >> next (2012-10-02 10:16:40 -0700)
> > >> 
> > >> are available in the git repository at:
> > >> 
> > >> 
> > >> git://git.denx.de/u-boot-usb.git next
> > >> 
> > >> for you to fetch changes up to
> > >> f0ede0e8305bc3c959862446bce40cb028b36293:
> > >> 
> > >> usb.h: Add udc_disconnect prototype to usb.h (2012-10-07 02:08:48
> > >> +0200)
> > > 
> > > I had to rebase this locally to merge (such is next), and now it's 
> > > applied to u-boot/next, thanks!
> > 
> > Hmm. Can't "git merge" solve merge conflicts just as well as "git rebase"?
> > 
> > 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.
> 
> > It would be awesome if U-Boot could adopt something more similar to
> > the Linux kernel's git usage model, namely:
> > 
> > * All downstream branches are based off some known stable point in the
> > master branch (e.g. 2012.10-rc1). Before these branches are merged
> > into any other branch, they can be rebased if absolutely needed, but
> > preferably not.
> > 
> > * Once a downstream branch is merged upwards, the downstream branch
> > doesn't merge upstream back down into the downstream branch, but either:
> > 
> > a) Keeps adding to the existing branch so that incremental pull
> > requests can be sent.
> > 
> > Or often when u-boot/master has made a complete new release does:
> > 
> > b) Creates a new branch based on the latest rc or release from
> > u-boot/master.
> > 
> > (in practice, downstream branches typically end up with something like
> > for-3.5 based on v3.4-rcN, for-3.6 based on v3.5-rcN, for-3.7 based on
> > v3.6-rcN, some running in parallel containing either important
> > bugfixes for the release or new development as determined by the
> > current state of the various releases in the mainline tree).
> > 
> > * When a branch is merged from a repo to a parent repo, it's always a
> > git merge --no-ff; never a rebase or fast-forward.
> > 
> > * In order to resolve merge conflicts/dependencies between different
> > downstream branches, one of the following happens:
> > 
> > 1)
> > 
> > a) The first downstream branch gets merged into u-boot/master.
> > b) The second downstream branch creates a new branch starting at an an
> > rc or release in u-boot-master that contains it the required patches.
> > c) The dependent patches are applied to the second downstream branch.
> > d) The second downstream branch gets merged into u-boot/master.
> > 
> > 2)
> > 
> > All the patches that would usually be merged through downstream branch
> > 2 actually get ack'd by the maintainer of downstream branch 2 and
> > applied to downstream branch 1 after the patches they depend on. This
> > is simplest, but may cause complications if both branches need to take
> > patches that build on the merged patches they're merged into an rc or
> > release in u-boot/master.
> > 
> > 3)
> > 
> > A topic branch is created by one of the downstream maintainers,
> > branched from a u-boot/master rc or release, and containing just the
> > patches that other patches depend on, and this topic branch gets
> > merged into both the two downstream branches for further work.
> > 
> > Yes, this does all take a little bit more thought, planning, and
> > co-ordination, but I think having a simpler and more stable git
> > history is worth it.
> 
> Interesting.  As this is more work on the custodians end, what does
> everyone else say?

IIUC the current rule for U-Boot is that master branches do not rebase
while next branches can (as Tom said).

Apart from this, I'm not sure why forbidding fast-forward is a good
thing, but if there are benefits, why not.

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.

And I am pretty sure we don't need to create branches "for such
version" "based on such version" all the time; keeping each custodia

Re: [U-Boot] [PATCH 67/72] serial: Unconditionally enable CONFIG_SERIAL_MULTI

[Stephen Warren]

On 10/09/2012 04:13 PM, Tom Rini wrote:
> On 10/09/12 15:09, Stephen Warren wrote:
>> On 10/09/2012 03:38 PM, Tom Rini wrote:
>>> On Tue, Oct 09, 2012 at 02:33:51PM -0600, Stephen Warren wrote:
 On 09/29/2012 03:53 PM, Marek Vasut wrote:
> Enable CONFIG_SERIAL_MULTI for all builds of U-Boot. That 
> includes both SPL builds and non-SPL builds, everything. To 
> avoid poluting this patch with removal of ifdef-endif 
> constructions containing CONFIG_SERIAL_MULTI, the 
> CONFIG_SERIAL_MULTI is temporarily added into CPPFLAGS in 
> config.mk . This will be again removed in following patch.

 Marek,

 This patch (at least, the version of it checked into
 u-boot/next) breaks U-Boot on Tegra.

 I believe the reason is because nothing ever calls 
 serial_initialize() in the SPL on Tegra. If I edit 
 arch/arm/cpu/arm720t/tegra20/spl.c function 
 preloader_console_init() to call serial_initialize() right
 before it calls serial_init(), then everything works fine.
 Without this, drivers/serial/serial.c is never initialised (not
 even BSS cleared!) and so it's left set to some bogus value,
 and so get_current() doesn't replace it with
 default_serial_console(), so an invalid pointer is accessed,
 causing a hang or crash.

 I'm not sure quite what the correct solution is here. Is
 Tegra's custom spl.c doing too much; stuff that should come
 from the common spl.c is cut/paste here? Or, is adding the call
 to serial_initialize() the correct fix? Or, is the root-cause
 of the problem that BSS (serial_current) isn't being cleared to
 0?
>>>
>>> Tegra SPL needs to either be updated ala common/spl/ 
>>> (preloader_console_init() calls serial_init()) or switched over
>>> to it.
> 
>> Hmm, well it's already calling serial_init() just not 
>> serial_initialize(). Perhaps the issue is the following code
>> missing from Tegra's SPL:
> 
>> /* Clear the BSS. */ memset(__bss_start, 0, __bss_end__ -
>> __bss_start);
> 
>> Anyway, I'll let Allen take a look at it, since he's most familiar 
>> with Tegra SPL.
> 
> Yes, if SPL wasn't previously clearing the BSS, this would be a
> problem now.

It was at least at some point in time; Tegra's spl.c does:

> /*
>  * We call relocate_code() with relocation target same as the
>  * CONFIG_SYS_SPL_TEXT_BASE. This will result in relocation getting
>  * skipped. Instead, only .bss initialization will happen. That's
>  * all we need
>  */
> debug(">>board_init_f()\n");
> relocate_code(CONFIG_SPL_STACK, &gdata, CONFIG_SPL_TEXT_BASE);

Perhaps that call doesn't clear BSS any more?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 67/72] serial: Unconditionally enable CONFIG_SERIAL_MULTI

[Stephen Warren]

On 10/09/2012 03:38 PM, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 02:33:51PM -0600, Stephen Warren wrote:
>> On 09/29/2012 03:53 PM, Marek Vasut wrote:
>>> Enable CONFIG_SERIAL_MULTI for all builds of U-Boot. That
>>> includes both SPL builds and non-SPL builds, everything. To
>>> avoid poluting this patch with removal of ifdef-endif
>>> constructions containing CONFIG_SERIAL_MULTI, the
>>> CONFIG_SERIAL_MULTI is temporarily added into CPPFLAGS in
>>> config.mk . This will be again removed in following patch.
>> 
>> Marek,
>> 
>> This patch (at least, the version of it checked into u-boot/next)
>> breaks U-Boot on Tegra.
>> 
>> I believe the reason is because nothing ever calls
>> serial_initialize() in the SPL on Tegra. If I edit
>> arch/arm/cpu/arm720t/tegra20/spl.c function
>> preloader_console_init() to call serial_initialize() right before
>> it calls serial_init(), then everything works fine. Without
>> this, drivers/serial/serial.c is never initialised (not even BSS
>> cleared!) and so it's left set to some bogus value, and so
>> get_current() doesn't replace it with default_serial_console(),
>> so an invalid pointer is accessed, causing a hang or crash.
>> 
>> I'm not sure quite what the correct solution is here. Is Tegra's
>> custom spl.c doing too much; stuff that should come from the
>> common spl.c is cut/paste here? Or, is adding the call to
>> serial_initialize() the correct fix? Or, is the root-cause of the
>> problem that BSS (serial_current) isn't being cleared to 0?
> 
> Tegra SPL needs to either be updated ala common/spl/ 
> (preloader_console_init() calls serial_init()) or switched over to 
> it.

Hmm, well it's already calling serial_init() just not
serial_initialize(). Perhaps the issue is the following code missing
from Tegra's SPL:

/* Clear the BSS. */
memset(__bss_start, 0, __bss_end__ - __bss_start);

Anyway, I'll let Allen take a look at it, since he's most familiar
with Tegra SPL.
___
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/09/2012 03:32 PM, Tom Rini wrote:
> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
>> On 10/09/2012 08:23 AM, Tom Rini wrote:
>>> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
>>> 
 NOTE: I get a few more size issues with ELDK 4.2 on IXP
 (that big-endian ARM) after this patchset is applied. I
 wonder if we shouldn't just throw these away, since they're
 dead code mostly.
 
 The following changes since commit 
 c7ee66a8222660b565e9240775efa4c82cb348c2:
 
 Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx
 into next (2012-10-02 10:16:40 -0700)
 
 are available in the git repository at:
 
 
 git://git.denx.de/u-boot-usb.git next
 
 for you to fetch changes up to 
 f0ede0e8305bc3c959862446bce40cb028b36293:
 
 usb.h: Add udc_disconnect prototype to usb.h (2012-10-07
 02:08:48 +0200)
>>> 
>>> I had to rebase this locally to merge (such is next), and now
>>> it's applied to u-boot/next, thanks!
>> 
>> Hmm. Can't "git merge" solve merge conflicts just as well as "git
>> rebase"?
>> 
>> 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 don't quite follow that; linux-next is also purely merge-based. Are
you referring to the fact that it's re-created every day, and the
source branches that go into the merge can be rebased if needed?

Instead, I think u-boot/next is just a place where patches get
applied, or branches get merged, before u-boot/master is open to
accept new patches for the next release. Unless I'm misunderstanding
it purpose of course...

Now, having a linux-next style daily merge of u-boot-*/next would be
pretty awesome.

>> It would be awesome if U-Boot could adopt something more similar
>> to the Linux kernel's git usage model, namely:
>> 
>> * All downstream branches are based off some known stable point
>> in the master branch (e.g. 2012.10-rc1). Before these branches
>> are merged into any other branch, they can be rebased if
>> absolutely needed, but preferably not.
>> 
>> * Once a downstream branch is merged upwards, the downstream
>> branch doesn't merge upstream back down into the downstream
>> branch, but either:
>> 
>> a) Keeps adding to the existing branch so that incremental pull 
>> requests can be sent.
>> 
>> Or often when u-boot/master has made a complete new release
>> does:
>> 
>> b) Creates a new branch based on the latest rc or release from 
>> u-boot/master.
>> 
>> (in practice, downstream branches typically end up with something
>> like for-3.5 based on v3.4-rcN, for-3.6 based on v3.5-rcN,
>> for-3.7 based on v3.6-rcN, some running in parallel containing
>> either important bugfixes for the release or new development as
>> determined by the current state of the various releases in the
>> mainline tree).
>> 
>> * When a branch is merged from a repo to a parent repo, it's
>> always a git merge --no-ff; never a rebase or fast-forward.
>> 
>> * In order to resolve merge conflicts/dependencies between
>> different downstream branches, one of the following happens:
>> 
>> 1)
>> 
>> a) The first downstream branch gets merged into u-boot/master. b)
>> The second downstream branch creates a new branch starting at an
>> an rc or release in u-boot-master that contains it the required
>> patches. c) The dependent patches are applied to the second
>> downstream branch. d) The second downstream branch gets merged
>> into u-boot/master.
>> 
>> 2)
>> 
>> All the patches that would usually be merged through downstream
>> branch 2 actually get ack'd by the maintainer of downstream
>> branch 2 and applied to downstream branch 1 after the patches
>> they depend on. This is simplest, but may cause complications if
>> both branches need to take patches that build on the merged
>> patches they're merged into an rc or release in u-boot/master.
>> 
>> 3)
>> 
>> A topic branch is created by one of the downstream maintainers, 
>> branched from a u-boot/master rc or release, and containing just
>> the patches that other patches depend on, and this topic branch
>> gets merged into both the two downstream branches for further
>> work.
>> 
>> Yes, this does all take a little bit more thought, planning, and 
>> co-ordination, but I think having a simpler and more stable git 
>> history is worth it.
> 
> Interesting.  As this is more work on the custodians end, what
> does everyone else say?

This actually turns out to be less work for custodians if there aren't
any dependencies between patch series, since whenever you send a pull
request right now

Re: [U-Boot] [PATCH 67/72] serial: Unconditionally enable CONFIG_SERIAL_MULTI

[Tom Rini]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/09/12 15:09, Stephen Warren wrote:
> On 10/09/2012 03:38 PM, Tom Rini wrote:
>> On Tue, Oct 09, 2012 at 02:33:51PM -0600, Stephen Warren wrote:
>>> On 09/29/2012 03:53 PM, Marek Vasut wrote:
 Enable CONFIG_SERIAL_MULTI for all builds of U-Boot. That 
 includes both SPL builds and non-SPL builds, everything. To 
 avoid poluting this patch with removal of ifdef-endif 
 constructions containing CONFIG_SERIAL_MULTI, the 
 CONFIG_SERIAL_MULTI is temporarily added into CPPFLAGS in 
 config.mk . This will be again removed in following patch.
>>> 
>>> Marek,
>>> 
>>> This patch (at least, the version of it checked into
>>> u-boot/next) breaks U-Boot on Tegra.
>>> 
>>> I believe the reason is because nothing ever calls 
>>> serial_initialize() in the SPL on Tegra. If I edit 
>>> arch/arm/cpu/arm720t/tegra20/spl.c function 
>>> preloader_console_init() to call serial_initialize() right
>>> before it calls serial_init(), then everything works fine.
>>> Without this, drivers/serial/serial.c is never initialised (not
>>> even BSS cleared!) and so it's left set to some bogus value,
>>> and so get_current() doesn't replace it with
>>> default_serial_console(), so an invalid pointer is accessed,
>>> causing a hang or crash.
>>> 
>>> I'm not sure quite what the correct solution is here. Is
>>> Tegra's custom spl.c doing too much; stuff that should come
>>> from the common spl.c is cut/paste here? Or, is adding the call
>>> to serial_initialize() the correct fix? Or, is the root-cause
>>> of the problem that BSS (serial_current) isn't being cleared to
>>> 0?
>> 
>> Tegra SPL needs to either be updated ala common/spl/ 
>> (preloader_console_init() calls serial_init()) or switched over
>> to it.
> 
> Hmm, well it's already calling serial_init() just not 
> serial_initialize(). Perhaps the issue is the following code
> missing from Tegra's SPL:
> 
> /* Clear the BSS. */ memset(__bss_start, 0, __bss_end__ -
> __bss_start);
> 
> Anyway, I'll let Allen take a look at it, since he's most familiar 
> with Tegra SPL.

Yes, if SPL wasn't previously clearing the BSS, this would be a
problem now.

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

iQIcBAEBAgAGBQJQdKGaAAoJENk4IS6UOR1W3WcP/2d60PT9cL2Y0OauFG9/7gAD
PnrwKgTGWVD5wSb4bKNxb9abFSFhoeqn9BKxAYvAQ0TPXXaMgvYdHGOe9D422K1z
V76I3At84AYqXQq/3xeVTHzqK4on1H751e4einvbcd5IelkwMoKdA94Kufq1OdeD
MR5kXp1oyE11Ty9b/OZsDQlqczY8SG5x556+sO8FFa4yoQc82LF3x8ymL0R51wlB
D38/uqbvBPCYuE6H+GAawIW7L+SJjXhMaykTyUnNbb+tfvZYMt1IGFNMq2SsL75j
Kq7WuXGLb1UBB+ebFdlzPtuEtybtBjyhbqTBBu3ikKB7SLWG5ligGVbP5WVRFNuc
p3po82Wn4erzoX9y1e+LA/9Idhm8ttXZpbwFVqNc9DveJvTfItRV6A2jJWnhRfCp
SJqh10QCvlMOKdibB4j4f4aFAiR0Og2jOSlFHPfIidPXme/ZqqM5nhmN3WFW8acU
LvEimmz5XSeJ0Uosg39JtgoXPCJwKLG9px9wby5NjxbvavE7S4wHNs1h3tHo7B8e
D+csKIvoGJLiPKSr80xesv23JogHJab+37uj8Aazc/4R3GDgBeTChPvGuxsQBoeP
ZvlaD03SuyGbQ6kQJrCa9/VZS/HR2y0lFqEk0MTvwRh0mZCCR/N/nTSI/dss9rEG
uuYMDXwlIjZ0cY/ggIrv
=PNet
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] yaffs2: Fix GCC 4.6 compile warnings

[Tom Rini]

On Tue, Oct 09, 2012 at 02:08:13PM -0500, Scott Wood wrote:
> On 10/09/2012 01:51:14 PM, Tom Rini wrote:
> >On Tue, Oct 09, 2012 at 01:09:22PM -0500, Scott Wood wrote:
> >> On 10/06/2012 11:59:17 AM, Albert ARIBAUD wrote:
> >> >Hi Anatolij,
> >> >
> >> >On Sat,  6 Oct 2012 11:31:03 +0200, Anatolij Gustschin
> >
> >> >wrote:
> >> >
> >> >> Fix:
> >> >> yaffs_guts.c: In function 'yaffs_check_chunk_erased':
> >> >> yaffs_guts.c:324:6: warning: variable 'result' set but not used
> >> >> [-Wunused-but-set-variable]
> >> [snip]
> >> >Tested-by: Albert ARIBAUD 
> >> >
> >> >This effectively makes VCMA9 and smdk2410 (the two boards which had
> >> >the yaffs warnings) build clean.
> >>
> >> It takes care of the warnings, but I still see this:
> >>
> >> Configuring for VCMA9 board...
> >> make: *** [u-boot] Error 139
> >
> >The linaro and ELDK 4.2, 5.2 toolchains build this fine.  I would
> >suggest grabbing one of those for ARM.
> 
> I'll give one of them a try, but is it expected that the compiler
> will be able to do 64/32 division without __udivdi3?  Shouldn't
> yaffs2 be using lldiv() or do_div()?

Based on a very short skim, yes, yaffs2 looks to be buggy here and for
example "end_block = mtd->size / mtd->erasesize - 1;" from
yaffs_uboot_glue.c should be using mtd->erase_shift and shifting.

-- 
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 v2 0/3] Enable MMC support for at91sam9x5ek board.

[Andreas Bießmann]

Hi Josh,

On 09.10.12 12:11, Josh Wu wrote:
> Hi, Andreas
> 
> Any feedback of these patches?

short answer: no ;)

I think they could go into next (no obvious objections), but I would
like to do some runtime tests on avr32 before. Beside that, if you do
not insist on applying them ASAP to next I would like to wait until the
release next Monday and apply the patches to u-boot-atmel/master then.
Is that OK for you?

Best regards

Andreas Bießmann

> 
> Best Regards,
> Josh Wu
> 
> On 9/14/2012 4:22 PM, Josh Wu wrote:
>> This patch series enable MCI0 solt in at91sam9x5ek board.
>>
>> Josh Wu (3):
>>mmc: at91: add multi block read/write support.
>>ARM: at91sam9x5: enable MCI0 support for 9x5ek board.
>>mmc: at91: use max timeout value. It will avoid some situation that
>>  timeout happened.
>>
>>   arch/arm/cpu/arm926ejs/at91/at91sam9x5_devices.c |   15 +++
>>   board/atmel/at91sam9x5ek/at91sam9x5ek.c  |   10 ++
>>   drivers/mmc/gen_atmel_mci.c  |   15 +--
>>   include/atmel_mci.h  |7 ++-
>>   include/configs/at91sam9x5ek.h   |   10 ++
>>   5 files changed, 54 insertions(+), 3 deletions(-)
>>
> 
___
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/next into u-boot/next

[Tom Rini]

On Tue, Oct 09, 2012 at 05:34:13PM +0200, Albert ARIBAUD wrote:

> Hi Tom,
> 
> The following changes since commit 661c21dd46e857b74682b0610d83cfea7f3ac3c2:
> 
>   usb.h: Add udc_disconnect prototype to usb.h (2012-10-08 18:01:17 -0700)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arm next
> 
> for you to fetch changes up to 0d6b8f29a3c59306d6cd8f2baa92897f56b06695:
> 
>   configs: mx6qsabre_common.h: Use default clock definitions (2012-10-09 
> 16:52:18 +0200)
[snip]
> Lukasz Dalek (2):
>   h2200: Add support for iPAQ h2200 palmtop

This doesn't compile in next due to not having been updated for the
serial changes:
serial_pxa.c:297:2: error: #error "Bad CONFIG_CONS_INDEX."

Do you want me to pull or do you want to fix this first?  Thanks.

-- 
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 67/72] serial: Unconditionally enable CONFIG_SERIAL_MULTI

[Tom Rini]

On Tue, Oct 09, 2012 at 02:33:51PM -0600, Stephen Warren wrote:
> On 09/29/2012 03:53 PM, Marek Vasut wrote:
> > Enable CONFIG_SERIAL_MULTI for all builds of U-Boot. That includes
> > both SPL builds and non-SPL builds, everything. To avoid poluting
> > this patch with removal of ifdef-endif constructions containing
> > CONFIG_SERIAL_MULTI, the CONFIG_SERIAL_MULTI is temporarily added
> > into CPPFLAGS in config.mk . This will be again removed in following
> > patch.
> 
> Marek,
> 
> This patch (at least, the version of it checked into u-boot/next) breaks
> U-Boot on Tegra.
> 
> I believe the reason is because nothing ever calls serial_initialize()
> in the SPL on Tegra. If I edit arch/arm/cpu/arm720t/tegra20/spl.c
> function preloader_console_init() to call serial_initialize() right
> before it calls serial_init(), then everything works fine. Without this,
> drivers/serial/serial.c is never initialised (not even BSS cleared!) and
> so it's left set to some bogus value, and so get_current() doesn't
> replace it with default_serial_console(), so an invalid pointer is
> accessed, causing a hang or crash.
> 
> I'm not sure quite what the correct solution is here. Is Tegra's custom
> spl.c doing too much; stuff that should come from the common spl.c is
> cut/paste here? Or, is adding the call to serial_initialize() the
> correct fix? Or, is the root-cause of the problem that BSS
> (serial_current) isn't being cleared to 0?

Tegra SPL needs to either be updated ala common/spl/
(preloader_console_init() calls serial_init()) or switched over to
it.

-- 
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 (was: Re: [PULL] u-boot-usb/next)

[Tom Rini]

On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren wrote:
> On 10/09/2012 08:23 AM, Tom Rini wrote:
> > On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
> > 
> >> NOTE: I get a few more size issues with ELDK 4.2 on IXP (that
> >> big-endian ARM) after this patchset is applied. I wonder if we
> >> shouldn't just throw these away, since they're dead code mostly.
> >> 
> >> The following changes since commit
> >> c7ee66a8222660b565e9240775efa4c82cb348c2:
> >> 
> >> Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx into
> >> next (2012-10-02 10:16:40 -0700)
> >> 
> >> are available in the git repository at:
> >> 
> >> 
> >> git://git.denx.de/u-boot-usb.git next
> >> 
> >> for you to fetch changes up to
> >> f0ede0e8305bc3c959862446bce40cb028b36293:
> >> 
> >> usb.h: Add udc_disconnect prototype to usb.h (2012-10-07 02:08:48
> >> +0200)
> > 
> > I had to rebase this locally to merge (such is next), and now it's 
> > applied to u-boot/next, thanks!
> 
> Hmm. Can't "git merge" solve merge conflicts just as well as "git rebase"?
> 
> 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.

> It would be awesome if U-Boot could adopt something more similar to
> the Linux kernel's git usage model, namely:
> 
> * All downstream branches are based off some known stable point in the
> master branch (e.g. 2012.10-rc1). Before these branches are merged
> into any other branch, they can be rebased if absolutely needed, but
> preferably not.
> 
> * Once a downstream branch is merged upwards, the downstream branch
> doesn't merge upstream back down into the downstream branch, but either:
> 
> a) Keeps adding to the existing branch so that incremental pull
> requests can be sent.
> 
> Or often when u-boot/master has made a complete new release does:
> 
> b) Creates a new branch based on the latest rc or release from
> u-boot/master.
> 
> (in practice, downstream branches typically end up with something like
> for-3.5 based on v3.4-rcN, for-3.6 based on v3.5-rcN, for-3.7 based on
> v3.6-rcN, some running in parallel containing either important
> bugfixes for the release or new development as determined by the
> current state of the various releases in the mainline tree).
> 
> * When a branch is merged from a repo to a parent repo, it's always a
> git merge --no-ff; never a rebase or fast-forward.
> 
> * In order to resolve merge conflicts/dependencies between different
> downstream branches, one of the following happens:
> 
> 1)
> 
> a) The first downstream branch gets merged into u-boot/master.
> b) The second downstream branch creates a new branch starting at an an
> rc or release in u-boot-master that contains it the required patches.
> c) The dependent patches are applied to the second downstream branch.
> d) The second downstream branch gets merged into u-boot/master.
> 
> 2)
> 
> All the patches that would usually be merged through downstream branch
> 2 actually get ack'd by the maintainer of downstream branch 2 and
> applied to downstream branch 1 after the patches they depend on. This
> is simplest, but may cause complications if both branches need to take
> patches that build on the merged patches they're merged into an rc or
> release in u-boot/master.
> 
> 3)
> 
> A topic branch is created by one of the downstream maintainers,
> branched from a u-boot/master rc or release, and containing just the
> patches that other patches depend on, and this topic branch gets
> merged into both the two downstream branches for further work.
> 
> Yes, this does all take a little bit more thought, planning, and
> co-ordination, but I think having a simpler and more stable git
> history is worth it.

Interesting.  As this is more work on the custodians end, what does
everyone else say?

-- 
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 v3] add nand spl boot for qi_lb60 board

[Daniel Schwierzeck]

2012/10/9 Tom Rini :
> On Tue, Oct 09, 2012 at 04:28:05PM +0800, xian...@openmobilefree.net wrote:
>
>> From: Xiangfu Liu 
>>
>>  * 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
>>   
>>   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
>>
>>
>>  * Add software usbboot mode
>>Downloads user program from the USB port to internal
>>SRAM and branches to the internal SRAM to execute the program.
>>(JZ4740 CPU have a internal ROM have such kind of code, that make
>> JZ4740 can boot from USB)
>> ---
>> v3:
>>   * add simpile string.c to mips/lib
>>   * some cleanup on jz4740.c
>>   * move to new spl/ structure
>>   * support software usbboot mode
>
> I'm happy you've moved to the new SPL infrastructure.  A few comments:
>
> In general, please check for checkpatch.pl issues, I spotted a few.
> Also, don't use // comments in asm, everything else in MIPS uses '#' or
> '/* ... */'.  Please use 'puts' rather than 'serial_puts' directly.
>
> [snip]
>> diff --git a/arch/mips/lib/string.c b/arch/mips/lib/string.c
>> new file mode 100644
>> index 000..d59f44a
>> --- /dev/null
>> +++ b/arch/mips/lib/string.c
>> @@ -0,0 +1,32 @@
>
> Can you try just enabling CONFIG_SPL_LIBGENERIC_SUPPORT ?  You should
> have the unused functions garbage collected automatically.
>
>> diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
>> index 3ec34f3..4ab2229 100644
>> --- a/drivers/mtd/nand/jz4740_nand.c
>> +++ b/drivers/mtd/nand/jz4740_nand.c
>> @@ -15,6 +15,9 @@
>>  #include 
>>  #include 
>>
>> +#ifdef CONFIG_SPL_BUILD
>> +#define printf(arg...) do {} while (0)
>> +#endif
>
> In this case you should just switch to puts.
>
> And a non-blocking question, have you looked at the CONFIG_SPL_FRAMEWORK
> code in common/spl/ now?
>

in addition to Tom's comments:
please split coding style cleanups, code reordering, NAND SPL and USB
boot into separate patches

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

Re: [U-Boot] [PATCH 3/9] x86: Allow excluding reset handling code from u-boot.

[Simon Glass]

Hi Graeme,

On Wed, Oct 3, 2012 at 6:01 PM, Graeme Russ  wrote:
> Hi Simon,
>
> At first I thought this patch dealt with the 'board reset' code but
> then realised it deals with the 'reset vector' - Can you fix the patch
> subject please

Will do.

>
> On Thu, Oct 4, 2012 at 10:39 AM, Simon Glass  wrote:
>> From: Gabe Black 
>>
>> When running from coreboot we don't want this code.
>>
>> This version works by ifdef-ing out all of the code that would go
>> into those sections and all the code that refers to it. The sections are
>> then empty, and the linker will either leave them empty for the loader
>> to ignore or remove them entirely.
>
> Could this be done by #ifdef'ing the section in the linker script?

Yes, in fact that is already in this patch.

>
>> Signed-off-by: Gabe Black 
>> Signed-off-by: Simon Glass 
>> ---
>>  arch/x86/cpu/resetvec.S  |6 ++
>>  arch/x86/cpu/start16.S   |4 
>>  arch/x86/cpu/u-boot.lds  |3 +++
>>  board/chromebook-x86/coreboot/coreboot_start16.S |6 ++
>>  board/eNET/eNET_start16.S|4 
>>  5 files changed, 23 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/x86/cpu/resetvec.S b/arch/x86/cpu/resetvec.S
>> index 44aee5f..5b359ff 100644
>> --- a/arch/x86/cpu/resetvec.S
>> +++ b/arch/x86/cpu/resetvec.S
>> @@ -25,6 +25,10 @@
>>
>>  /* Reset vector, jumps to start16.S */
>>
>> +#include 
>> +
>> +#ifndef CONFIG_NO_RESET_CODE
>> +
>>  .extern start16
>>
>>  .section .resetvec, "ax"
>> @@ -36,3 +40,5 @@ reset_vector:
>>
>> .org 0xf
>> nop
>> +
>> +#endif
>
> Condition it out in the Makefile instead

I suspect the reason it was done here is these lines in the top-level Makefile.

OBJS  = $(CPUDIR)/start.o
ifeq ($(CPU),x86)
OBJS += $(CPUDIR)/start16.o
OBJS += $(CPUDIR)/resetvec.o
endif


If we just take it out of the .lds file then start16.o and resetvec.o
are not included in the image. But they will still be built. We could
add an additional condition here perhaps, like:

OBJS  = $(CPUDIR)/start.o
ifeq ($(CPU),x86)
ifneq ($(CONFIG_NO_RESET_CODE),y)
OBJS += $(CPUDIR)/start16.o
OBJS += $(CPUDIR)/resetvec.o
endif
endif


Here is the menu as I see it - what would you prefer?
- top level Makefile change
- arch/arm/cpu/Makefile change (pointless if top level Makefile
includes these files anyway)
- building everything but removing unneeded object files in the link script

>
>> diff --git a/arch/x86/cpu/start16.S b/arch/x86/cpu/start16.S
>> index cc393ff..d944840 100644
>> --- a/arch/x86/cpu/start16.S
>> +++ b/arch/x86/cpu/start16.S
>> @@ -28,11 +28,14 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>
>>  #define BOOT_SEG   0x  /* linear segment of boot code */
>>  #define a32.byte 0x67;
>>  #define o32.byte 0x66;
>>
>> +#ifndef CONFIG_NO_RESET_CODE
>> +
>>  .section .start16, "ax"
>>  .code16
>>  .globl start16
>> @@ -141,3 +144,4 @@ gdt:
>> .byte   0x93/* access */
>> .byte   0xcf/* flags + limit_high */
>> .byte   0x00/* base_high */
>> +#endif
>
> Ditto
>
>> diff --git a/arch/x86/cpu/u-boot.lds b/arch/x86/cpu/u-boot.lds
>> index fe28030..2a90a01 100644
>> --- a/arch/x86/cpu/u-boot.lds
>> +++ b/arch/x86/cpu/u-boot.lds
>> @@ -85,6 +85,8 @@ SECTIONS
>> __bios_start = LOADADDR(.bios);
>> __bios_size = SIZEOF(.bios);
>>
>> +#ifndef CONFIG_NO_RESET_CODE
>> +
>> /*
>>  * The following expressions place the 16-bit Real-Mode code and
>>  * Reset Vector at the end of the Flash ROM
>> @@ -94,4 +96,5 @@ SECTIONS
>>
>> . = RESET_VEC_LOC;
>> .resetvec : AT (CONFIG_SYS_TEXT_BASE + (CONFIG_SYS_MONITOR_LEN - 
>> RESET_SEG_SIZE + RESET_VEC_LOC)) { KEEP(*(.resetvec)); }
>> +#endif
>>  }
>
> The commit comment states "and the linker will either leave them empty
> for the loader to ignore or remove them entirely" but you are actually
> explicitly remove them anyway - If they are not compiled, is this
> necessary?

We need either or.

>
>> diff --git a/board/chromebook-x86/coreboot/coreboot_start16.S 
>> b/board/chromebook-x86/coreboot/coreboot_start16.S
>> index 9ad06df..6fac3d6 100644
>> --- a/board/chromebook-x86/coreboot/coreboot_start16.S
>> +++ b/board/chromebook-x86/coreboot/coreboot_start16.S
>> @@ -28,6 +28,10 @@
>>   * that is used by U-boot to its final destination.
>>   */
>>
>> +#include 
>> +
>> +#ifndef CONFIG_NO_RESET_CODE
>> +
>>  .text
>>  .section .start16, "ax"
>>  .code16
>> @@ -35,6 +39,8 @@
>>  board_init16:
>> jmp board_init16_ret
>>
>> +#endif
>> +
>>  .section .bios, "ax"
>>  .code16
>>  .globl realmode_reset
>
> Hmm, I doubt coreboot really need a board level start16.S and (quite
> frankly) the whole 'realmode reset' code (i.e. BIOS reset) is crap and
> should be globally tossed (no one will ever call it)

Will drop this.

>

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

[Stephen Warren]

On 10/09/2012 08:23 AM, Tom Rini wrote:
> On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:
> 
>> NOTE: I get a few more size issues with ELDK 4.2 on IXP (that
>> big-endian ARM) after this patchset is applied. I wonder if we
>> shouldn't just throw these away, since they're dead code mostly.
>> 
>> The following changes since commit
>> c7ee66a8222660b565e9240775efa4c82cb348c2:
>> 
>> Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx into
>> next (2012-10-02 10:16:40 -0700)
>> 
>> are available in the git repository at:
>> 
>> 
>> git://git.denx.de/u-boot-usb.git next
>> 
>> for you to fetch changes up to
>> f0ede0e8305bc3c959862446bce40cb028b36293:
>> 
>> usb.h: Add udc_disconnect prototype to usb.h (2012-10-07 02:08:48
>> +0200)
> 
> I had to rebase this locally to merge (such is next), and now it's 
> applied to u-boot/next, thanks!

Hmm. Can't "git merge" solve merge conflicts just as well as "git rebase"?

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.

It would be awesome if U-Boot could adopt something more similar to
the Linux kernel's git usage model, namely:

* All downstream branches are based off some known stable point in the
master branch (e.g. 2012.10-rc1). Before these branches are merged
into any other branch, they can be rebased if absolutely needed, but
preferably not.

* Once a downstream branch is merged upwards, the downstream branch
doesn't merge upstream back down into the downstream branch, but either:

a) Keeps adding to the existing branch so that incremental pull
requests can be sent.

Or often when u-boot/master has made a complete new release does:

b) Creates a new branch based on the latest rc or release from
u-boot/master.

(in practice, downstream branches typically end up with something like
for-3.5 based on v3.4-rcN, for-3.6 based on v3.5-rcN, for-3.7 based on
v3.6-rcN, some running in parallel containing either important
bugfixes for the release or new development as determined by the
current state of the various releases in the mainline tree).

* When a branch is merged from a repo to a parent repo, it's always a
git merge --no-ff; never a rebase or fast-forward.

* In order to resolve merge conflicts/dependencies between different
downstream branches, one of the following happens:

1)

a) The first downstream branch gets merged into u-boot/master.
b) The second downstream branch creates a new branch starting at an an
rc or release in u-boot-master that contains it the required patches.
c) The dependent patches are applied to the second downstream branch.
d) The second downstream branch gets merged into u-boot/master.

2)

All the patches that would usually be merged through downstream branch
2 actually get ack'd by the maintainer of downstream branch 2 and
applied to downstream branch 1 after the patches they depend on. This
is simplest, but may cause complications if both branches need to take
patches that build on the merged patches they're merged into an rc or
release in u-boot/master.

3)

A topic branch is created by one of the downstream maintainers,
branched from a u-boot/master rc or release, and containing just the
patches that other patches depend on, and this topic branch gets
merged into both the two downstream branches for further work.

Yes, this does all take a little bit more thought, planning, and
co-ordination, but I think having a simpler and more stable git
history is worth it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH V2 3/3] FAT: implement fat_set_blk_dev(), convert cmd_fat.c

[Stephen Warren]

From: Stephen Warren 

This makes the FAT filesystem API more consistent with other block-based
filesystems. If in the future standard multi-filesystem commands such as
"ls" or "load" are implemented, having FAT work the same way as other
filesystems will be necessary.

Convert cmd_fat.c to the new API, so the code looks more like other files
implementing the same commands for other filesystems.

Signed-off-by: Stephen Warren 
---
v2: Fix inverted test of get_partition_info() result in fat_register_device().
---
 common/cmd_fat.c |8 +++---
 fs/fat/fat.c |   65 ++---
 include/fat.h|1 +
 3 files changed, 37 insertions(+), 37 deletions(-)

diff --git a/common/cmd_fat.c b/common/cmd_fat.c
index 5a5698b..c38302d 100644
--- a/common/cmd_fat.c
+++ b/common/cmd_fat.c
@@ -55,7 +55,7 @@ int do_fat_fsload (cmd_tbl_t *cmdtp, int flag, int argc, char 
* const argv[])
return 1;
 
dev = dev_desc->dev;
-   if (fat_register_device(dev_desc,part)!=0) {
+   if (fat_set_blk_dev(dev_desc, &info) != 0) {
printf("\n** Unable to use %s %d:%d for fatload **\n",
argv[1], dev, part);
return 1;
@@ -111,7 +111,7 @@ int do_fat_ls (cmd_tbl_t *cmdtp, int flag, int argc, char * 
const argv[])
return 1;
 
dev = dev_desc->dev;
-   if (fat_register_device(dev_desc,part)!=0) {
+   if (fat_set_blk_dev(dev_desc, &info) != 0) {
printf("\n** Unable to use %s %d:%d for fatls **\n",
argv[1], dev, part);
return 1;
@@ -149,7 +149,7 @@ int do_fat_fsinfo (cmd_tbl_t *cmdtp, int flag, int argc, 
char * const argv[])
return 1;
 
dev = dev_desc->dev;
-   if (fat_register_device(dev_desc,part)!=0) {
+   if (fat_set_blk_dev(dev_desc, &info) != 0) {
printf("\n** Unable to use %s %d:%d for fatinfo **\n",
argv[1], dev, part);
return 1;
@@ -185,7 +185,7 @@ static int do_fat_fswrite(cmd_tbl_t *cmdtp, int flag,
 
dev = dev_desc->dev;
 
-   if (fat_register_device(dev_desc, part) != 0) {
+   if (fat_set_blk_dev(dev_desc, &info) != 0) {
printf("\n** Unable to use %s %d:%d for fatwrite **\n",
argv[1], dev, part);
return 1;
diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 1e0d2a3..79e66ce 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -61,42 +61,12 @@ static int disk_read(__u32 block, __u32 nr_blocks, void 
*buf)
cur_part_info.start + block, nr_blocks, buf);
 }
 
-int fat_register_device(block_dev_desc_t * dev_desc, int part_no)
+int fat_set_blk_dev(block_dev_desc_t *dev_desc, disk_partition_t *info)
 {
ALLOC_CACHE_ALIGN_BUFFER(unsigned char, buffer, dev_desc->blksz);
 
-   /* First close any currently found FAT filesystem */
-   cur_dev = NULL;
-
-#if (defined(CONFIG_CMD_IDE) || \
- defined(CONFIG_CMD_SATA) || \
- defined(CONFIG_CMD_SCSI) || \
- defined(CONFIG_CMD_USB) || \
- defined(CONFIG_MMC) || \
- defined(CONFIG_SYSTEMACE) )
-
-   /* Read the partition table, if present */
-   if (!get_partition_info(dev_desc, part_no, &cur_part_info)) {
-   cur_dev = dev_desc;
-   }
-#endif
-
-   /* Otherwise it might be a superfloppy (whole-disk FAT filesystem) */
-   if (!cur_dev) {
-   if (part_no != 0) {
-   printf("** Partition %d not valid on device %d **\n",
-   part_no, dev_desc->dev);
-   return -1;
-   }
-
-   cur_dev = dev_desc;
-   cur_part_info.part = 0;
-   cur_part_info.start = 0;
-   cur_part_info.size = dev_desc->lba;
-   cur_part_info.blksz = dev_desc->blksz;
-   memset(cur_part_info.name, 0, sizeof(cur_part_info.name));
-   memset(cur_part_info.type, 0, sizeof(cur_part_info.type));
-   }
+   cur_dev = dev_desc;
+   cur_part_info = *info;
 
/* Make sure it has a valid FAT header */
if (disk_read(0, 1, buffer) != 1) {
@@ -120,6 +90,35 @@ int fat_register_device(block_dev_desc_t * dev_desc, int 
part_no)
return -1;
 }
 
+int fat_register_device(block_dev_desc_t *dev_desc, int part_no)
+{
+   disk_partition_t info;
+
+   /* First close any currently found FAT filesystem */
+   cur_dev = NULL;
+
+   /* Read the partition table, if present */
+   if (get_partition_info(dev_desc, part_no, &info)) {
+   if (part_no != 0) {
+   printf("** Partition %d not valid on device %d **\n",
+   part_no, dev_desc->dev);
+   return -1;
+   }
+
+   info.part = 0;
+   info.start = 0;
+   info.size = dev_desc->lba;
+   i

[U-Boot] [PATCH V2 2/3] FAT: make use of disk_partition_t.part

[Stephen Warren]

From: Stephen Warren 

This removes the standalone cur_part_nr variable, opening the way to
replacing fat_register_device() with fat_set_blk_dev().

Note that when get_partition_info() fails and we use the entire disk,
the correct partition number is 0 (whole disk) not 1 (first partition),
so that change is also made here.

An alternative to this (and the previous) patch might be to simply
remove the partition number from the printf(). I don't know how attached
people are to it.

Signed-off-by: Stephen Warren 
---
v2: No change.
---
 fs/fat/fat.c |6 ++
 1 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 80156c8..1e0d2a3 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -46,7 +46,6 @@ static void downcase(char *str)
 }
 
 static block_dev_desc_t *cur_dev;
-static unsigned int cur_part_nr;
 static disk_partition_t cur_part_info;
 
 #define DOS_BOOT_MAGIC_OFFSET  0x1fe
@@ -79,7 +78,6 @@ int fat_register_device(block_dev_desc_t * dev_desc, int 
part_no)
/* Read the partition table, if present */
if (!get_partition_info(dev_desc, part_no, &cur_part_info)) {
cur_dev = dev_desc;
-   cur_part_nr = part_no;
}
 #endif
 
@@ -92,7 +90,7 @@ int fat_register_device(block_dev_desc_t * dev_desc, int 
part_no)
}
 
cur_dev = dev_desc;
-   cur_part_nr = 1;
+   cur_part_info.part = 0;
cur_part_info.start = 0;
cur_part_info.size = dev_desc->lba;
cur_part_info.blksz = dev_desc->blksz;
@@ -1235,7 +1233,7 @@ int file_fat_detectfs(void)
vol_label[11] = '\0';
volinfo.fs_type[5] = '\0';
 
-   printf("Partition %d: Filesystem: %s \"%s\"\n", cur_part_nr,
+   printf("Partition %d: Filesystem: %s \"%s\"\n", cur_part_info.part,
volinfo.fs_type, vol_label);
 
return 0;
-- 
1.7.0.4

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

[U-Boot] [PATCH V2 1/3] part: add partition number to disk_partition_t

[Stephen Warren]

From: Stephen Warren 

The FAT filesystem code knows which partition ID it is operating on.
Currently, this is passed to fat_register_device() as a parameter.
In order to convert FAT to the more standardized fat_set_blk_dev(), the
information needs to come from somewhere else, and the partition
definition structure is the logical place.

Signed-off-by: Stephen Warren 
---
v2: No change.
---
 disk/part.c|1 +
 include/part.h |1 +
 2 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/disk/part.c b/disk/part.c
index a0c77dd..2bc7acb 100644
--- a/disk/part.c
+++ b/disk/part.c
@@ -391,6 +391,7 @@ int get_partition_info(block_dev_desc_t *dev_desc, int part
defined(CONFIG_MMC) || \
defined(CONFIG_SYSTEMACE)
 
+   info->part = part;
 #ifdef CONFIG_PARTITION_UUIDS
/* The common case is no UUID support */
info->uuid[0] = 0;
diff --git a/include/part.h b/include/part.h
index 27ea283..ebdebd8 100644
--- a/include/part.h
+++ b/include/part.h
@@ -88,6 +88,7 @@ typedef struct block_dev_desc {
 #define DEV_TYPE_OPDISK0x07/* optical disk */
 
 typedef struct disk_partition {
+   int part;   /* Partition number */
ulong   start;  /* # of first block in partition*/
ulong   size;   /* number of blocks in partition*/
ulong   blksz;  /* block size in bytes  */
-- 
1.7.0.4

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

Re: [U-Boot] [PATCH 67/72] serial: Unconditionally enable CONFIG_SERIAL_MULTI

[Stephen Warren]

On 09/29/2012 03:53 PM, Marek Vasut wrote:
> Enable CONFIG_SERIAL_MULTI for all builds of U-Boot. That includes
> both SPL builds and non-SPL builds, everything. To avoid poluting
> this patch with removal of ifdef-endif constructions containing
> CONFIG_SERIAL_MULTI, the CONFIG_SERIAL_MULTI is temporarily added
> into CPPFLAGS in config.mk . This will be again removed in following
> patch.

Marek,

This patch (at least, the version of it checked into u-boot/next) breaks
U-Boot on Tegra.

I believe the reason is because nothing ever calls serial_initialize()
in the SPL on Tegra. If I edit arch/arm/cpu/arm720t/tegra20/spl.c
function preloader_console_init() to call serial_initialize() right
before it calls serial_init(), then everything works fine. Without this,
drivers/serial/serial.c is never initialised (not even BSS cleared!) and
so it's left set to some bogus value, and so get_current() doesn't
replace it with default_serial_console(), so an invalid pointer is
accessed, causing a hang or crash.

I'm not sure quite what the correct solution is here. Is Tegra's custom
spl.c doing too much; stuff that should come from the common spl.c is
cut/paste here? Or, is adding the call to serial_initialize() the
correct fix? Or, is the root-cause of the problem that BSS
(serial_current) isn't being cleared to 0?

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

Re: [U-Boot] [PATCH] ARM: prevent misaligned array inits -- PLEASE DISREGARD.

[Albert ARIBAUD]

This patch has been sent without a proper Vx indication.

Resending.

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

[U-Boot] [PATCH V6] [RESEND] ARM: prevent misaligned array inits

[Albert ARIBAUD]

Under option -munaligned-access, gcc can perform local char
or 16-bit array initializations using misaligned native
accesses which will throw a data abort exception. Fix files
where these array initializations were unneeded, and for
files known to contain such initializations, enforce gcc
option -mno-unaligned-access.

Signed-off-by: Albert ARIBAUD 
---
V6: Make sure that gcc does not silently drop -mno-unaligned-access
if it does not support it.
V5: -mno-unaligned-access was applied to all platforms. Make it apply
only to armv7.
Clarified README.arm-unaligned-accesses re how to fix issue.
Included revert of 'release-only' workaround.
V4: added information on how to find relocation offset for pc
common/Makefile missed a comment re README.arm-unaligned-accesses
V3: *really* fix incorrect doc file name in dabort handler message
clarifications and typo fixes in README.arm-unaligned-accesses
V2: fix incorrect doc file name in dabort handler message

 arch/arm/cpu/arm926ejs/orion5x/cpu.c |4 +-
 arch/arm/cpu/armv7/config.mk |6 +-
 arch/arm/lib/interrupts.c|2 +-
 board/ti/omap2420h4/sys_info.c   |   28 
 common/Makefile  |4 ++
 common/cmd_dfu.c |2 +-
 doc/README.arm-unaligned-accesses|  122 ++
 fs/fat/Makefile  |2 +
 fs/ubifs/Makefile|3 +
 lib/Makefile |3 +
 10 files changed, 156 insertions(+), 20 deletions(-)
 create mode 100644 doc/README.arm-unaligned-accesses

diff --git a/arch/arm/cpu/arm926ejs/orion5x/cpu.c 
b/arch/arm/cpu/arm926ejs/orion5x/cpu.c
index c3948d3..5a4775a 100644
--- a/arch/arm/cpu/arm926ejs/orion5x/cpu.c
+++ b/arch/arm/cpu/arm926ejs/orion5x/cpu.c
@@ -194,8 +194,8 @@ u32 orion5x_device_rev(void)
  */
 int print_cpuinfo(void)
 {
-   char dev_str[] = "0x";
-   char rev_str[] = "0x00";
+   char dev_str[7]; /* room enough for 0x plus null byte */
+   char rev_str[5]; /* room enough for 0x00 plus null byte */
char *dev_name = NULL;
char *rev_name = NULL;
 
diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 560c084..3c5ca23 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -26,8 +26,6 @@ PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 # supported by more tool-chains
 PF_CPPFLAGS_ARMV7 := $(call cc-option, -march=armv7-a, -march=armv5)
 PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV7)
-PF_CPPFLAGS_NO_UNALIGNED := $(call cc-option, -mno-unaligned-access,)
-PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_NO_UNALIGNED)
 
 # =
 #
@@ -36,6 +34,10 @@ PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_NO_UNALIGNED)
 # =
 PF_RELFLAGS_SLB_AT := $(call cc-option,-mshort-load-bytes,$(call 
cc-option,-malignment-traps,))
 PLATFORM_RELFLAGS += $(PF_RELFLAGS_SLB_AT)
+
+# SEE README.arm-unaligned-accesses
+PLATFORM_NO_UNALIGNED := -mno-unaligned-access
+
 ifneq ($(CONFIG_IMX_CONFIG),)
 ALL-y  += $(obj)u-boot.imx
 endif
diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c
index 74ff5ce..02124a7 100644
--- a/arch/arm/lib/interrupts.c
+++ b/arch/arm/lib/interrupts.c
@@ -169,7 +169,7 @@ void do_prefetch_abort (struct pt_regs *pt_regs)
 
 void do_data_abort (struct pt_regs *pt_regs)
 {
-   printf ("data abort\n");
+   printf ("data abort\n\nMAYBE you should read 
doc/README.arm-unaligned-accesses\n\n");
show_regs (pt_regs);
bad_mode ();
 }
diff --git a/board/ti/omap2420h4/sys_info.c b/board/ti/omap2420h4/sys_info.c
index a9f7241..b12011e 100644
--- a/board/ti/omap2420h4/sys_info.c
+++ b/board/ti/omap2420h4/sys_info.c
@@ -237,20 +237,20 @@ u32 wait_on_value(u32 read_bit_mask, u32 match_value, u32 
read_addr, u32 bound)
  */
 void display_board_info(u32 btype)
 {
-   char cpu_2420[] = "2420";   /* cpu type */
-   char cpu_2422[] = "2422";
-   char cpu_2423[] = "2423";
-   char db_men[] = "Menelaus"; /* board type */
-   char db_ip[] = "IP";
-   char mem_sdr[] = "mSDR";/* memory type */
-   char mem_ddr[] = "mDDR";
-   char t_tst[] = "TST";   /* security level */
-   char t_emu[] = "EMU";
-   char t_hs[] = "HS";
-   char t_gp[] = "GP";
-   char unk[] = "?";
-
-   char *cpu_s, *db_s, *mem_s, *sec_s;
+   static const char cpu_2420 [] = "2420";   /* cpu type */
+   static const char cpu_2422 [] = "2422";
+   static const char cpu_2423 [] = "2423";
+   static const char db_men [] = "Menelaus"; /* board type */
+   static const char db_ip [] = "IP";
+   static const char mem_sdr [] = "mSDR";/* memory type */
+   static const char mem_ddr [] = "mDDR";
+   static const char t_tst [] = "TST";  

[U-Boot] [PATCH] ARM: prevent misaligned array inits

[Albert ARIBAUD]

Under option -munaligned-access, gcc can perform local char
or 16-bit array initializations using misaligned native
accesses which will throw a data abort exception. Fix files
where these array initializations were unneeded, and for
files known to contain such initializations, enforce gcc
option -mno-unaligned-access.

Signed-off-by: Albert ARIBAUD 
---
V6: Make sure that gcc does not silently drop -mno-unaligned-access
if it does not support it.
V5: -mno-unaligned-access was applied to all platforms. Make it apply
only to armv7.
Clarified README.arm-unaligned-accesses re how to fix issue.
Included revert of 'release-only' workaround.
V4: added information on how to find relocation offset for pc
common/Makefile missed a comment re README.arm-unaligned-accesses
V3: *really* fix incorrect doc file name in dabort handler message
clarifications and typo fixes in README.arm-unaligned-accesses
V2: fix incorrect doc file name in dabort handler message

 arch/arm/cpu/arm926ejs/orion5x/cpu.c |4 +-
 arch/arm/cpu/armv7/config.mk |6 +-
 arch/arm/lib/interrupts.c|2 +-
 board/ti/omap2420h4/sys_info.c   |   28 
 common/Makefile  |4 ++
 common/cmd_dfu.c |2 +-
 doc/README.arm-unaligned-accesses|  122 ++
 fs/fat/Makefile  |2 +
 fs/ubifs/Makefile|3 +
 lib/Makefile |3 +
 10 files changed, 156 insertions(+), 20 deletions(-)
 create mode 100644 doc/README.arm-unaligned-accesses

diff --git a/arch/arm/cpu/arm926ejs/orion5x/cpu.c 
b/arch/arm/cpu/arm926ejs/orion5x/cpu.c
index c3948d3..5a4775a 100644
--- a/arch/arm/cpu/arm926ejs/orion5x/cpu.c
+++ b/arch/arm/cpu/arm926ejs/orion5x/cpu.c
@@ -194,8 +194,8 @@ u32 orion5x_device_rev(void)
  */
 int print_cpuinfo(void)
 {
-   char dev_str[] = "0x";
-   char rev_str[] = "0x00";
+   char dev_str[7]; /* room enough for 0x plus null byte */
+   char rev_str[5]; /* room enough for 0x00 plus null byte */
char *dev_name = NULL;
char *rev_name = NULL;
 
diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 560c084..3c5ca23 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -26,8 +26,6 @@ PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 # supported by more tool-chains
 PF_CPPFLAGS_ARMV7 := $(call cc-option, -march=armv7-a, -march=armv5)
 PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV7)
-PF_CPPFLAGS_NO_UNALIGNED := $(call cc-option, -mno-unaligned-access,)
-PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_NO_UNALIGNED)
 
 # =
 #
@@ -36,6 +34,10 @@ PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_NO_UNALIGNED)
 # =
 PF_RELFLAGS_SLB_AT := $(call cc-option,-mshort-load-bytes,$(call 
cc-option,-malignment-traps,))
 PLATFORM_RELFLAGS += $(PF_RELFLAGS_SLB_AT)
+
+# SEE README.arm-unaligned-accesses
+PLATFORM_NO_UNALIGNED := -mno-unaligned-access
+
 ifneq ($(CONFIG_IMX_CONFIG),)
 ALL-y  += $(obj)u-boot.imx
 endif
diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c
index 74ff5ce..02124a7 100644
--- a/arch/arm/lib/interrupts.c
+++ b/arch/arm/lib/interrupts.c
@@ -169,7 +169,7 @@ void do_prefetch_abort (struct pt_regs *pt_regs)
 
 void do_data_abort (struct pt_regs *pt_regs)
 {
-   printf ("data abort\n");
+   printf ("data abort\n\nMAYBE you should read 
doc/README.arm-unaligned-accesses\n\n");
show_regs (pt_regs);
bad_mode ();
 }
diff --git a/board/ti/omap2420h4/sys_info.c b/board/ti/omap2420h4/sys_info.c
index a9f7241..b12011e 100644
--- a/board/ti/omap2420h4/sys_info.c
+++ b/board/ti/omap2420h4/sys_info.c
@@ -237,20 +237,20 @@ u32 wait_on_value(u32 read_bit_mask, u32 match_value, u32 
read_addr, u32 bound)
  */
 void display_board_info(u32 btype)
 {
-   char cpu_2420[] = "2420";   /* cpu type */
-   char cpu_2422[] = "2422";
-   char cpu_2423[] = "2423";
-   char db_men[] = "Menelaus"; /* board type */
-   char db_ip[] = "IP";
-   char mem_sdr[] = "mSDR";/* memory type */
-   char mem_ddr[] = "mDDR";
-   char t_tst[] = "TST";   /* security level */
-   char t_emu[] = "EMU";
-   char t_hs[] = "HS";
-   char t_gp[] = "GP";
-   char unk[] = "?";
-
-   char *cpu_s, *db_s, *mem_s, *sec_s;
+   static const char cpu_2420 [] = "2420";   /* cpu type */
+   static const char cpu_2422 [] = "2422";
+   static const char cpu_2423 [] = "2423";
+   static const char db_men [] = "Menelaus"; /* board type */
+   static const char db_ip [] = "IP";
+   static const char mem_sdr [] = "mSDR";/* memory type */
+   static const char mem_ddr [] = "mDDR";
+   static const char t_tst [] = "TST";  

[U-Boot] [PATCH V5] ARM: prevent misaligned array inits

[Albert ARIBAUD]

Under option -munaligned-access, gcc can perform local char
or 16-bit array initializations using misaligned native
accesses which will throw a data abort exception. Fix files
where these array initializations were unneeded, and for
files known to contain such initializations, enforce gcc
option -mno-unaligned-access.

Signed-off-by: Albert ARIBAUD 
---
V5: -mno-unaligned-access was applied to all platforms. Make it apply
only to armv7.
Clarified README.arm-unaligned-accesses re how to fix issue.
Included revert of 'release-only' workaround.
V4: added information on how to find relocation offset for pc
common/Makefile missed a comment re README.arm-unaligned-accesses
V3: *really* fix incorrect doc file name in dabort handler message
clarifications and typo fixes in README.arm-unaligned-accesses
V2: fix incorrect doc file name in dabort handler message

 arch/arm/cpu/arm926ejs/orion5x/cpu.c |4 +-
 arch/arm/cpu/armv7/config.mk |6 +-
 arch/arm/lib/interrupts.c|2 +-
 board/ti/omap2420h4/sys_info.c   |   28 
 common/Makefile  |4 ++
 common/cmd_dfu.c |2 +-
 doc/README.arm-unaligned-accesses|  122 ++
 fs/fat/Makefile  |2 +
 fs/ubifs/Makefile|3 +
 lib/Makefile |3 +
 10 files changed, 156 insertions(+), 20 deletions(-)
 create mode 100644 doc/README.arm-unaligned-accesses

diff --git a/arch/arm/cpu/arm926ejs/orion5x/cpu.c 
b/arch/arm/cpu/arm926ejs/orion5x/cpu.c
index c3948d3..5a4775a 100644
--- a/arch/arm/cpu/arm926ejs/orion5x/cpu.c
+++ b/arch/arm/cpu/arm926ejs/orion5x/cpu.c
@@ -194,8 +194,8 @@ u32 orion5x_device_rev(void)
  */
 int print_cpuinfo(void)
 {
-   char dev_str[] = "0x";
-   char rev_str[] = "0x00";
+   char dev_str[7]; /* room enough for 0x plus null byte */
+   char rev_str[5]; /* room enough for 0x00 plus null byte */
char *dev_name = NULL;
char *rev_name = NULL;
 
diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 560c084..429231e 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -26,8 +26,6 @@ PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 # supported by more tool-chains
 PF_CPPFLAGS_ARMV7 := $(call cc-option, -march=armv7-a, -march=armv5)
 PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV7)
-PF_CPPFLAGS_NO_UNALIGNED := $(call cc-option, -mno-unaligned-access,)
-PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_NO_UNALIGNED)
 
 # =
 #
@@ -36,6 +34,10 @@ PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_NO_UNALIGNED)
 # =
 PF_RELFLAGS_SLB_AT := $(call cc-option,-mshort-load-bytes,$(call 
cc-option,-malignment-traps,))
 PLATFORM_RELFLAGS += $(PF_RELFLAGS_SLB_AT)
+
+# SEE README.arm-unaligned-accesses
+PLATFORM_NO_UNALIGNED := $(call cc-option, -mno-unaligned-access,)
+
 ifneq ($(CONFIG_IMX_CONFIG),)
 ALL-y  += $(obj)u-boot.imx
 endif
diff --git a/arch/arm/lib/interrupts.c b/arch/arm/lib/interrupts.c
index 74ff5ce..02124a7 100644
--- a/arch/arm/lib/interrupts.c
+++ b/arch/arm/lib/interrupts.c
@@ -169,7 +169,7 @@ void do_prefetch_abort (struct pt_regs *pt_regs)
 
 void do_data_abort (struct pt_regs *pt_regs)
 {
-   printf ("data abort\n");
+   printf ("data abort\n\nMAYBE you should read 
doc/README.arm-unaligned-accesses\n\n");
show_regs (pt_regs);
bad_mode ();
 }
diff --git a/board/ti/omap2420h4/sys_info.c b/board/ti/omap2420h4/sys_info.c
index a9f7241..b12011e 100644
--- a/board/ti/omap2420h4/sys_info.c
+++ b/board/ti/omap2420h4/sys_info.c
@@ -237,20 +237,20 @@ u32 wait_on_value(u32 read_bit_mask, u32 match_value, u32 
read_addr, u32 bound)
  */
 void display_board_info(u32 btype)
 {
-   char cpu_2420[] = "2420";   /* cpu type */
-   char cpu_2422[] = "2422";
-   char cpu_2423[] = "2423";
-   char db_men[] = "Menelaus"; /* board type */
-   char db_ip[] = "IP";
-   char mem_sdr[] = "mSDR";/* memory type */
-   char mem_ddr[] = "mDDR";
-   char t_tst[] = "TST";   /* security level */
-   char t_emu[] = "EMU";
-   char t_hs[] = "HS";
-   char t_gp[] = "GP";
-   char unk[] = "?";
-
-   char *cpu_s, *db_s, *mem_s, *sec_s;
+   static const char cpu_2420 [] = "2420";   /* cpu type */
+   static const char cpu_2422 [] = "2422";
+   static const char cpu_2423 [] = "2423";
+   static const char db_men [] = "Menelaus"; /* board type */
+   static const char db_ip [] = "IP";
+   static const char mem_sdr [] = "mSDR";/* memory type */
+   static const char mem_ddr [] = "mDDR";
+   static const char t_tst [] = "TST"; /* security level */
+   static const char t_emu [] = "EMU";
+  

Re: [U-Boot] [PATCH] yaffs2: Fix GCC 4.6 compile warnings

[Scott Wood]

On 10/09/2012 01:51:14 PM, Tom Rini wrote:

On Tue, Oct 09, 2012 at 01:09:22PM -0500, Scott Wood wrote:
> On 10/06/2012 11:59:17 AM, Albert ARIBAUD wrote:
> >Hi Anatolij,
> >
> >On Sat,  6 Oct 2012 11:31:03 +0200, Anatolij Gustschin  


> >wrote:
> >
> >> Fix:
> >> yaffs_guts.c: In function 'yaffs_check_chunk_erased':
> >> yaffs_guts.c:324:6: warning: variable 'result' set but not used
> >> [-Wunused-but-set-variable]
> [snip]
> >Tested-by: Albert ARIBAUD 
> >
> >This effectively makes VCMA9 and smdk2410 (the two boards which had
> >the yaffs warnings) build clean.
>
> It takes care of the warnings, but I still see this:
>
> Configuring for VCMA9 board...
> make: *** [u-boot] Error 139

The linaro and ELDK 4.2, 5.2 toolchains build this fine.  I would
suggest grabbing one of those for ARM.


I'll give one of them a try, but is it expected that the compiler will  
be able to do 64/32 division without __udivdi3?  Shouldn't yaffs2 be  
using lldiv() or do_div()?


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

Re: [U-Boot] [PATCH V4] ARM: prevent misaligned array inits

[Tom Rini]

On Tue, Oct 09, 2012 at 08:42:26PM +0200, Albert ARIBAUD wrote:
> Hi Tom,
> 
> On Tue, 9 Oct 2012 11:34:11 -0700, Tom Rini  wrote:
> 
> > On Mon, Oct 08, 2012 at 09:50:18PM +0200, Albert ARIBAUD wrote:
> > 
> > > Under option -munaligned-access, gcc can perform local char
> > > or 16-bit array initializations using misaligned native
> > > accesses which will throw a data abort exception. Fix files
> > > where these array initializations were unneeded, and for
> > > files known to contain such initializations, enforce gcc
> > > option -mno-unaligned-access.
> > > 
> > > Signed-off-by: Albert ARIBAUD 
> > 
> > We unfortunately have a problem here.  This ends up passing
> > -mno-unaligned-access globally, for all platforms.  We need something
> > like the following:
> 
> General remark: I'd strongly suggest not to copy-paste in a list reply
> somtheing that looks suspiciously like a (new) patch. It leads to this
> kind of things: http://patchwork.ozlabs.org/patch/190403/ which may not
> be what you wanted.
> 
> > Ensure that we only pass -mno-unaligned-access to ARMv7 platforms (where
> > we must ensure this flag is passed so no using call-cc-option).
> > 
> > Signed-off-by; Tom Rini 
> > 
> > diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
> > index 5407cb6..3c5ca23 100644
> > --- a/arch/arm/cpu/armv7/config.mk
> > +++ b/arch/arm/cpu/armv7/config.mk
> > @@ -34,6 +34,10 @@ PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV7)
> >  # =
> >  PF_RELFLAGS_SLB_AT := $(call cc-option,-mshort-load-bytes,$(call 
> > cc-option,-malignment-traps,))
> >  PLATFORM_RELFLAGS += $(PF_RELFLAGS_SLB_AT)
> > +
> > +# SEE README.arm-unaligned-accesses
> > +PLATFORM_NO_UNALIGNED := -mno-unaligned-access
> 
> I suspect that you meant
> 
> PLATFORM_NO_UNALIGNED := $(call cc-option,-mno-unaligned-access,)

This could lead to silently not applying the flag when we want to apply
the flag.  Just like before, I think we need to force the option, until
such time as we can do $(call
cc-option,-mdont-unalign-strings-for-fun,-mno-unaligned-access).

-- 
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] yaffs2: Fix GCC 4.6 compile warnings

[Tom Rini]

On Tue, Oct 09, 2012 at 01:09:22PM -0500, Scott Wood wrote:
> On 10/06/2012 11:59:17 AM, Albert ARIBAUD wrote:
> >Hi Anatolij,
> >
> >On Sat,  6 Oct 2012 11:31:03 +0200, Anatolij Gustschin 
> >wrote:
> >
> >> Fix:
> >> yaffs_guts.c: In function 'yaffs_check_chunk_erased':
> >> yaffs_guts.c:324:6: warning: variable 'result' set but not used
> >> [-Wunused-but-set-variable]
> [snip]
> >Tested-by: Albert ARIBAUD 
> >
> >This effectively makes VCMA9 and smdk2410 (the two boards which had
> >the yaffs warnings) build clean.
> 
> It takes care of the warnings, but I still see this:
> 
> Configuring for VCMA9 board...
> make: *** [u-boot] Error 139

The linaro and ELDK 4.2, 5.2 toolchains build this fine.  I would
suggest grabbing one of those for ARM.

-- 
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 V4] ARM: prevent misaligned array inits

[Albert ARIBAUD]

Hi Tom,

On Tue, 9 Oct 2012 11:34:11 -0700, Tom Rini  wrote:

> On Mon, Oct 08, 2012 at 09:50:18PM +0200, Albert ARIBAUD wrote:
> 
> > Under option -munaligned-access, gcc can perform local char
> > or 16-bit array initializations using misaligned native
> > accesses which will throw a data abort exception. Fix files
> > where these array initializations were unneeded, and for
> > files known to contain such initializations, enforce gcc
> > option -mno-unaligned-access.
> > 
> > Signed-off-by: Albert ARIBAUD 
> 
> We unfortunately have a problem here.  This ends up passing
> -mno-unaligned-access globally, for all platforms.  We need something
> like the following:

General remark: I'd strongly suggest not to copy-paste in a list reply
somtheing that looks suspiciously like a (new) patch. It leads to this
kind of things: http://patchwork.ozlabs.org/patch/190403/ which may not
be what you wanted.

> Ensure that we only pass -mno-unaligned-access to ARMv7 platforms (where
> we must ensure this flag is passed so no using call-cc-option).
> 
> Signed-off-by; Tom Rini 
> 
> diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
> index 5407cb6..3c5ca23 100644
> --- a/arch/arm/cpu/armv7/config.mk
> +++ b/arch/arm/cpu/armv7/config.mk
> @@ -34,6 +34,10 @@ PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV7)
>  # =
>  PF_RELFLAGS_SLB_AT := $(call cc-option,-mshort-load-bytes,$(call 
> cc-option,-malignment-traps,))
>  PLATFORM_RELFLAGS += $(PF_RELFLAGS_SLB_AT)
> +
> +# SEE README.arm-unaligned-accesses
> +PLATFORM_NO_UNALIGNED := -mno-unaligned-access

I suspect that you meant

PLATFORM_NO_UNALIGNED := $(call cc-option,-mno-unaligned-access,)

?

> +
>  ifneq ($(CONFIG_IMX_CONFIG),)
>  ALL-y+= $(obj)u-boot.imx
>  endif
> diff --git a/common/Makefile b/common/Makefile
> index a498367..33c606a 100644
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -233,8 +233,8 @@ $(obj)../tools/envcrc:
>   $(MAKE) -C ../tools
>  
>  # SEE README.arm-unaligned-accesses
> -$(obj)hush.o: CFLAGS += -mno-unaligned-access
> -$(obj)fdt_support.o: CFLAGS += -mno-unaligned-access
> +$(obj)hush.o: CFLAGS += $(PLATFORM_NO_UNALIGNED)
> +$(obj)fdt_support.o: CFLAGS += $(PLATFORM_NO_UNALIGNED)
>  
>  #
>  
> diff --git a/fs/fat/Makefile b/fs/fat/Makefile
> index 5c4a2aa..02e6881 100644
> --- a/fs/fat/Makefile
> +++ b/fs/fat/Makefile
> @@ -40,7 +40,7 @@ $(LIB): $(obj).depend $(OBJS)
>   $(call cmd_link_o_target, $(OBJS))
>  
>  # SEE README.arm-unaligned-accesses
> -$(obj)file.o: CFLAGS += -mno-unaligned-access
> +$(obj)file.o: CFLAGS += $(PLATFORM_NO_UNALIGNED)
>  
>  #
>  
> diff --git a/fs/ubifs/Makefile b/fs/ubifs/Makefile
> index 71c40f2..bfe6874 100644
> --- a/fs/ubifs/Makefile
> +++ b/fs/ubifs/Makefile
> @@ -43,7 +43,7 @@ $(LIB): $(obj).depend $(OBJS)
>   $(call cmd_link_o_target, $(OBJS))
>  
>  # SEE README.arm-unaligned-accesses
> -$(obj)super.o: CFLAGS += -mno-unaligned-access
> +$(obj)super.o: CFLAGS += $(PLATFORM_NO_UNALIGNED)
>  
>  #
>  
> diff --git a/lib/Makefile b/lib/Makefile
> index decc5ee..e44e045 100644
> --- a/lib/Makefile
> +++ b/lib/Makefile
> @@ -84,7 +84,7 @@ $(LIB): $(obj).depend $(OBJS)
>   $(call cmd_link_o_target, $(OBJS))
>  
>  # SEE README.arm-unaligned-accesses
> -$(obj)bzlib.o: CFLAGS += -mno-unaligned-access
> +$(obj)bzlib.o: CFLAGS += $(PLATFORM_NO_UNALIGNED)
>  
>  #

Will prepare V5 right away.

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

Re: [U-Boot] [PATCH V4] ARM: prevent misaligned array inits

[Tom Rini]

On Mon, Oct 08, 2012 at 09:50:18PM +0200, Albert ARIBAUD wrote:

> Under option -munaligned-access, gcc can perform local char
> or 16-bit array initializations using misaligned native
> accesses which will throw a data abort exception. Fix files
> where these array initializations were unneeded, and for
> files known to contain such initializations, enforce gcc
> option -mno-unaligned-access.
> 
> Signed-off-by: Albert ARIBAUD 

We unfortunately have a problem here.  This ends up passing
-mno-unaligned-access globally, for all platforms.  We need something
like the following:

Ensure that we only pass -mno-unaligned-access to ARMv7 platforms (where
we must ensure this flag is passed so no using call-cc-option).

Signed-off-by; Tom Rini 

diff --git a/arch/arm/cpu/armv7/config.mk b/arch/arm/cpu/armv7/config.mk
index 5407cb6..3c5ca23 100644
--- a/arch/arm/cpu/armv7/config.mk
+++ b/arch/arm/cpu/armv7/config.mk
@@ -34,6 +34,10 @@ PLATFORM_CPPFLAGS += $(PF_CPPFLAGS_ARMV7)
 # =
 PF_RELFLAGS_SLB_AT := $(call cc-option,-mshort-load-bytes,$(call 
cc-option,-malignment-traps,))
 PLATFORM_RELFLAGS += $(PF_RELFLAGS_SLB_AT)
+
+# SEE README.arm-unaligned-accesses
+PLATFORM_NO_UNALIGNED := -mno-unaligned-access
+
 ifneq ($(CONFIG_IMX_CONFIG),)
 ALL-y  += $(obj)u-boot.imx
 endif
diff --git a/common/Makefile b/common/Makefile
index a498367..33c606a 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -233,8 +233,8 @@ $(obj)../tools/envcrc:
$(MAKE) -C ../tools
 
 # SEE README.arm-unaligned-accesses
-$(obj)hush.o: CFLAGS += -mno-unaligned-access
-$(obj)fdt_support.o: CFLAGS += -mno-unaligned-access
+$(obj)hush.o: CFLAGS += $(PLATFORM_NO_UNALIGNED)
+$(obj)fdt_support.o: CFLAGS += $(PLATFORM_NO_UNALIGNED)
 
 #
 
diff --git a/fs/fat/Makefile b/fs/fat/Makefile
index 5c4a2aa..02e6881 100644
--- a/fs/fat/Makefile
+++ b/fs/fat/Makefile
@@ -40,7 +40,7 @@ $(LIB):   $(obj).depend $(OBJS)
$(call cmd_link_o_target, $(OBJS))
 
 # SEE README.arm-unaligned-accesses
-$(obj)file.o: CFLAGS += -mno-unaligned-access
+$(obj)file.o: CFLAGS += $(PLATFORM_NO_UNALIGNED)
 
 #
 
diff --git a/fs/ubifs/Makefile b/fs/ubifs/Makefile
index 71c40f2..bfe6874 100644
--- a/fs/ubifs/Makefile
+++ b/fs/ubifs/Makefile
@@ -43,7 +43,7 @@ $(LIB):   $(obj).depend $(OBJS)
$(call cmd_link_o_target, $(OBJS))
 
 # SEE README.arm-unaligned-accesses
-$(obj)super.o: CFLAGS += -mno-unaligned-access
+$(obj)super.o: CFLAGS += $(PLATFORM_NO_UNALIGNED)
 
 #
 
diff --git a/lib/Makefile b/lib/Makefile
index decc5ee..e44e045 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -84,7 +84,7 @@ $(LIB):   $(obj).depend $(OBJS)
$(call cmd_link_o_target, $(OBJS))
 
 # SEE README.arm-unaligned-accesses
-$(obj)bzlib.o: CFLAGS += -mno-unaligned-access
+$(obj)bzlib.o: CFLAGS += $(PLATFORM_NO_UNALIGNED)
 
 #
 
-- 
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] yaffs2: Fix GCC 4.6 compile warnings

[Scott Wood]

On 10/06/2012 11:59:17 AM, Albert ARIBAUD wrote:

Hi Anatolij,

On Sat,  6 Oct 2012 11:31:03 +0200, Anatolij Gustschin 
wrote:

> Fix:
> yaffs_guts.c: In function 'yaffs_check_chunk_erased':
> yaffs_guts.c:324:6: warning: variable 'result' set but not used
> [-Wunused-but-set-variable]

[snip]

Tested-by: Albert ARIBAUD 

This effectively makes VCMA9 and smdk2410 (the two boards which had
the yaffs warnings) build clean.


It takes care of the warnings, but I still see this:

Configuring for VCMA9 board...
make: *** [u-boot] Error 139
/home/scott/fsl/tc/arm-gentoo-linux-gnu/bin/arm-gentoo-linux-gnu-size:  
./u-boot: File format not recognized

fs/yaffs2/libyaffs2.o: In function `cmd_yaffs_devconfig':
/home/scott/fsl/git/u-boot/upstream/fs/yaffs2/yaffs_uboot_glue.c:187:  
undefined reference to `__udivdi3'

fs/yaffs2/libyaffs2.o: In function `yaffsfs_DoStat':
/home/scott/fsl/git/u-boot/upstream/fs/yaffs2/yaffsfs.c:1606: undefined  
reference to `__divdi3'
  
/home/scott/fsl/tc/arm-gentoo-linux-gnu/bin/arm-gentoo-linux-gnu-ld.bfd:  
BFD (GNU Binutils) 2.21.1 assertion fail  
/var/tmp/portage/cross-arm-gentoo-linux-gnu/binutils-2.21.1-r1/work/binutils-2.21.1/bfd/elf32-arm.c:12478
/bin/bash: line 1:  6558 Segmentation fault  (core dumped)  
/home/scott/fsl/tc/arm-gentoo-linux-gnu/bin/arm-gentoo-linux-gnu-ld.bfd  
-pie -T u-boot.lds -Bstatic -Ttext 0x0 $UNDEF_SYM  
arch/arm/cpu/arm920t/start.o --start-group api/libapi.o  
arch/arm/cpu/arm920t/libarm920t.o  
arch/arm/cpu/arm920t/s3c24x0/libs3c24x0.o arch/arm/lib/libarm.o  
common/libcommon.o disk/libdisk.o drivers/bios_emulator/libatibiosemu.o  
drivers/block/libblock.o drivers/dfu/libdfu.o drivers/dma/libdma.o  
drivers/fpga/libfpga.o drivers/gpio/libgpio.o drivers/hwmon/libhwmon.o  
drivers/i2c/libi2c.o drivers/input/libinput.o drivers/misc/libmisc.o  
drivers/mmc/libmmc.o drivers/mtd/libmtd.o drivers/mtd/nand/libnand.o  
drivers/mtd/onenand/libonenand.o drivers/mtd/spi/libspi_flash.o  
drivers/mtd/ubi/libubi.o drivers/net/libnet.o drivers/net/phy/libphy.o  
drivers/pci/libpci.o drivers/pcmcia/libpcmcia.o  
drivers/power/libpower.o drivers/rtc/librtc.o  
drivers/serial/libserial.o drivers/spi/libspi.o  
drivers/twserial/libtws.o drivers/usb/eth/libusb_eth.o  
drivers/usb/gadget/libusb_gadget.o drivers/usb/host/libusb_host.o  
drivers/usb/musb/libusb_musb.o drivers/usb/phy/libusb_phy.o  
drivers/usb/ulpi/libusb_ulpi.o drivers/video/libvideo.o  
drivers/watchdog/libwatchdog.o fs/cramfs/libcramfs.o  
fs/ext4/libext4fs.o fs/fat/libfat.o fs/fdos/libfdos.o  
fs/jffs2/libjffs2.o fs/reiserfs/libreiserfs.o fs/ubifs/libubifs.o  
fs/yaffs2/libyaffs2.o fs/zfs/libzfs.o lib/libfdt/libfdt.o  
lib/libgeneric.o lib/lzma/liblzma.o lib/lzo/liblzo.o lib/zlib/libz.o  
net/libnet.o post/libpost.o test/libtest.o board/mpl/vcma9/libvcma9.o  
--end-group /home/scott/fsl/git/u-boot/upstream/arch/arm/lib/libgcc.o  
-Map u-boot.map -o u-boot

make: *** [u-boot] Error 139

This is with USE_PRIVATE_LIBGCC=yes and "gcc version 4.6.2 (Gentoo 4.6.2
p1.0, pie-0.4.5)" from Mike Frysinger's toolchain set.

Turning off USE_PRIVATE_LIBGCC produces more errors (lots of hard/soft  
FP

conflicts, undefined "raise", and the same linker segfault).

Is this toolchain expected to work?

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

Re: [U-Boot] [PATCH v2 05/21] pmic: Introduce power_board_init() method at ./lib/board.c file

[Tom Rini]

On Tue, Oct 09, 2012 at 01:34:35PM +0200, Stefano Babic wrote:
> On 09/10/2012 12:25, Lukasz Majewski wrote:
[snip]
> >> We use often the "weak" mechanism to avoid that a board maintainer is
> >> constrained to implement an empty function only to make happy the
> >> linker. It is better to declare the function as weak and call it with
> >> the same schema, such as board_power_init() (several board_* are weak)
> > 
> > Correct me if I'm wrong, but weren't we recently trying to remove
> > functions defined as weak?
> 
> I am not aware of it. I see several patches in last days adding weak
> function. Several weak function are present in the recent added SPL
> framework.

We should use weak functions when we can provide a functioning in many
cases default but need to allow for overrides in some cases.  We
shouldn't use them when everyone needs to define the function and it has
to do something.

-- 
Tom


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

[U-Boot] [PATCH V2] fs: fat: Fix mkcksum() function parameters

[Marek Vasut]

The mkcksum() function now takes one parameter, the pointer to
11-byte wide character array, which it then operates on.

Currently, the function is wrongly passed (dir_entry)->name, which
is only 8-byte wide character array. Though by further inspecting
the dir_entry structure, it can be noticed that the name[8] entry
is immediatelly followed by ext[3] entry. Thus, name[8] and ext[3]
in the dir_entry structure actually work as this 11-byte wide array
since they're placed right next to each other by current compiler
behavior.

Depending on this is obviously wrong, thus fix this by correctly
passing both (dir_entry)->name and (dir_entry)->ext to the mkcksum()
function and adjust the function appropriately.

Signed-off-by: Marek Vasut 
Cc: Tom Rini 
---
 fs/fat/fat.c   |   20 
 fs/fat/fat_write.c |2 +-
 2 files changed, 13 insertions(+), 9 deletions(-)

V2: Fix fat write by adding braces

diff --git a/fs/fat/fat.c b/fs/fat/fat.c
index 41ae15e..8870292 100644
--- a/fs/fat/fat.c
+++ b/fs/fat/fat.c
@@ -567,15 +567,16 @@ get_vfatname(fsdata *mydata, int curclust, __u8 *cluster,
 }
 
 /* Calculate short name checksum */
-static __u8 mkcksum(const char *str)
+static __u8 mkcksum(const char name[8], const char ext[3])
 {
int i;
 
__u8 ret = 0;
 
-   for (i = 0; i < 11; i++) {
-   ret = (((ret & 1) << 7) | ((ret & 0xfe) >> 1)) + str[i];
-   }
+   for (i = 0; i < sizeof(name); i++)
+   ret = (((ret & 1) << 7) | ((ret & 0xfe) >> 1)) + name[i];
+   for (i = 0; i < sizeof(ext); i++)
+   ret = (((ret & 1) << 7) | ((ret & 0xfe) >> 1)) + ext[i];
 
return ret;
 }
@@ -678,7 +679,8 @@ static dir_entry *get_dentfromdir(fsdata *mydata, int 
startsect,
return NULL;
}
 #ifdef CONFIG_SUPPORT_VFAT
-   if (dols && mkcksum(dentptr->name) == prevcksum) {
+   __u8 csum = mkcksum(dentptr->name, dentptr->ext);
+   if (dols && csum == prevcksum) {
prevcksum = 0x;
dentptr++;
continue;
@@ -946,13 +948,16 @@ do_fat_read_at(const char *filename, unsigned long pos, 
void *buffer,
 
for (i = 0; i < DIRENTSPERBLOCK; i++) {
char s_name[14], l_name[VFAT_MAXLEN_BYTES];
+   __u8 csum;
 
l_name[0] = '\0';
if (dentptr->name[0] == DELETED_FLAG) {
dentptr++;
continue;
}
-   if ((dentptr->attr & ATTR_VOLUME)) {
+
+   csum = mkcksum(dentptr->name, dentptr->ext);
+   if (dentptr->attr & ATTR_VOLUME) {
 #ifdef CONFIG_SUPPORT_VFAT
if ((dentptr->attr & ATTR_VFAT) == ATTR_VFAT &&
(dentptr->name[0] & LAST_LONG_ENTRY_MASK)) {
@@ -1015,8 +1020,7 @@ do_fat_read_at(const char *filename, unsigned long pos, 
void *buffer,
goto exit;
}
 #ifdef CONFIG_SUPPORT_VFAT
-   else if (dols == LS_ROOT &&
-mkcksum(dentptr->name) == prevcksum) {
+   else if (dols == LS_ROOT && csum == prevcksum) {
prevcksum = 0x;
dentptr++;
continue;
diff --git a/fs/fat/fat_write.c b/fs/fat/fat_write.c
index 5829adf..4a1bda0 100644
--- a/fs/fat/fat_write.c
+++ b/fs/fat/fat_write.c
@@ -335,7 +335,7 @@ fill_dir_slot(fsdata *mydata, dir_entry **dentptr, const 
char *l_name)
 
/* Get short file name and checksum value */
strncpy(s_name, (*dentptr)->name, 16);
-   checksum = mkcksum(s_name);
+   checksum = mkcksum((*dentptr)->name, (*dentptr)->ext);
 
do {
memset(slotptr, 0x00, sizeof(dir_slot));
-- 
1.7.10.4

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

Re: [U-Boot] common: cmd_bdinfo: fix type of value in print_lnum

[Tom Rini]

On Wed, Oct 03, 2012 at 08:36:11AM -, Daniel Schwierzeck wrote:

> From: Daniel Schwierzeck 
> 
> This fixes a warning when compiling with ELDK-5.2.1 for MIPS64:
> 
> cmd_bdinfo.c: In function 'print_lnum':
> cmd_bdinfo.c:56:2: warning: format '%llX' expects argument of type 'long long 
> unsigned int', but argument 3 has type 'u64' [-Wformat]
> 
> Signed-off-by: Daniel Schwierzeck 

Applied to u-boot/next, thanks!

-- 
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,v2] tools: Add cleanpatch

[Tom Rini]

On Fri, Sep 28, 2012 at 03:36:14AM -, Fabio Estevam wrote:

> There are some errors reported by checkpatch.pl that can be easily cleaned up 
> by 
> using the cleanpatch tool.
> 
> Import the cleanpatch script from linux kernel 3.5.4 stable version as from 
> the 
> following commit:
> 
> commit cb3ed5b7e09c6c0462e396d55e3fecc0980a333a
> Author: H. Peter Anvin 
> Date:   Fri May 25 17:58:26 2007 -0700
> 
> scripts: Make cleanfile/cleanpatch warn about long lines
> 
> Signed-off-by: Fabio Estevam 

Applied to u-boot/next, thanks!

-- 
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] MAKEALL: add a -C/--check option to enable build checking

[Tom Rini]

On Thu, Sep 27, 2012 at 02:57:34PM -, Kim Phillips wrote:

> thanks to Tom Rini for the good idea.
> 
> Signed-off-by: Kim Phillips 

Applied to u-boot/next, thanks!

-- 
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] add check infrastructure, default sparse

[Tom Rini]

On Fri, Sep 21, 2012 at 12:28:17PM -, Kim Phillips wrote:

> Add support for running source code checkers on u-boot source, e.g.,
> using sparse to aid with typechecking.  This comes in especially
> handy as SoC vendors mix and match cores and devices with different
> endianness, thus here we add CHECK_ENDIAN to the otherwise linux
> kernel default CHECKFLAGS.
> 
> Signed-off-by: Kim Phillips 

Applied to u-boot/next, thanks!

-- 
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] patman: Handle checkpatch.pl not providing file/line info

[Tom Rini]

On Thu, Sep 27, 2012 at 03:33:46PM -, Simon Glass wrote:

> Sometimes we don't get a valid filename or line number from checkpatch.pl,
> for example if the patch is in a bad format. Deal with this by using a
> default value, rather than a stack trace.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

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

Re: [U-Boot] patman: Support Series-name tag to name a series

[Tom Rini]

On Thu, Sep 27, 2012 at 03:06:02PM -, Simon Glass wrote:

> Sometimes it is possible to forget the name of the branch you used to
> generate an upstream series. To assist with this, add an optional
> patman does not use this.
> 
> Signed-off-by: Simon Glass 

Applied to u-boot/next, thanks!

-- 
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 v1 0/9] block: Fix some inconsistencies in block_{read, write} implementors

[Tom Rini]

On Sat, Sep 29, 2012 at 01:51:47PM -0700, Tom Rini wrote:

> Hey all,
> 
> I ran into this problem while testing Pavel Herrmann's patch to move
> externs to .  To fix these problems I've taken over the patch.
> Pavel's patch makes all of the sata drivers include , and this
> exposed a number of build problems due to type mis-match.  Examining
> these mis-matches leads to this series.  Both  and  set
> prototypes for block_dev_desc_t->block_{read,write} implementors that
> did not match the prototype.  First we fix these implemenators (and in
> the case of ata_piix.[ch] fix a large number of checkpatch issues.  Then
> we fix the prototypes in the headers.

I've applied this to u-boot/next.

-- 
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 05/10] split CPC45 board-specific IDE functions from cmd_ide.c

[Marek Vasut]

Dear Pavel Herrmann,

> On Sunday 07 of October 2012 20:20:08 Marek Vasut wrote:
> > Dear Pavel Herrmann,
> > 
> > > Move input_data() and friends to board/cpc45/ide.c, as overrides for
> > > weak aliases in cmd_ide.c
> > > 
> > > note: checkpatch emits warnings about using volatile
> > > 
> > > Signed-off-by: Pavel Herrmann 
> > > ---
> > > 
> > >  board/cpc45/Makefile |   2 +-
> > >  board/cpc45/ide.c| 130
> > > 
> > > +++ common/cmd_ide.c   
> > >  |
> > > 
> > >  91 
> > >  3 files changed, 131 insertions(+), 92 deletions(-)
> > >  create mode 100644 board/cpc45/ide.c
> > > 
> > > diff --git a/board/cpc45/Makefile b/board/cpc45/Makefile
> > > index 5c6b78f..ac1d174 100644
> > > --- a/board/cpc45/Makefile
> > > +++ b/board/cpc45/Makefile
> > > @@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
> > > 
> > >  LIB  = $(obj)lib$(BOARD).o
> > > 
> > > -COBJS= $(BOARD).o flash.o plx9030.o pd67290.o
> > > +COBJS= $(BOARD).o flash.o plx9030.o pd67290.o ide.o
> > > 
> > >  SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> > >  OBJS := $(addprefix $(obj),$(COBJS))
> > > 
> > > diff --git a/board/cpc45/ide.c b/board/cpc45/ide.c
> > > new file mode 100644
> > > index 000..7b7237b
> > > --- /dev/null
> > > +++ b/board/cpc45/ide.c
> > > @@ -0,0 +1,130 @@
> > > +/*
> > > + * (C) Copyright 2001
> > > + * Rob Taylor, Flying Pig Systems. r...@flyingpig.com.
> > > + *
> > > + * (C) Copyright 2000-2011
> > > + * 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
> > > + */
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > > +
> > > +#define EIEIO__asm__ volatile ("eieio")
> > > +#define SYNC __asm__ volatile ("sync")
> > 
> > Make it asm, not __asm__
> > 
> > > +
> > > +void ide_input_swap_data(int dev, ulong *sect_buf, int words)
> > > +{
> > > + uchar i;
> > > + volatile uchar *pbuf_even =
> > > + (uchar *) (ATA_CURR_BASE(dev) + ATA_DATA_EVEN);
> > > + volatile uchar *pbuf_odd =
> > > + (uchar *) (ATA_CURR_BASE(dev) + ATA_DATA_ODD);
> > > + ushort *dbuf = (ushort *) sect_buf;
> > 
> > What's this, some kind of __swab16() ?
> 
> more probably this is a hack for strange wiring on the board

That much I see myself ... but the goo below does the same thing as swab16(), 
doesn't it ?

> > > + while (words--) {
> > > + for (i = 0; i < 2; i++) {
> > > + *(((uchar *) (dbuf)) + 1) = *pbuf_even;
> > > + *(uchar *) dbuf = *pbuf_odd;
> > > + dbuf += 1;
> > > + }
> > > + }
> > > +}
> > 
> > [...]
> > 
> > I'm not reviewing this any further ... this is some ancient code, right?
> 
> yes, this series is mostly cut-and-paste cleanup of old code, changes were
> made only when checkpatch didnt approve.
> 
> Pavel Herrmann

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 0/4] Keyboard input improvements

[Tom Rini]

On Thu, Sep 27, 2012 at 06:18:39PM -0700, Simon Glass wrote:

> This is a small series of patches to improve keyboard input for matrix
> keyboards:
> 
> - Fix an fdt decoding bug which breaks seaboard
> - Permit key repeat/delay to be altered after init
> - Allow key ghosting filter to be enabled/disabled
> - Add a bit more debugging
> 
> Since this series mostly affects tegra I suggest that it goes through
> the tegra tree.
> 
> 
> Simon Glass (4):
>   input: Correct key_matrix fdt decoding
>   input: Separate out keyboard repeat/delay from init
>   input: Allow key ghosting filter to be disabled
>   input: Add debugging for key matrix key codes
> 
>  drivers/input/input.c  |   13 +
>  drivers/input/key_matrix.c |   22 --
>  drivers/input/tegra-kbc.c  |7 ---
>  include/input.h|   14 ++
>  include/key_matrix.h   |5 -
>  5 files changed, 43 insertions(+), 18 deletions(-)

Applied to u-boot/next, thanks!

-- 
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 v2 0/5] Cleanup fw_*env and a few common env

[Tom Rini]

On Wed, Oct 03, 2012 at 02:38:45PM -0500, Joe Hershberger wrote:

> This is a gutted version of my previous env series in an effort to reduce the
> risk to the release that is approaching shortly.
> 
> Changes in v2:
> - Further simplified based Mike's comments
> 
> Joe Hershberger (5):
>   tools/env: Use a board-specific default env
>   tools/env: Remove unneeded complexity
>   tools/env: Don't call env_init() in fw_getenv()
>   tools/env: Serialize calls to fw_*env
>   env: Check for NULL pointer in envmatch()
> 
>  common/cmd_nvedit.c |  3 +++
>  tools/env/Makefile  |  5 ++--
>  tools/env/fw_env.c  | 66 
> +
>  tools/env/fw_env.h  | 19 ++
>  tools/env/fw_env_main.c | 59 ++-
>  5 files changed, 90 insertions(+), 62 deletions(-)

This, and the follow up README have been applied to u-boot/next, thanks!

-- 
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 04/10] change all versions of input_data() and output_data() to global weak aliases

[Marek Vasut]

Dear Pavel Herrmann,

> On Sunday 07 of October 2012 20:14:23 Marek Vasut wrote:
> > Dear Pavel Herrmann,
> > 
> > > This changes input_data() and friends from static function to global
> > > symbols under weak alias, to enable board specific overrides (and
> > > therefore get rid of board-specific code in cmd_ide.c)
> > > Also declare ide_bus_offset in the header file, so other files can use
> > > ATA_CURR_BASE as well.
> > > 
> > > Signed-off-by: Pavel Herrmann 
> > > ---
> > 
> > [...]
> > 
> > > +void ide_input_swap_data(int dev, ulong *sect_buf, int words)
> > > + __attribute__ ((weak, alias("__ide_input_swap_data")));
> > 
> > #include 
> > 
> > __weak void ide_input_swap_data(int dev, ulong *sect_buf, int words)
> > {
> > 
> >... body ...
> > 
> > }
> > 
> > Works just fine ;-)
> > 
> > [...]
> > 
> > > +/*
> > > + * I/O function overrides
> > > + */
> > > +void ide_input_swap_data(int dev, ulong *sect_buf, int words);
> > > +void ide_input_data(int dev, ulong *sect_buf, int words);
> > > +void ide_output_data(int dev, const ulong *sect_buf, int words);
> > > +void ide_input_data_shorts(int dev, ushort *sect_buf, int words);
> > > +void ide_output_data_shorts(int dev, ushort *sect_buf, int words);
> > 
> > Shorts ... you mean like pants ? :-p
> > 
> > I'd say it's supposed to be "short", like u16 ;-)
> 
> the code says "shorts", as in "multiple of u16", rather than "pants".

Hm, ide_input_data_u16 is good, no ?

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

[U-Boot] [PATCH v2 08/10] split AU1X00 specific code from cmd_ide.c

[Pavel Herrmann]

move special case of ide_swap_read() for AU1X00 SoC into SoC-specific directory.

Signed-off-by: Pavel Herrmann 
---
Changes for v2:
 rebase on top of next
 include missing  to fix compilation

 arch/mips/cpu/mips32/au1x00/Makefile |  2 +-
 arch/mips/cpu/mips32/au1x00/au1x00_ide.c | 32 
 common/cmd_ide.c |  5 ++---
 3 files changed, 35 insertions(+), 4 deletions(-)
 create mode 100644 arch/mips/cpu/mips32/au1x00/au1x00_ide.c

diff --git a/arch/mips/cpu/mips32/au1x00/Makefile 
b/arch/mips/cpu/mips32/au1x00/Makefile
index dc58475..b9f895d 100644
--- a/arch/mips/cpu/mips32/au1x00/Makefile
+++ b/arch/mips/cpu/mips32/au1x00/Makefile
@@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(SOC).o
 
-COBJS  = au1x00_eth.o au1x00_serial.o au1x00_usb_ohci.o
+COBJS  = au1x00_eth.o au1x00_serial.o au1x00_usb_ohci.o au1x00_ide.o
 
 SRCS   := $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS))
diff --git a/arch/mips/cpu/mips32/au1x00/au1x00_ide.c 
b/arch/mips/cpu/mips32/au1x00/au1x00_ide.c
new file mode 100644
index 000..932cdfb
--- /dev/null
+++ b/arch/mips/cpu/mips32/au1x00/au1x00_ide.c
@@ -0,0 +1,32 @@
+/*
+ * (C) Copyright 2000-2011
+ * 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
+ *
+ */
+
+#include 
+#include 
+
+/* AU1X00 swaps data in big-endian mode, enforce little-endian function */
+void ide_input_swap_data(int dev, ulong *sect_buf, int words)
+{
+   ide_input_data(dev, sect_buf, words);
+}
diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index 7eb19cf..5b46e3c 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -503,8 +503,7 @@ void ide_output_data(int dev, const ulong *sect_buf, int 
words)
__attribute__ ((weak, alias("__ide_output_data")));
 
 /* We only need to swap data if we are running on a big endian cpu. */
-/* But Au1x00 cpu:s already swaps data in big endian mode! */
-#if defined(__LITTLE_ENDIAN) || defined(CONFIG_SOC_AU1X00)
+#if defined(__LITTLE_ENDIAN)
 void __ide_input_swap_data(int dev, ulong *sect_buf, int words)
 {
ide_input_data(dev, sect_buf, words);
@@ -532,7 +531,7 @@ void __ide_input_swap_data(int dev, ulong *sect_buf, int 
words)
 #endif /* !MIPS */
}
 }
-#endif /* __LITTLE_ENDIAN || CONFIG_AU1X00 */
+#endif /* __LITTLE_ENDIAN */
 
 
 #if defined(CONFIG_IDE_SWAP_IO)
-- 
1.7.12

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

Re: [U-Boot] [PATCH] arm: trats: Power down core 1

[Albert ARIBAUD]

Hi Piotr,

On Tue, 09 Oct 2012 08:45:42 +0200, Piotr Wilczek
 wrote:

> This patch turns power down for unused core 1
> 
> Signed-off-by: Piotr Wilczek 
> Signed-off-by: Kyungmin Park 
> CC: Minkyu Kang 
> ---
>  board/samsung/trats/trats.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/board/samsung/trats/trats.c b/board/samsung/trats/trats.c
> index 57400ce..d5c681c 100644
> --- a/board/samsung/trats/trats.c
> +++ b/board/samsung/trats/trats.c
> @@ -321,6 +321,10 @@ static void board_power_init(void)
>   writel(0, (unsigned int)&pwr->lcd1_configuration);
>   writel(0, (unsigned int)&pwr->gps_configuration);
>   writel(0, (unsigned int)&pwr->gps_alive_configuration);
> +
> + /* It is necessary to power down core 1 */
> + /* to successfully boot CPU1 in kernel */
> + writel(0, (unsigned int)&pwr->arm_core1_configuration);
>  }
>  
>  static void board_uart_init(void)

Cc:ing trats maintainer.

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

[U-Boot] [PATCH v2 07/10] move CPC45 ide_led to the same file as other IDE hooks

[Pavel Herrmann]

Keep all IDE-related hooks and overrides in a single file, to avoid confusion

Signed-off-by: Pavel Herrmann 
---
Changes for v2:
 style fixes

 board/cpc45/cpc45.c | 15 ---
 board/cpc45/ide.c   | 15 +++
 2 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/board/cpc45/cpc45.c b/board/cpc45/cpc45.c
index 1178822..2200806 100644
--- a/board/cpc45/cpc45.c
+++ b/board/cpc45/cpc45.c
@@ -260,21 +260,6 @@ int pcmcia_init(void)
 
 #endif
 
-# ifdef CONFIG_IDE_LED
-void ide_led (uchar led, uchar status)
-{
-   u_char  val;
-   /* We have one PCMCIA slot and use LED H4 for the IDE Interface */
-   val = readb(BCSR_BASE + 0x04);
-   if (status) {   /* led on */
-   val |= B_CTRL_LED0;
-   } else {
-   val &= ~B_CTRL_LED0;
-   }
-   writeb(val, BCSR_BASE + 0x04);
-}
-# endif
-
 int board_eth_init(bd_t *bis)
 {
return pci_eth_init(bis);
diff --git a/board/cpc45/ide.c b/board/cpc45/ide.c
index 7b7237b..03be59f 100644
--- a/board/cpc45/ide.c
+++ b/board/cpc45/ide.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define EIEIO  __asm__ volatile ("eieio")
 #define SYNC   __asm__ volatile ("sync")
@@ -128,3 +129,17 @@ void ide_output_data_shorts(int dev, ushort *sect_buf, int 
shorts)
*pbuf_odd = *dbuf++;
}
 }
+
+void ide_led(uchar led, uchar status)
+{
+   u_char  val;
+   /* We have one PCMCIA slot and use LED H4 for the IDE Interface */
+   val = readb(BCSR_BASE + 0x04);
+   if (status) /* led on */
+   val |= B_CTRL_LED0;
+   else
+   val &= ~B_CTRL_LED0;
+
+   writeb(val, BCSR_BASE + 0x04);
+}
+
-- 
1.7.12

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

[U-Boot] [PATCH v2 04/10] change all versions of input_data() and output_data() to global weak aliases

[Pavel Herrmann]

This changes input_data() and friends from static function to global symbols
under weak alias, to enable board specific overrides (and therefore get rid of
board-specific code in cmd_ide.c)
Also declare ide_bus_offset in the header file, so other files can use
ATA_CURR_BASE as well.

Signed-off-by: Pavel Herrmann 
---
Changes for v2:
 rebase on top of next
 use "shorts" as a count parameter for the short-aligned I/O calls

 board/esd/cpci750/ide.c   |  1 -
 board/linkstation/ide.c   |  1 -
 board/pcs440ep/pcs440ep.c |  1 -
 common/cmd_ide.c  | 57 ++-
 include/ide.h | 11 +
 5 files changed, 48 insertions(+), 23 deletions(-)

diff --git a/board/esd/cpci750/ide.c b/board/esd/cpci750/ide.c
index aa001df..4ef10e7 100644
--- a/board/esd/cpci750/ide.c
+++ b/board/esd/cpci750/ide.c
@@ -30,7 +30,6 @@
 #include 
 #include 
 
-extern ulong ide_bus_offset[CONFIG_SYS_IDE_MAXBUS];
 int cpci_hd_type;
 
 int ata_device(int dev)
diff --git a/board/linkstation/ide.c b/board/linkstation/ide.c
index f3e3fce..541c958 100644
--- a/board/linkstation/ide.c
+++ b/board/linkstation/ide.c
@@ -37,7 +37,6 @@
 #define IT8212_PCI_IdeBusSkewCONTROL   0x4c
 #define IT8212_PCI_IdeDrivingCURRENT   0x42
 
-extern ulong ide_bus_offset[CONFIG_SYS_IDE_MAXBUS];
 extern struct pci_controller hose;
 
 int ide_preinit (void)
diff --git a/board/pcs440ep/pcs440ep.c b/board/pcs440ep/pcs440ep.c
index 746a54c..52da053 100644
--- a/board/pcs440ep/pcs440ep.c
+++ b/board/pcs440ep/pcs440ep.c
@@ -672,7 +672,6 @@ U_BOOT_CMD(
  * ( bus per_addr 20 -30 is connectsd on CF bus A10-A0)
  * These values are shifted
  */
-extern ulong *ide_bus_offset;
 void inline ide_outb(int dev, int port, unsigned char val)
 {
debug ("ide_outb (dev= %d, port= 0x%x, val= 0x%02x) : @ 0x%08lx\n",
diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index 6b4813e..b9feb80 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -109,8 +109,6 @@ static uchar ide_wait  (int dev, ulong t);
 
 #define IDE_SPIN_UP_TIME_OUT 5000 /* 5 sec spin-up timeout */
 
-static void input_data(int dev, ulong *sect_buf, int words);
-static void output_data(int dev, const ulong *sect_buf, int words);
 static void ident_cpy (unsigned char *dest, unsigned char *src, unsigned int 
len);
 
 #ifndef CONFIG_SYS_ATA_PORT_ADDR
@@ -483,12 +481,24 @@ block_dev_desc_t *ide_get_dev(int dev)
 
 /* - */
 
+void ide_input_swap_data(int dev, ulong *sect_buf, int words)
+   __attribute__ ((weak, alias("__ide_input_swap_data")));
+
+void ide_input_data(int dev, ulong *sect_buf, int words)
+   __attribute__ ((weak, alias("__ide_input_data")));
+
+void ide_output_data(int dev, const ulong *sect_buf, int words)
+   __attribute__ ((weak, alias("__ide_output_data")));
+
 /* We only need to swap data if we are running on a big endian cpu. */
 /* But Au1x00 cpu:s already swaps data in big endian mode! */
 #if defined(__LITTLE_ENDIAN) || defined(CONFIG_SOC_AU1X00)
-#define input_swap_data(x,y,z) input_data(x,y,z)
+void __ide_input_swap_data(int dev, ulong *sect_buf, int words)
+{
+   ide_input_data(dev, sect_buf, words);
+}
 #else
-static void input_swap_data(int dev, ulong *sect_buf, int words)
+void __ide_input_swap_data(int dev, ulong *sect_buf, int words)
 {
 #if defined(CONFIG_CPC45)
uchar i;
@@ -531,7 +541,7 @@ static void input_swap_data(int dev, ulong *sect_buf, int 
words)
 
 
 #if defined(CONFIG_IDE_SWAP_IO)
-static void output_data(int dev, const ulong *sect_buf, int words)
+void __ide_output_data(int dev, const ulong *sect_buf, int words)
 {
 #if defined(CONFIG_CPC45)
uchar *dbuf;
@@ -574,7 +584,7 @@ static void output_data(int dev, const ulong *sect_buf, int 
words)
 #endif
 }
 #else  /* ! CONFIG_IDE_SWAP_IO */
-static void output_data(int dev, const ulong *sect_buf, int words)
+void __ide_output_data(int dev, const ulong *sect_buf, int words)
 {
 #if defined(CONFIG_IDE_AHB)
ide_write_data(dev, sect_buf, words);
@@ -585,7 +595,7 @@ static void output_data(int dev, const ulong *sect_buf, int 
words)
 #endif /* CONFIG_IDE_SWAP_IO */
 
 #if defined(CONFIG_IDE_SWAP_IO)
-static void input_data(int dev, ulong *sect_buf, int words)
+void __ide_input_data(int dev, ulong *sect_buf, int words)
 {
 #if defined(CONFIG_CPC45)
uchar *dbuf;
@@ -634,7 +644,7 @@ static void input_data(int dev, ulong *sect_buf, int words)
 #endif
 }
 #else  /* ! CONFIG_IDE_SWAP_IO */
-static void input_data(int dev, ulong *sect_buf, int words)
+void __ide_input_data(int dev, ulong *sect_buf, int words)
 {
 #if defined(CONFIG_IDE_AHB)
ide_read_data(dev, sect_buf, words);
@@ -744,7 +754,7 @@ static void ide_ident(block_dev_desc_t *dev_desc)
return;
 #endif
 
-   input_swap_data(device, (ulong *)&iop, ATA_SECTORWORDS);
+   ide_input_swap_data(device, (ulong *)&iop, ATA_SECTORWORDS);
 
ident_cpy((unsigned char *) dev_desc->

[U-Boot] [PATCH v2 02/10] split mpc8xx hooks from cmd_ide.c

[Pavel Herrmann]

move most of mpc8xx hooks from cmd_ide.c into ide_preinit() and newly created
ide_init_postreset() (invoked after calling ide_reset after ide_preinit),
some cleanup to make checkpatch happy, enable IDE init hooks in configs of
affected boards.
confusingly, these hooks are used by more than just mpc8xx-based boards, and
therefore are placed in arch/ppc/lib/

note: checkpatch still emits warnings about using volatile

Signed-off-by: Pavel Herrmann 
---
Changes for v2:
 style fixes

 arch/powerpc/lib/Makefile|   1 +
 arch/powerpc/lib/ide.c   | 201 +++
 arch/powerpc/lib/ide.h   |  31 +++
 common/cmd_ide.c | 190 ++--
 include/configs/CPC45.h  |   1 +
 include/configs/ICU862.h |   1 +
 include/configs/IVML24.h |   2 +
 include/configs/IVMS8.h  |   2 +
 include/configs/KUP4K.h  |   1 +
 include/configs/KUP4X.h  |   1 +
 include/configs/MBX.h|   1 +
 include/configs/NETTA.h  |   1 +
 include/configs/NSCU.h   |   1 +
 include/configs/R360MPI.h|   1 +
 include/configs/RPXClassic.h |   1 +
 include/configs/RPXlite.h|   1 +
 include/configs/RPXlite_DW.h |   1 +
 include/configs/RRvision.h   |   1 +
 include/configs/SPD823TS.h   |   2 +
 include/configs/TK885D.h |   1 +
 include/configs/TQM823L.h|   1 +
 include/configs/TQM823M.h|   1 +
 include/configs/TQM850L.h|   1 +
 include/configs/TQM850M.h|   1 +
 include/configs/TQM855L.h|   1 +
 include/configs/TQM855M.h|   1 +
 include/configs/TQM860L.h|   1 +
 include/configs/TQM860M.h|   1 +
 include/configs/TQM862L.h|   1 +
 include/configs/TQM862M.h|   1 +
 include/configs/TQM866M.h|   1 +
 include/configs/TQM885D.h|   1 +
 include/configs/atc.h|   1 +
 include/configs/c2mon.h  |   1 +
 include/configs/lwmon.h  |   1 +
 include/configs/quantum.h|   1 +
 include/configs/svm_sc8xx.h  |   2 +
 include/configs/uc100.h  |   1 +
 include/configs/virtlab2.h   |   1 +
 include/ide.h|   8 ++
 40 files changed, 287 insertions(+), 183 deletions(-)
 create mode 100644 arch/powerpc/lib/ide.c
 create mode 100644 arch/powerpc/lib/ide.h

diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 965f9ea..808021c 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -50,6 +50,7 @@ COBJS-y   += cache.o
 COBJS-y+= extable.o
 COBJS-y+= interrupts.o
 COBJS-$(CONFIG_CMD_KGDB) += kgdb.o
+COBJS-${CONFIG_CMD_IDE} += ide.o
 COBJS-y+= time.o
 
 # Workaround for local bus unaligned access problems
diff --git a/arch/powerpc/lib/ide.c b/arch/powerpc/lib/ide.c
new file mode 100644
index 000..139a94a
--- /dev/null
+++ b/arch/powerpc/lib/ide.c
@@ -0,0 +1,201 @@
+/*
+ * (C) Copyright 2000-2011
+ * 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
+ *
+ */
+
+/* Code taken from cmd_ide.c */
+#include 
+#include 
+#include "ide.h"
+
+#ifdef CONFIG_IDE_8xx_DIRECT
+#include 
+#include 
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Timings for IDE Interface
+ *
+ * SETUP / LENGTH / HOLD - cycles valid for 50 MHz clk
+ * 70 165  30 PIO-Mode 0, [ns]
+ *  4   9   2 [Cycles]
+ * 50 125  20 PIO-Mode 1, [ns]
+ *  3   7   2 [Cycles]
+ * 30 100  15 PIO-Mode 2, [ns]
+ *  2   6   1 [Cycles]
+ * 30  80  10 PIO-Mode 3, [ns]
+ *  2   5   1 [Cycles]
+ * 25  70  10 PIO-Mode 4, [ns]
+ *  2   4   1 [Cycles]
+ */
+
+static const pio_config_t pio_config_ns[IDE_MAX_PIO_MODE+1] = {
+/*  Setup  Length  Hold  */
+   { 70,   165,30 },   /* PIO-Mode 0, [ns] */
+   { 50,   125,20 },   /* PIO-Mode 1, [ns] */
+   { 30,   101,15 },   /* PIO-Mode 2, [ns] */
+   { 30,80,10 },   /* PIO-Mode 3, [ns] */
+   { 25,70,10 },   /* PIO-Mode 4, [ns] */
+};
+
+static pio_config_t pio_config_clk[IDE_MAX_PIO_MODE+1];
+
+#ifndef CONFIG_SYS_PIO_MODE
+#define CONFIG_SYS_PIO_MO

Re: [U-Boot] ELDK4.2 build failures for highbank, omap4_panda and omap4_sdp4430

[Albert ARIBAUD]

Hi R,

On Tue, 9 Oct 2012 11:16:06 +0530, R Sricharan 
wrote:

> On Monday 08 October 2012 10:05 PM, Tom Rini wrote:
> > On Sat, Oct 6, 2012 at 4:34 AM, Albert ARIBAUD  
> > wrote:
> >> Hi,
> >>
> >> On Sat, 6 Oct 2012 13:02:49 +0200, Albert ARIBAUD
> >>  wrote:
> >>
> >>> Hi All,
> >>>
> >>> With Anatolij's fix in, ELDK4.2 still fails to build three boards:
> >>> highbank, omap4_panda and omap4_sdp4430 (maintainers CCed).
> >>>
> >>> Build logs are weird for the two omap boards:
> >>>
> >>> Configuring for omap4_panda board...
> >>> arm-linux-gnueabi-size: './u-boot': No such file
> >>> make: *** [checkthumb] Erreur 1
> >>> make: INTERNAL: Exiting with 10 jobserver tokens available; should be 9!
> >>> Configuring for omap4_sdp4430 board...
> >>> arm-linux-gnueabi-size: './u-boot': No such file
> >>> make: *** [checkthumb] Erreur 1
> >>> make: INTERNAL: Exiting with 10 jobserver tokens available; should be 9!
> >>>
> >>> For highbank, it is a matter of emitting instructions invalid for
> >>> armv5.
> >>>
> >>> Do these boards need to support building with older toolchains?
> >>>
> >>> Amicalement,
> >>
> >> Seems like sricha...@ti.com does not exist any more. That makes
> >>
> >>  omap4_panda ARM ARMV7 (OMAP4xx SoC)
> >>  omap4_sdp4430   ARM ARMV7 (OMAP4xx SoC)
> >>  omap5_evm   ARM ARMV7 (OMAP5xx Soc)
> >>
> >> Up for bids for a new maintainer.
> >
> > But that's not quite his email address :)  Cc'ing him now but as I said 
> > later in the thread, it's a feature that it doesn't build for eldk4.2

Apologies for messing Sricharan's e-mail.

>   Thats right. They are currently build with THUMB mode.

Thanks.

> Regards,
>   Sricharan

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

Re: [U-Boot] [PULL] : Please pull u-boot-imx/next

[Albert ARIBAUD]

Hi Stefano,

On Mon, 08 Oct 2012 11:56:23 +0200, Stefano Babic 
wrote:

> Hi Albert,
> 
> these changes are in my -next branch, so please pull them into arm/next.
> 
> The following changes since commit 4668a086bb0a769b741e3a4ffab85f1c41c7cdb8:
> 
>   sandbox: Add asm/errno.h (2012-09-29 10:00:29 -0700)
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-imx.git next
> 
> for you to fetch changes up to 635e9c5c1cd51f6f2cf9f62f01cb6aa436b119a6:
> 
>   configs: mx6qsabre_common.h: Use default clock definitions (2012-10-03
> 17:19:39 +0200)
> 
> 
> Benoît Thébaudeau (28):
>   mx51evk: Add CONFIG_REVISION_TAG
>   KARO TX25: Fix NAND Flash R/W cycle times
>   mx5/6: Define default SoC input clock frequencies
>   mx5 clocks: Cleanup
>   mx5: Use explicit clock gate names
>   mx5: Fix clock gate values
>   mx51: Fix USB PHY clocks
>   mx5 clocks: Add and use CCSR definitions
>   mx5 clocks: Fix get_lp_apm()
>   mx5 clocks: Fix get_periph_clk()
>   mx5 clocks: Fix get_ipg_per_clk()
>   mx5 clocks: Fix get_uart_clk()
>   mx5 clocks: Simplify imx_get_cspiclk()
>   mx5 clocks: Fix MXC_FEC_CLK
>   mx51: Fix I2C clock ID check
>   mx5/6 clocks: Fix SDHC clocks
>   mx25: Fix decode_pll
>   mx25: Clean up clock calculations
>   mx25: Define more standard clocks
>   mx25 clocks: Fix MXC_FEC_CLK
>   mx25: Clean up clocks API
>   mx25: Define cpu_eth_init() only if needed
>   mx25: Fix eSDHC support
>   mx5: Optimize lowlevel_init code size
>   mx31: Add more CCM access macros
>   mx35: Define MAX and AIPS registers
>   mx31: Fix PDR0_CSI_PODF
>   mx25: Clean up lowlevel_init
> 
> Eric Benard (1):
>   mx25: add CPU revision 1.2
> 
> Eric Nelson (9):
>   i.MX: mxc_ipuv3_fb: add ipuv3_fb_shutdown() routine to stop IPU
> frame buffer
>   i.MX: shut down video before launch of O/S
>   i.MX6: provide functional names for CCM_CCGR0-CCGR6 bit fields
>   i.MX6: change register name for CCM_CHSCCDR to match ref. manual
>   i.MX6: define bitfields for CHSCCDR register
>   i.MX6: define IOMUX_GPR3 register bitfields
>   i.MX6: Add ANATOP_PFD_480 bitfield constants
>   i.MX6: define struct iomuxc and IOMUX_GPR2 register bitfields
>   i.MX6: get rid of redundant struct src_regs (dupe of struct src)
> 
> Fabio Estevam (9):
>   mx28evk: Remove fecmxc_mii_postcall()
>   mx6q: Factor out common DDR3 init code
>   mx6: Add basic support for mx6qsabresd board.
>   mx6qsabresd: Add Ethernet support
>   mx6qsabresd: Add 8-bit USDHC support
>   configs: mx6: Add a common config file
>   mx6q: Add basic support for mx6qsabreauto
>   mx6qsabreauto: Add Ethernet support
>   configs: mx6qsabre_common.h: Use default clock definitions
> 
> Matthias Weisser (1):
>   imx: Use MXC_I2C_CLK in imx i2c driver
> 
> Otavio Salvador (2):
>   mx28evk: Add missing 'setexpr' command
>   mx6qsabreauto: Use ttymxc3 as console
> 
>  MAINTAINERS|2 +
>  arch/arm/cpu/arm1136/mx31/generic.c|1 +
>  arch/arm/cpu/arm1136/mx35/asm-offsets.c|   33 +-
>  arch/arm/cpu/arm1136/mx35/generic.c|1 +
>  arch/arm/cpu/arm926ejs/mx25/generic.c  |   66 +--
>  arch/arm/cpu/armv7/mx5/clock.c |  454
> +++-
>  arch/arm/cpu/armv7/mx5/lowlevel_init.S |  112 ++---
>  arch/arm/cpu/armv7/mx6/clock.c |   31 +-
>  arch/arm/cpu/armv7/mx6/soc.c   |2 +-
>  arch/arm/imx-common/cpu.c  |9 +
>  arch/arm/imx-common/speed.c|   18 +-
>  arch/arm/imx-common/timer.c|   12 +-
>  arch/arm/include/asm/arch-mx25/clock.h |   14 +-
>  arch/arm/include/asm/arch-mx25/imx-regs.h  |1 +
>  arch/arm/include/asm/arch-mx25/macro.h |   87 +++-
>  arch/arm/include/asm/arch-mx31/clock.h |1 +
>  arch/arm/include/asm/arch-mx31/imx-regs.h  |   16 +-
>  arch/arm/include/asm/arch-mx35/clock.h |1 +
>  arch/arm/include/asm/arch-mx35/imx-regs.h  |   52 +++
>  arch/arm/include/asm/arch-mx5/clock.h  |   22 +-
>  arch/arm/include/asm/arch-mx5/crm_regs.h   |  419
> +-
>  arch/arm/include/asm/arch-mx5/imx-regs.h   |2 +
>  arch/arm/include/asm/arch-mx6/clock.h  |   15 +
>  arch/arm/include/asm/arch-mx6/crm_regs.h   |  364 
>  arch/arm/include/asm/arch-mx6/imx-regs.h   |  166 ++-
>  .../imximage.cfg => imx/ddr/mx6q_4x_mt41j128.cfg}  |0
>  board/freescale/mx28evk/mx28evk.c  |   25 --
>  board/freescale/mx31ads/lowlevel_init.S|4 +-
>  board/freescale/mx51evk/mx51evk.c 

Re: [U-Boot] [PATCH] fs: fat: Fix mkcksum() function parameters

[Tom Rini]

On Sun, Sep 30, 2012 at 02:49:09AM +0200, Marek Vasut wrote:

> The mkcksum() function now takes one parameter, the pointer to
> 11-byte wide character array, which it then operates on.
> 
> Currently, the function is wrongly passed (dir_entry)->name, which
> is only 8-byte wide character array. Though by further inspecting
> the dir_entry structure, it can be noticed that the name[8] entry
> is immediatelly followed by ext[3] entry. Thus, name[8] and ext[3]
> in the dir_entry structure actually work as this 11-byte wide array
> since they're placed right next to each other by current compiler
> behavior.
> 
> Depending on this is obviously wrong, thus fix this by correctly
> passing both (dir_entry)->name and (dir_entry)->ext to the mkcksum()
> function and adjust the function appropriately.
> 
> Signed-off-by: Marek Vasut 
> Cc: Tom Rini 

Building on current next:
Configuring for trats board...
fat_write.c:338:29: error: request for member 'name' in something not a
structure or union
fat_write.c:338:45: error: request for member 'ext' in something not a
structure or union

Please fix and submit a v2, thanks.

-- 
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 v3] add nand spl boot for qi_lb60 board

[Tom Rini]

On Tue, Oct 09, 2012 at 04:28:05PM +0800, xian...@openmobilefree.net wrote:

> From: Xiangfu Liu 
> 
>  * 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
>   
>   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
> 
> 
>  * Add software usbboot mode
>Downloads user program from the USB port to internal
>SRAM and branches to the internal SRAM to execute the program.
>(JZ4740 CPU have a internal ROM have such kind of code, that make 
> JZ4740 can boot from USB)
> ---
> v3:
>   * add simpile string.c to mips/lib
>   * some cleanup on jz4740.c
>   * move to new spl/ structure 
>   * support software usbboot mode

I'm happy you've moved to the new SPL infrastructure.  A few comments:

In general, please check for checkpatch.pl issues, I spotted a few.
Also, don't use // comments in asm, everything else in MIPS uses '#' or
'/* ... */'.  Please use 'puts' rather than 'serial_puts' directly.

[snip]
> diff --git a/arch/mips/lib/string.c b/arch/mips/lib/string.c
> new file mode 100644
> index 000..d59f44a
> --- /dev/null
> +++ b/arch/mips/lib/string.c
> @@ -0,0 +1,32 @@

Can you try just enabling CONFIG_SPL_LIBGENERIC_SUPPORT ?  You should
have the unused functions garbage collected automatically.

> diff --git a/drivers/mtd/nand/jz4740_nand.c b/drivers/mtd/nand/jz4740_nand.c
> index 3ec34f3..4ab2229 100644
> --- a/drivers/mtd/nand/jz4740_nand.c
> +++ b/drivers/mtd/nand/jz4740_nand.c
> @@ -15,6 +15,9 @@
>  #include 
>  #include 
>  
> +#ifdef CONFIG_SPL_BUILD
> +#define printf(arg...) do {} while (0)
> +#endif

In this case you should just switch to puts.

And a non-blocking question, have you looked at the CONFIG_SPL_FRAMEWORK
code in common/spl/ now?

-- 
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] sram overflowed

[Tom Rini]

On Mon, Oct 08, 2012 at 11:23:20PM -0700, Grant wrote:
> >> >> git clone git://arago-project.org/git/projects/u-boot-am33x.git
> >> >
> >> > This is definitely NOT what you want to use when somebody mentions
> >> > "latest version".  This term always refers to top of tree in mainline
> >> > U-Boot, see http://git.denx.de/?p=u-boot.git;a=summary  resp.
> >> > git://git.denx.de/u-boot.git
> >>
> >> Thank you for that.  There is some outdated info here:
> >>
> >> "Upstream U-Boot(the one you can download from www.denx.de)'s SPL
> >> support doesn't include the AM33XX chip, which is the one used in the
> >> Beaglebone. Progress is being done as of December 2011 to get it
> >> included. For this reason, we'll use a patched U-Boot provided from
> >> TI."
> >
> > Well, December 2011 is a long time ago.  As of v2012.10-rc1 am335x
> > platforms are rather well supported in mainline, especially the
> > beaglebone (which doesn't have NAND, the biggest gap between mainline
> > and the u-boot-am33x.git tree, at least as of Dec 2011).  Using mainline
> > and the toolchain you likely have from TI, or from Linaro (if you use
> > v2012.10-rc3) or from ELDK 5.2 will produce functional binaries for your
> > platform.
> 
> Thank you, I was able to boot the Beaglebone with mainline u-boot by
> moving uImage to / and adding this to uEnv.txt:
> 
> bootfile="/uImage"
> 
> As an aside, I noticed omap3_beagle in board.cfg, so I tried 'make
> omap3_beagle_config && make' but the resultant MLO and u-boot.img did
> not work at all.  am335x_evm_config works fine, but I'm curious what
> omap3_beagle_config is for if anyone knows.

omap3_beagle is for the beagleboard and beagleboard xM boards.
am335x_evm as you noticed is for the beaglebone (And am335x GP EVM and
am335x EVM SK).

-- 
Tom


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

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

[Albert ARIBAUD]

Hi Tom,

The following changes since commit 661c21dd46e857b74682b0610d83cfea7f3ac3c2:

  usb.h: Add udc_disconnect prototype to usb.h (2012-10-08 18:01:17 -0700)

are available in the git repository at:

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

for you to fetch changes up to 0d6b8f29a3c59306d6cd8f2baa92897f56b06695:

  configs: mx6qsabre_common.h: Use default clock definitions (2012-10-09 
16:52:18 +0200)


Benoît Thébaudeau (26):
  mx5/6: Define default SoC input clock frequencies
  mx5 clocks: Cleanup
  mx5: Use explicit clock gate names
  mx5: Fix clock gate values
  mx51: Fix USB PHY clocks
  mx5 clocks: Add and use CCSR definitions
  mx5 clocks: Fix get_lp_apm()
  mx5 clocks: Fix get_periph_clk()
  mx5 clocks: Fix get_ipg_per_clk()
  mx5 clocks: Fix get_uart_clk()
  mx5 clocks: Simplify imx_get_cspiclk()
  mx5 clocks: Fix MXC_FEC_CLK
  mx51: Fix I2C clock ID check
  mx5/6 clocks: Fix SDHC clocks
  mx25: Fix decode_pll
  mx25: Clean up clock calculations
  mx25: Define more standard clocks
  mx25 clocks: Fix MXC_FEC_CLK
  mx25: Clean up clocks API
  mx25: Define cpu_eth_init() only if needed
  mx25: Fix eSDHC support
  mx5: Optimize lowlevel_init code size
  mx31: Add more CCM access macros
  mx35: Define MAX and AIPS registers
  mx31: Fix PDR0_CSI_PODF
  mx25: Clean up lowlevel_init

Eric Benard (1):
  mx25: add CPU revision 1.2

Eric Nelson (7):
  i.MX6: provide functional names for CCM_CCGR0-CCGR6 bit fields
  i.MX6: change register name for CCM_CHSCCDR to match ref. manual
  i.MX6: define bitfields for CHSCCDR register
  i.MX6: define IOMUX_GPR3 register bitfields
  i.MX6: Add ANATOP_PFD_480 bitfield constants
  i.MX6: define struct iomuxc and IOMUX_GPR2 register bitfields
  i.MX6: get rid of redundant struct src_regs (dupe of struct src)

Fabio Estevam (8):
  mx6q: Factor out common DDR3 init code
  mx6: Add basic support for mx6qsabresd board.
  mx6qsabresd: Add Ethernet support
  mx6qsabresd: Add 8-bit USDHC support
  configs: mx6: Add a common config file
  mx6q: Add basic support for mx6qsabreauto
  mx6qsabreauto: Add Ethernet support
  configs: mx6qsabre_common.h: Use default clock definitions

Lucas Stach (6):
  tegra20: complete periph_id enum
  tegra20: add clock_set_pllout function
  tegra20: rework UART GPIO handling
  tegra: add funcmux entry for NAND attached to KBC
  tegra: clean up board include hell
  tegra: nand: add board pinmux

Lukasz Dalek (2):
  h2200: Add support for iPAQ h2200 palmtop
  pxa: Add code to examine cpu model and revision

Matthias Weisser (1):
  imx: Use MXC_I2C_CLK in imx i2c driver

Otavio Salvador (1):
  mx6qsabreauto: Use ttymxc3 as console

Stephen Warren (1):
  tegra: enable CONFIG_CMD_PART

Thierry Reding (2):
  tegra: Update Avionic Design vendor prefix
  tegra: Rename Medcom to Medcom-Wide

Tom Warren (2):
  Tegra20: Move some code files to common directories for upcoming Tegra30 
patches.
  Tegra20: Move some include files to arch-tegra for sharing with Tegra30

 MAINTAINERS|4 +-
 Makefile   |2 +
 arch/arm/cpu/arm1136/mx31/generic.c|1 +
 arch/arm/cpu/arm1136/mx35/asm-offsets.c|   33 +-
 arch/arm/cpu/arm1136/mx35/generic.c|1 +
 arch/arm/cpu/arm720t/tegra-common/Makefile |   47 ++
 .../cpu/arm720t/{tegra20 => tegra-common}/cpu.h|0
 .../cpu/arm720t/{tegra20 => tegra-common}/spl.c|   18 +-
 arch/arm/cpu/arm720t/tegra20/Makefile  |1 -
 arch/arm/cpu/arm720t/tegra20/cpu.c |   12 +-
 arch/arm/cpu/arm926ejs/mx25/generic.c  |   66 +--
 arch/arm/cpu/armv7/mx5/clock.c |  454 +++-
 arch/arm/cpu/armv7/mx5/lowlevel_init.S |  112 ++---
 arch/arm/cpu/armv7/mx6/clock.c |   31 +-
 arch/arm/cpu/armv7/mx6/soc.c   |2 +-
 arch/arm/cpu/armv7/tegra-common/Makefile   |   48 +++
 .../armv7/{tegra20 => tegra-common}/cmd_enterrcm.c |4 +-
 arch/arm/cpu/armv7/tegra20/Makefile|1 -
 arch/arm/cpu/armv7/tegra20/usb.c   |8 +-
 arch/arm/cpu/pxa/cpuinfo.c |   11 +-
 arch/arm/cpu/tegra-common/Makefile |   48 +++
 .../{tegra20-common/ap20.c => tegra-common/ap.c}   |   12 +-
 .../cpu/{tegra20-common => tegra-common}/board.c   |9 +-
 .../lowlevel_init.S|0
 .../{tegra20-common => tegra-common}/sys_info.c|0
 .../cpu/{tegra20-common => tegra-common}/timer.c   |4 +-
 arch/arm/cpu/tegra20-common/Makefile   |3 +-
 arch/arm/cpu/tegra20-common/clock.c|   4

Re: [U-Boot] [PULL] u-boot-usb/next

[Tom Rini]

On Sun, Oct 07, 2012 at 08:49:00PM +0200, Marek Vasut wrote:

> NOTE: I get a few more size issues with ELDK 4.2 on IXP (that big-endian ARM) 
> after this patchset is applied. I wonder if we shouldn't just throw these 
> away, 
> since they're dead code mostly.
> 
> The following changes since commit c7ee66a8222660b565e9240775efa4c82cb348c2:
> 
>   Merge branch 'next' of git://www.denx.de/git/u-boot-ppc4xx into next 
> (2012-10-02 10:16:40 -0700)
> 
> are available in the git repository at:
> 
> 
>   git://git.denx.de/u-boot-usb.git next
> 
> for you to fetch changes up to f0ede0e8305bc3c959862446bce40cb028b36293:
> 
>   usb.h: Add udc_disconnect prototype to usb.h (2012-10-07 02:08:48 +0200)
> 
> 
> Lucas Stach (7):
>   usb: lowlevel interface change to support multiple controllers
>   usb: ehci: rework to take advantage of new lowlevel interface
>   usb: add support for multiple usb controllers
>   tegra20: port to new ehci interface
>   usb: ehci: don't print debug output
>   usb: ulpi: add indicator configuration function
>   tegra20: add USB ULPI init code
> 
> Lukasz Dalek (5):
>   usbether: Fixed bug when using with PXA25X chips
>   usbether: Define CONFIG_USB_ETH_{CDC,SUBSET}
>   usbether: Removed DEV_CONFIG_{CDC,SUBSET}
>   pxa25x: Add support for USB ethernet gadget
>   usb.h: Add udc_disconnect prototype to usb.h
> 
>  README|3 +
>  arch/arm/cpu/arm920t/s3c24x0/usb_ohci.c   |4 +-
>  arch/arm/cpu/armv7/tegra20/usb.c  |  168 --
>  arch/arm/include/asm/arch-tegra20/usb.h   |   33 +-
>  arch/arm/include/asm/ehci-omap.h  |   10 +-
>  arch/mips/cpu/mips32/au1x00/au1x00_usb_ohci.c |4 +-
>  arch/powerpc/cpu/mpc5xxx/usb_ohci.c   |4 +-
>  arch/powerpc/cpu/ppc4xx/usb_ohci.c|4 +-
>  arch/sparc/cpu/leon3/usb_uhci.c   |4 +-
>  arch/sparc/lib/bootm.c|2 +-
>  board/htkw/mcx/mcx.c  |6 +-
>  board/mpl/common/usb_uhci.c   |4 +-
>  board/technexion/twister/twister.c|6 +-
>  board/teejet/mt_ventoux/mt_ventoux.c  |6 +-
>  board/ti/beagle/beagle.c  |6 +-
>  board/ti/panda/panda.c|6 +-
>  common/cmd_usb.c  |   16 +-
>  common/usb.c  |  108 ++--
>  common/usb_hub.c  |2 +-
>  common/usb_storage.c  |2 +-
>  drivers/usb/eth/usb_ether.c   |2 +-
>  drivers/usb/gadget/Makefile   |1 +
>  drivers/usb/gadget/ether.c|   69 +--
>  drivers/usb/gadget/pxa25x_udc.c   | 2059 
> ++
>  drivers/usb/gadget/pxa25x_udc.h   |  162 ++
>  drivers/usb/host/ehci-armada100.c |   15 +-
>  drivers/usb/host/ehci-atmel.c |   11 +-
>  drivers/usb/host/ehci-core.h  |   29 --
>  drivers/usb/host/ehci-exynos.c|   15 +-
>  drivers/usb/host/ehci-fsl.c   |   15 +-
>  drivers/usb/host/ehci-hcd.c   |  126 ++---
>  drivers/usb/host/ehci-ixp4xx.c|   15 +-
>  drivers/usb/host/ehci-marvell.c   |   15 +-
>  drivers/usb/host/ehci-mpc512x.c   |   25 +-
>  drivers/usb/host/ehci-mx5.c   |   11 +-
>  drivers/usb/host/ehci-mx6.c   |   11 +-
>  drivers/usb/host/ehci-mxc.c   |   11 +-
>  drivers/usb/host/ehci-mxs.c   |   20 +-
>  drivers/usb/host/ehci-omap.c  |   10 +-
>  drivers/usb/host/ehci-pci.c   |   15 +-
>  drivers/usb/host/ehci-ppc4xx.c|   11 +-
>  drivers/usb/host/ehci-tegra.c |   14 +-
>  drivers/usb/host/ehci-vct.c   |9 +-
>  drivers/usb/host/ehci.h   |4 +-
>  drivers/usb/host/isp116x-hcd.c|4 +-
>  drivers/usb/host/ohci-hcd.c   |4 +-
>  drivers/usb/host/r8a66597-hcd.c   |4 +-
>  drivers/usb/host/sl811-hcd.c  |4 +-
>  drivers/usb/musb/musb_hcd.c   |4 +-
>  drivers/usb/ulpi/ulpi.c   |   32 +-
>  include/usb.h |   21 +-
>  include/usb/mv_udc.h  |2 +-
>  include/usb/ulpi.h|   13 +-
>  53 files changed, 2779 insertions(+), 382 deletions(-)
>  create mode 100644 drivers/usb/gadget/pxa25x_udc.c
>  create mode 100644 drivers/usb/gadget/pxa25x_udc.h
>  delete mode 100644 drivers/usb/host/ehci-core.h

I had to rebase this locally to merge (such is next), and now it's
applied to u-boot/next, thanks!

-- 
T

[U-Boot] I2C clock frequency on P1022/P1013

[BRUNMAYR Peter]

Is it possible that a further differentiation is required for setting the I2C 
clock frequency in arch/powerpc/cpu/mpc85xx/speed.c? For P1022 and P1013 
devices the default ratio CCB/2 is taken. However, on those devices the I2C 
clock frequency is equal to CCB. If I'm not mistaken, P1022 and P1013 should be 
added to the #ifdef branch used for the 8540, 8541, 8560 and 8555.

Thank you,
_

Peter Brunmayr
Hardware Engineer
FREQUENTIS AG
Innovationsstrasse 1, 1100 Vienna, Austria
Web www.frequentis.com




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

Re: [U-Boot] [PATCH 04/10] change all versions of input_data() and output_data() to global weak aliases

[Pavel Herrmann]

On Sunday 07 of October 2012 20:14:23 Marek Vasut wrote:
> Dear Pavel Herrmann,
> 
> > This changes input_data() and friends from static function to global
> > symbols under weak alias, to enable board specific overrides (and
> > therefore get rid of board-specific code in cmd_ide.c)
> > Also declare ide_bus_offset in the header file, so other files can use
> > ATA_CURR_BASE as well.
> > 
> > Signed-off-by: Pavel Herrmann 
> > ---
> 
> [...]
> 
> > +void ide_input_swap_data(int dev, ulong *sect_buf, int words)
> > +   __attribute__ ((weak, alias("__ide_input_swap_data")));
> 
> #include 
> 
> __weak void ide_input_swap_data(int dev, ulong *sect_buf, int words)
> {
>... body ...
> }
> 
> Works just fine ;-)
> 
> [...]
> 
> > +/*
> > + * I/O function overrides
> > + */
> > +void ide_input_swap_data(int dev, ulong *sect_buf, int words);
> > +void ide_input_data(int dev, ulong *sect_buf, int words);
> > +void ide_output_data(int dev, const ulong *sect_buf, int words);
> > +void ide_input_data_shorts(int dev, ushort *sect_buf, int words);
> > +void ide_output_data_shorts(int dev, ushort *sect_buf, int words);
> 
> Shorts ... you mean like pants ? :-p
> 
> I'd say it's supposed to be "short", like u16 ;-)

the code says "shorts", as in "multiple of u16", rather than "pants".

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

Re: [U-Boot] [PATCH 05/10] split CPC45 board-specific IDE functions from cmd_ide.c

[Pavel Herrmann]

On Sunday 07 of October 2012 20:20:08 Marek Vasut wrote:
> Dear Pavel Herrmann,
> 
> > Move input_data() and friends to board/cpc45/ide.c, as overrides for weak
> > aliases in cmd_ide.c
> > 
> > note: checkpatch emits warnings about using volatile
> > 
> > Signed-off-by: Pavel Herrmann 
> > ---
> > 
> >  board/cpc45/Makefile |   2 +-
> >  board/cpc45/ide.c| 130
> > 
> > +++ common/cmd_ide.c |
> > 
> >  91 
> >  3 files changed, 131 insertions(+), 92 deletions(-)
> >  create mode 100644 board/cpc45/ide.c
> > 
> > diff --git a/board/cpc45/Makefile b/board/cpc45/Makefile
> > index 5c6b78f..ac1d174 100644
> > --- a/board/cpc45/Makefile
> > +++ b/board/cpc45/Makefile
> > @@ -25,7 +25,7 @@ include $(TOPDIR)/config.mk
> > 
> >  LIB= $(obj)lib$(BOARD).o
> > 
> > -COBJS  = $(BOARD).o flash.o plx9030.o pd67290.o
> > +COBJS  = $(BOARD).o flash.o plx9030.o pd67290.o ide.o
> > 
> >  SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> >  OBJS   := $(addprefix $(obj),$(COBJS))
> > 
> > diff --git a/board/cpc45/ide.c b/board/cpc45/ide.c
> > new file mode 100644
> > index 000..7b7237b
> > --- /dev/null
> > +++ b/board/cpc45/ide.c
> > @@ -0,0 +1,130 @@
> > +/*
> > + * (C) Copyright 2001
> > + * Rob Taylor, Flying Pig Systems. r...@flyingpig.com.
> > + *
> > + * (C) Copyright 2000-2011
> > + * 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
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define EIEIO  __asm__ volatile ("eieio")
> > +#define SYNC   __asm__ volatile ("sync")
> 
> Make it asm, not __asm__
> 
> > +
> > +void ide_input_swap_data(int dev, ulong *sect_buf, int words)
> > +{
> > +   uchar i;
> > +   volatile uchar *pbuf_even =
> > +   (uchar *) (ATA_CURR_BASE(dev) + ATA_DATA_EVEN);
> > +   volatile uchar *pbuf_odd =
> > +   (uchar *) (ATA_CURR_BASE(dev) + ATA_DATA_ODD);
> > +   ushort *dbuf = (ushort *) sect_buf;
> 
> What's this, some kind of __swab16() ?

more probably this is a hack for strange wiring on the board

> > +   while (words--) {
> > +   for (i = 0; i < 2; i++) {
> > +   *(((uchar *) (dbuf)) + 1) = *pbuf_even;
> > +   *(uchar *) dbuf = *pbuf_odd;
> > +   dbuf += 1;
> > +   }
> > +   }
> > +}
> 
> [...]
> 
> I'm not reviewing this any further ... this is some ancient code, right?

yes, this series is mostly cut-and-paste cleanup of old code, changes were 
made only when checkpatch didnt approve.

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

Re: [U-Boot] [PATCH 08/10] split AU1X00 specific code from cmd_ide.c

[Pavel Herrmann]

On Monday 08 of October 2012 16:38:46 Tom Rini wrote:
> On Sun, Oct 07, 2012 at 05:56:12PM +0200, Pavel Herrmann wrote:
> > Move special case of ide_swap_read() for AU1X00 SoC into SoC-specific
> > directory.
> > 
> > Signed-off-by: Pavel Herrmann 
> 
> Two problems:
> > diff --git a/arch/mips/cpu/mips32/au1x00/au1x00_ide.c
> > b/arch/mips/cpu/mips32/au1x00/au1x00_ide.c
> [snip]
> 
> > +#ifndef CONFIG_GTH2 /* GTH2 board behaves as it should */
> > +void ide_input_swap_data(int dev, ulong *sect_buf, int words)
> > +{
> > +   ide_input_data(dev, sect_buf, words);
> > +}
> > +
> > diff --git a/common/cmd_ide.c b/common/cmd_ide.c
> 
> That won't compile :)

sorry, my bad, i only compile tested on ppc, this is missing a header and 
endif

> Second, re-base on top of next where the gth2 board is gone, this will
> make things simpiler.

done, will send V2 after MAKEALL -a powerpc finishes, just to be sure

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

Re: [U-Boot] [PATCH 2/2] cm-t35: increase the MAXARGS

[Igor Grinberg]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/08/12 17:39, Tom Rini wrote:
> On 10/07/12 04:17, Igor Grinberg wrote:
>> Increase the MAXARGS to support more than 16 arguments.
> 
>> Signed-off-by: Igor Grinberg  --- 
>> include/configs/cm_t35.h |2 +- 1 files changed, 1
>> insertions(+), 1 deletions(-)
> 
>> diff --git a/include/configs/cm_t35.h b/include/configs/cm_t35.h 
>> index 8e28fbc..e18fb5a 100644 --- a/include/configs/cm_t35.h +++
>> b/include/configs/cm_t35.h @@ -256,7 +256,7 @@ /* Print Buffer Size
>> */ #define CONFIG_SYS_PBSIZE (CONFIG_SYS_CBSIZE + \ 
>> sizeof(CONFIG_SYS_PROMPT) + 16) -#define CONFIG_SYS_MAXARGS  16  
>> /*
>> max number of command args */ +#define CONFIG_SYS_MAXARGS32  
>> /*
>> max number of command args */ /* Boot Argument Buffer Size */ 
>> #define CONFIG_SYS_BARGSIZE  (CONFIG_SYS_CBSIZE)
> 
> Why?  This is the max number of arguments to a command in U-Boot not
> the size of the command line arguments.

Yes, I know that, but for some reason I was mislead by one of our engineers
that we need to increase it.
After checking the issue, I've came to a conclusion, that there was a missing
quote(s) and we don't really need to increase the MAXARGS.

Thanks for bringing my attention to this.
You can drop this patch.

- -- 
Regards,
Igor.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQdB/GAAoJEBDE8YO64Efa08oP/AkwuOWXy5h/P2LwYCBSc+ZC
s9nEb+ZKdkICLrOaxaV6lCj9PEce3/PZIcPTYPXeFx3O3dW5ZAXSGiyLHTdB2Nut
N+9Tfmi9lsOywWn7rmWbEsC67+ZVG28kq4IzCpPccV7HTjEHT8BTUVE55qGRJgDj
jM1EcTYJ/MwoYx2ymel0XHDLqkUMzLChk47T8+OwiBj5SDAWXBcp4Iiufy5cBKB8
mqKbUkHklfzGt4PZrLB47MFJIl9B0y2864fyCrAz3cCS3d2W0Lf6MbUA1CguxsHY
DCs3prineQFwatkgiNMTLzk0vCqpakLfzLEIVtOf4EI+IVdbyhNnTAGkacr0HMbt
PqLnC8evfdYbaGNEeU1h4WCL6Fjzs0vD/KW29mGxNbj0tTE8TypXto8LbnF1MLJ6
vE0JKQMCu9oMA9ph4cQ00ZX6GMgbyBxnhpVQ02MyUanH+dylWtdkosoodcqdHf7p
RhpkDnOJV8//dmTS32bMp42k8hNb7tXbU1ebFU6ZMwpzY+jEmqrl15E7mYmki/ZE
F488LJQektTzEGZbMqpBtlIomLQ5OMRG2vhKz9gwY/FNvJsjKRw4+Owy+HGIOKwU
IZzNaOhBp8U0yx+/70G5N2i2mnh6+on30vWfMC3x6x2yAy/Uu05ayG5NyK/sIsDP
KydW6Ibm5CvE0fFwds4l
=DXK1
-END PGP SIGNATURE-
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 5/7] lcd: Fix fb offset calculation for bpix == 16 in BMP display

[Simon Glass]

Hi Nikita,

On Thu, Oct 4, 2012 at 1:48 AM, Nikita Kiryanov  wrote:
> Hi Simon,
>
>
> On 09/29/2012 03:11 AM, Simon Glass wrote:
>>
>> From: Tom Wai-Hong Tam 
>>
>> For bpix == 16, each pixel is 2-byte. fb offset should shift more x bytes.
>>
>> Signed-off-by: Tom Wai-Hong Tam 
>> Signed-off-by: Simon Glass 
>> ---
>>   common/lcd.c |6 --
>>   1 files changed, 4 insertions(+), 2 deletions(-)
>>
>> diff --git a/common/lcd.c b/common/lcd.c
>> index 7c6cb09..004a6be 100644
>> --- a/common/lcd.c
>> +++ b/common/lcd.c
>> @@ -775,8 +775,10 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
>> height = panel_info.vl_row - y;
>>
>> bmap = (uchar *)bmp + le32_to_cpu(bmp->header.data_offset);
>> -   fb   = (uchar *) (lcd_base +
>> -   (y + height - 1) * lcd_line_length + x * bpix / 8);
>> +   fb   = (uchar *) (lcd_base + (y + height - 1) * lcd_line_length +
>> x);
>> +   /* additional fb shift for bpix == 16 since each pixel is 2-byte
>> */
>> +   if (bpix == 16)
>> +   fb += x;
>>
>
> Why is this change necessary? if bpix == 16 then x * bpix / 8 == 2 * x
> anyway.

Yes I agree, I can't see what the difference might me. Tom, do you
have any idea on this please?

Regards,
Simon

>
>
>> switch (bmp_bpix) {
>> case 1: /* pass through */
>>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Sandbox: Add spi driver to sandbox

[Simon Glass]

Hi,

On Thu, Oct 4, 2012 at 3:14 AM,   wrote:
> From: Viktor Krivak 
>
> Signed-off-by: Viktor Krivak 
> ---
>  Simple spi driver which only cache input data and send them back
>  on next call. Usefull for high level testing in sandbox.
>
>  drivers/spi/Makefile  |1 +
>  drivers/spi/sandbox.c |  162 
> +
>  include/configs/sandbox.h |3 +
>  3 files changed, 166 insertions(+)
>  create mode 100644 drivers/spi/sandbox.c
>

Please can you take a look at Mike's work here also? He seems to have
done a similar thing.

http://patchwork.ozlabs.org/patch/146127/
http://patchwork.ozlabs.org/patch/146128/
http://patchwork.ozlabs.org/patch/146129/

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

Re: [U-Boot] [PATCH v2 06/21] pmic: Enable power_board_init() support at TRATS

[Lukasz Majewski]

Hi Stefano,

> On 09/10/2012 12:30, Lukasz Majewski wrote:
> 
> >> This enforces my comment in previous patch. We have two CONFIG_
> >> options, both must be turned on. So at least one is redundant.IMHO
> >> you can drop both of them if power_board_init() is declared weak.
> > 
> > I can define power_board_init() as __weak if you are OK with
> > this :-).
> 
> IMHO yes, and call it board_power_init(). We know directly from the
> name that board_* function are often declared weak.

Ok, I will prepare v3 of this patch set.

> 
> 
> > In this case for sure CONFIG_POWER_INIT could be removed. 
> > 
> > I agree that CONFIG_PMIC can be removed from this piece of code. 
> > 
> >>
> 
> Best regards,
> Stefano Babic
> 
> 



-- 
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] go command is not working for smdkv310 board

[Wolfgang Denk]

Dear VISWANADHULA BALAJI,

In message  
you wrote:
> 
>  I am  using a  u-boot-2010-12 version for the smdkv310 board. I used

This is very old code.  Please update.

> dnw tool for loading a u-boot on to the RAM with C0008000 as a load adress.
> *Go* command is not working and gets hang when i type the following command

You cannot load U-Boot to any arbitrary address and start it there.
Please see FAQ # 1.

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
Our business is run on trust.  We trust you will pay in advance.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 06/21] pmic: Enable power_board_init() support at TRATS

[Stefano Babic]

On 09/10/2012 12:30, Lukasz Majewski wrote:

>> This enforces my comment in previous patch. We have two CONFIG_
>> options, both must be turned on. So at least one is redundant.IMHO
>> you can drop both of them if power_board_init() is declared weak.
> 
> I can define power_board_init() as __weak if you are OK with this :-).

IMHO yes, and call it board_power_init(). We know directly from the name
that board_* function are often declared weak.


> In this case for sure CONFIG_POWER_INIT could be removed. 
> 
> I agree that CONFIG_PMIC can be removed from this piece of code. 
> 
>>

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 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 05/21] pmic: Introduce power_board_init() method at ./lib/board.c file

[Stefano Babic]

On 09/10/2012 12:25, Lukasz Majewski wrote:

>> Now you want to add a new one. This means we have cases where the PMIC
>> must be initialized before flash, right ?
> 
> The case is that PMIC (and other devices) needs to be setup after
> malloc init and before MMC (in our case).
> The board_init() is before malloc init and board_late_init() is after
> MMC initialization for which working PMIC is necessary.
> PMIC_v1 works since there is a single, static instance of PMIC device
> (no lists needed).

Ok

> 
> 
> Filling the above gap was my motivation to define special callback
> for power.
> 
> In the ./arch/arm/lib/board.c there is 
> #ifdef CONFIG_ARCH_EARLY_INIT_R
>   arch_early_init_r();
> #endif

arch_early_init_r has nothing to do with power management

> 
> Which could be used and defined at e.g. ./boards/samsung/trats.c
> However it is only ARM specific (not available at PPC) and the name is
> a bit misleading. (frankly speaking it is a dead code).

Agree

>>
>> We use often the "weak" mechanism to avoid that a board maintainer is
>> constrained to implement an empty function only to make happy the
>> linker. It is better to declare the function as weak and call it with
>> the same schema, such as board_power_init() (several board_* are weak)
> 
> Correct me if I'm wrong, but weren't we recently trying to remove
> functions defined as weak?

I am not aware of it. I see several patches in last days adding weak
function. Several weak function are present in the recent added SPL
framework.

> One of arguments was that weak function will
> allow to build a u-boot.bin, which then crash at null pointer
> dereference when proper CONFIG not selected.  

I think that if there is a general agreement to drop the weak functions,
this must be done coherent for the whole code. However, I have not seen
that weak functions are rejected, and they are currently used in many parts.


>> Do we need a config option only for calling this ? I think that the
>> decision can be taken with CONFIG_PMIC, declaring the function as
>> weak.
> 
> This is one of options -> __weak power_board_init() would be defined
> when no CONFIG_PMIC defined.
> Good idea, since one CONFIG_POWER_* option would be removed. 

Right


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 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 02/21] pmic:i2c: Add I2C byte order to PMIC framework

[Stefano Babic]

On 09/10/2012 11:52, Lukasz Majewski wrote:
> Hi Stefano,
> 
>> On 05/10/2012 10:16, Lukasz Majewski wrote:
>>> Since the pmic_reg_read is the u32 value, the order in which bytes
>>> are placed to form u32 value is important.
>>>
>>> This commit adds the reverse (which is default) and normal byte
>>> order.
>>>
>>> Signed-off-by: Lukasz Majewski 
>>> Signed-off-by: Kyungmin Park 
>>>
>>> ---
>>
>> Hi Lucasz,
>>
>>> Changes for v2:
>>> - Move byte_order variable to struct pmic
>>
>> Is the byte reversal you introduce here only another way for the
>> endianess ?
>>
>> It seems to me you have a PMIC whose endianess is different as the
>> SOC's endianess, and that must be changed.
>>
>> I can suppose that "normal byte" and "reverse byte" works only with
>> ARM SOC, as they are (normally, but not always) little endian, but
>> not for example on PowerPC (big endian).
> 
> This procedure was necessary since, some sensor produces output of 2B
> and those bytes are in a big endian.

Right. So we have the endianess of the SOC and the endianess of the
PMIC, and they can differ.

> For simplicity reason I decided to make the switch on received bytes.
> 
> I suppose that witch some luck :-), proper cpu_to_le16|be16 (le32|be32)
> functions can be used to avoid repetition.

I hope so.

> 
> To make the code working at both ARM and PPC we shall use the 
> __BYTE_ORDER == __LITTLE_ENDIAN check, which is CPU dependent. Hence,
> the interpretation of stored data would be consistent from CPU point of
> view.
> 
> To sum up - two options possible:
> 1. Use cpu_to_le|be functions (hack cpu_to_le32 to handle 3B input) 
> 2. Perform switch (as it was done in this patch) with explicit check of 
> __BYTE_ORDER == __LITTLE_ENDIAN.
> 
> I would opt for 1 here.

I vote for 1, too. I think generally in u-boot and kernel there is no
use of the explicit check, but I have not grepped in code.

> 
>>
>> If this is correct, then I think we need a parameter in the structure
>> to indicate the endianess, 
> 
> We need also the endiness of data coming out from sensor as it is
> defined in this patch:
> enum { PMIC_BYTE_ORDER_REVERSED, PMIC_BYTE_ORDER_NORMAL, };
> I admit, that name could be more appropriate here (like
> SENSOR_BYTE_ORDER).

Yes. The name is misleading. Which is "normal" nowadays ?


> 
> In this patch I've added a "byte_order" variable to struct pmic to
> indicate the endiantess of device (I2C connected) to which we are
> talking to. It is per sensor defined (as the struct pmic is)

I think the procedure is correct. The endianess is stored in the pmic
structure, and then calling appropriate cpu_to_le/be function we should
have the bytes in the right order.

> 
> Please feel free to comment other patches, so I could prepare v3 of
> this series :-). 

I will do..

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 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] mxc: Fix SDHC multi-instance clock

[Stefano Babic]

On 09/10/2012 12:35, Benoît Thébaudeau wrote:
> Hi Stefano,
> 
> On Monday, October 1, 2012 8:36:25 PM, Benoît Thébaudeau wrote:
>> On mxc, each SDHC instance has a dedicated clock, so gd->sdhc_clk is
>> not
>> suitable for the multi-instance use case (initialization made
>> directly with
>> fsl_esdhc_initialize()).
>>
>> This patch fixes this issue by adding a configuration field for the
>> SDHC input
>> clock frequency.
>>
>> Signed-off-by: Benoît Thébaudeau 
>> Cc: Stefano Babic 
>> Cc: Eric Bénard 
>> Cc: Otavio Salvador 
>> Cc: Fabio Estevam 
>> Cc: Jason Liu 
>> Cc: Matt Sealey 
>> Cc: Andy Fleming 
>> ---
>> This patch should be applied after (series of series...):
>> http://patchwork.ozlabs.org/patch/187467/
>> http://patchwork.ozlabs.org/patch/187468/
>> http://patchwork.ozlabs.org/patch/187475/
>>
>> This patch supersedes http://patchwork.ozlabs.org/patch/187476/ .
>>
>> Changes for v2:
>>  - Since this patch will go to /next, extend the original patch with
>>  the mxc
>>boards newly added to this branch: mx6qsabreauto and mx6qsabresd.
> 
> Did you forget to apply this patch (and
> http://patchwork.ozlabs.org/patch/187468/ before it) when you applied my mx5 
> and
> mx25 clock series, or is it just still in your TODO list?

No, I did not forget. There are two patches for ESDHC. I wanted to be
sure that PowerPC boards are not broken and I have rechecked it this
morning. They are both ready in my queue to be merged.

> If you could apply them before the Nitrogen6X series (in order to avoid a v3 
> of
> this patch), I'd be grateful ;) . But if you need more review/test time, of
> course no problem if this is not possible.

I have some patches ready to be merged, but I sent also a pull request
for the -next branch, and it is not yet merged into arm-next. Anyway, I
can modify my pull request including further patches, too.

Best 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
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] go command is not working for smdkv310 board

[Chander Kashyap]

Hi Balaji,


On 9 October 2012 16:00, VISWANADHULA BALAJI  wrote:
> Hi,
>
>  I am  using a  u-boot-2010-12 version for the smdkv310 board. I used
> dnw tool for loading a u-boot on to the RAM with C0008000 as a load adress.
> *Go* command is not working and gets hang when i type the following command
> to run the u-boot code on to the u-boot prompt.
>
>go   c8000
>

open include/configs/smdkv310.h
#define CONFIG_STANDALONE_LOAD_ADDR  0x6000
then load application to 0x6000
and do: go  0x6000

> Can any one help me how to come out from this issue.
>
> Thanks
> Balaji
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>



-- 
with warm regards,
Chander Kashyap
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 08/21] pmic: Move pmic related code to ./drivers/power directory

[Lukasz Majewski]

Hi Stefano,

> On 05/10/2012 10:16, Lukasz Majewski wrote:
> > The PMIC framework has been moved to its more natural place
> > ./drivers/power from ./drivers/misc directory.
> > 
> > Signed-off-by: Lukasz Majewski 
> > Signed-off-by: Kyungmin Park 
> > ---
> > Changes for v2:
> > - New patch for v2
> > ---
> >  drivers/misc/Makefile  |7 ---
> >  drivers/power/Makefile |8 
> >  drivers/{misc => power/max8997}/pmic_max8997.c |0
> >  drivers/{misc => power/max8998}/pmic_max8998.c |0
> >  drivers/{misc => power}/pmic_core.c|0
> >  drivers/{misc => power}/pmic_dialog.c  |0
> >  drivers/{misc => power}/pmic_fsl.c |0
> >  drivers/{misc => power}/pmic_i2c.c |0
> >  drivers/{misc => power}/pmic_spi.c |0
> >  9 files changed, 8 insertions(+), 7 deletions(-)
> >  rename drivers/{misc => power/max8997}/pmic_max8997.c (100%)
> >  rename drivers/{misc => power/max8998}/pmic_max8998.c (100%)
> >  rename drivers/{misc => power}/pmic_core.c (100%)
> >  rename drivers/{misc => power}/pmic_dialog.c (100%)
> >  rename drivers/{misc => power}/pmic_fsl.c (100%)
> >  rename drivers/{misc => power}/pmic_i2c.c (100%)
> >  rename drivers/{misc => power}/pmic_spi.c (100%)
> > 
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> > index 271463c..cdec88b 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -34,13 +34,6 @@ COBJS-$(CONFIG_NS87308) += ns87308.o
> >  COBJS-$(CONFIG_PDSP188x) += pdsp188x.o
> >  COBJS-$(CONFIG_STATUS_LED) += status_led.o
> >  COBJS-$(CONFIG_TWL4030_LED) += twl4030_led.o
> > -COBJS-$(CONFIG_PMIC) += pmic_core.o
> > -COBJS-$(CONFIG_DIALOG_PMIC) += pmic_dialog.o
> > -COBJS-$(CONFIG_PMIC_FSL) += pmic_fsl.o
> > -COBJS-$(CONFIG_PMIC_I2C) += pmic_i2c.o
> > -COBJS-$(CONFIG_PMIC_SPI) += pmic_spi.o
> > -COBJS-$(CONFIG_PMIC_MAX8998) += pmic_max8998.o
> > -COBJS-$(CONFIG_PMIC_MAX8997) += pmic_max8997.o
> >  
> >  COBJS  := $(COBJS-y)
> >  SRCS   := $(COBJS:.o=.c)
> > diff --git a/drivers/power/Makefile b/drivers/power/Makefile
> > index 6bf388c..7016d5b 100644
> > --- a/drivers/power/Makefile
> > +++ b/drivers/power/Makefile
> > @@ -31,6 +31,14 @@ COBJS-$(CONFIG_TWL4030_POWER)+= twl4030.o
> >  COBJS-$(CONFIG_TWL6030_POWER)  += twl6030.o
> >  COBJS-$(CONFIG_TWL6035_POWER)  += twl6035.o
> >  
> > +COBJS-$(CONFIG_PMIC) += pmic_core.o
> > +COBJS-$(CONFIG_DIALOG_PMIC) += pmic_dialog.o
> > +COBJS-$(CONFIG_PMIC_FSL) += pmic_fsl.o
> > +COBJS-$(CONFIG_PMIC_I2C) += pmic_i2c.o
> > +COBJS-$(CONFIG_PMIC_SPI) += pmic_spi.o
> > +COBJS-$(CONFIG_PMIC_MAX8998) += max8998/pmic_max8998.o
> > +COBJS-$(CONFIG_PMIC_MAX8997) += max8997/pmic_max8997.o
> > +
> >  COBJS  := $(COBJS-y)
> >  SRCS   := $(COBJS:.o=.c)
> >  OBJS   := $(addprefix $(obj),$(COBJS))
> > diff --git a/drivers/misc/pmic_max8997.c
> > b/drivers/power/max8997/pmic_max8997.c similarity index 100%
> > rename from drivers/misc/pmic_max8997.c
> > rename to drivers/power/max8997/pmic_max8997.c
> > diff --git a/drivers/misc/pmic_max8998.c
> > b/drivers/power/max8998/pmic_max8998.c similarity index 100%
> > rename from drivers/misc/pmic_max8998.c
> > rename to drivers/power/max8998/pmic_max8998.c
> > diff --git a/drivers/misc/pmic_core.c b/drivers/power/pmic_core.c
> > similarity index 100%
> > rename from drivers/misc/pmic_core.c
> > rename to drivers/power/pmic_core.c
> > diff --git a/drivers/misc/pmic_dialog.c
> > b/drivers/power/pmic_dialog.c similarity index 100%
> > rename from drivers/misc/pmic_dialog.c
> > rename to drivers/power/pmic_dialog.c
> > diff --git a/drivers/misc/pmic_fsl.c b/drivers/power/pmic_fsl.c
> > similarity index 100%
> > rename from drivers/misc/pmic_fsl.c
> > rename to drivers/power/pmic_fsl.c
> > diff --git a/drivers/misc/pmic_i2c.c b/drivers/power/pmic_i2c.c
> > similarity index 100%
> > rename from drivers/misc/pmic_i2c.c
> > rename to drivers/power/pmic_i2c.c
> > diff --git a/drivers/misc/pmic_spi.c b/drivers/power/pmic_spi.c
> > similarity index 100%
> > rename from drivers/misc/pmic_spi.c
> > rename to drivers/power/pmic_spi.c
> > 
> 
> Fully agree.
> 
> Acked-by: Stefano Babic 

Some names haven't been changed (e.g. pmic_core.c -> power_core.c). This
is to reduce number of changes in the patch series and keep the PMIC
subsystem working.

Further rename (PMIC->POWER) will be performed when the initial
PMIC_v2.0 would be merged to mainline.

I simply want to avoid changing too many things at a time (now the
patch series counts of 21 patches).

-- 
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