Re: [U-Boot] [PATCH] USB:host: Attribute packed removed from usb structures

[Vipin Kumar]

On 2/25/2012 3:42 PM, Albert ARIBAUD wrote:

Hi Amit,



Hello Albert,


Le 24/02/2012 12:58, Amit Virdi a écrit :

From: Vipin Kumar

Packed attribute is forcing a bytewise write on device registers,
there by, resulting in a misbehavior on gcc-4.4.1.
Reverting the structures to non-packed


If (just asking, not asserting) the issue is caused by fields being u8
where u8 access is not possible, then should you not make the fields u16
/ u32 according to access requirements?



The problem is not with the fields being of a different width. AFAIK, 
the packed attribute changes the generated code to access even the word 
field elements in a byte by byte manner


Infact, there is a discussion on lkml that I can point
https://lkml.org/lkml/2011/4/27/278

It seems that the discussion did not lead to a conclusion but it was 
sensible (at least for ARM) to remove the packed attribute from this 
structure


Regards
Vipin


Amicalement,


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

Re: [U-Boot] [PATCH] [OMAP3] Pass timings structure pointer to board_get_mem_timings()

[Igor Grinberg]

Hi Peter,

Good work! Thanks.

On 02/26/12 17:30, Peter Barada wrote:
> Instead of passing individual registers by value to board_get_mem_timings,
> pass a board_mem_timings structure pointer for the board files to fill in.
> Pass same structure pointer to write_sdrc_timings.  This saves about
> 90 bytes of space in SPL.
> 
> Signed-off-by: Peter Barada 

Acked-by: Igor Grinberg 


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

Re: [U-Boot] [PATCH] ARM: omap3: temporary disable USB on TAM3517 boards

[Igor Grinberg]

On 02/27/12 01:10, Marek Vasut wrote:
>> The TAM3517 boards require a patch for EHCI OMAP
>> that does not yet find a way to mainline. The patch
>> disables temporary USB until EHCI OMAP will be supported.
>>
>> Signed-off-by: Stefano Babic 
>> Cc: Tom Rini 
>> Cc: Albert Aribaud 
>> ---
>>  include/configs/tam3517-common.h |7 +--
>>  1 files changed, 5 insertions(+), 2 deletions(-)
>>
> 
> Hi,
> 
> what's the status of this patch/patchset?

Superseded by:
8c589d6f (OMAP3: TAM3517: update ehci interface)


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

Re: [U-Boot] Unable to run scripts with autoscr command

[Graeme Russ]

Hi Asif,

On 02/27/2012 05:26 PM, Asif Sulikeri wrote:
> >> And the increase of 100kB is massive - are you sure you are
> compiling with
> >> the same set of options defined in the board config file? If you are
> sure,
> >> then it would be interesting to find out what has caused it.
> 
> 
> I am compiling with the default options, with no additional changes made to
> the conf file, the 1.3.4 version used to give me 150kB binary as compared
> to the 252kB binary generated by the 2010.06 version.

Ah - Looks like some more options have crept into the default configuration
- Can you send the two board config files (as inline text, not attachments)
so I can compare?

Regards,

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

Re: [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs

[Govindraj]

Hi Marek,

On Mon, Feb 27, 2012 at 4:43 AM, Marek Vasut  wrote:
>> From: "Govindraj.R" 
>>
>> Clean up ehci-omap added and make it generic to extend support for omap4
>> socs. Add ehci support for panda board.
>>
>> Patch series depends on below patch:
>>       http://patchwork.ozlabs.org/patch/130952/
>>
>> Patch series based commit id:
>>       9a4209869bd2c37affd931d627b3c3e72952
>>
>> This patch series long with above dependent patch is avialable at:
>>       git://gitorious.org/denx_u-boot/denx_uboot_omap.git
>>       v2_ehci_omap4
>>
>> Fatls, ping and tftp was tested with this patch series.
>> Test log for Panda available here:
>>       http://pastebin.pandaboard.org/index.php/view/55361716
>> Test log for Beagle-XM available here:
>>       http://pastebin.pandaboard.org/index.php/view/98437825
>>
> Hi,
>
> what's the status of this patch/patchset?

It's merged.

ubnuser@ula0131859:~/clones/mainline_loaders/u-boot$ gls dd54d31..49be71c
49be71c  OMAP4: ehci-omap: enable ehci-omap for panda boards (2 weeks ago)
860004c  OMAP4: clock-common: Move the usb dppl configuration to new
func (2 weeks ago)
95f8791  OMAP3+: Clock: Adding ehci clock enabling (2 weeks ago)
43b6239  ehci-omap: Clean up added ehci-omap.c (2 weeks ago)
29321c0  ehci-omap: driver for EHCI host on OMAP3 (2 weeks ago)
928c4bd  usb: ulpi: Add omap-ulpi-view port support (2 weeks ago)
3e6e809  usb: ulpi: Extend the existing ulpi framework. (2 weeks ago)

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

Re: [U-Boot] Unable to run scripts with autoscr command

[Asif Sulikeri]

Hi Graeme,



On Mon, Feb 27, 2012 at 11:33 AM, Graeme Russ  wrote:

> Hi,
>
> On Feb 27, 2012 4:57 PM, "Asif Sulikeri"  wrote:
> >
> > Hi any updates on this?
>
> Have you looked into any of my other suggestions?
>
> Regards,
>
> Graeme
>

I'm sorry don't know how I missed out to see the updated mail from you, I
thought there was no response at all, sorry though.


>  >
> >
> > On Sat, Feb 25, 2012 at 6:44 AM, Graeme Russ 
> wrote:
> >>
> >> Hi Asif,
> >>
> >> On 02/24/2012 04:43 PM, Asif Sulikeri wrote:
> >> > Thanks Graeme,
> >> >
> >> > replies in-line,
> >>
> >> Appreciated (after all, that is ML etiquette)
> >>
> >> >
> >> > On Fri, Feb 24, 2012 at 11:01 AM, Graeme Russ  >> > > wrote:
> >> >
> >> > Hi Asif,
> >> >
> >> > On Fri, Feb 24, 2012 at 4:25 PM, Asif Sulikeri <
> asifiqbal...@gmail.com
> >> > > wrote:
> >> > > Hi, any updates on this, this is a blocker for me, and waiting
> for your
> >> > > suggestions to resolve this issue.
> >> >
> >> > >
> >> > > On Mon, Feb 20, 2012 at 3:45 PM, Asif Sulikeri
> >> > mailto:asifiqbal...@gmail.com>>wrote:
> >> > >
> >> > >> Detlev Zundel  denx.de > writes:
> >> > >>
> >> > >> Appreciate your reply Detlev, please find my replies in-line,
> >> > >>
> >> > >> > what is the "DM365-IPNC-1.0.14" version about?  I cannot see
> such a
> >> > >> > version (or tag) in mainline U-Boot.
> >> > >>
> >> > >> I'm sorry for the typo that is supposed to be 1.0.1.
> >> >
> >> > >Don't expect much response if you stay with version 1.0.1
> >> >
> >> >
> >> >
> >> > I'm sorry for all the confusion, the u-boot version is actually 1.3.4
> and
> >> > 1.0.1 is added as a suffix for internal use, sorry for that. Am I
> still not
> >> > liable to get help for this version(1.3.4) of u-boot?
> >>
> >> Nope - 1.3.4 is 3.5 years old - more than half of the commits in
> mainline
> >> have been applied since then.
> >>
>

Hmmm, seems to be I'm on my own if I have decided to resolve this
particular issue on this particular version.


>  >> > >> > On the other hand, davinci_dm365evm is a supported
> configuration in
> >> > >> > mainline, so why not try current code.  This way we would be
> in a much
> >> > >> > better position to help you.
> >> > >> >
> >> > >>
> >> > >> I'll consider the suggestion, but since I've spent
> considerable time on
> >> > >> this,
> >> > >> want to make sure where actually the problem lies.
> >> >
> >> > Have you tried the suggestion of using the current mainline code?
> >> >
> >> > If the problem still exists in latest mainline, you stand a fair
> >> > chance that we'll make an effort to help you out :)
> >> >
> >> >
> >> > :) Thats definitely not the way you bail me out ;), jokes apart, I
> did try
> >> > using u-boot-2010.06 but the u-boot binary generated is bulky 252KB,
> as
> >> > compared the usual 150KB, this leads to another blocker as the
> UBL(User
> >> > Boot Loader) is now unable to load this bulky u-boot into RAM(or may
> be
> >> > some other issue), and gets stuck as below:
> >>
> >> Well 2010.06 is also very old - the latest release is 2011.12
> >>
> >> And the increase of 100kB is massive - are you sure you are compiling
> with
> >> the same set of options defined in the board config file? If you are
> sure,
> >> then it would be interesting to find out what has caused it.
>

I am compiling with the default options, with no additional changes made to
the conf file, the 1.3.4 version used to give me 150kB binary as compared
to the 252kB binary generated by the 2010.06 version.


>>Could you try
> >> some intermediate releases (2008.10 is the next release after 1.3.4)
> >>
>

I would definitely give it a try. I want to resolve this with whatever it
takes. :)



 >> > DM36x initialization passed!
> >> > TI UBL Base Version: 1.50
> >> > Boot Loader BootMode = NAND
> >> > Starting NAND Copy...
> >> > Valid magicnum, 0xA1ACED66, found in block 0x0008.
> >> > Boot Mode Task Completed
> >> >
> >> > IPNC UBL Version: 1.1.0
> >> > Platform: DM365
> >> >
> >> > Jumping to entry point at 0x8108
> >> >
> >> >
> >> > and there's no response whatsoever after this. what might be the
> issue now?
> >>
> >> This is outside my knowledge - I've Cc'd the davinci_dm365evm (Sandeep
> >> Paulraj), maybe he can provide some pointers...
> >>
>

Thanks for all the help, definitely appreciate your support and the early
help.



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

Re: [U-Boot] Unable to run scripts with autoscr command

[Graeme Russ]

Hi,

On Feb 27, 2012 4:57 PM, "Asif Sulikeri"  wrote:
>
> Hi any updates on this?

Have you looked into any of my other suggestions?

Regards,

Graeme
>
>
> On Sat, Feb 25, 2012 at 6:44 AM, Graeme Russ 
wrote:
>>
>> Hi Asif,
>>
>> On 02/24/2012 04:43 PM, Asif Sulikeri wrote:
>> > Thanks Graeme,
>> >
>> > replies in-line,
>>
>> Appreciated (after all, that is ML etiquette)
>>
>> >
>> > On Fri, Feb 24, 2012 at 11:01 AM, Graeme Russ > > > wrote:
>> >
>> > Hi Asif,
>> >
>> > On Fri, Feb 24, 2012 at 4:25 PM, Asif Sulikeri <
asifiqbal...@gmail.com
>> > > wrote:
>> > > Hi, any updates on this, this is a blocker for me, and waiting
for your
>> > > suggestions to resolve this issue.
>> >
>> > >
>> > > On Mon, Feb 20, 2012 at 3:45 PM, Asif Sulikeri
>> > mailto:asifiqbal...@gmail.com>>wrote:
>> > >
>> > >> Detlev Zundel  denx.de > writes:
>> > >>
>> > >> Appreciate your reply Detlev, please find my replies in-line,
>> > >>
>> > >> > what is the "DM365-IPNC-1.0.14" version about?  I cannot see
such a
>> > >> > version (or tag) in mainline U-Boot.
>> > >>
>> > >> I'm sorry for the typo that is supposed to be 1.0.1.
>> >
>> > >Don't expect much response if you stay with version 1.0.1
>> >
>> >
>> >
>> > I'm sorry for all the confusion, the u-boot version is actually 1.3.4
and
>> > 1.0.1 is added as a suffix for internal use, sorry for that. Am I
still not
>> > liable to get help for this version(1.3.4) of u-boot?
>>
>> Nope - 1.3.4 is 3.5 years old - more than half of the commits in mainline
>> have been applied since then.
>>
>> > >> > On the other hand, davinci_dm365evm is a supported
configuration in
>> > >> > mainline, so why not try current code.  This way we would be
in a much
>> > >> > better position to help you.
>> > >> >
>> > >>
>> > >> I'll consider the suggestion, but since I've spent considerable
time on
>> > >> this,
>> > >> want to make sure where actually the problem lies.
>> >
>> > Have you tried the suggestion of using the current mainline code?
>> >
>> > If the problem still exists in latest mainline, you stand a fair
>> > chance that we'll make an effort to help you out :)
>> >
>> >
>> > :) Thats definitely not the way you bail me out ;), jokes apart, I did
try
>> > using u-boot-2010.06 but the u-boot binary generated is bulky 252KB, as
>> > compared the usual 150KB, this leads to another blocker as the UBL(User
>> > Boot Loader) is now unable to load this bulky u-boot into RAM(or may be
>> > some other issue), and gets stuck as below:
>>
>> Well 2010.06 is also very old - the latest release is 2011.12
>>
>> And the increase of 100kB is massive - are you sure you are compiling
with
>> the same set of options defined in the board config file? If you are
sure,
>> then it would be interesting to find out what has caused it. Could you
try
>> some intermediate releases (2008.10 is the next release after 1.3.4)
>>
>> > DM36x initialization passed!
>> > TI UBL Base Version: 1.50
>> > Boot Loader BootMode = NAND
>> > Starting NAND Copy...
>> > Valid magicnum, 0xA1ACED66, found in block 0x0008.
>> > Boot Mode Task Completed
>> >
>> > IPNC UBL Version: 1.1.0
>> > Platform: DM365
>> >
>> > Jumping to entry point at 0x8108
>> >
>> >
>> > and there's no response whatsoever after this. what might be the issue
now?
>>
>> This is outside my knowledge - I've Cc'd the davinci_dm365evm (Sandeep
>> Paulraj), maybe he can provide some pointers...
>>
>> Regards,
>>
>> Graeme
>
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Unable to run scripts with autoscr command

[Asif Sulikeri]

Hi any updates on this?

On Sat, Feb 25, 2012 at 6:44 AM, Graeme Russ  wrote:

> Hi Asif,
>
> On 02/24/2012 04:43 PM, Asif Sulikeri wrote:
> > Thanks Graeme,
> >
> > replies in-line,
>
> Appreciated (after all, that is ML etiquette)
>
> >
> > On Fri, Feb 24, 2012 at 11:01 AM, Graeme Russ  > > wrote:
> >
> > Hi Asif,
> >
> > On Fri, Feb 24, 2012 at 4:25 PM, Asif Sulikeri <
> asifiqbal...@gmail.com
> > > wrote:
> > > Hi, any updates on this, this is a blocker for me, and waiting for
> your
> > > suggestions to resolve this issue.
> >
> > >
> > > On Mon, Feb 20, 2012 at 3:45 PM, Asif Sulikeri
> > mailto:asifiqbal...@gmail.com>>wrote:
> > >
> > >> Detlev Zundel  denx.de > writes:
> > >>
> > >> Appreciate your reply Detlev, please find my replies in-line,
> > >>
> > >> > what is the "DM365-IPNC-1.0.14" version about?  I cannot see
> such a
> > >> > version (or tag) in mainline U-Boot.
> > >>
> > >> I'm sorry for the typo that is supposed to be 1.0.1.
> >
> > >Don't expect much response if you stay with version 1.0.1
> >
> >
> >
> > I'm sorry for all the confusion, the u-boot version is actually 1.3.4 and
> > 1.0.1 is added as a suffix for internal use, sorry for that. Am I still
> not
> > liable to get help for this version(1.3.4) of u-boot?
>
> Nope - 1.3.4 is 3.5 years old - more than half of the commits in mainline
> have been applied since then.
>
> > >> > On the other hand, davinci_dm365evm is a supported
> configuration in
> > >> > mainline, so why not try current code.  This way we would be in
> a much
> > >> > better position to help you.
> > >> >
> > >>
> > >> I'll consider the suggestion, but since I've spent considerable
> time on
> > >> this,
> > >> want to make sure where actually the problem lies.
> >
> > Have you tried the suggestion of using the current mainline code?
> >
> > If the problem still exists in latest mainline, you stand a fair
> > chance that we'll make an effort to help you out :)
> >
> >
> > :) Thats definitely not the way you bail me out ;), jokes apart, I did
> try
> > using u-boot-2010.06 but the u-boot binary generated is bulky 252KB, as
> > compared the usual 150KB, this leads to another blocker as the UBL(User
> > Boot Loader) is now unable to load this bulky u-boot into RAM(or may be
> > some other issue), and gets stuck as below:
>
> Well 2010.06 is also very old - the latest release is 2011.12
>
> And the increase of 100kB is massive - are you sure you are compiling with
> the same set of options defined in the board config file? If you are sure,
> then it would be interesting to find out what has caused it. Could you try
> some intermediate releases (2008.10 is the next release after 1.3.4)
>
> > DM36x initialization passed!
> > TI UBL Base Version: 1.50
> > Boot Loader BootMode = NAND
> > Starting NAND Copy...
> > Valid magicnum, 0xA1ACED66, found in block 0x0008.
> > Boot Mode Task Completed
> >
> > IPNC UBL Version: 1.1.0
> > Platform: DM365
> >
> > Jumping to entry point at 0x8108
> >
> >
> > and there's no response whatsoever after this. what might be the issue
> now?
>
> This is outside my knowledge - I've Cc'd the davinci_dm365evm (Sandeep
> Paulraj), maybe he can provide some pointers...
>
> Regards,
>
> Graeme
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing

[Simon Glass]

Hi Mike,

On Sun, Feb 26, 2012 at 8:42 PM, Mike Frysinger  wrote:
> On Sunday 26 February 2012 23:33:25 Simon Glass wrote:
>> On Sun, Feb 26, 2012 at 8:08 PM, Mike Frysinger wrote:
>> > On Sunday 26 February 2012 21:50:32 Simon Glass wrote:
>> >> Given your efforts on the cmdline parsing I'm beginning to think we
>> >> should perhaps add os_printf() and os_printf_stderr() and provide an
>> >> explicit interface. It might only be useful prior to main(), then
>> >> again I'm not so sure.
>> >
>> > i've been pondering this.  on one hand, we want to parse flags as soon as
>> > possible, but on the other, we want to be able to not have to worry about
>> > what state the system is in when parsing things.  maybe we specially
>> > mark the few flags that we need very early on and parse those, and then
>> > parse the rest once the system is mostly functional ?  i can really only
>> > think of one or two flags that we *might* need very early -- namely,
>> > ones that'd select a config or fdt. on the other hand, are there things
>> > that we'd want to change that'd affect everything from console_init_f()
>> > and earlier ?
>>
>> IMO flags should purely update the initial state and therefore we
>> don't need the system to be function to parse them. Once the system is
>> functional, the various bits that are interested can go and look at
>> the state to get the info they want. IOW I don't think we need to
>> delay parsing until the system is functional - we just need to take
>> 'action' then.
>
> ok, so for example, i updated my spi flash patch to do:
>
> drivers/mtd/spi/sandbox.c:
> static int sb_cmdline_cb_spi_sf(struct sandbox_state *state, const char *arg)
> {
>    unsigned long bus, cs;
>    const char *spec = sb_spi_parse_spec(arg, &bus, &cs);
>
>    if (!spec)
>        return 1;
>
>    state->spi[bus][cs][0] = &sb_sf_ops;
>    state->spi[bus][cs][1] = spec;
>    return 0;
> }
> SB_CMDLINE_OPT(spi_sf, 1, "connect a SPI flash: :::");

sandbox...give me your address and I'll send you a cheque to cover the
bytes so used :-)

>
> and people could do:
>        ./u-boot --spi_sf 0:3:m25p16:./some-file.bin
> this would connect the spi flash simulation up to the simulated spi bus 0 on 
> cs
> 3 and have it simulate a m25p16 flash with "some-file.bin" backing it.
>
> if someone were to enter the wrong value for "0:3:m25p16:./some-file.bin", how
> do you propose we communicate that ?  the existing code can easily signal the
> higher parsing logic via return values, but then we'd just get:
>        failed to parse option: 0:3:m25p16:./some-file.bin
>
> but what exactly did the code not like ?  was it the bus # ?  the cs # ?  the
> spi flash id ?  the backing file ?  if the getopt code has access to printf(),
> we can clearly communicate to the user what is going wrong.

Yes I think printf() is useful in getopt, I just would prefer to avoid
using U-Boot's printf. It goes through all the console code, and we
might be running a test that deliberately breaks that, perhaps.
Actually this could be a pretty important thing to sort out - we need
to keep a clear boundary between test code and U-Boot code (as we
discussed over GPIO). Having the test code use U-Boot's printf() is
blurring that.

To your example, if the syntax is correct perhaps, then it got through
initial parsing. If the filename is wrong, or the bus number, then
perhaps there will be a message and failure much later. Perhaps the
initial parsing just does what it can to avoid running past an obvious
syntax error. But we can't really know success until we open the file,
or try the bus.

Regards,
Simon

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

Re: [U-Boot] Facing the problem with yaffs2 from uboot

[Graeme Russ]

Hi Viswanadhula,

On Mon, Feb 27, 2012 at 3:37 PM, VISWANADHULA BALAJI
 wrote:
> Hi,
>
>      Iam using SMDK6410 arm11 board having the samsung Nandflash with a
> capacity of 1Gb.Iam not able to load the yaffs2image on to the Nandflash
> from uboot by the command nandwrite,yaffs.Though the command works well
> ,the data is not added to Nand flash.Iam using uboot-1.1.6 version and

I'm sorry to say, but you're not likely to get much of a response with
such an ancient version of U-Boot - Try latest release (2011.12) and
if the problem persists, re-post your question

> kernel-2.6.28.6.Please Can you suggest on it.

Regards,

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

Re: [U-Boot] [PATCH]powerpc/8xxx:Add MPH controller support in USB device-tree fixup

[Mehresh Ramneek-B31383]

Hi Marek,

The final version of this patch is under review, didn't get any more comments, 
waiting for its acceptance...

http://patchwork.ozlabs.org/patch/140557/

Thanks and Regards,
Ramneek

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Monday, February 27, 2012 4:42 AM
> To: u-boot@lists.denx.de
> Cc: Mehresh Ramneek-B31383
> Subject: Re: [U-Boot] [PATCH]powerpc/8xxx:Add MPH controller support in
> USB device-tree fixup
> 
> > Add support for fixing usb mode and phy type for MPH(Multi Port Host)
> > USB controllers in device-tree nodes.
> > Required for socs like P3060, P5020, etc having MPH USB controller.
> >
> > Signed-off-by: Ramneek Mehresh 
> > ---
> >  arch/powerpc/cpu/mpc8xxx/fdt.c |   46
> > ++-- include/fdt_support.h
> |
> >   4 +-
> >  2 files changed, 32 insertions(+), 18
> Hi,
> 
> what's the status of this patch/patchset?
> 
> Thanks
> M


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

[U-Boot] Facing the problem with yaffs2 from uboot

[VISWANADHULA BALAJI]

Hi,

  Iam using SMDK6410 arm11 board having the samsung Nandflash with a
capacity of 1Gb.Iam not able to load the yaffs2image on to the Nandflash
from uboot by the command nandwrite,yaffs.Though the command works well
,the data is not added to Nand flash.Iam using uboot-1.1.6 version and
kernel-2.6.28.6.Please Can you suggest on it.


WithRegards

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

Re: [U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing

[Mike Frysinger]

On Sunday 26 February 2012 23:33:25 Simon Glass wrote:
> On Sun, Feb 26, 2012 at 8:08 PM, Mike Frysinger wrote:
> > On Sunday 26 February 2012 21:50:32 Simon Glass wrote:
> >> Given your efforts on the cmdline parsing I'm beginning to think we
> >> should perhaps add os_printf() and os_printf_stderr() and provide an
> >> explicit interface. It might only be useful prior to main(), then
> >> again I'm not so sure.
> > 
> > i've been pondering this.  on one hand, we want to parse flags as soon as
> > possible, but on the other, we want to be able to not have to worry about
> > what state the system is in when parsing things.  maybe we specially
> > mark the few flags that we need very early on and parse those, and then
> > parse the rest once the system is mostly functional ?  i can really only
> > think of one or two flags that we *might* need very early -- namely,
> > ones that'd select a config or fdt. on the other hand, are there things
> > that we'd want to change that'd affect everything from console_init_f()
> > and earlier ?
> 
> IMO flags should purely update the initial state and therefore we
> don't need the system to be function to parse them. Once the system is
> functional, the various bits that are interested can go and look at
> the state to get the info they want. IOW I don't think we need to
> delay parsing until the system is functional - we just need to take
> 'action' then.

ok, so for example, i updated my spi flash patch to do:

drivers/mtd/spi/sandbox.c:
static int sb_cmdline_cb_spi_sf(struct sandbox_state *state, const char *arg)
{   
unsigned long bus, cs;
const char *spec = sb_spi_parse_spec(arg, &bus, &cs);

if (!spec)
return 1;

state->spi[bus][cs][0] = &sb_sf_ops;
state->spi[bus][cs][1] = spec;
return 0;
}
SB_CMDLINE_OPT(spi_sf, 1, "connect a SPI flash: :::");

and people could do:
./u-boot --spi_sf 0:3:m25p16:./some-file.bin
this would connect the spi flash simulation up to the simulated spi bus 0 on cs 
3 and have it simulate a m25p16 flash with "some-file.bin" backing it.

if someone were to enter the wrong value for "0:3:m25p16:./some-file.bin", how 
do you propose we communicate that ?  the existing code can easily signal the 
higher parsing logic via return values, but then we'd just get:
failed to parse option: 0:3:m25p16:./some-file.bin

but what exactly did the code not like ?  was it the bus # ?  the cs # ?  the 
spi flash id ?  the backing file ?  if the getopt code has access to printf(), 
we can clearly communicate to the user what is going wrong.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] sandbox: add getopt support

[Simon Glass]

Hi Mike,

On Sun, Feb 26, 2012 at 8:35 PM, Mike Frysinger  wrote:
> On Sunday 26 February 2012 23:26:52 Simon Glass wrote:
>> On Sun, Feb 26, 2012 at 8:20 PM, Mike Frysinger wrote:
>> > On Sunday 26 February 2012 21:46:23 Simon Glass wrote:
>> >> On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger wrote:
>> >> >  int main(int argc, char *argv[])
>> >> >  {
>> >> > ...
>> >> > +       state = state_get_current();
>> >> > +       os_parse_args(state, argc, argv);
>> >>
>> >> We don't check the return value. Perhaps add a comment as to why.
>> >
>> > since the code takes care of setting parse_err itself now, i'm not sure
>> > what to do with the return value
>>
>> I agree it is right, just asking for a comment. Same with most of my
>> other things - more comments as I suggested is nice for people that
>> come into the code fresh.
>
> my plan was to clean this up a bit more before submitting (such as adding
> comments).  i was looking more for feedback on the general approach here and
> any fundamental sticking points since this is a semi-radical departure from
> what either of us posted earlier.

OK I see. Well actually I was expecting that we would need something
along these lines eventually, since arg parsing belongs with the
module that provides the argument I think. So as well to have it now,
even if it doesn't have a lot of uses yet. It will.

>
> in this case, i'm asking: should we just toss the return value and have it be
> void ?

I suggest not - even if we ignore it, it seems like information that
should be returned. Perhaps we should make it more explicit by
returning state->return_code with a comment that callers can use it
now or later. But I think the way you have done it is fine.

Regards,
Simon

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

Re: [U-Boot] [PATCH 3/3] sandbox: add getopt support

[Mike Frysinger]

On Sunday 26 February 2012 23:26:52 Simon Glass wrote:
> On Sun, Feb 26, 2012 at 8:20 PM, Mike Frysinger wrote:
> > On Sunday 26 February 2012 21:46:23 Simon Glass wrote:
> >> On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger wrote:
> >> >  int main(int argc, char *argv[])
> >> >  {
> >> > ...
> >> > +   state = state_get_current();
> >> > +   os_parse_args(state, argc, argv);
> >> 
> >> We don't check the return value. Perhaps add a comment as to why.
> > 
> > since the code takes care of setting parse_err itself now, i'm not sure
> > what to do with the return value
> 
> I agree it is right, just asking for a comment. Same with most of my
> other things - more comments as I suggested is nice for people that
> come into the code fresh.

my plan was to clean this up a bit more before submitting (such as adding 
comments).  i was looking more for feedback on the general approach here and 
any fundamental sticking points since this is a semi-radical departure from 
what either of us posted earlier.

in this case, i'm asking: should we just toss the return value and have it be 
void ?
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing

[Simon Glass]

Hi Mike,

On Sun, Feb 26, 2012 at 8:08 PM, Mike Frysinger  wrote:
> On Sunday 26 February 2012 21:50:32 Simon Glass wrote:
>> Given your efforts on the cmdline parsing I'm beginning to think we
>> should perhaps add os_printf() and os_printf_stderr() and provide an
>> explicit interface. It might only be useful prior to main(), then
>> again I'm not so sure.
>
> i've been pondering this.  on one hand, we want to parse flags as soon as
> possible, but on the other, we want to be able to not have to worry about what
> state the system is in when parsing things.  maybe we specially mark the few
> flags that we need very early on and parse those, and then parse the rest once
> the system is mostly functional ?  i can really only think of one or two flags
> that we *might* need very early -- namely, ones that'd select a config or fdt.
> on the other hand, are there things that we'd want to change that'd affect
> everything from console_init_f() and earlier ?

IMO flags should purely update the initial state and therefore we
don't need the system to be function to parse them. Once the system is
functional, the various bits that are interested can go and look at
the state to get the info they want. IOW I don't think we need to
delay parsing until the system is functional - we just need to take
'action' then.

Anyway once we have a lot of test subsystems we are going to want to
have options in a config file.

>
> wrt os_printf/etc..., the only way we could do that is if we dlopen-ed glibc
> and called the symbol directly.  u-boot provides printf() so we can't have an
> os_printf() in os.c call printf() in glibc simply because we included stdio.h
> from glibc.

Yes that reminds me why I didn't do that last time. I was wondering
about using a link flag to rename the library version of the call but
it seemed a bit ugly.

Regards,
Simon

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

Re: [U-Boot] [PATCH 05/15] common/main.c: Fix function readline

[Mike Frysinger]

On Saturday 07 January 2012 03:51:16 Pali Rohár wrote:
> On Friday 06 January 2012 15:15:29 Mike Frysinger wrote:
> > On Sunday 18 December 2011 16:34:01 Pali Rohár wrote:
> > >  * Ignore ANSI escape codes for moving cursor, which are generated by
> > > 
> > > keyboard
> > 
> > this probably should be behind an appropriate CONFIG knob.  i don't think
> > this is relevant to serial users (which are the majority of boards).
> 
> I think this is also relevant to serial console too. I tried serial console
> (over USB) with Nokia N900 on computer (ANSI terminal) and if I pressed
> cursor key (UP/DOWN/LEFT/RIGHT) it moved cursor. But in readline function
> buffer was stored ANSI sequence. So when I pressed ENTER, u-boot tried to
> execute that buffer and showed me error. But it showed error message
> something like unknown command . ansi_seq was recognized in ansi
> terminal on computer and it garbaged output. (for example if asn_seq was
> move up, error message continued on previous line...)
> 
> This patch ignore ansi codes which can be generated by curosor keys, so
> there will not be that bad error messages...

do you have CONFIG_CMDLINE_EDITING enabled ?  arrow keys work just fine when 
that's enabled, and if it isn't, then i think it's expected behavior that 
pressing the arrow keys would generate "junk" that u-boot wouldn't interpret.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 3/3] sandbox: add getopt support

[Simon Glass]

Hi Mike,

On Sun, Feb 26, 2012 at 8:20 PM, Mike Frysinger  wrote:
> On Sunday 26 February 2012 21:46:23 Simon Glass wrote:
>> On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger wrote:
>> > --- a/arch/sandbox/cpu/os.c
>> > +++ b/arch/sandbox/cpu/os.c
>> >
>> > +extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
>> > +       *__u_boot_sb_getopt_end[];
>>
>> I wonder if we can put this in asm-generic/sections.h - or perhaps
>> that doesn't exist yet?
>
> sorry, should have labeled this patch more as a PoC as i know it requires a
> little more polish.  these would go into sandbox's asm/sections.h since these
> are specific to the sandbox port.
>
>> Also how about __u_boot_sandbox_option_start/end? I'm really not keen on
>> 'sb'.
>
> for these two vars, that's fine.  i prefer "sb" for internal static stuff 
> since
> "sandbox" can get wordy real fast.
>
>> > +       int hidden_short_opt;
>> > +       size_t si;
>>
>> si?
>
> short_opt_index is the self-commenting name
>
>> > +       short_opts = os_malloc(sizeof(*short_opts) * (num_flags + 1));
>>
>> Comment on why +1? is it for \0 terminator?
>
> yes, the getopt_long() api requires a NUL terminated string
>
>> > +       si = 0;
>> > +       hidden_short_opt = 0x80;
>> > +       for (i = 0; i < num_flags; ++i) {
>> > +               long_opts[i].name = sb_opt[i]->flag;
>> > +               long_opts[i].has_arg = sb_opt[i]->has_arg ?
>> > +                       required_argument : no_argument;
>> > +               long_opts[i].flag = NULL;
>> > +
>> > +               if (sb_opt[i]->flag_short)
>> > +                       short_opts[si++] = long_opts[i].val =
>> > sb_opt[i]->flag_short; +               else
>> > +                       long_opts[i].val = sb_opt[i]->flag_short =
>> > hidden_short_opt++;
>>
>> What is this hidden_short_opt for? Suggest a comment.
>
> i think most options we have will be long only.  much harder to make sure you
> don't have collisions in the entire base when the flag definition is in the
> subfiles.  but getopt_long() needs a unique int for each long flag, so 
> "hidden"
> just means "not an ascii char".
>
>> > +       if (state->parse_err < 0)
>> > +               printf("error: unknown option: %s\n\n",
>> > +                       state->argv[-state->parse_err - 1]);
>> > +
>> > +       printf(
>>
>> do we need this extra newline?
>
> i find the extra newline helps to differentiate from the noise when we turn
> around and dump the --help output.  alternative would be to not automatically
> show --help.
>
>> > +       for (i = 0; i < num_flags; ++i) {
>> > +               /* first output the short flag if it has one */
>> > +               if (sb_opt[i]->flag_short >= 0x80)
>>
>> Can we declare a pointer to sb_opt[i] and the top here and use it below?
>
> yes
>
>> > +                       printf("      ");
>> > +               else
>> > +                       printf("  -%c, ", sb_opt[i]->flag_short);
>> > +
>> > +               /* then the long flag */
>> > +               if (sb_opt[i]->has_arg)
>> > +                       printf("--%-*s", max_noarg_len, sb_opt[i]->flag);
>> > +               else
>> > +                       printf("--%-*s  ", max_arg_len,
>> > sb_opt[i]->flag); +
>> > +               /* finally the help text */
>> > +               printf("  %s\n", sb_opt[i]->help);
>>
>> puts() might be safer, but then again I think we have vsnprintf() turned on
>> now.
>
> not sure what you mean by "safer" ... if you mean the implicit stack 
> overflows,
> i don't think that'll be an issue here.  the help strings aren't very long.
>
>> >  int main(int argc, char *argv[])
>> >  {
>> > ...
>> > +       state = state_get_current();
>> > +       os_parse_args(state, argc, argv);
>>
>> We don't check the return value. Perhaps add a comment as to why.
>
> since the code takes care of setting parse_err itself now, i'm not sure what
> to do with the return value

I agree it is right, just asking for a comment. Same with most of my
other things - more comments as I suggested is nice for people that
come into the code fresh.

Regards,
Simon

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

Re: [U-Boot] [PATCH 3/3] sandbox: add getopt support

[Mike Frysinger]

On Sunday 26 February 2012 21:46:23 Simon Glass wrote:
> On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger wrote:
> > --- a/arch/sandbox/cpu/os.c
> > +++ b/arch/sandbox/cpu/os.c
> >
> > +extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
> > +   *__u_boot_sb_getopt_end[];
> 
> I wonder if we can put this in asm-generic/sections.h - or perhaps
> that doesn't exist yet?

sorry, should have labeled this patch more as a PoC as i know it requires a 
little more polish.  these would go into sandbox's asm/sections.h since these 
are specific to the sandbox port.

> Also how about __u_boot_sandbox_option_start/end? I'm really not keen on
> 'sb'.

for these two vars, that's fine.  i prefer "sb" for internal static stuff since 
"sandbox" can get wordy real fast.

> > +   int hidden_short_opt;
> > +   size_t si;
> 
> si?

short_opt_index is the self-commenting name

> > +   short_opts = os_malloc(sizeof(*short_opts) * (num_flags + 1));
> 
> Comment on why +1? is it for \0 terminator?

yes, the getopt_long() api requires a NUL terminated string

> > +   si = 0;
> > +   hidden_short_opt = 0x80;
> > +   for (i = 0; i < num_flags; ++i) {
> > +   long_opts[i].name = sb_opt[i]->flag;
> > +   long_opts[i].has_arg = sb_opt[i]->has_arg ?
> > +   required_argument : no_argument;
> > +   long_opts[i].flag = NULL;
> > +
> > +   if (sb_opt[i]->flag_short)
> > +   short_opts[si++] = long_opts[i].val =
> > sb_opt[i]->flag_short; +   else
> > +   long_opts[i].val = sb_opt[i]->flag_short =
> > hidden_short_opt++;
> 
> What is this hidden_short_opt for? Suggest a comment.

i think most options we have will be long only.  much harder to make sure you 
don't have collisions in the entire base when the flag definition is in the 
subfiles.  but getopt_long() needs a unique int for each long flag, so "hidden" 
just means "not an ascii char".

> > +   if (state->parse_err < 0)
> > +   printf("error: unknown option: %s\n\n",
> > +   state->argv[-state->parse_err - 1]);
> > +
> > +   printf(
> 
> do we need this extra newline?

i find the extra newline helps to differentiate from the noise when we turn 
around and dump the --help output.  alternative would be to not automatically 
show --help.

> > +   for (i = 0; i < num_flags; ++i) {
> > +   /* first output the short flag if it has one */
> > +   if (sb_opt[i]->flag_short >= 0x80)
> 
> Can we declare a pointer to sb_opt[i] and the top here and use it below?

yes

> > +   printf("  ");
> > +   else
> > +   printf("  -%c, ", sb_opt[i]->flag_short);
> > +
> > +   /* then the long flag */
> > +   if (sb_opt[i]->has_arg)
> > +   printf("--%-*s", max_noarg_len, sb_opt[i]->flag);
> > +   else
> > +   printf("--%-*s  ", max_arg_len,
> > sb_opt[i]->flag); +
> > +   /* finally the help text */
> > +   printf("  %s\n", sb_opt[i]->help);
> 
> puts() might be safer, but then again I think we have vsnprintf() turned on
> now.

not sure what you mean by "safer" ... if you mean the implicit stack overflows, 
i don't think that'll be an issue here.  the help strings aren't very long.

> >  int main(int argc, char *argv[])
> >  {
> > ...
> > +   state = state_get_current();
> > +   os_parse_args(state, argc, argv);
> 
> We don't check the return value. Perhaps add a comment as to why.

since the code takes care of setting parse_err itself now, i'm not sure what 
to do with the return value
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 00/14] Nokia RX-51 support

[Mike Frysinger]

On Sunday 26 February 2012 17:08:04 Marek Vasut wrote:
> > On Tuesday 24 January 2012 15:27:57 Pali Rohár wrote:
> > > This patch series add support for new board Nokia RX-51 (aka N900).
> > > Last two patches adding on screen bootmenu support.
> > > 
> > > This series supersedes the last sent version.
> > 
> > Hi, what is state of this patch series? From our discussion is only
> > problematic bootmenu part, but other could be OK.
> > 
> > So what is needed for including this patches (without bootmenu support)
> > to uboot master?
> 
> You should probably split the patches into smaller series and resubmit
> individually.

yeah, we aren't keen on manually trying to pick things out of a patchset since 
it's hard for us to know what is required to be together.  a patchset, by 
nature, should be merged as a group.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing

[Mike Frysinger]

On Sunday 26 February 2012 21:50:32 Simon Glass wrote:
> Given your efforts on the cmdline parsing I'm beginning to think we
> should perhaps add os_printf() and os_printf_stderr() and provide an
> explicit interface. It might only be useful prior to main(), then
> again I'm not so sure.

i've been pondering this.  on one hand, we want to parse flags as soon as 
possible, but on the other, we want to be able to not have to worry about what 
state the system is in when parsing things.  maybe we specially mark the few 
flags that we need very early on and parse those, and then parse the rest once 
the system is mostly functional ?  i can really only think of one or two flags 
that we *might* need very early -- namely, ones that'd select a config or fdt.  
on the other hand, are there things that we'd want to change that'd affect 
everything from console_init_f() and earlier ?

wrt os_printf/etc..., the only way we could do that is if we dlopen-ed glibc 
and called the symbol directly.  u-boot provides printf() so we can't have an 
os_printf() in os.c call printf() in glibc simply because we included stdio.h 
from glibc.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v5 0/18] tegra: Add fdt definitions and USB driver

[Simon Glass]

Hi Marek,

On Sun, Feb 26, 2012 at 3:13 PM, Marek Vasut  wrote:
>> This series brings in the Linux kernel fdt file and provides a working
>> USB driver for Tegra2 Seaboard.
>>
>> (I have done this in one series since otherwise most of the fdt additions
>> will just look like dead code.)
>>
>> The driver requires CONFIG_OF_CONTROL and a device tree to operate.
>>
>> Some enhancements to fdtdec are required to make this easier, and these
>> are included in the series also. I have had to bring in basic GPIO
>> support due to the request to put the USB VBUS into the fdt.
>>
>> Since the kernel recently got a very minimal USB binding, I have started
>> with that and extended it where appropriate.
>>
>> Tegra likes to have cache-aligned buffers. I have dropped the patch which
>> implements this since we will solve this problem by making callers align
>> their buffers (as we did with MMC).
>>
>
> Hi,
>
> what's the status of this patch/patchset?

Superceded, v6 is on its way in the next few days.

>
> Thanks
> M

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

Re: [U-Boot] [PATCH] sandbox: disable fortification

[Simon Glass]

On Sun, Feb 26, 2012 at 1:01 PM, Mike Frysinger  wrote:
> Since we provide all our own library calls, the fortification from
> glibc just gets in our way (which some distros enable by default).
>
> Signed-off-by: Mike Frysinger 

Acked-by: Simon Glass 

> ---
>  arch/sandbox/config.mk |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk
> index 2ec1bb7..02ce4a4 100644
> --- a/arch/sandbox/config.mk
> +++ b/arch/sandbox/config.mk
> @@ -17,5 +17,5 @@
>  # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
>  # MA 02111-1307 USA
>
> -PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__
> +PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ -U_FORTIFY_SOURCE
>  PLATFORM_LIBS += -lrt
> --
> 1.7.8.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sandbox: tweak style in linker script

[Simon Glass]

On Sun, Feb 26, 2012 at 11:26 AM, Mike Frysinger  wrote:
> We use tabs for indentation, not spaces.
>
> Signed-off-by: Mike Frysinger 

Acked-by: Simon Glass 

> ---
>  arch/sandbox/cpu/u-boot.lds |   10 +-
>  1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/sandbox/cpu/u-boot.lds b/arch/sandbox/cpu/u-boot.lds
> index 2d2e50f..0c56aa7 100644
> --- a/arch/sandbox/cpu/u-boot.lds
> +++ b/arch/sandbox/cpu/u-boot.lds
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2011 The Chromium OS Authors.
> + * Copyright (c) 2011-2012 The Chromium OS Authors.
>  * Use of this source code is governed by a BSD-style license that can be
>  * found in the LICENSE file.
>  *
> @@ -24,11 +24,11 @@
>
>  SECTIONS
>  {
> -  __u_boot_cmd_start = .;
> -  .u_boot_cmd : { *(.u_boot_cmd) }
> -  __u_boot_cmd_end = .;
> -  __bss_start = .;
> +       __u_boot_cmd_start = .;
> +       _u_boot_cmd : { *(.u_boot_cmd) }
> +       __u_boot_cmd_end = .;
>
> +       __bss_start = .;
>  }
>
>  INSERT BEFORE .data;
> --
> 1.7.8.4
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3 0/16] tegra: Add fdt definitions and USB driver

[Simon Glass]

Hi Marek,

On Sun, Feb 26, 2012 at 3:09 PM, Marek Vasut  wrote:
>> This series brings in the kernel fdt file and provides a working
>> USB driver for Tegra2 Seaboard.
>>
>> (I have done this in one series since otherwise most of the fdt additions
>> will just look like dead code.)
>>
>> The driver requires CONFIG_OF_CONTROL and a device tree to operate.
>>
>> Some enhancements to fdtdec are required to make this easier, and these
>> are included in the series also. I have had to bring in basic GPIO
>> support due to the request to put the USB VBUS into the fdt.
>>
>> Since the kernel recently got a very minimal USB binding, I have started
>> with that and extended it where appropriate.
>>
>> Tegra likes to have cache-aligned buffers. I have dropped the patch which
>> implements this since we will solve this problem by making callers align
>> their buffers (as we did with MMC).
>>
>> Changes in v2:
>> - Use "okay" instead of "ok" for fdt node status
>> - Remove 0x from fdt aliases
>> - Rename params to timing
>> - Store entire fdt config in port list, not just register pointer
>> - Remove non-fdt operation of USB, since it is not needed
>> - Decode USB VBUS GPIO from the fdt
>> - Decode phy type differently (to match new kernel fdt)
>> - Rename tegra20-usb to tegra20-ehcui (to match new kernel fdt)
>> - Improve debug() printouts in case of failure to init USB
>> - Add setting of pinmux for USB VBUS GPIO
>> - Remove unneeded CONFIG_TEGRA_USBx defines
>>
>> Changes in v3:
>> - Remove "okay" from nodes since this is the default anyway
>> - Fix device tree indenting with tabs instead of spaces
>> - Disable USB2 which is not used on Seaboard
>> - Remove usbparams properties from fdt and moved them to C code
>> - Drop Tegra USB alignment patch as we will deal with this another way
>>
>> Simon Glass (16):
>>   fdt: Tidy up a few fdtdec problems
>>   fdt: Add functions to access phandles, arrays and bools
>>   Add gpio_request() to asm-generic header
>>   fdt: Add basic support for decoding GPIO definitions
>>   arm: fdt: Ensure that an embedded fdt is word-aligned
>>   arm: fdt: Add skeleton device tree file from kernel
>>   tegra: fdt: Add Tegra2x device tree file from kernel
>>   tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel
>>   tegra: usb: fdt: Add additional device tree definitions for USB ports
>>   tegra: usb: fdt: Add USB definitions for Tegra2 Seaboard
>>   usb: Add support for txfifo threshold
>>   tegra: usb: Add support for Tegra USB peripheral
>>   tegra: usb: Add USB support to nvidia boards
>>   tegra: usb: Add common USB defines for tegra2 boards
>>   tegra: usb: Enable USB on Seaboard
>>   tegra: fdt: Enable FDT support for Seaboard
>>
>>  README                                    |    3 +
>>  arch/arm/cpu/armv7/tegra2/Makefile        |    4 +-
>>  arch/arm/cpu/armv7/tegra2/config.mk       |    2 +
>>  arch/arm/cpu/armv7/tegra2/usb.c           |  430
>> + arch/arm/cpu/armv7/u-boot.lds             |
>>   5 +
>>  arch/arm/dts/skeleton.dtsi                |   13 +
>>  arch/arm/dts/tegra20.dtsi                 |  172 
>>  arch/arm/include/asm/arch-tegra2/tegra2.h |    2 +
>>  arch/arm/include/asm/arch-tegra2/usb.h    |  255 +
>>  board/nvidia/common/board.c               |    8 +
>>  board/nvidia/dts/tegra2-seaboard.dts      |   47 
>>  drivers/usb/host/Makefile                 |    1 +
>>  drivers/usb/host/ehci-hcd.c               |    7 +
>>  drivers/usb/host/ehci-tegra.c             |   63 +
>>  drivers/usb/host/ehci.h                   |    6 +-
>>  dts/Makefile                              |    2 +-
>>  include/asm-generic/gpio.h                |   10 +
>>  include/configs/seaboard.h                |   12 +
>>  include/configs/tegra2-common.h           |   14 +
>>  include/fdtdec.h                          |  109 +++-
>>  lib/fdtdec.c                              |  168 +++-
>>  21 files changed, 1320 insertions(+), 13 deletions(-)
>>  create mode 100644 arch/arm/cpu/armv7/tegra2/usb.c
>>  create mode 100644 arch/arm/dts/skeleton.dtsi
>>  create mode 100644 arch/arm/dts/tegra20.dtsi
>>  create mode 100644 arch/arm/include/asm/arch-tegra2/usb.h
>>  create mode 100644 board/nvidia/dts/tegra2-seaboard.dts
>>  create mode 100644 drivers/usb/host/ehci-tegra.c
>
> Hi,
>
> what's the status of this patch/patchset?

It needs a small update to the Tegra device tree files (2 of the
patches) and another change to deal with peripheral IDs (another 2 of
the patches). I expect to get this done in the next few days. After
that I am hoping we are done, but let's see.

Regards,
Simon

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

Re: [U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing

[Simon Glass]

Hi Mike,

On Sun, Feb 26, 2012 at 1:04 PM, Mike Frysinger  wrote:
> On Wednesday 15 February 2012 18:51:18 Simon Glass wrote:
>> --- a/arch/sandbox/cpu/os.c
>> +++ b/arch/sandbox/cpu/os.c
>>
>> +#include 
>>
>> +void os_usage(int err)
>> +{
>> +     if (err < 0)
>> +             fprintf(stderr, "Try `--help' for more information.\n");
>> +     fprintf(err < 0 ? stderr : stdout, "u-boot, "
>> +             "a command line test interface to U-Boot\n\n"
>> +             "usage:\tu-boot [-ch]\n"
>> +             "Options:\n"
>> +             "\t-h\tDisplay help\n"
>> +             "\t-c \tExecute U-Boot command\n");
>
> this actually doesn't work.  we're using the stdio from u-boot itself, so we
> can't use stdio.h from glibc.  if it works for you, i'm pretty sure it's
> purely an accident (perhaps related to the fortification change i just 
> posted).

>From memory this actually used U-Boot's fprintf, not stdio's, but I
can't really remember why it worked.

Given your efforts on the cmdline parsing I'm beginning to think we
should perhaps add os_printf() and os_printf_stderr() and provide an
explicit interface. It might only be useful prior to main(), then
again I'm not so sure.

> -mike

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

Re: [U-Boot] [PATCH 3/3] sandbox: add getopt support

[Simon Glass]

Hi Mike,

On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger  wrote:
> Signed-off-by: Mike Frysinger 
> ---
>  arch/sandbox/cpu/os.c                     |   64 ++
>  arch/sandbox/cpu/start.c                  |   83 
> +
>  arch/sandbox/cpu/u-boot.lds               |    4 ++
>  arch/sandbox/include/asm/state.h          |    5 ++
>  arch/sandbox/include/asm/u-boot-sandbox.h |    1 +
>  arch/sandbox/lib/board.c                  |    1 +
>  include/os.h                              |   35 
>  7 files changed, 193 insertions(+), 0 deletions(-)
>
> diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
> index cb469e0..4b1c987 100644
> --- a/arch/sandbox/cpu/os.c
> +++ b/arch/sandbox/cpu/os.c
> @@ -21,6 +21,7 @@
>
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -32,6 +33,7 @@
>  #include 
>
>  #include 
> +#include 
>
>  /* Operating System Interface */
>
> @@ -155,3 +157,65 @@ u64 os_get_nsec(void)
>        return tv.tv_sec * 10ULL + tv.tv_usec * 1000;
>  #endif
>  }
> +
> +extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
> +       *__u_boot_sb_getopt_end[];

I wonder if we can put this in asm-generic/sections.h - or perhaps
that doesn't exist yet?

Also how about __u_boot_sandbox_option_start/end? I'm really not keen on 'sb'.

> +static char *short_opts;
> +static struct option *long_opts;
> +
> +int os_parse_args(struct sandbox_state *state, int argc, char *argv[])
> +{
> +       struct sb_cmdline_option **sb_opt = __u_boot_sb_getopt_start;
> +       size_t num_flags = __u_boot_sb_getopt_end - __u_boot_sb_getopt_start;

num_options?

> +       size_t i;
> +
> +       int hidden_short_opt;
> +       size_t si;

si?

> +
> +       int c;
> +
> +       if (short_opts || long_opts)
> +               os_exit(1);
> +
> +       state->argc = argc;
> +       state->argv = argv;
> +
> +       short_opts = os_malloc(sizeof(*short_opts) * (num_flags + 1));

Comment on why +1? is it for \0 terminator?

> +       long_opts = os_malloc(sizeof(*long_opts) * num_flags);
> +       if (!short_opts || !long_opts)
> +               os_exit(1);
> +
> +       si = 0;
> +       hidden_short_opt = 0x80;
> +       for (i = 0; i < num_flags; ++i) {
> +               long_opts[i].name = sb_opt[i]->flag;
> +               long_opts[i].has_arg = sb_opt[i]->has_arg ?
> +                       required_argument : no_argument;
> +               long_opts[i].flag = NULL;
> +
> +               if (sb_opt[i]->flag_short)
> +                       short_opts[si++] = long_opts[i].val = 
> sb_opt[i]->flag_short;
> +               else
> +                       long_opts[i].val = sb_opt[i]->flag_short = 
> hidden_short_opt++;

What is this hidden_short_opt for? Suggest a comment.

> +       }
> +       short_opts[si] = '\0';
> +
> +       /* We need to handle output ourselves since u-boot provides printf */
> +       opterr = 0;
> +
> +       while ((c = getopt_long(argc, argv, short_opts, long_opts, NULL)) != 
> -1) {
> +               for (i = 0; i < num_flags; ++i) {
> +                       if (sb_opt[i]->flag_short == c) {
> +                               sb_opt[i]->callback(state, optarg);
> +                               break;
> +                       }
> +               }
> +               if (i == num_flags) {
> +                       /* store the faulting flag index for later */
> +                       state->parse_err = -optind;
> +                       break;
> +               }
> +       }
> +
> +       return 0;
> +}
> diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
> index dc020ee..895ec49 100644
> --- a/arch/sandbox/cpu/start.c
> +++ b/arch/sandbox/cpu/start.c
> @@ -22,19 +22,102 @@
>  #include 
>  #include 
>
> +#include 
> +
> +extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
> +       *__u_boot_sb_getopt_end[];

As above

> +
> +int sb_early_getopt_check(void)
> +{
> +       struct sandbox_state *state = state_get_current();
> +       struct sb_cmdline_option **sb_opt = __u_boot_sb_getopt_start;
> +       size_t num_flags = __u_boot_sb_getopt_end - __u_boot_sb_getopt_start;

num_options again

> +       size_t i;
> +       int max_arg_len, max_noarg_len;
> +
> +       if (state->parse_err == 0)
> +               return 0;
> +

Comment: parse_error stores -n where n is the index of the option that
we faulted.

> +       if (state->parse_err < 0)
> +               printf("error: unknown option: %s\n\n",
> +                       state->argv[-state->parse_err - 1]);
> +
> +       printf(

do we need this extra newline?

> +               "u-boot, a command line test interface to U-Boot\n\n"
> +               "Usage: u-boot [options]\n"
> +               "Options:\n");
> +
> +       max_arg_len = 0;
> +       for (i = 0; i < num_flags; ++i)
> +               max_arg_len = max(strlen(sb_opt[i]->flag), max_arg_len);
> +       max_noarg_len = max_arg_len + 7;
> +
> +       for (i = 0;

Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when missing USB PHY clock

[Liu Shengzhou-B36685]

> -Original Message-
> From: Marek Vasut [mailto:ma...@denx.de]
> Sent: Monday, February 27, 2012 7:13 AM
> To: u-boot@lists.denx.de
> Cc: Liu Shengzhou-B36685
> Subject: Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when
> missing USB PHY clock
> 
> > when missing USB PHY clock and issuing "usb start" at u-boot prompt,
> > writing to or_portsc register will cause CPU halt. We should check
> > USBGP[PHY_CLK_VALID] bit at the first time in ehci_hcd_init() to
> avoid
> > CPU hang in this case.
> >
> > Signed-off-by: Shengzhou Liu 
> > ---
> >  drivers/usb/host/ehci-fsl.c |   22 +++---
> >  1 files changed, 19 insertions(+), 3 deletions(-)
> >
> Hi,
> 
> what's the status of this patch/patchset?
> 
> Thanks
> M

Currently we found that usb CTRL_PHY_CLK_VALID bit breaks on P1022 platform, 
which not contains this bit.
 - P1023/P3041/P5020 etc, have this bit
 - P3060/4080/PSC913x do have this bit, but not mentioned in RM.
 - P1022(perhaps and other) has no this bit
I'm waiting for the response from FSL silicon team to confirm whether there is 
other platform 
not including this bit or not, so this patch maybe have to be pending until I 
get confirmation.

Thanks,
Shengzhou


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

Re: [U-Boot] u-boot for SPEAr1310

[Vipin Kumar]

Hello Pavel,


Not bad so far. :)


...it started something. According to gdb it looks like "new" u-boot
executes briefly, but fails in C code while processing intialization,
and it seems that "old" u-boot takes over. (Some kind of failure and
board resets itself?).




Yes, the u-boot resets itself. This is a workaround of a known problem
The code lies at arch/arm/cpu/arm_cortexa8/spear13xx/cpu.c
search for config_spear1300_issue_101435.

It can be disabled during development

Regards
Vipin

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

Re: [U-Boot] [PATCH 1/3] sandbox: add concept of sandbox state

[Simon Glass]

On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger  wrote:
> From: Simon Glass 
>
> The state exists through the life of U-Boot. It can be adjusted by command
> line options and perhaps later through a config file.  It is available to
> U-Boot through state_...() calls (within sandbox code).
>
> The primary purpose of this is to contain the "hardware" state.  It should
> only be used by sandbox internal code.
>
> Signed-off-by: Simon Glass 
> Signed-off-by: Mike Frysinger 

Acked-by: Simon Glass 

> ---
>  arch/sandbox/cpu/Makefile        |    2 +-
>  arch/sandbox/cpu/start.c         |    9 +-
>  arch/sandbox/cpu/state.c         |   51 ++
>  arch/sandbox/include/asm/state.h |   57 
> ++
>  4 files changed, 117 insertions(+), 2 deletions(-)
>  create mode 100644 arch/sandbox/cpu/state.c
>  create mode 100644 arch/sandbox/include/asm/state.h
>
> diff --git a/arch/sandbox/cpu/Makefile b/arch/sandbox/cpu/Makefile
> index 2ae0f71..6fd09ff 100644
> --- a/arch/sandbox/cpu/Makefile
> +++ b/arch/sandbox/cpu/Makefile
> @@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
>
>  LIB    = $(obj)lib$(CPU).o
>
> -COBJS  := cpu.o start.o os.o
> +COBJS  := cpu.o os.o start.o state.o
>
>  SRCS   := $(COBJS:.o=.c)
>  OBJS   := $(addprefix $(obj),$(COBJS))
> diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
> index a429e29..2b66eed 100644
> --- a/arch/sandbox/cpu/start.c
> +++ b/arch/sandbox/cpu/start.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright (c) 2011 The Chromium OS Authors.
> + * Copyright (c) 2011-2012 The Chromium OS Authors.
>  * See file CREDITS for list of people who contributed to this
>  * project.
>  *
> @@ -20,9 +20,16 @@
>  */
>
>  #include 
> +#include 
>
>  int main(int argc, char *argv[])
>  {
> +       int err;
> +
> +       err = state_init();
> +       if (err)
> +               return err;
> +
>        /*
>         * Do pre- and post-relocation init, then start up U-Boot. This will
>         * never return.
> diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
> new file mode 100644
> index 000..88ae2b0
> --- /dev/null
> +++ b/arch/sandbox/cpu/state.c
> @@ -0,0 +1,51 @@
> +/*
> + * Copyright (c) 2011-2012 The Chromium OS Authors.
> + * 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 
> +
> +/* Main state record for the sandbox */
> +static struct sandbox_state main_state;
> +static struct sandbox_state *state;    /* Pointer to current state record */
> +
> +void state_record_exit(enum exit_type_id exit_type)
> +{
> +       state->exit_type = exit_type;
> +}
> +
> +struct sandbox_state *state_get_current(void)
> +{
> +       assert(state);
> +       return state;
> +}
> +
> +int state_init(void)
> +{
> +       state = &main_state;
> +
> +       /*
> +        * Example of how to use GPIOs:
> +        *
> +        * sandbox_gpio_set_direction(170, 0);
> +        * sandbox_gpio_set_value(170, 0);
> +        */
> +       return 0;
> +}
> diff --git a/arch/sandbox/include/asm/state.h 
> b/arch/sandbox/include/asm/state.h
> new file mode 100644
> index 000..5b34e94
> --- /dev/null
> +++ b/arch/sandbox/include/asm/state.h
> @@ -0,0 +1,57 @@
> +/*
> + * Copyright (c) 2011-2012 The Chromium OS Authors.
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#ifndef __SANDBOX_STATE_H
> +#define __SANDBOX_STATE_H
> +
> +/* How we

Re: [U-Boot] [PATCH 2/3] sandbox: allow processing before main loop

[Simon Glass]

Hi Mike,

On Sun, Feb 26, 2012 at 2:38 PM, Mike Frysinger  wrote:
> From: Simon Glass 
>
> In order to pass command line arguments to sandbox we need to be able
> to act on them. So take control back at the end of board_init_r() from
> where we can call the main loop or do something else.
>
> Signed-off-by: Simon Glass 
> Signed-off-by: Mike Frysinger 
> ---
>  arch/sandbox/cpu/start.c                  |    5 +
>  arch/sandbox/include/asm/u-boot-sandbox.h |    3 +++
>  arch/sandbox/lib/board.c                  |    2 ++
>  3 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
> index 2b66eed..dc020ee 100644
> --- a/arch/sandbox/cpu/start.c
> +++ b/arch/sandbox/cpu/start.c
> @@ -22,6 +22,11 @@
>  #include 
>  #include 
>
> +int sb_main_loop_init(void)

Would prefer sandbox_main_loop_init()

> +{
> +       return 0;
> +}
> +
>  int main(int argc, char *argv[])
>  {
>        int err;
> diff --git a/arch/sandbox/include/asm/u-boot-sandbox.h 
> b/arch/sandbox/include/asm/u-boot-sandbox.h
> index 236b4ee..f0e8b3c 100644
> --- a/arch/sandbox/include/asm/u-boot-sandbox.h
> +++ b/arch/sandbox/include/asm/u-boot-sandbox.h
> @@ -35,4 +35,7 @@
>  int board_init(void);
>  int dram_init(void);
>
> +/* start.c */
> +int sb_main_loop_init(void);
> +
>  #endif /* _U_BOOT_SANDBOX_H_ */
> diff --git a/arch/sandbox/lib/board.c b/arch/sandbox/lib/board.c
> index 6d464d6..1082e7d 100644
> --- a/arch/sandbox/lib/board.c
> +++ b/arch/sandbox/lib/board.c
> @@ -269,6 +269,8 @@ void board_init_r(gd_t *id, ulong dest_addr)
>        post_run(NULL, POST_RAM | post_bootmode_get(0));
>  #endif
>
> +       sb_main_loop_init();
> +
>        /*
>         * For now, run the main loop. Later we might let this be done
>         * in the main program.
> --
> 1.7.8.4
>

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

Re: [U-Boot] [PATCH] AVR32 removal due to lack of custodian.

[Paul Gortmaker]

Adding linux maintainers to CC, since if it dies here, it should probably
also die in the linux kernel as well...

P.
---

On Sat, Feb 25, 2012 at 5:13 PM, Wolfgang Denk  wrote:
> AVR32 appaers to be unmaintained, and nobody appears to care about
> that.  Let's get rid fof it.
>
> Signed-off-by: Wolfgang Denk 
> ---
>  doc/feature-removal-schedule.txt |    7 ++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/doc/feature-removal-schedule.txt 
> b/doc/feature-removal-schedule.txt
> index e04ba2d..f0b828e 100644
> --- a/doc/feature-removal-schedule.txt
> +++ b/doc/feature-removal-schedule.txt
> @@ -7,6 +7,20 @@ file.
>
>  ---
>
> +What:  ARV32 Support
> +When:  v2012.06
> +Why:   Lack of a custodian and of interest, and lack of time and/or sponsors.
> +Who:   Wolfgang Denk 
> +
> +---
> +
>  What:  Users of the legacy miiphy_* code
>  When:  undetermined
>
> --
> 1.7.7.6
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: musb: fix printf warning

[Mike Frysinger]

On Sunday 26 February 2012 18:48:26 Marek Vasut wrote:
> > On Sunday 26 February 2012 18:13:58 Marek Vasut wrote:
> > > > musb_hcd.c: In function 'musb_submit_rh_msg':
> > > > musb_hcd.c:827:2: warning: format '%d' expects type 'int',
> > > > 
> > > > but argument 3 has type 'long unsigned int'
> > > 
> > > what's the status of this patch/patchset?
> > 
> > the usb ones are waiting for someone to pick up
> 
> Ok, can you please resend and Cc me so I can pick them up?

http://patchwork.ozlabs.org/patch/139366/
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] usb: musb: fix printf warning

[Marek Vasut]

> On Sunday 26 February 2012 18:13:58 Marek Vasut wrote:
> > > musb_hcd.c: In function 'musb_submit_rh_msg':
> > > musb_hcd.c:827:2: warning: format '%d' expects type 'int',
> > > 
> > >   but argument 3 has type 'long unsigned int'
> > 
> > what's the status of this patch/patchset?
> 
> the usb ones are waiting for someone to pick up
> -mike

Ok, can you please resend and Cc me so I can pick them up?

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

Re: [U-Boot] [PATCH] usb: musb: fix printf warning

[Mike Frysinger]

On Sunday 26 February 2012 18:13:58 Marek Vasut wrote:
> > musb_hcd.c: In function 'musb_submit_rh_msg':
> > musb_hcd.c:827:2: warning: format '%d' expects type 'int',
> > 
> > but argument 3 has type 'long unsigned int'
> 
> what's the status of this patch/patchset?

the usb ones are waiting for someone to pick up
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Deprecation (planned removal) of 'maintainer-less' code

[Marek Vasut]

> Hi Marek,
> 
> On Mon, Feb 27, 2012 at 10:06 AM, Marek Vasut  wrote:
> >> Hi Wolfgang,
> >> 
> >> I notice you've finally gotten sick of 'talking to the wall' regarding
> >> unmaintained code (net, USB, AVR32, etc.)
> >> 
> >> To make life a little easier for everyone, maybe we can put together a
> >> list of U-Boot sub-components which do not have an active maintainer so
> >> we can discuss what to do about it as a whole rather than in a
> >> piecemeal fashion
> > 
> > And this'll produce more talk to the wall.
> 
> Sorry, should have been more specific - List all the code that does not
> have a maintainer in one thread and set a timeframe on deprication of the
> lot unless maintainers are found (say 3 months) and then just depricate it
> all in one go...
> 
> > I'll take over the USB, so you better CC me for USB patches. We need
> > someone for NET now ...
> 
> I still wonder if we can't just move all the unmaintained code off to a
> corner like /depricated with a CONFIG_SYS_ENABLE_DEPRICATED with a big fat
> warning that there is no support for depricated code? Anything that stays
> in depricated for longer than 6 months can them be thrown away. Make a
> rule that no board configuration which sets CONFIG_SYS_ENABLE_DEPRICATED
> will be accepted into mainline - If you really want feature 'X' for your
> board and simply cannot live without it, be prepared to maintain it :)
> 
> Like Wolfgang, I would like to see these sub-systems that are prone to
> bit-rot removed, but I think we should be able to come to a comprimise and
> 'box' the bit-rot (kind of an inverse to the Linux 'staging' strategy which
> prevents non-compliant code getting into the main kernel code base)

Or find some maintainers ...

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

Re: [U-Boot] Deprecation (planned removal) of 'maintainer-less' code

[Graeme Russ]

Hi Marek,

On Mon, Feb 27, 2012 at 10:06 AM, Marek Vasut  wrote:
>> Hi Wolfgang,
>>
>> I notice you've finally gotten sick of 'talking to the wall' regarding
>> unmaintained code (net, USB, AVR32, etc.)
>>
>> To make life a little easier for everyone, maybe we can put together a list
>> of U-Boot sub-components which do not have an active maintainer so we can
>> discuss what to do about it as a whole rather than in a piecemeal fashion
>
> And this'll produce more talk to the wall.

Sorry, should have been more specific - List all the code that does not
have a maintainer in one thread and set a timeframe on deprication of the
lot unless maintainers are found (say 3 months) and then just depricate it
all in one go...

>
> I'll take over the USB, so you better CC me for USB patches. We need someone 
> for
> NET now ...

I still wonder if we can't just move all the unmaintained code off to a
corner like /depricated with a CONFIG_SYS_ENABLE_DEPRICATED with a big fat
warning that there is no support for depricated code? Anything that stays in
depricated for longer than 6 months can them be thrown away. Make a rule that
no board configuration which sets CONFIG_SYS_ENABLE_DEPRICATED will be
accepted into mainline - If you really want feature 'X' for your board and
simply cannot live without it, be prepared to maintain it :)

Like Wolfgang, I would like to see these sub-systems that are prone to
bit-rot removed, but I think we should be able to come to a comprimise and
'box' the bit-rot (kind of an inverse to the Linux 'staging' strategy which
prevents non-compliant code getting into the main kernel code base)

Regards,

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

Re: [U-Boot] [PATCH]powerpc/8xxx: Cleanup USB device-tree fixup

[Marek Vasut]

> Some code cleanup done for USB device-tree fixup:
>   - handling error value returned from fdt_fixup_usb_mode_phy_type()
>   - using ARRAY_SIZE macro
>   - using snprintf instead of sprintf
> 
> Signed-off-by: Ramneek Mehresh 
> ---
> KW Warnings fixed: using snprintf instead of sprintf
> 

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH v6 10/18] tegra: usb: fdt: Add additional device tree definitions for USB ports

[Marek Vasut]

> This adds clock references to the USB part of the device tree for U-Boot,
> and marks USB1 as supporting legacy mode (which we disable in the driver).
> 
> The USB timing information may vary between boards sometimes, but for
> now we hard-code it in C. This is because all current T2x boards use
> the same values, we will deal with T3x later and we first need to agree
> on the format for this timing information in the fdt and may in fact
> decide that it has no place there.
> 

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH] usb: musb: fix printf warning

[Marek Vasut]

> musb_hcd.c: In function 'musb_submit_rh_msg':
> musb_hcd.c:827:2: warning: format '%d' expects type 'int',
>   but argument 3 has type 'long unsigned int'
> 
> Signed-off-by: Mike Frysinger 
> ---
>  drivers/usb/musb/musb_hcd.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH v5 0/18] tegra: Add fdt definitions and USB driver

[Marek Vasut]

> This series brings in the Linux kernel fdt file and provides a working
> USB driver for Tegra2 Seaboard.
> 
> (I have done this in one series since otherwise most of the fdt additions
> will just look like dead code.)
> 
> The driver requires CONFIG_OF_CONTROL and a device tree to operate.
> 
> Some enhancements to fdtdec are required to make this easier, and these
> are included in the series also. I have had to bring in basic GPIO
> support due to the request to put the USB VBUS into the fdt.
> 
> Since the kernel recently got a very minimal USB binding, I have started
> with that and extended it where appropriate.
> 
> Tegra likes to have cache-aligned buffers. I have dropped the patch which
> implements this since we will solve this problem by making callers align
> their buffers (as we did with MMC).
> 

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH v2 0/4] Clean up ehci-omap and extend support for omap3/4 socs

[Marek Vasut]

> From: "Govindraj.R" 
> 
> Clean up ehci-omap added and make it generic to extend support for omap4
> socs. Add ehci support for panda board.
> 
> Patch series depends on below patch:
>   http://patchwork.ozlabs.org/patch/130952/
> 
> Patch series based commit id:
>   9a4209869bd2c37affd931d627b3c3e72952
> 
> This patch series long with above dependent patch is avialable at:
>   git://gitorious.org/denx_u-boot/denx_uboot_omap.git
>   v2_ehci_omap4
> 
> Fatls, ping and tftp was tested with this patch series.
> Test log for Panda available here:
>   http://pastebin.pandaboard.org/index.php/view/55361716
> Test log for Beagle-XM available here:
>   http://pastebin.pandaboard.org/index.php/view/98437825
> 
Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH] powerpc/usb: fix bug of CPU halt when missing USB PHY clock

[Marek Vasut]

> when missing USB PHY clock and issuing "usb start" at u-boot prompt,
> writing to or_portsc register will cause CPU halt. We should check
> USBGP[PHY_CLK_VALID] bit at the first time in ehci_hcd_init() to avoid CPU
> hang in this case.
> 
> Signed-off-by: Shengzhou Liu 
> ---
>  drivers/usb/host/ehci-fsl.c |   22 +++---
>  1 files changed, 19 insertions(+), 3 deletions(-)
> 
Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH 1/3] USB: Armada100: Add UTMI PHY interface driver

[Marek Vasut]

> This patch adds USB host controller's UTMI PHY interface driver for
> Armada100 SOCs.
> 
> Signed-off-by: Ajay Bhargav 
> ---
>  arch/arm/include/asm/arch-armada100/armada100.h |7 ++
>  drivers/usb/host/utmi-armada100.c   |   87
> +++ drivers/usb/host/utmi-armada100.h   | 
>  79  3 files changed, 173 insertions(+), 0
> deletions(-)
>  create mode 100644 drivers/usb/host/utmi-armada100.c
>  create mode 100644 drivers/usb/host/utmi-armada100.h
> 

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH]powerpc/8xxx:Add MPH controller support in USB device-tree fixup

[Marek Vasut]

> Add support for fixing usb mode and phy type for
> MPH(Multi Port Host) USB controllers in device-tree nodes.
> Required for socs like P3060, P5020, etc having MPH USB controller.
> 
> Signed-off-by: Ramneek Mehresh 
> ---
>  arch/powerpc/cpu/mpc8xxx/fdt.c |   46
> ++-- include/fdt_support.h  | 
>   4 +-
>  2 files changed, 32 insertions(+), 18
Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH] USB: reevaluate iomux stdin on USB kbd detect

[Marek Vasut]

> If CONSOLE_MUX is enabled, reevaluate console stdin when USB keyboard
> device is detected.
> 
> Signed-off-by: Allen Martin 
> ---

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH] USB: move keyboard polling into kbd driver

[Marek Vasut]

> This moves keyboard polling logic from USB HCD drivers into USB
> keyboard driver.  Remove usb_event_poll() as keyboard polling was
> the only user of this API.  With this patch USB keyboard works with
> EHCI controllers again.  Tested on a tegra2 seaboard.
> 
> Signed-off-by: Allen Martin 
> ---
>  common/usb_kbd.c|   18 +-
>  drivers/usb/host/ehci-hcd.c |   30 --
>  drivers/usb/host/ohci-hcd.c |6 --
>  drivers/usb/host/r8a66597-hcd.c |6 --
>  drivers/usb/musb/musb_hcd.c |   28 
>  include/usb.h   |1 -
>  6 files changed, 17 insertions(+), 72 deletions(-)
> 

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH] ARM: omap3: temporary disable USB on TAM3517 boards

[Marek Vasut]

> The TAM3517 boards require a patch for EHCI OMAP
> that does not yet find a way to mainline. The patch
> disables temporary USB until EHCI OMAP will be supported.
> 
> Signed-off-by: Stefano Babic 
> Cc: Tom Rini 
> Cc: Albert Aribaud 
> ---
>  include/configs/tam3517-common.h |7 +--
>  1 files changed, 5 insertions(+), 2 deletions(-)
> 

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH] usb: add numeric keypad support to HID driver

[Marek Vasut]

> When keys are pressed on the numeric keypad, emit key codes for the
> numbers, operators, dot and enter.
> 
> Signed-off-by: Vincent Palatin 
> ---

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH] USB: fix USB keyboard polling parameter

[Marek Vasut]

> When doing a "GET_REPORT" request on the keyboard control endpoint,
> the report ID should 0 (ie report ID not used) rather than 1
> as reports are not used in boot mode.
> 
> Signed-off-by: Vincent Palatin 
> ---
>  common/usb_kbd.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/common/usb_kbd.c b/common/usb_kbd.c
> index 75107c9..aaf7d6f 100644
> --- a/common/usb_kbd.c
> +++ b/common/usb_kbd.c
> @@ -320,7 +320,7 @@ static inline void usb_kbd_poll_for_event(struct
> usb_device *dev) struct usb_kbd_pdata *data = dev->privptr;
>   iface = &dev->config.if_desc[0];
>   usb_get_report(dev, iface->desc.bInterfaceNumber,
> - 1, 1, data->new, sizeof(data->new));
> + 1, 0, data->new, sizeof(data->new));
>   if (memcmp(data->old, data->new, sizeof(data->new)))
>   usb_kbd_irq_worker(dev);
>  #endif

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH] USB: relax usbcore reset timings

[Marek Vasut]

> From: Wolfgang Grandegger 
> 
> Following the corresponding Linux code, this patch relaxes reset timings
> waiting at least 100ms after power to the ports. There are some reports
> that it helps make enumeration work better on some high speed devices.
> Furthermore, the wait is only done once after power has been enabled
> on all ports.
> 
> CC: Remy Bohmer 
> CC: Vincent Palatin 
> Signed-off-by: Wolfgang Grandegger 
> ---

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH] eth: remove usb-ethernet devices before re-enumerating them

[Marek Vasut]

> Fix the crash when running several times usb_init() with a USB ethernet
> device plugged.
> 
> Signed-off-by: Vincent Palatin 
> Tested-by: Wolfgang Grandegger 
> ---

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [RFC PATCH 0/2] fdt: Deal correctly with alias nodes

[Marek Vasut]

> This series proposes a new way to deal with alias nodes and introduces a
> function to take care of it.
> 
> It includes an example of converting USB code over to use this new
> function.
> 
> Note: At present it does not deal automatically with disabled nodes,
> but perhaps it should? Or perhaps this is better as an option. Something
> to leave for later perhaps.
> 
> Note 2: The actual logic of this function is not properly tested yet.
> 
> 
> Simon Glass (2):
>   fdt: Add fdtdec_find_aliases() to deal with alias nodes
>   tegra: Use fdtdec_find_aliases() to find USB ports
> 
>  arch/arm/cpu/armv7/tegra2/usb.c |   17 
>  include/fdtdec.h|   51 ++
>  lib/fdtdec.c|   89
> +++ 3 files changed, 148
> insertions(+), 9 deletions(-)

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] [PATCH v3 0/16] tegra: Add fdt definitions and USB driver

[Marek Vasut]

> This series brings in the kernel fdt file and provides a working
> USB driver for Tegra2 Seaboard.
> 
> (I have done this in one series since otherwise most of the fdt additions
> will just look like dead code.)
> 
> The driver requires CONFIG_OF_CONTROL and a device tree to operate.
> 
> Some enhancements to fdtdec are required to make this easier, and these
> are included in the series also. I have had to bring in basic GPIO
> support due to the request to put the USB VBUS into the fdt.
> 
> Since the kernel recently got a very minimal USB binding, I have started
> with that and extended it where appropriate.
> 
> Tegra likes to have cache-aligned buffers. I have dropped the patch which
> implements this since we will solve this problem by making callers align
> their buffers (as we did with MMC).
> 
> Changes in v2:
> - Use "okay" instead of "ok" for fdt node status
> - Remove 0x from fdt aliases
> - Rename params to timing
> - Store entire fdt config in port list, not just register pointer
> - Remove non-fdt operation of USB, since it is not needed
> - Decode USB VBUS GPIO from the fdt
> - Decode phy type differently (to match new kernel fdt)
> - Rename tegra20-usb to tegra20-ehcui (to match new kernel fdt)
> - Improve debug() printouts in case of failure to init USB
> - Add setting of pinmux for USB VBUS GPIO
> - Remove unneeded CONFIG_TEGRA_USBx defines
> 
> Changes in v3:
> - Remove "okay" from nodes since this is the default anyway
> - Fix device tree indenting with tabs instead of spaces
> - Disable USB2 which is not used on Seaboard
> - Remove usbparams properties from fdt and moved them to C code
> - Drop Tegra USB alignment patch as we will deal with this another way
> 
> Simon Glass (16):
>   fdt: Tidy up a few fdtdec problems
>   fdt: Add functions to access phandles, arrays and bools
>   Add gpio_request() to asm-generic header
>   fdt: Add basic support for decoding GPIO definitions
>   arm: fdt: Ensure that an embedded fdt is word-aligned
>   arm: fdt: Add skeleton device tree file from kernel
>   tegra: fdt: Add Tegra2x device tree file from kernel
>   tegra: fdt: Add device tree file for Tegra2 Seaboard from kernel
>   tegra: usb: fdt: Add additional device tree definitions for USB ports
>   tegra: usb: fdt: Add USB definitions for Tegra2 Seaboard
>   usb: Add support for txfifo threshold
>   tegra: usb: Add support for Tegra USB peripheral
>   tegra: usb: Add USB support to nvidia boards
>   tegra: usb: Add common USB defines for tegra2 boards
>   tegra: usb: Enable USB on Seaboard
>   tegra: fdt: Enable FDT support for Seaboard
> 
>  README|3 +
>  arch/arm/cpu/armv7/tegra2/Makefile|4 +-
>  arch/arm/cpu/armv7/tegra2/config.mk   |2 +
>  arch/arm/cpu/armv7/tegra2/usb.c   |  430
> + arch/arm/cpu/armv7/u-boot.lds | 
>   5 +
>  arch/arm/dts/skeleton.dtsi|   13 +
>  arch/arm/dts/tegra20.dtsi |  172 
>  arch/arm/include/asm/arch-tegra2/tegra2.h |2 +
>  arch/arm/include/asm/arch-tegra2/usb.h|  255 +
>  board/nvidia/common/board.c   |8 +
>  board/nvidia/dts/tegra2-seaboard.dts  |   47 
>  drivers/usb/host/Makefile |1 +
>  drivers/usb/host/ehci-hcd.c   |7 +
>  drivers/usb/host/ehci-tegra.c |   63 +
>  drivers/usb/host/ehci.h   |6 +-
>  dts/Makefile  |2 +-
>  include/asm-generic/gpio.h|   10 +
>  include/configs/seaboard.h|   12 +
>  include/configs/tegra2-common.h   |   14 +
>  include/fdtdec.h  |  109 +++-
>  lib/fdtdec.c  |  168 +++-
>  21 files changed, 1320 insertions(+), 13 deletions(-)
>  create mode 100644 arch/arm/cpu/armv7/tegra2/usb.c
>  create mode 100644 arch/arm/dts/skeleton.dtsi
>  create mode 100644 arch/arm/dts/tegra20.dtsi
>  create mode 100644 arch/arm/include/asm/arch-tegra2/usb.h
>  create mode 100644 board/nvidia/dts/tegra2-seaboard.dts
>  create mode 100644 drivers/usb/host/ehci-tegra.c

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] net: re-enumerating usb-ethernet devices hangs the system

[Marek Vasut]

> Hi Vincent,
> 
> as you already know, the re-enumerating of usb ethernet devices (calling
> "usb start" twice) hangs the system because eth_register() is called
> more than once. If have found a related patch from you with the subject
> "eth: remove usb-ethernet devices before re-enumerating them" in the
> chromium.org git repos. Could that be pushed mainline. Feel free to add
> my "Tested-by: Wolfgang Grandegger ".
> 
> Thanks,
> 
> Wolfgang.
Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] Fastboot gadget, v2

[Marek Vasut]

> This series contains a smaller version of the fastboot gadget. I removed
> the flash/mmc/write to media part and re-add once I'm through with this
> basic thing :)
> This "basic" gadget supports the retrieval of variables (like serial
> number), reboot functionality, download of binary data and booting them in
> case the binary data is a bootable image.
> I did not include the fastboot client in this series. Remy asked about
> this. I could take it and stash it in tools if someone really wants this
> to have. This would include the fastboot and libzipfile folder from
> Andorid's system/core repository. An online version can be found at [0]. I
> haven't seen the library somewhere else than Android. For basic testing,
> the library could be excluded.
> 
> v1..v2:
>   fixed all issues that came up so far, including:
>   - s/andoir_img_get_kload/android_img_get_kload/ spotted by Mike
>   - adjusted Copyright message to GPLv2 or later for f_fastboot.c and
> removed "change" comments.
>   - removed two header files in example patch 3/3
>   I believe that the "All rights reserved" problem got resolved.
Hi,

what's the status of this patch/patchset?

Thanks
M
___
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 access to FAT filesystem in an ISO9660 El-Torito volume

[Marek Vasut]

> This series fixes several bugs in the FAT code and the USB storage
> stack to make it possible to read from a FAT filesystem image embedded
> as an "El-Torito boot image" in an ISO9660 volume (IE: a CD or DVD).
> 
> This has been tested on the eXMeritus HWW-1U-1A
> 
> I've addressed the review commentary on these patches and I believe
> that they should be acceptable for merging into "next" now.
> 
> Cheers,
> Kyle Moffett

Hi,

what's the status of this patch/patchset?

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

Re: [U-Boot] Deprecation (planned removal) of 'maintainer-less' code

[Marek Vasut]

> Hi Wolfgang,
> 
> I notice you've finally gotten sick of 'talking to the wall' regarding
> unmaintained code (net, USB, AVR32, etc.)
> 
> To make life a little easier for everyone, maybe we can put together a list
> of U-Boot sub-components which do not have an active maintainer so we can
> discuss what to do about it as a whole rather than in a piecemeal fashion

And this'll produce more talk to the wall.

I'll take over the USB, so you better CC me for USB patches. We need someone 
for 
NET now ...

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

[U-Boot] Deprecation (planned removal) of 'maintainer-less' code

[Graeme Russ]

Hi Wolfgang,

I notice you've finally gotten sick of 'talking to the wall' regarding
unmaintained code (net, USB, AVR32, etc.)

To make life a little easier for everyone, maybe we can put together a list
of U-Boot sub-components which do not have an active maintainer so we can
discuss what to do about it as a whole rather than in a piecemeal fashion

Regards,

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

[U-Boot] [PATCH] sandbox: mark os_exit as noreturn

[Mike Frysinger]

Signed-off-by: Mike Frysinger 
---
 include/os.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/os.h b/include/os.h
index aea4503..35ef9b0 100644
--- a/include/os.h
+++ b/include/os.h
@@ -95,7 +95,7 @@ int os_close(int fd);
  *
  * @param exit_codeexit code for U-Boot
  */
-void os_exit(int exit_code);
+void os_exit(int exit_code) __attribute__((noreturn));
 
 /**
  * Put tty into raw mode to mimic serial console better
-- 
1.7.8.4

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

Re: [U-Boot] [PATCH v3] AVR32: fix timer_init() function

[Wolfgang Denk]

Dear Sven,

> Date: Sun,  4 Oct 2015 21:53:32 +0200

would you be willing to disclose the secrets of running such a time
machine ?


In message <1443988412-13421-1-git-send-email-sv...@stackframe.org> you wrote:
> timer_init() now returns an int (the error code) instead of void.
> This makes compilation fail with:
> 
> interrupts.c:111: error: conflicting types for 'timer_init'
> /home/svens/u-boot/u-boot/include/common.h:246: error: previous declaration 
> of 'timer_init' was here
> make[1]: *** [interrupts.o] Error 1

We're just discussing to drop support for AVR32 systems due to lack of
a custodian, and appearent lack of interest, see
 02/25 To:u-boot@lists.d  [PATCH] AVR32 removal due to lack of custodian.
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/125752

Are you still interestedin AVR32?  Would you be willing to volunteer
to take over custodianship for this processor family?

Or Andreas, would you?

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
A good aphorism is too hard for the tooth of time, and  is  not  worn
away  by  all  the  centuries,  although  it serves as food for every
epoch.  - Friedrich Wilhelm Nietzsche
  _Miscellaneous Maxims and Opinions_ no. 168
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 3/3] sandbox: add getopt support

[Mike Frysinger]

Signed-off-by: Mike Frysinger 
---
 arch/sandbox/cpu/os.c |   64 ++
 arch/sandbox/cpu/start.c  |   83 +
 arch/sandbox/cpu/u-boot.lds   |4 ++
 arch/sandbox/include/asm/state.h  |5 ++
 arch/sandbox/include/asm/u-boot-sandbox.h |1 +
 arch/sandbox/lib/board.c  |1 +
 include/os.h  |   35 
 7 files changed, 193 insertions(+), 0 deletions(-)

diff --git a/arch/sandbox/cpu/os.c b/arch/sandbox/cpu/os.c
index cb469e0..4b1c987 100644
--- a/arch/sandbox/cpu/os.c
+++ b/arch/sandbox/cpu/os.c
@@ -21,6 +21,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -32,6 +33,7 @@
 #include 
 
 #include 
+#include 
 
 /* Operating System Interface */
 
@@ -155,3 +157,65 @@ u64 os_get_nsec(void)
return tv.tv_sec * 10ULL + tv.tv_usec * 1000;
 #endif
 }
+
+extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
+   *__u_boot_sb_getopt_end[];
+static char *short_opts;
+static struct option *long_opts;
+
+int os_parse_args(struct sandbox_state *state, int argc, char *argv[])
+{
+   struct sb_cmdline_option **sb_opt = __u_boot_sb_getopt_start;
+   size_t num_flags = __u_boot_sb_getopt_end - __u_boot_sb_getopt_start;
+   size_t i;
+
+   int hidden_short_opt;
+   size_t si;
+
+   int c;
+
+   if (short_opts || long_opts)
+   os_exit(1);
+
+   state->argc = argc;
+   state->argv = argv;
+
+   short_opts = os_malloc(sizeof(*short_opts) * (num_flags + 1));
+   long_opts = os_malloc(sizeof(*long_opts) * num_flags);
+   if (!short_opts || !long_opts)
+   os_exit(1);
+
+   si = 0;
+   hidden_short_opt = 0x80;
+   for (i = 0; i < num_flags; ++i) {
+   long_opts[i].name = sb_opt[i]->flag;
+   long_opts[i].has_arg = sb_opt[i]->has_arg ?
+   required_argument : no_argument;
+   long_opts[i].flag = NULL;
+
+   if (sb_opt[i]->flag_short)
+   short_opts[si++] = long_opts[i].val = 
sb_opt[i]->flag_short;
+   else
+   long_opts[i].val = sb_opt[i]->flag_short = 
hidden_short_opt++;
+   }
+   short_opts[si] = '\0';
+
+   /* We need to handle output ourselves since u-boot provides printf */
+   opterr = 0;
+
+   while ((c = getopt_long(argc, argv, short_opts, long_opts, NULL)) != 
-1) {
+   for (i = 0; i < num_flags; ++i) {
+   if (sb_opt[i]->flag_short == c) {
+   sb_opt[i]->callback(state, optarg);
+   break;
+   }
+   }
+   if (i == num_flags) {
+   /* store the faulting flag index for later */
+   state->parse_err = -optind;
+   break;
+   }
+   }
+
+   return 0;
+}
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index dc020ee..895ec49 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -22,19 +22,102 @@
 #include 
 #include 
 
+#include 
+
+extern struct sb_cmdline_option *__u_boot_sb_getopt_start[],
+   *__u_boot_sb_getopt_end[];
+
+int sb_early_getopt_check(void)
+{
+   struct sandbox_state *state = state_get_current();
+   struct sb_cmdline_option **sb_opt = __u_boot_sb_getopt_start;
+   size_t num_flags = __u_boot_sb_getopt_end - __u_boot_sb_getopt_start;
+   size_t i;
+   int max_arg_len, max_noarg_len;
+
+   if (state->parse_err == 0)
+   return 0;
+
+   if (state->parse_err < 0)
+   printf("error: unknown option: %s\n\n",
+   state->argv[-state->parse_err - 1]);
+
+   printf(
+   "u-boot, a command line test interface to U-Boot\n\n"
+   "Usage: u-boot [options]\n"
+   "Options:\n");
+
+   max_arg_len = 0;
+   for (i = 0; i < num_flags; ++i)
+   max_arg_len = max(strlen(sb_opt[i]->flag), max_arg_len);
+   max_noarg_len = max_arg_len + 7;
+
+   for (i = 0; i < num_flags; ++i) {
+   /* first output the short flag if it has one */
+   if (sb_opt[i]->flag_short >= 0x80)
+   printf("  ");
+   else
+   printf("  -%c, ", sb_opt[i]->flag_short);
+
+   /* then the long flag */
+   if (sb_opt[i]->has_arg)
+   printf("--%-*s", max_noarg_len, sb_opt[i]->flag);
+   else
+   printf("--%-*s  ", max_arg_len, sb_opt[i]->flag);
+
+   /* finally the help text */
+   printf("  %s\n", sb_opt[i]->help);
+   }
+
+   os_exit(state->parse_err < 0 ? 1 : 0);
+}
+
+static int sb_cmdline_cb_help(struct sandbox_state *state, const char *arg)
+{
+   /* just flag

[U-Boot] [PATCH 2/3] sandbox: allow processing before main loop

[Mike Frysinger]

From: Simon Glass 

In order to pass command line arguments to sandbox we need to be able
to act on them. So take control back at the end of board_init_r() from
where we can call the main loop or do something else.

Signed-off-by: Simon Glass 
Signed-off-by: Mike Frysinger 
---
 arch/sandbox/cpu/start.c  |5 +
 arch/sandbox/include/asm/u-boot-sandbox.h |3 +++
 arch/sandbox/lib/board.c  |2 ++
 3 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index 2b66eed..dc020ee 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -22,6 +22,11 @@
 #include 
 #include 
 
+int sb_main_loop_init(void)
+{
+   return 0;
+}
+
 int main(int argc, char *argv[])
 {
int err;
diff --git a/arch/sandbox/include/asm/u-boot-sandbox.h 
b/arch/sandbox/include/asm/u-boot-sandbox.h
index 236b4ee..f0e8b3c 100644
--- a/arch/sandbox/include/asm/u-boot-sandbox.h
+++ b/arch/sandbox/include/asm/u-boot-sandbox.h
@@ -35,4 +35,7 @@
 int board_init(void);
 int dram_init(void);
 
+/* start.c */
+int sb_main_loop_init(void);
+
 #endif /* _U_BOOT_SANDBOX_H_ */
diff --git a/arch/sandbox/lib/board.c b/arch/sandbox/lib/board.c
index 6d464d6..1082e7d 100644
--- a/arch/sandbox/lib/board.c
+++ b/arch/sandbox/lib/board.c
@@ -269,6 +269,8 @@ void board_init_r(gd_t *id, ulong dest_addr)
post_run(NULL, POST_RAM | post_bootmode_get(0));
 #endif
 
+   sb_main_loop_init();
+
/*
 * For now, run the main loop. Later we might let this be done
 * in the main program.
-- 
1.7.8.4

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

[U-Boot] [PATCH 1/3] sandbox: add concept of sandbox state

[Mike Frysinger]

From: Simon Glass 

The state exists through the life of U-Boot. It can be adjusted by command
line options and perhaps later through a config file.  It is available to
U-Boot through state_...() calls (within sandbox code).

The primary purpose of this is to contain the "hardware" state.  It should
only be used by sandbox internal code.

Signed-off-by: Simon Glass 
Signed-off-by: Mike Frysinger 
---
 arch/sandbox/cpu/Makefile|2 +-
 arch/sandbox/cpu/start.c |9 +-
 arch/sandbox/cpu/state.c |   51 ++
 arch/sandbox/include/asm/state.h |   57 ++
 4 files changed, 117 insertions(+), 2 deletions(-)
 create mode 100644 arch/sandbox/cpu/state.c
 create mode 100644 arch/sandbox/include/asm/state.h

diff --git a/arch/sandbox/cpu/Makefile b/arch/sandbox/cpu/Makefile
index 2ae0f71..6fd09ff 100644
--- a/arch/sandbox/cpu/Makefile
+++ b/arch/sandbox/cpu/Makefile
@@ -27,7 +27,7 @@ include $(TOPDIR)/config.mk
 
 LIB= $(obj)lib$(CPU).o
 
-COBJS  := cpu.o start.o os.o
+COBJS  := cpu.o os.o start.o state.o
 
 SRCS   := $(COBJS:.o=.c)
 OBJS   := $(addprefix $(obj),$(COBJS))
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index a429e29..2b66eed 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011 The Chromium OS Authors.
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
  * See file CREDITS for list of people who contributed to this
  * project.
  *
@@ -20,9 +20,16 @@
  */
 
 #include 
+#include 
 
 int main(int argc, char *argv[])
 {
+   int err;
+
+   err = state_init();
+   if (err)
+   return err;
+
/*
 * Do pre- and post-relocation init, then start up U-Boot. This will
 * never return.
diff --git a/arch/sandbox/cpu/state.c b/arch/sandbox/cpu/state.c
new file mode 100644
index 000..88ae2b0
--- /dev/null
+++ b/arch/sandbox/cpu/state.c
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
+ * 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 
+
+/* Main state record for the sandbox */
+static struct sandbox_state main_state;
+static struct sandbox_state *state;/* Pointer to current state record */
+
+void state_record_exit(enum exit_type_id exit_type)
+{
+   state->exit_type = exit_type;
+}
+
+struct sandbox_state *state_get_current(void)
+{
+   assert(state);
+   return state;
+}
+
+int state_init(void)
+{
+   state = &main_state;
+
+   /*
+* Example of how to use GPIOs:
+*
+* sandbox_gpio_set_direction(170, 0);
+* sandbox_gpio_set_value(170, 0);
+*/
+   return 0;
+}
diff --git a/arch/sandbox/include/asm/state.h b/arch/sandbox/include/asm/state.h
new file mode 100644
index 000..5b34e94
--- /dev/null
+++ b/arch/sandbox/include/asm/state.h
@@ -0,0 +1,57 @@
+/*
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#ifndef __SANDBOX_STATE_H
+#define __SANDBOX_STATE_H
+
+/* How we exited U-Boot */
+enum exit_type_id {
+   STATE_EXIT_NORMAL,
+   STATE_EXIT_COLD_REBOOT,
+   STATE_EXIT_POWER_OFF,
+};
+
+/* The complete state of the test system */
+struct sandbox_state {
+   const char *cmd;/* Command to execute */
+   enum exit_type_id exit_type;/* How we exited U-Boot */
+};
+
+/**
+ * Record the exi

[U-Boot] [PATCH 3/7] i.MX28: Reformat the DRAM memory configuration data

[Marek Vasut]

Reformat the data so it's easier to navigate through them.

Signed-off-by: Marek Vasut 
---
 arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c |   86 +++
 1 files changed, 48 insertions(+), 38 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c 
b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index db67011..4af9eb7 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -32,44 +32,54 @@
 #include "mx28_init.h"
 
 uint32_t dram_vals[] = {
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x0100, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x00010101, 0x01010101, 0x000f0f01, 0x0f02020a,
-   0x, 0x00010101, 0x0100, 0x0100, 0x,
-   0x0002, 0x0101, 0x05060302, 0x06005003, 0x0ac8,
-   0x02009c40, 0x030c, 0x0036a609, 0x031a0612, 0x02030202,
-   0x00c8001c, 0x, 0x, 0x00012100, 0x0303,
-   0x00012100, 0x0303, 0x00012100, 0x0303, 0x00012100,
-   0x0303, 0x0003, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x0612, 0x01000F02, 0x06120612, 0x0200,
-   0x00020007, 0xf5014b27, 0xf5014b27, 0xf5014b27, 0xf5014b27,
-   0x07000300, 0x07000300, 0x07000300, 0x07000300, 0x0006,
-   0x, 0x, 0x0100, 0x01020408, 0x08040201,
-   0x000f1133, 0x, 0x1f04, 0x1f04, 0x1f04,
-   0x1f04, 0x1f04, 0x1f04, 0x1f04, 0x1f04,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x, 0x0001, 0x00020304, 0x0004,
-   0x, 0x, 0x, 0x, 0x,
-   0x, 0x0101, 0x0100, 0x0303, 0x00010303,
-   0x01020202, 0x, 0x02040303, 0x21002103, 0x00061200,
-   0x06120612, 0x04320432, 0x04320432, 0x00040004, 0x00040004,
-   0x, 0x, 0x, 0x, 0x00010001
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x0100, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x00010101, 0x01010101,
+   0x000f0f01, 0x0f02020a, 0x, 0x00010101,
+   0x0100, 0x0100, 0x, 0x0002,
+   0x0101, 0x05060302, 0x06005003, 0x0ac8,
+   0x02009c40, 0x030c, 0x0036a609, 0x031a0612,
+   0x02030202, 0x00c8001c, 0x, 0x,
+   0x00012100, 0x0303, 0x00012100, 0x0303,
+   0x00012100, 0x0303, 0x00012100, 0x0303,
+   0x0003, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x0612, 0x01000F02,
+   0x06120612, 0x0200, 0x00020007, 0xf5014b27,
+   0xf5014b27, 0xf5014b27, 0xf5014b27, 0x07000300,
+   0x07000300, 0x07000300, 0x07000300, 0x0006,
+   0x, 0x, 0x0100, 0x01020408,
+   0x08040201, 0x000f1133, 0x, 0x1f04,
+   0x1f04, 0x1f04, 0x1f04, 0x1f04,
+   0x1f04, 0x1f04, 0x1f04, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x, 0x,
+   0x, 0x, 0x

[U-Boot] [PATCH 7/7] Fix erroneous 32-bit access to hw_clkctrl_frac0 and hw_clkctrl_frac1 registers

[Marek Vasut]

From: Robert Delien 

This patch fixes erroneous 32-bit access to registers
hw_clkctrl_frac0 and hw_clkctrl_frac1.

Signed-off-by: Robert Delien 
Acked-by: Marek Vasut 
Tested-by: Marek Vasut 
---
 arch/arm/cpu/arm926ejs/mx28/clock.c   |   70 ++---
 arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c|   26 -
 arch/arm/include/asm/arch-mx28/regs-clkctrl.h |   44 +---
 3 files changed, 52 insertions(+), 88 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx28/clock.c 
b/arch/arm/cpu/arm926ejs/mx28/clock.c
index 9d3a018..0439f9c 100644
--- a/arch/arm/cpu/arm926ejs/mx28/clock.c
+++ b/arch/arm/cpu/arm926ejs/mx28/clock.c
@@ -46,8 +46,8 @@ static uint32_t mx28_get_pclk(void)
struct mx28_clkctrl_regs *clkctrl_regs =
(struct mx28_clkctrl_regs *)MXS_CLKCTRL_BASE;
 
-   uint32_t clkctrl, clkseq, clkfrac;
-   uint32_t frac, div;
+   uint32_t clkctrl, clkseq, div;
+   uint8_t clkfrac, frac;
 
clkctrl = readl(&clkctrl_regs->hw_clkctrl_cpu);
 
@@ -67,8 +67,8 @@ static uint32_t mx28_get_pclk(void)
}
 
/* REF Path */
-   clkfrac = readl(&clkctrl_regs->hw_clkctrl_frac0);
-   frac = clkfrac & CLKCTRL_FRAC0_CPUFRAC_MASK;
+   clkfrac = readb(&clkctrl_regs->hw_clkctrl_frac0[CLKCTRL_FRAC0_CPU]);
+   frac = clkfrac & CLKCTRL_FRAC_FRAC_MASK;
div = clkctrl & CLKCTRL_CPU_DIV_CPU_MASK;
return (PLL_FREQ_MHZ * PLL_FREQ_COEF / frac) / div;
 }
@@ -96,8 +96,8 @@ static uint32_t mx28_get_emiclk(void)
struct mx28_clkctrl_regs *clkctrl_regs =
(struct mx28_clkctrl_regs *)MXS_CLKCTRL_BASE;
 
-   uint32_t frac, div;
-   uint32_t clkctrl, clkseq, clkfrac;
+   uint32_t clkctrl, clkseq, div;
+   uint8_t clkfrac, frac;
 
clkseq = readl(&clkctrl_regs->hw_clkctrl_clkseq);
clkctrl = readl(&clkctrl_regs->hw_clkctrl_emi);
@@ -109,11 +109,9 @@ static uint32_t mx28_get_emiclk(void)
return XTAL_FREQ_MHZ / div;
}
 
-   clkfrac = readl(&clkctrl_regs->hw_clkctrl_frac0);
-
/* REF Path */
-   frac = (clkfrac & CLKCTRL_FRAC0_EMIFRAC_MASK) >>
-   CLKCTRL_FRAC0_EMIFRAC_OFFSET;
+   clkfrac = readb(&clkctrl_regs->hw_clkctrl_frac0[CLKCTRL_FRAC0_EMI]);
+   frac = clkfrac & CLKCTRL_FRAC_FRAC_MASK;
div = clkctrl & CLKCTRL_EMI_DIV_EMI_MASK;
return (PLL_FREQ_MHZ * PLL_FREQ_COEF / frac) / div;
 }
@@ -123,8 +121,8 @@ static uint32_t mx28_get_gpmiclk(void)
struct mx28_clkctrl_regs *clkctrl_regs =
(struct mx28_clkctrl_regs *)MXS_CLKCTRL_BASE;
 
-   uint32_t frac, div;
-   uint32_t clkctrl, clkseq, clkfrac;
+   uint32_t clkctrl, clkseq, div;
+   uint8_t clkfrac, frac;
 
clkseq = readl(&clkctrl_regs->hw_clkctrl_clkseq);
clkctrl = readl(&clkctrl_regs->hw_clkctrl_gpmi);
@@ -135,11 +133,9 @@ static uint32_t mx28_get_gpmiclk(void)
return XTAL_FREQ_MHZ / div;
}
 
-   clkfrac = readl(&clkctrl_regs->hw_clkctrl_frac1);
-
/* REF Path */
-   frac = (clkfrac & CLKCTRL_FRAC1_GPMIFRAC_MASK) >>
-   CLKCTRL_FRAC1_GPMIFRAC_OFFSET;
+   clkfrac = readb(&clkctrl_regs->hw_clkctrl_frac1[CLKCTRL_FRAC1_GPMI]);
+   frac = clkfrac & CLKCTRL_FRAC_FRAC_MASK;
div = clkctrl & CLKCTRL_GPMI_DIV_MASK;
return (PLL_FREQ_MHZ * PLL_FREQ_COEF / frac) / div;
 }
@@ -152,11 +148,12 @@ void mx28_set_ioclk(enum mxs_ioclock io, uint32_t freq)
struct mx28_clkctrl_regs *clkctrl_regs =
(struct mx28_clkctrl_regs *)MXS_CLKCTRL_BASE;
uint32_t div;
+   int io_reg;
 
if (freq == 0)
return;
 
-   if (io > MXC_IOCLK1)
+   if ((io < MXC_IOCLK0) || (io > MXC_IOCLK1))
return;
 
div = (PLL_FREQ_KHZ * PLL_FREQ_COEF) / freq;
@@ -167,23 +164,13 @@ void mx28_set_ioclk(enum mxs_ioclock io, uint32_t freq)
if (div > 35)
div = 35;
 
-   if (io == MXC_IOCLK0) {
-   writel(CLKCTRL_FRAC0_CLKGATEIO0,
-   &clkctrl_regs->hw_clkctrl_frac0_set);
-   clrsetbits_le32(&clkctrl_regs->hw_clkctrl_frac0,
-   CLKCTRL_FRAC0_IO0FRAC_MASK,
-   div << CLKCTRL_FRAC0_IO0FRAC_OFFSET);
-   writel(CLKCTRL_FRAC0_CLKGATEIO0,
-   &clkctrl_regs->hw_clkctrl_frac0_clr);
-   } else {
-   writel(CLKCTRL_FRAC0_CLKGATEIO1,
-   &clkctrl_regs->hw_clkctrl_frac0_set);
-   clrsetbits_le32(&clkctrl_regs->hw_clkctrl_frac0,
-   CLKCTRL_FRAC0_IO1FRAC_MASK,
-   div << CLKCTRL_FRAC0_IO1FRAC_OFFSET);
-   writel(CLKCTRL_FRAC0_CLKGATEIO1,
-   &clkctrl_regs->hw_clkctrl_frac0_clr);
-   }
+   io_reg = CLKCTRL_FRAC0_IO0 - io;/* Register order is reversed */
+   writeb(CLKCTRL_FRAC_CLKGATE,
+  

[U-Boot] [PATCH 6/7] Introducing 8-bit wide register, mx28_register_8

[Marek Vasut]

From: Robert Delien 

This patch introduces an 8-bit register, mx28_register_8, in order to
prepare for fixing erroneous 32-bit wide access of registers
hw_clkctrl_frac0 and hw_clkctrl_frac1.

Signed-off-by: Robert Delien 
Acked-by: Marek Vasut 
Tested-by: Marek Vasut 
---
 arch/arm/include/asm/arch-mx28/regs-common.h |   16 
 1 files changed, 16 insertions(+), 0 deletions(-)

diff --git a/arch/arm/include/asm/arch-mx28/regs-common.h 
b/arch/arm/include/asm/arch-mx28/regs-common.h
index 75cc9a6..94b512d 100644
--- a/arch/arm/include/asm/arch-mx28/regs-common.h
+++ b/arch/arm/include/asm/arch-mx28/regs-common.h
@@ -47,16 +47,32 @@
  *
  */
 
+#define__mx28_reg_8(name)  \
+   uint8_t name[4];\
+   uint8_t name##_set[4];  \
+   uint8_t name##_clr[4];  \
+   uint8_t name##_tog[4];  \
+
 #define__mx28_reg_32(name) \
uint32_t name;  \
uint32_t name##_set;\
uint32_t name##_clr;\
uint32_t name##_tog;
 
+struct mx28_register_8 {
+   __mx28_reg_8(reg)
+};
+
 struct mx28_register_32 {
__mx28_reg_32(reg)
 };
 
+#definemx28_reg_8(name)\
+   union { \
+   struct { __mx28_reg_8(name) };  \
+   struct mx28_register_32 name##_reg; \
+   };
+
 #definemx28_reg_32(name)   \
union { \
struct { __mx28_reg_32(name) }; \
-- 
1.7.9

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

[U-Boot] [PATCH 4/7] i.MX28: Enable additional DRAM address bits

[Marek Vasut]

Signed-off-by: Marek Vasut 
---
 arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c 
b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
index 4af9eb7..fd18f70 100644
--- a/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
+++ b/arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c
@@ -39,7 +39,7 @@ uint32_t dram_vals[] = {
0x, 0x0100, 0x, 0x,
0x, 0x, 0x, 0x,
0x, 0x, 0x00010101, 0x01010101,
-   0x000f0f01, 0x0f02020a, 0x, 0x00010101,
+   0x000f0f01, 0x0f02010a, 0x, 0x00010101,
0x0100, 0x0100, 0x, 0x0002,
0x0101, 0x05060302, 0x06005003, 0x0ac8,
0x02009c40, 0x030c, 0x0036a609, 0x031a0612,
-- 
1.7.9

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

[U-Boot] [PATCH 1/7] M28: Fix LCD PINMUX

[Marek Vasut]

The LCD pins configuration was wrong in U-Boot, configure pins properly.

Signed-off-by: Marek Vasut 
Cc: Wolfgang Denk 
Cc: Detlev Zundel 
Cc: Stefano Babic 
Cc: Fabio Estevam 
---
 board/denx/m28evk/spl_boot.c |   11 ++-
 1 files changed, 2 insertions(+), 9 deletions(-)

diff --git a/board/denx/m28evk/spl_boot.c b/board/denx/m28evk/spl_boot.c
index 86d7d87..91316a7 100644
--- a/board/denx/m28evk/spl_boot.c
+++ b/board/denx/m28evk/spl_boot.c
@@ -31,7 +31,7 @@
 #include 
 
 #defineMUX_CONFIG_LED  (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL)
-#defineMUX_CONFIG_LCD  (MXS_PAD_3V3 | MXS_PAD_4MA)
+#defineMUX_CONFIG_LCD  (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_NOPULL)
 #defineMUX_CONFIG_TSC  (MXS_PAD_3V3 | MXS_PAD_8MA | MXS_PAD_PULLUP)
 #defineMUX_CONFIG_SSP0 (MXS_PAD_3V3 | MXS_PAD_12MA | MXS_PAD_PULLUP)
 #defineMUX_CONFIG_SSP2 (MXS_PAD_3V3 | MXS_PAD_4MA | MXS_PAD_PULLUP)
@@ -68,15 +68,8 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_LCD_D21__LCD_D21 | MUX_CONFIG_LCD,
MX28_PAD_LCD_D22__LCD_D22 | MUX_CONFIG_LCD,
MX28_PAD_LCD_D23__LCD_D23 | MUX_CONFIG_LCD,
-   MX28_PAD_LCD_RD_E__LCD_VSYNC | MUX_CONFIG_LCD,
-   MX28_PAD_LCD_WR_RWN__LCD_HSYNC | MUX_CONFIG_LCD,
-   MX28_PAD_LCD_RS__LCD_DOTCLK | MUX_CONFIG_LCD,
-   MX28_PAD_LCD_CS__LCD_CS | MUX_CONFIG_LCD,
-   MX28_PAD_LCD_VSYNC__LCD_VSYNC | MUX_CONFIG_LCD,
-   MX28_PAD_LCD_HSYNC__LCD_HSYNC | MUX_CONFIG_LCD,
MX28_PAD_LCD_DOTCLK__LCD_DOTCLK | MUX_CONFIG_LCD,
-   MX28_PAD_LCD_ENABLE__GPIO_1_31 | MUX_CONFIG_LCD,
-   MX28_PAD_LCD_RESET__GPIO_3_30 | MUX_CONFIG_LCD,
+   MX28_PAD_LCD_ENABLE__LCD_ENABLE | MUX_CONFIG_LCD,
 
/* UART1 */
MX28_PAD_PWM0__DUART_RX,
-- 
1.7.9

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

[U-Boot] [PATCH 5/7] Renamed mx28_register to mx28_register_32 to prepare for mx28_register_8

[Marek Vasut]

From: Robert Delien 

This patch renames mx28_register to mx28_register_32 in order to
prepare for the introduction of an 8-bit register, mx28_register_8.

Signed-off-by: Robert Delien 
Acked-by: Marek Vasut 
Tested-by: Marek Vasut 
---
 arch/arm/cpu/arm926ejs/mx28/clock.c   |4 +-
 arch/arm/cpu/arm926ejs/mx28/iomux.c   |6 +-
 arch/arm/cpu/arm926ejs/mx28/mx28.c|6 +-
 arch/arm/include/asm/arch-mx28/regs-apbh.h|  254 
 arch/arm/include/asm/arch-mx28/regs-bch.h |   42 ++--
 arch/arm/include/asm/arch-mx28/regs-clkctrl.h |   58 +++---
 arch/arm/include/asm/arch-mx28/regs-common.h  |   12 +-
 arch/arm/include/asm/arch-mx28/regs-gpmi.h|   26 ++--
 arch/arm/include/asm/arch-mx28/regs-i2c.h |   28 ++--
 arch/arm/include/asm/arch-mx28/regs-ocotp.h   |   86 
 arch/arm/include/asm/arch-mx28/regs-pinctrl.h |  168 
 arch/arm/include/asm/arch-mx28/regs-power.h   |   28 ++--
 arch/arm/include/asm/arch-mx28/regs-rtc.h |   28 ++--
 arch/arm/include/asm/arch-mx28/regs-ssp.h |   40 ++--
 arch/arm/include/asm/arch-mx28/regs-timrot.h  |   38 ++--
 arch/arm/include/asm/arch-mx28/regs-usbphy.h  |   20 +-
 arch/arm/include/asm/arch-mx28/sys_proto.h|   10 +-
 drivers/gpio/mxs_gpio.c   |   16 +-
 drivers/usb/host/ehci-mxs.c   |8 +-
 19 files changed, 441 insertions(+), 437 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx28/clock.c 
b/arch/arm/cpu/arm926ejs/mx28/clock.c
index f698506..9d3a018 100644
--- a/arch/arm/cpu/arm926ejs/mx28/clock.c
+++ b/arch/arm/cpu/arm926ejs/mx28/clock.c
@@ -223,7 +223,7 @@ void mx28_set_sspclk(enum mxs_sspclock ssp, uint32_t freq, 
int xtal)
return;
 
clkreg = (uint32_t)(&clkctrl_regs->hw_clkctrl_ssp0) +
-   (ssp * sizeof(struct mx28_register));
+   (ssp * sizeof(struct mx28_register_32));
 
clrbits_le32(clkreg, CLKCTRL_SSP_CLKGATE);
while (readl(clkreg) & CLKCTRL_SSP_CLKGATE)
@@ -272,7 +272,7 @@ static uint32_t mx28_get_sspclk(enum mxs_sspclock ssp)
return XTAL_FREQ_KHZ;
 
clkreg = (uint32_t)(&clkctrl_regs->hw_clkctrl_ssp0) +
-   (ssp * sizeof(struct mx28_register));
+   (ssp * sizeof(struct mx28_register_32));
 
tmp = readl(clkreg) & CLKCTRL_SSP_DIV_MASK;
 
diff --git a/arch/arm/cpu/arm926ejs/mx28/iomux.c 
b/arch/arm/cpu/arm926ejs/mx28/iomux.c
index 9ea411f..12916b6 100644
--- a/arch/arm/cpu/arm926ejs/mx28/iomux.c
+++ b/arch/arm/cpu/arm926ejs/mx28/iomux.c
@@ -43,7 +43,7 @@ int mxs_iomux_setup_pad(iomux_cfg_t pad)
 {
u32 reg, ofs, bp, bm;
void *iomux_base = (void *)MXS_PINCTRL_BASE;
-   struct mx28_register *mxs_reg;
+   struct mx28_register_32 *mxs_reg;
 
/* muxsel */
ofs = 0x100;
@@ -70,7 +70,7 @@ int mxs_iomux_setup_pad(iomux_cfg_t pad)
/* vol */
if (PAD_VOL_VALID(pad)) {
bp = PAD_PIN(pad) % 8 * 4 + 2;
-   mxs_reg = (struct mx28_register *)(iomux_base + ofs);
+   mxs_reg = (struct mx28_register_32 *)(iomux_base + ofs);
if (PAD_VOL(pad))
writel(1 << bp, &mxs_reg->reg_set);
else
@@ -82,7 +82,7 @@ int mxs_iomux_setup_pad(iomux_cfg_t pad)
ofs = PULL_OFFSET;
ofs += PAD_BANK(pad) * 0x10;
bp = PAD_PIN(pad);
-   mxs_reg = (struct mx28_register *)(iomux_base + ofs);
+   mxs_reg = (struct mx28_register_32 *)(iomux_base + ofs);
if (PAD_PULL(pad))
writel(1 << bp, &mxs_reg->reg_set);
else
diff --git a/arch/arm/cpu/arm926ejs/mx28/mx28.c 
b/arch/arm/cpu/arm926ejs/mx28/mx28.c
index b235091..9bfd83b 100644
--- a/arch/arm/cpu/arm926ejs/mx28/mx28.c
+++ b/arch/arm/cpu/arm926ejs/mx28/mx28.c
@@ -63,7 +63,7 @@ void reset_cpu(ulong ignored)
;
 }
 
-int mx28_wait_mask_set(struct mx28_register *reg, uint32_t mask, int timeout)
+int mx28_wait_mask_set(struct mx28_register_32 *reg, uint32_t mask, int 
timeout)
 {
while (--timeout) {
if ((readl(®->reg) & mask) == mask)
@@ -74,7 +74,7 @@ int mx28_wait_mask_set(struct mx28_register *reg, uint32_t 
mask, int timeout)
return !timeout;
 }
 
-int mx28_wait_mask_clr(struct mx28_register *reg, uint32_t mask, int timeout)
+int mx28_wait_mask_clr(struct mx28_register_32 *reg, uint32_t mask, int 
timeout)
 {
while (--timeout) {
if ((readl(®->reg) & mask) == 0)
@@ -85,7 +85,7 @@ int mx28_wait_mask_clr(struct mx28_register *reg, uint32_t 
mask, int timeout)
return !timeout;
 }
 
-int mx28_reset_block(struct mx28_register *reg)
+int mx28_reset_block(struct mx28_register_32 *reg)
 {
/* Clear SFTRST */
writel(MX28_BLOCK_SFTRST, ®->reg_clr);
diff --git a/arch/arm/include/asm/arch-mx28/regs-apbh.h 
b/arch/arm/include/asm/ar

[U-Boot] [PATCH 2/7] M28: Support for the old M28 SoM v1.0

[Marek Vasut]

This prototype version SoM is unused and not available to public.
Support this only for internal debugging purposes.

Signed-off-by: Marek Vasut 
---
 board/denx/m28evk/spl_boot.c |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/board/denx/m28evk/spl_boot.c b/board/denx/m28evk/spl_boot.c
index 91316a7..a04fe18 100644
--- a/board/denx/m28evk/spl_boot.c
+++ b/board/denx/m28evk/spl_boot.c
@@ -72,8 +72,13 @@ const iomux_cfg_t iomux_setup[] = {
MX28_PAD_LCD_ENABLE__LCD_ENABLE | MUX_CONFIG_LCD,
 
/* UART1 */
+#ifdef CONFIG_DENX_M28_V10
+   MX28_PAD_AUART0_CTS__DUART_RX,
+   MX28_PAD_AUART0_RTS__DUART_TX,
+#else
MX28_PAD_PWM0__DUART_RX,
MX28_PAD_PWM1__DUART_TX,
+#endif
MX28_PAD_AUART0_TX__DUART_RTS,
MX28_PAD_AUART0_RX__DUART_CTS,
 
-- 
1.7.9

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

[U-Boot] [PATCH 0/7] Set of various i.MX28 patches

[Marek Vasut]

These patches fix random issues on the i.MX28 series.

Marek Vasut (4):
  M28: Fix LCD PINMUX
  M28: Support for the old M28 SoM v1.0
  i.MX28: Reformat the DRAM memory configuration data
  i.MX28: Enable additional DRAM address bits

Robert Delien (3):
  Renamed mx28_register to mx28_register_32 to prepare for
mx28_register_8
  Introducing 8-bit wide register, mx28_register_8
  Fix erroneous 32-bit access to hw_clkctrl_frac0 and hw_clkctrl_frac1
registers

 arch/arm/cpu/arm926ejs/mx28/clock.c   |   74 +++-
 arch/arm/cpu/arm926ejs/mx28/iomux.c   |6 +-
 arch/arm/cpu/arm926ejs/mx28/mx28.c|6 +-
 arch/arm/cpu/arm926ejs/mx28/spl_mem_init.c|  112 ++-
 arch/arm/include/asm/arch-mx28/regs-apbh.h|  254 
 arch/arm/include/asm/arch-mx28/regs-bch.h |   42 ++--
 arch/arm/include/asm/arch-mx28/regs-clkctrl.h |   98 --
 arch/arm/include/asm/arch-mx28/regs-common.h  |   28 ++-
 arch/arm/include/asm/arch-mx28/regs-gpmi.h|   26 ++--
 arch/arm/include/asm/arch-mx28/regs-i2c.h |   28 ++--
 arch/arm/include/asm/arch-mx28/regs-ocotp.h   |   86 
 arch/arm/include/asm/arch-mx28/regs-pinctrl.h |  168 
 arch/arm/include/asm/arch-mx28/regs-power.h   |   28 ++--
 arch/arm/include/asm/arch-mx28/regs-rtc.h |   28 ++--
 arch/arm/include/asm/arch-mx28/regs-ssp.h |   40 ++--
 arch/arm/include/asm/arch-mx28/regs-timrot.h  |   38 ++--
 arch/arm/include/asm/arch-mx28/regs-usbphy.h  |   20 +-
 arch/arm/include/asm/arch-mx28/sys_proto.h|   10 +-
 board/denx/m28evk/spl_boot.c  |   16 +-
 drivers/gpio/mxs_gpio.c   |   16 +-
 drivers/usb/host/ehci-mxs.c   |8 +-
 21 files changed, 562 insertions(+), 570 deletions(-)

-- 
1.7.9

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

Re: [U-Boot] [PATCH 00/14] Nokia RX-51 support

[Marek Vasut]

> On Tuesday 24 January 2012 15:27:57 Pali Rohár wrote:
> > This patch series add support for new board Nokia RX-51 (aka N900).
> > Last two patches adding on screen bootmenu support.
> > 
> > This series supersedes the last sent version.
> 
> Hi, what is state of this patch series? From our discussion is only
> problematic bootmenu part, but other could be OK.
> 
> So what is needed for including this patches (without bootmenu support) to
> uboot master?

You should probably split the patches into smaller series and resubmit 
individually.

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

[U-Boot] [PATCH] mx6q: mx6qsabrelite: setup_spi() should be called in board_init to allow use for environment

[Eric Nelson]

Signed-off-by: Eric Nelson 
---
 board/freescale/mx6qsabrelite/mx6qsabrelite.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/board/freescale/mx6qsabrelite/mx6qsabrelite.c 
b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
index db1bea9..7fe2dc9 100644
--- a/board/freescale/mx6qsabrelite/mx6qsabrelite.c
+++ b/board/freescale/mx6qsabrelite/mx6qsabrelite.c
@@ -259,10 +259,6 @@ int board_eth_init(bd_t *bis)
if (ret)
printf("FEC MXC: %s:failed\n", __func__);
 
-#ifdef CONFIG_MXC_SPI
-   setup_spi();
-#endif
-
return 0;
 }
 
@@ -278,6 +274,10 @@ int board_init(void)
/* address of boot parameters */
gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
 
+#ifdef CONFIG_MXC_SPI
+   setup_spi();
+#endif
+
return 0;
 }
 
-- 
1.7.9

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

Re: [U-Boot] Pull request - microblaze

[Wolfgang Denk]

Dear Michal Simek,

In message <4f46224c.8010...@monstr.eu> you wrote:
> Dear Wolfgang,
> 
> please pull the following changes.
> Especially the first patch is important because it fixes build error.
> 
> Thanks,
> Michal
> 
> 
> The following changes since commit 2acca35ce4604dcef933f07d90aa9c9c930e1049:
>Wolfgang Denk (1):
>  Merge branch 'master' of git://git.denx.de/u-boot-mmc
> 
> are available in the git repository at:
> 
>git://www.denx.de/git/u-boot-microblaze.git master
> 
> Stephan Linz (3):
>microblaze: fix build failure due to undefined reference to `get_ticks'
>microblaze: avoid interrupt race conditions
>microblaze: Enable TFTP put command
> 
>   arch/microblaze/cpu/interrupts.c |4 ++--
>   arch/microblaze/cpu/timer.c  |   18 ++
>   include/configs/microblaze-generic.h |1 +
>   3 files changed, 21 insertions(+), 2 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"...all the  good  computer  designs  are  bootlegged;  the  formally
planned  products,  if  they  are built at all, are dogs!" - David E.
Lundstrom, "A Few Good Men From Univac", MIT Press, 1987
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [i2c] Pull request

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4f433dad.6050...@denx.de> you wrote:
> Hello Wolfgang,
> 
> The following changes since commit 2acca35ce4604dcef933f07d90aa9c9c930e1049:
> 
>   Merge branch 'master' of git://git.denx.de/u-boot-mmc (2012-02-17 23:54:46 
> +0100)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-i2c.git master
> 
> Tom Rini (2):
>   Revert "ARM: AM33XX: Add AM33XX I2C driver support"
>   Revert "ARM: I2C: I2C Multi byte address support"
> 
>  drivers/i2c/omap24xx_i2c.c |  475 
> 
>  drivers/i2c/omap24xx_i2c.h |2 -
>  2 files changed, 174 insertions(+), 303 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You can fool some of the people all of the time, and You can fool all
of the people some of the time, but You can't fool mom.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v4 8/8] sandbox: Add basic command line parsing

[Mike Frysinger]

On Wednesday 15 February 2012 18:51:18 Simon Glass wrote:
> --- a/arch/sandbox/cpu/os.c
> +++ b/arch/sandbox/cpu/os.c
> 
> +#include 
> 
> +void os_usage(int err)
> +{
> + if (err < 0)
> + fprintf(stderr, "Try `--help' for more information.\n");
> + fprintf(err < 0 ? stderr : stdout, "u-boot, "
> + "a command line test interface to U-Boot\n\n"
> + "usage:\tu-boot [-ch]\n"
> + "Options:\n"
> + "\t-h\tDisplay help\n"
> + "\t-c \tExecute U-Boot command\n");

this actually doesn't work.  we're using the stdio from u-boot itself, so we 
can't use stdio.h from glibc.  if it works for you, i'm pretty sure it's 
purely an accident (perhaps related to the fortification change i just posted).
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] sandbox: disable fortification

[Mike Frysinger]

Since we provide all our own library calls, the fortification from
glibc just gets in our way (which some distros enable by default).

Signed-off-by: Mike Frysinger 
---
 arch/sandbox/config.mk |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/sandbox/config.mk b/arch/sandbox/config.mk
index 2ec1bb7..02ce4a4 100644
--- a/arch/sandbox/config.mk
+++ b/arch/sandbox/config.mk
@@ -17,5 +17,5 @@
 # Foundation, Inc., 59 Temple Place, Suite 330, Boston,
 # MA 02111-1307 USA
 
-PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__
+PLATFORM_CPPFLAGS += -DCONFIG_SANDBOX -D__SANDBOX__ -U_FORTIFY_SOURCE
 PLATFORM_LIBS += -lrt
-- 
1.7.8.4

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

Re: [U-Boot] [PATCH 00/14] Nokia RX-51 support

[Pali Rohár]

On Tuesday 24 January 2012 15:27:57 Pali Rohár wrote:
> This patch series add support for new board Nokia RX-51 (aka N900).
> Last two patches adding on screen bootmenu support.
>
> This series supersedes the last sent version.
>

Hi, what is state of this patch series? From our discussion is only
problematic bootmenu part, but other could be OK.

So what is needed for including this patches (without bootmenu support) to
uboot master?

--
Pali Rohár
pali.ro...@gmail.com

signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] sandbox: tweak style in linker script

[Mike Frysinger]

We use tabs for indentation, not spaces.

Signed-off-by: Mike Frysinger 
---
 arch/sandbox/cpu/u-boot.lds |   10 +-
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/sandbox/cpu/u-boot.lds b/arch/sandbox/cpu/u-boot.lds
index 2d2e50f..0c56aa7 100644
--- a/arch/sandbox/cpu/u-boot.lds
+++ b/arch/sandbox/cpu/u-boot.lds
@@ -1,5 +1,5 @@
 /*
- * Copyright (c) 2011 The Chromium OS Authors.
+ * Copyright (c) 2011-2012 The Chromium OS Authors.
  * Use of this source code is governed by a BSD-style license that can be
  * found in the LICENSE file.
  *
@@ -24,11 +24,11 @@
 
 SECTIONS
 {
-  __u_boot_cmd_start = .;
-  .u_boot_cmd : { *(.u_boot_cmd) }
-  __u_boot_cmd_end = .;
-  __bss_start = .;
+   __u_boot_cmd_start = .;
+   _u_boot_cmd : { *(.u_boot_cmd) }
+   __u_boot_cmd_end = .;
 
+   __bss_start = .;
 }
 
 INSERT BEFORE .data;
-- 
1.7.8.4

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

Re: [U-Boot] [PATCH v4 09/13] hawkboard: Modify to work with generic relocation

[Simon Glass]

Hi,

On Thu, Feb 23, 2012 at 7:11 AM, Sughosh Ganu  wrote:
>
> On Thu, Feb 23, 2012 at 2:13 PM, Sughosh Ganu 
> wrote:
>>
>> hi Simon,
>> On Mon Feb 20, 2012 at 05:32:51PM -0800, Simon Glass wrote:
>> > Add use of common/ and lib/ libraries for the SPL stage, and
>> > add the new link symbol required for generic relocation.
>> >
>> > Signed-off-by: Simon Glass 
>> > ---
>> > Changes in v4:
>> > - Split out hawkboard changes into new patch
>> >
>> >  board/davinci/da8xxevm/u-boot-spl-hawk.lds |    1 +
>> >  include/configs/hawkboard.h                |    2 ++
>> >  2 files changed, 3 insertions(+), 0 deletions(-)
>>
>
> 
>
>>
>>  Btw, i had quite a substantial increase in the spl image size with
>>  these additions with a 4.5 based toolchain(will provide exact
>>  toolchain details and size difference tonight). Building with a 4.6
>>  based toolchain got the size increase down by quite a bit. Although i
>>  don't have any size restrictions with spl on my board, this could be
>>  a problem on boards which have these restrictions with toolchains
>>  before 4.6.
>
>
> gcc(arm-none-linux-gnueabi) -- 4.5.2
> binutils -- 2.20
>
> spl size without this patch
>    text       data        bss        dec        hex    filename
>    5208        620        464       6292       1894    spl/u-boot-spl
>
> spl size with this patch
>    text       data        bss        dec        hex    filename
>    8897        620        476       9993       2709    spl/u-boot-spl
>
>
> gcc(arm-none-eabi) -- 4.6.2
> binutils -- 2.21
>
> spl size without this patch
>    text       data        bss        dec        hex    filename
>    4692        620        464 5776      1690    spl/u-boot-spl
>
> spl size with this patch
>    text       data        bss        dec        hex    filename
>    4812        620      476   5908      1714    spl/u-boot-spl
>
> -sughosh

Thanks for looking at this.

I'm not sure why it doesn't happen with your 4.6.2 compiler. With my
4.6.0 I do see the size increase.

It seems to be due to vsprintf:

   textdata bss dec hex filename
   4011   0  224033 fc1 spl/lib/vsprintf.o

I wonder if it is a call to printf that the older compiler is failing
to optimize out?

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

Re: [U-Boot] [PATCH v4 07/13] davinci: Use correct #ifdef around gdata/bdata

[Simon Glass]

Hi Sughosh,

On Thu, Feb 23, 2012 at 9:25 AM, Sughosh Ganu  wrote:
> hi Simon,
>
> On Mon Feb 20, 2012 at 05:32:49PM -0800, Simon Glass wrote:
>> This fixes the following warnings in an SPL build when libcommon is
>> in use:
>>
>> spl.c:37: warning: 'gdata' defined but not used
>> spl.c:38: warning: 'bdata' defined but not used
>>
>> Signed-off-by: Simon Glass 
>> ---
>> Changes in v4:
>> - Add new patch to fix davinci build warnings
>>
>>  arch/arm/cpu/arm926ejs/davinci/spl.c |    2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/arch/arm/cpu/arm926ejs/davinci/spl.c 
>> b/arch/arm/cpu/arm926ejs/davinci/spl.c
>> index b1eff26..2861907 100644
>> --- a/arch/arm/cpu/arm926ejs/davinci/spl.c
>> +++ b/arch/arm/cpu/arm926ejs/davinci/spl.c
>> @@ -32,10 +32,12 @@
>>
>>  #ifdef CONFIG_SPL_LIBCOMMON_SUPPORT
>>
>> +#ifdef CONFIG_SPL_SPI_LOAD
>>  DECLARE_GLOBAL_DATA_PTR;
>>  /* Define global data structure pointer to it*/
>>  static gd_t gdata __attribute__ ((section(".data")));
>>  static bd_t bdata __attribute__ ((section(".data")));
>> +#endif
>
>  Can you specify which boards you get this warning for. With your
>  patch to add libcommon to hawkboard's spl image, this is now also
>  needed for hawkboard which uses CONFIG_SPL_NAND_LOAD.

Perhaps it is any davinci board, with SPI? I don't have any of these -
I was just fixing what I thought was a minor #ifdef bug in the code.

Regards,
Simon

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

[U-Boot] [PATCH] [OMAP3] Pass timings structure pointer to board_get_mem_timings()

[Peter Barada]

Instead of passing individual registers by value to board_get_mem_timings,
pass a board_mem_timings structure pointer for the board files to fill in.
Pass same structure pointer to write_sdrc_timings.  This saves about
90 bytes of space in SPL.

Signed-off-by: Peter Barada 
---
 arch/arm/cpu/armv7/omap3/sdrc.c |   36 --
 arch/arm/include/asm/arch-omap3/sys_proto.h |   12 +-
 board/corscience/tricorder/tricorder.c  |   13 +++
 board/overo/overo.c |   37 +--
 board/ti/beagle/beagle.c|   53 +--
 board/ti/evm/evm.c  |   19 +-
 board/timll/devkit8000/devkit8000.c |   13 +++
 7 files changed, 91 insertions(+), 92 deletions(-)

diff --git a/arch/arm/cpu/armv7/omap3/sdrc.c b/arch/arm/cpu/armv7/omap3/sdrc.c
index 91f42c0..4d8a57a 100644
--- a/arch/arm/cpu/armv7/omap3/sdrc.c
+++ b/arch/arm/cpu/armv7/omap3/sdrc.c
@@ -113,18 +113,18 @@ u32 get_sdr_cs_offset(u32 cs)
  *  - Test CS to make sure it's OK for use
  */
 static void write_sdrc_timings(u32 cs, struct sdrc_actim *sdrc_actim_base,
-   u32 mcfg, u32 ctrla, u32 ctrlb, u32 rfr_ctrl, u32 mr)
+   struct board_mem_timings *timings)
 {
/* Setup timings we got from the board. */
-   writel(mcfg, &sdrc_base->cs[cs].mcfg);
-   writel(ctrla, &sdrc_actim_base->ctrla);
-   writel(ctrlb, &sdrc_actim_base->ctrlb);
-   writel(rfr_ctrl, &sdrc_base->cs[cs].rfr_ctrl);
+   writel(timings->mcfg, &sdrc_base->cs[cs].mcfg);
+   writel(timings->ctrla, &sdrc_actim_base->ctrla);
+   writel(timings->ctrlb, &sdrc_actim_base->ctrlb);
+   writel(timings->rfr_ctrl, &sdrc_base->cs[cs].rfr_ctrl);
writel(CMD_NOP, &sdrc_base->cs[cs].manual);
writel(CMD_PRECHARGE, &sdrc_base->cs[cs].manual);
writel(CMD_AUTOREFRESH, &sdrc_base->cs[cs].manual);
writel(CMD_AUTOREFRESH, &sdrc_base->cs[cs].manual);
-   writel(mr, &sdrc_base->cs[cs].mr);
+   writel(timings->mr, &sdrc_base->cs[cs].mr);
 
/*
 * Test ram in this bank
@@ -143,7 +143,7 @@ static void write_sdrc_timings(u32 cs, struct sdrc_actim 
*sdrc_actim_base,
 void do_sdrc_init(u32 cs, u32 early)
 {
struct sdrc_actim *sdrc_actim_base0, *sdrc_actim_base1;
-   u32 mcfg, ctrla, ctrlb, rfr_ctrl, mr;
+   struct board_mem_timings timings;
 
sdrc_actim_base0 = (struct sdrc_actim *)SDRC_ACTIM_CTRL0_BASE;
sdrc_actim_base1 = (struct sdrc_actim *)SDRC_ACTIM_CTRL1_BASE;
@@ -158,7 +158,7 @@ void do_sdrc_init(u32 cs, u32 early)
 * setup CS1.
 */
 #ifdef CONFIG_SPL_BUILD
-   get_board_mem_timings(&mcfg, &ctrla, &ctrlb, &rfr_ctrl, &mr);
+   get_board_mem_timings(&timings);
 #endif
if (early) {
/* reset sdrc controller */
@@ -177,11 +177,9 @@ void do_sdrc_init(u32 cs, u32 early)
writel(ENADLL | DLLPHASE_90, &sdrc_base->dlla_ctrl);
sdelay(0x2);
 #ifdef CONFIG_SPL_BUILD
-   write_sdrc_timings(CS0, sdrc_actim_base0, mcfg, ctrla, ctrlb,
-   rfr_ctrl, mr);
+   write_sdrc_timings(CS0, sdrc_actim_base0, &timings);
make_cs1_contiguous();
-   write_sdrc_timings(CS0, sdrc_actim_base1, mcfg, ctrla, ctrlb,
-   rfr_ctrl, mr);
+   write_sdrc_timings(CS0, sdrc_actim_base1, &timings);
 #endif
 
}
@@ -193,14 +191,12 @@ void do_sdrc_init(u32 cs, u32 early)
 * so we may be asked now to setup CS1.
 */
if (cs == CS1) {
-   mcfg = readl(&sdrc_base->cs[CS0].mcfg),
-   rfr_ctrl = readl(&sdrc_base->cs[CS0].rfr_ctrl);
-   ctrla = readl(&sdrc_actim_base0->ctrla),
-   ctrlb = readl(&sdrc_actim_base0->ctrlb);
-   mr = readl(&sdrc_base->cs[CS0].mr);
-   write_sdrc_timings(cs, sdrc_actim_base1, mcfg, ctrla, ctrlb,
-   rfr_ctrl, mr);
-
+   timings.mcfg = readl(&sdrc_base->cs[CS0].mcfg);
+   timings.rfr_ctrl = readl(&sdrc_base->cs[CS0].rfr_ctrl);
+   timings.ctrla = readl(&sdrc_actim_base0->ctrla),
+   timings.ctrlb = readl(&sdrc_actim_base0->ctrlb);
+   timings.mr = readl(&sdrc_base->cs[CS0].mr);
+   write_sdrc_timings(cs, sdrc_actim_base1, &timings);
}
 }
 
diff --git a/arch/arm/include/asm/arch-omap3/sys_proto.h 
b/arch/arm/include/asm/arch-omap3/sys_proto.h
index 2a89e56..723e445 100644
--- a/arch/arm/include/asm/arch-omap3/sys_proto.h
+++ b/arch/arm/include/asm/arch-omap3/sys_proto.h
@@ -32,6 +32,15 @@ struct emu_hal_params {
u32 param1;
 };
 
+/* Board DRAM timing values */
+struct board_mem_timings {
+   u32 mcfg;
+   u32 ctrla;
+   u32 ctrlb;
+   u32 rfr_ctrl;
+   u32 mr;
+};
+
 void prcm_init(void);
 void per_clocks_enable(void);
 void ehci_cloc

Re: [U-Boot] [RFC} [PATCH] Feature removal due to lack of custodians

[Simon Glass]

Hi Wolfgang,

On Sat, Feb 25, 2012 at 2:10 PM, Wolfgang Denk  wrote:
> Despite several calls nobody volunteered to help out.
>
> Signed-off-by: Wolfgang Denk 
> ---
>  doc/feature-removal-schedule.txt |   14 ++
>  1 files changed, 14 insertions(+), 0 deletions(-)
>
> diff --git a/doc/feature-removal-schedule.txt 
> b/doc/feature-removal-schedule.txt
> index e04ba2d..f0b828e 100644
> --- a/doc/feature-removal-schedule.txt
> +++ b/doc/feature-removal-schedule.txt
> @@ -7,6 +7,20 @@ file.
>
>  ---
>
> +What:  USB Support
> +When:  v2012.06
> +Why:   Lack of a custodian, and lack of time and/or sponsors.
> +Who:   Wolfgang Denk 
> +
> +---
> +
> +What:  Network Support
> +When:  v2012.09
> +Why:   Lack of a custodian, and lack of time and/or sponsors.
> +Who:   Wolfgang Denk 

I might be able to help out with the network side. I am unsure of the
qualifications needed to be a custodian though.

Regards,
Simon

> +
> +---
> +
>  What:  Users of the legacy miiphy_* code
>  When:  undetermined
>
> --
> 1.7.7.6
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot