Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Andy Pont]

Marek wrote loads of stuff then wrote...

> But then, how shall we go about it? Any python gurus around?

I wouldn't class myself as a "guru" as that should be a title that is
bestowed on you by others but I know a fair amount of Python and might be
able to have a go at implementing some of this stuff once we know exactly
what we are after.

Andy.

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

Re: [U-Boot] [PATCH 0/7] dfu:usb: Composite USB download gadget with DFU function

[Lukasz Majewski]

Hi Marek,

> Dear Lukasz Majewski,
> 
> > Those patches add support for composite USB download gadget.
> > This gadget (at least for now) is equipped with DFU download
> > function.
> > 
> > A separate DFU back-end and front-end have been added.
> > Back-end is placed at ./drivers/dfu directory. The front-end is
> > implemented as USB function.
> > 
> > The back-end is written in a generic manner with storage device
> > specific code separated (eMMC).
> > 
> > DFU specification can be found at:
> > http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade_sta
> > ndard
> 
> [...]
> 
> will we see a next version of this series please? 

I've just come back from my holiday. I will continue work on this.

> Or where did the
> discussion get?

As fair as I remember, the discussion ended up with a conclusion, that
new layer of abstraction (in a form of function call) is needed.

I will rehack the cmd_mmc.c to include new functions in it. It will be
a prepatch for the DFU.


-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [PATCH 2/2] mpc85xx: Initial SP alignment is wrong.

[Joakim Tjernlund]

>
>
> Scott Wood  wrote on 2012/07/20 23:11:33:
> >
> > On 07/20/2012 04:20 AM, Joakim Tjernlund wrote:
> > > PowerPC mandates SP to be 16 bytes aligned.
> > > Furthermore, a stack frame is added, pointing to the reset vector
> > > which is just get in the way when gdb is walking the stack because
> > > the reset vector may not accessible depending on emulator settings.
> > > Also use a temp register so gdb doesn't pick up intermediate values.
> > >
> > > Signed-off-by: Joakim Tjernlund 
> > > ---
> > >  arch/powerpc/cpu/mpc85xx/start.S |   16 +---
> > >  1 files changed, 5 insertions(+), 11 deletions(-)
> > >
> > > diff --git arch/powerpc/cpu/mpc85xx/start.S 
> > > arch/powerpc/cpu/mpc85xx/start.S
> > > index 8d66cf1..8c75af9 100644
> > > --- arch/powerpc/cpu/mpc85xx/start.S
> > > +++ arch/powerpc/cpu/mpc85xx/start.S
> > > @@ -848,18 +848,12 @@ version_string:
> > > .globl   _start_cont
> > >  _start_cont:
> > > /* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/
> > > -   lis   r1,CONFIG_SYS_INIT_RAM_ADDR@h
> > > -   ori   r1,r1,CONFIG_SYS_INIT_SP_OFFSET@l
> > > -
> > > +   lis   r2,(CONFIG_SYS_INIT_RAM_ADDR)@h
> > > +   ori   r2,r2,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
> >
> > Please don't use r2 as a general purpose register -- even if it's early
> > enough that we haven't started using it for its fixed purpose yet.
>
> I guess that would be a tiny improvement, but it is nothing compared
> with the r1 abuse in this file :)
>
> >
> > > +   stw   r0,-4(r2)   /* Store a NULL LR */
> > > +   stw   r0,0(r2)   /* Store a NULL Back Chain */
> > > +   mr   r1,r2  /* Transfer to SP(r1) */
> >
> > Why are you storing anything below the stack pointer?  LR goes above the
> > backchain, not below -- and it's not valid anyway for the current stack
> > frame.  If you want to have a terminating stack frame with a NULL LR,
> > you need to create a second stack frame, like the code currently does.
>
> Right, it should be +4 where the NULL LR should be. As you said, it doesn't 
> matter
> because it is not valid for this stack frame and could be left out.
>
> I do not want to create a frame as the current code does, it
> might create an memory access to 0xfffc which I don't want.
> How about this then:
>
>lis   r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
>ori   r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
>li   r0,0
>stw   r0,0(r3)   /* Terminate Back Chain */
>stw   r0,+4(r3)   /* NULL LR, to be nice. */
>mr   r1,r3  /* Transfer to SP(r1) */
>
> or if that reset address is wanted:
>lis   r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
>ori   r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
>li   r0,0
>stw   r0,0(r3)   /* Terminate Back Chain */
>stw   r0,+4(r3)   /* NULL LR, to be nice. */
>stwu   r3,-16(r3)   /* save back chain and move SP */
>lis   r0,RESET_VECTOR@h
>ori   r0,RESET_VECTOR@l
>stw   r0,+20(r3)   /* save return address */
>mr   r1,r3  /* Transfer to SP(r1) */
>
> I would have to test with the emulator if both are OK or if there will
> be an access to RESET_VECTOR(I don't have that connected ATM).

So I got the BDI connected and did som experiments.
Having RESET_VECTOR in the initial stack chain makes gdb print this:
(gdb) bt
#0  cpu_init_early_f () at cpu_init_early.c:116
#1  0xeff800a4 in _start_cont () at start.S:877
Backtrace stopped: frame did not save the PC
(gdb)

So I don't think there is any benefit trying to squeeze RESET_VECTOR into the 
stack chain.

 Jocke

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

Re: [U-Boot] [PATCH] integrator: break out common config

[Linus Walleij]

On Wed, Jun 13, 2012 at 3:37 PM, Linus Walleij  wrote:
> On Tue, May 22, 2012 at 10:53 PM, Linus Walleij
>  wrote:
>
>> The configuration that is common for all Integrator boards may
>> just as well be stored in a common include file as per pattern
>> from other boards. This eases maintenance quite a bit.
>>
>> Signed-off-by: Linus Walleij 
>
> Albert, is this patch OK?
>
> It's available here in patchwork:
> http://patchwork.ozlabs.org/patch/160740/

Ping on this, tell me if I'm doing something wrong,
it's been floating for 2 months now...

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

Re: [U-Boot] [PATCH 0/7] dfu:usb: Composite USB download gadget with DFU function

[Marek Vasut]

Dear Lukasz Majewski,

> Hi Marek,
> 
> > Dear Lukasz Majewski,
> > 
> > > Those patches add support for composite USB download gadget.
> > > This gadget (at least for now) is equipped with DFU download
> > > function.
> > > 
> > > A separate DFU back-end and front-end have been added.
> > > Back-end is placed at ./drivers/dfu directory. The front-end is
> > > implemented as USB function.
> > > 
> > > The back-end is written in a generic manner with storage device
> > > specific code separated (eMMC).
> > > 
> > > DFU specification can be found at:
> > > http://wiki.openmoko.org/wiki/USB_DFU_-_The_USB_Device_Firmware_Upgrade
> > > _sta ndard
> > 
> > [...]
> > 
> > will we see a next version of this series please?
> 
> I've just come back from my holiday. I will continue work on this.
> 
> > Or where did the
> > discussion get?
> 
> As fair as I remember, the discussion ended up with a conclusion, that
> new layer of abstraction (in a form of function call) is needed.
> 
> I will rehack the cmd_mmc.c to include new functions in it. It will be
> a prepatch for the DFU.

Thanks a lot! I didn't intend to torture you, really ... I just wanted this to 
be done properly.

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

Re: [U-Boot] Uboot and initramfs

[Frank Agius]

On 7/15/2012 12:19 PM, Wojtek wrote:

Hi,

I'm struggling with the topic for long two days and I want to ask for help.

I have a DNS-320 system with u-boot. I compiled kernel and it works
well, but I need initramfs. I prepared contents on this system (ARM) (no
need to cross-compile), then did:

find . -print0 | cpio --null -ov --format=newc | gzip -9 > initramfs
mkimage -A arm -O linux -T ramdisk -C gzip -n "Some name" -d initramfs
initramfs.kwb

flash_eraseall /dev/mtd2
nandwrite -p /dev/mtd2 ./initramfs.kwb

reboot

Marvell_DNS320>> nand read.e 0xa0 0x10 0x20

NAND read: device 0 offset 0x10, size 0x20 load addr   =a0

  2097152 bytes read: OK
Marvell_DNS320>> nand read.e 0xf0 0x60 0x50

NAND read: device 0 offset 0x60, size 0x50 load addr   =f0

  5242880 bytes read: OK
Marvell_DNS320>> bootm 0xa0 0xf0
## Booting image at 00a0 ...
Image Name:   Linux-3.4.4
Created:  2012-07-08  11:45:53 UTC
Image Type:   ARM Linux Kernel Image (uncompressed)
Data Size:2039456 Bytes =  1.9 MB
Load Address: 8000
Entry Point:  8000
Verifying Checksum ... OK
OK
## Loading Ramdisk Image at 0f0 ...
Image Name:   Initramfs 3.4.4
Created:  2012-07-15  16:08:35 UTC
Image Type:   ARM Linux RAMDisk Image (gzip compressed)
Data Size:4816677 Bytes =  4.6 MB
Load Address: 
Entry Point:  
Verifying Checksum ... OK

Starting kernel ...

And here it hangs.


If I skip passing initramfs system boots properly.
What is wrong?

Cheers,
Wojtek


In your mkimage command, try changing "-C gzip" to "-C none".

frank

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

Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed

[Stefan Herbrechtsmeier]

Am 20.07.2012 17:35, schrieb Benoît Thébaudeau:

On Friday 20 July 2012 17:15:13 Stefan Herbrechtsmeier wrote:

Am 20.07.2012 17:03, schrieb Benoît Thébaudeau:

On Friday 20 July 2012 16:51:33 Stefan Herbrechtsmeier wrote:

Am 20.07.2012 15:56, schrieb Benoît Thébaudeau:

Dear Marek Vasut,

On Friday 20 July 2012 15:44:01 Marek Vasut wrote:

On Friday 20 July 2012 13:37:37 Stefan Herbrechtsmeier wrote:

Am 20.07.2012 13:26, schrieb Benoît Thébaudeau:

+   int xfr_bytes = min(left_length,
+   (QT_BUFFER_CNT * 4096 -
+((uint32_t)buf_ptr & 4095)) &
+   ~4095);

Why you align the length to 4096?

It's to guarantee that each transfer length is a multiple of
the
max packet
length. Otherwise, early short packets are issued, which breaks
the
transfer and results in time-out error messages.

Early short packets ? What do you mean?

During a USB transfer, all packets must have a length of max
packet
length for
the pipe/endpoint, except the final one that can be a short
packet.
Without the
alignment I make for xfr_bytes, short packets can occur within a
transfer,
because the hardware starts a new packet for each new queued qTD
it
handles.

But if I am right, the max packet length is 512 for bulk and 1024
for
Interrupt transfer.

There are indeed different max packet lengths for different
transfer types, but
it does not matter since the chosen alignment guarantees a multiple
of all these
possible max packet lengths.

But thereby you limit the transfer to 4 qT buffers for unaligned
transfers.

Not exactly. The 5 qt_buffers are used for page-unaligned buffers, but that
results in only 4 full pages of unaligned data, requiring 5 aligned pages.

Sorry I mean 4 full pages of unaligned data.


For page-aligned buffers, the 5 qt_buffers result in 5 full pages of aligned
data.

Sure.


The unaligned case could be a little bit improved to always use as many packets
as possible per qTD, but that would over-complicate things for a very negligible
speed and memory gain.
In my use case (fragmented file on usb storage)  the gain would be 
nearly 20%. The reason is that the data are block aligned (512) and 
could be aligned to 4096 with the first transfer (5 qt_buffers).


My suggestion would be to truncate the xfr_bytes with the max 
wMaxPacketSize (1024) and for the qtd_count use:


if ((uint32_t)buffer & 1023)/* wMaxPacketSize unaligned */
qtd_count += DIV_ROUND_UP(((uint32_t)buffer & 4095) +
length, (QT_BUFFER_CNT - 1) * 4096);
else/* wMaxPacketSize aligned */
qtd_count += DIV_ROUND_UP(((uint32_t)buffer & 4095) +
length, QT_BUFFER_CNT * 4096);

This allows 50% of unaligned block data (512) to be transferred with min 
qTDs.


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

Re: [U-Boot] Sparc build warnings

[Mike Frysinger]

On Sunday 22 July 2012 17:29:49 Peter Tyser wrote:
> Most the the warnings look pretty trivial to fix, so I could gin
> something up, but I don't have a Sparc toolchain to actually test any
> modifications.

http://dev.gentoo.org/~vapier/u-boot/sparc.tar.xz
-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 1/2] common.h: Introduce DEFINE_CACHE_ALIGN_BUFFER

[Tom Rini]

On Sat, Jul 21, 2012 at 01:22:40PM -0400, Mike Frysinger wrote:
> On Friday 20 July 2012 17:50:33 Tom Rini wrote:
> > On 07/20/2012 02:47 PM, Mike Frysinger wrote:
> > > On Friday 20 July 2012 07:31:47 Marek Vasut wrote:
> > >> Dear Mike Frysinger,
> > >> 
> > >>> On Saturday 07 July 2012 23:08:14 Marek Vasut wrote:
> >  +/* DEFINE_CACHE_ALIGN_BUFFER() is similar to
> >  ALLOC_CACHE_ALIGN_BUFFER, but it's purpose is to allow
> >  allocating aligned buffers outside of function scope.  Usage
> >  of this macro shall be avoided or used with extreme care! */
> >  +#define DEFINE_CACHE_ALIGN_BUFFER(type, name, size) + static
> >  char __##name[roundup(size * sizeof(type),
> >  ARCH_DMA_MINALIGN)] +  __aligned(ARCH_DMA_MINALIGN); +
> >  static type *name = (type *)__##name;
> > >>> 
> > >>> how is this any different from doing: static __u8 foo[1234]
> > >>> __aligned(ARCH_DMA_MINALIGN);
> > >> 
> > >> Does __aligned() align both start of the buffer downwards and end
> > >> of it upwards ?
> > > 
> > > it guarantees the start is aligned.  i don't believe it does any
> > > tail padding.
> > > 
> > > that said, you've added just 1 consumer, but it uses in function
> > > scope, so i don't see why you had to define a new helper in the
> > > first place.  the existing one would work fine shouldn't it ?
> > 
> > The rough outline of the problems are:
> > - We need to have buffers that are multiple of cache size, for clearing.
> > - Today we know ehci-hcd had a problem.  We also know other drivers /
> > layers have problems, but they aren't as readily breakable.
> > 
> > That's why we put the macro in  rather than a USB header.
> 
> that wasn't the question.  no one in the tree needs the new macro at all, 
> regardless of what header it lives in.  i guess the answer is that some code 
> in the future (which hasn't been merged) might use it.

Er, between drivers/usb/host/ehci-hcd.c and drivers/usb/eth/smsc95xx.c
the three new macros are used today.

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

Re: [U-Boot] [PATCH 1/7] dfu:usb: Support for g_dnl composite download gadget.

[Lukasz Majewski]

Dear Mike Frysinger,

Thank you for thorough review.

> On Tuesday 03 July 2012 05:38:05 Lukasz Majewski wrote:
> > --- /dev/null
> > +++ b/drivers/usb/gadget/g_dnl.c
> >
> > +static const char shortname[] = "usb_dnl_";
> 
> shortname -> gadget_name_prefix

This might be only matter of taste, but in my opinion this name is more
readable.

> 
> > +static void g_dnl_suspend(struct usb_composite_dev *cdev)
> > +{
> > +   if (cdev->gadget->speed == USB_SPEED_UNKNOWN)
> > +   return;
> > +
> > +   debug("suspend\n");
> > +}
> > +
> > +static void g_dnl_resume(struct usb_composite_dev *cdev)
> > +{
> > +   debug("resume\n");
> > +}
> 
> do suspend/resume funcs make any sense in u-boot ?

You have reviewed the v1 of this patch series. Marek Vasut has already
pointed out this problem and it has been resoled with v2.

> 
> > +int g_dnl_init(char *s)
> 
> const char

Ok.
> 
> > +{
> > +   int ret;
> > +   static char str[16];
> > +
> > +   memset(str, '\0', sizeof(str));
> > +
> > +   strncpy(str, shortname, sizeof(shortname));
> 
> no need for the memset. 
The gadget can be called from many separate commands (e.g. command
"dfu" and command "ums") and those commands can be executed without
power cycle. Thereof I need to be sure, that str is not polluted by
previous name. 

> this strncpy looks broken -- the 3rd arg is
> for how many bytes are available in the *dest* buffer, not how long
> the source is.
After looking deeply into the source I admit that providing the
upper bound on the dest is more safe. 

> 
> > +   if (!strncmp(s, "dfu", sizeof(s))) {
> 
> sizeof() here is wrong -- that gives you back 4 (the size of a
> pointer) on 32bit systems

... and it works only because the "dfu\0" and "ums\0" is 4 lenght. :/

> 
> > +   strncat(str, s, sizeof(str));
> 
> this is also incorrect.  the length given to strncat is how many
> bytes are left, not the total length.
I cannot agree. sizeof(str) return 16, which is the destination buffer
size.
> 
> since this string parsing logic is all just completely broken, i'd
> suggest replacing it all with:
> 
> {
>   int ret;
>   /* We only allow "dfu" atm, so 3 should be enough */
>   static char name[sizeof(shortname) + 3];
> 
>   if (strcmp(s, "dfu")) {
>   printf("%s: unknown command: %s\n", __func__, s);
>   return -EINVAL;
>   }
> 
>   strcpy(name, shortname);
>   strcat(name, s);
> 

This is a very neat design, but it assumes that there will be only one
function ("dfu" in this case). For this particular function +3
applies, but what if another function (like "usb_storage") will be
defined? 
I'm now working on another function - the USB Mass Storage (named
"ums" ;-) ).

Another issue is omitting the strncmp/strncpy functions and depending on
the: static char name[sizeof(shortname) + 3]; definition to prevent
buffer overflow.

The +3 magic number worries me a bit...

> > +   if (ret) {
> > +   printf("%s: failed!, error:%d ", __func__, ret);
> 
> needs a space between "error:" and "%d"
Will be fixed
> 
> > --- /dev/null
> > +++ b/include/g_dnl.h
> >
> > +#include 
> > +#include 
> > +#include 
> 
> unused -> delete
I will remove those includes from g_dnl.c file
> 
> > +int g_dnl_init(char *s);
> 
> int g_dnl_register(const char *type);
> 
> this also needs documentation in the header explaining how to use
> this func

I will provide the working example of this gadget. I will not insist on
the function name. It can be g_dnl_register().

> 
> > +void g_dnl_cleanup(void);
> 
> void g_dnl_unregister(void);
Can be g_dnl_unregister() as well.
> 
> > +/* USB initialization declaration - board specific*/
> > +void board_usb_init(void);
> 
> not used in these files -> delete

But it is used at e.g. samsung/trats/trats.c I think that g_dnl.h is a
good place for this.

> -mike


-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [PATCH 5/7] dfu:cmd: Support for DFU u-boot command

[Lukasz Majewski]

Dear Mike,

> On Tuesday 03 July 2012 05:38:09 Lukasz Majewski wrote:
> > --- /dev/null
> > +++ b/common/cmd_dfu.c
> >
> > +int do_dfu(cmd_tbl_t *cmdtp, int flag, int argc, char * const
> > argv[])
> 
> static

It can be static (static int do_dfu). On the other hand the U_BOOT_CMD
macro defines:

int (*cmd)(struct cmd_tbl_s *, int, int, char * const []); at
struct cmd_tbl_s, which is int.

> 
> > +{
> > +   char *str_env = NULL, *env_bkp = NULL;
> 
> no need to assign NULL here.  str_env should be const.
Yes, correct.
> 
> > +   static char *s = "dfu";
> 
> no need to declare this static
Why not? The s ptr is further passed to g_dnl_init(s), so my intend was
to declare string in the data segment of this translation unit. In this
way the data under this ptr will not vanish. 
> 
> > +   int ret = 0;
> 
> no need to init to 0

Ok.
> 
> > +   env_bkp = strdup(str_env);
> > +   ret = dfu_config_entities(env_bkp, argv[1],
> > +   (int)simple_strtoul(argv[2], NULL,
> > 10));
> > +   if (ret)
> > +   return CMD_RET_FAILURE;
> > +
> > +   if (strcmp(argv[3], "list") == 0) {
> > +   dfu_show_entities();
> > +   dfu_free_entities();
> > +   free(env_bkp);
> > +   return CMD_RET_SUCCESS;
> 
> for these last three statements, you could just do "goto done" and
> put a done label below ...

Yes, you are correct. Thanks for tip.

> 
> > +exit:
> > +   g_dnl_cleanup();
> 
> done:
> 
> > +   dfu_free_entities();
> > +   free(env_bkp);
> > +
> > +   return CMD_RET_SUCCESS;
> 
> -mike



-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] [PATCH 3/7] dfu: DFU backend implementation

[Lukasz Majewski]

Dear Mike Frysinger,

> On Tuesday 03 July 2012 05:38:07 Lukasz Majewski wrote:
> > +   puts("UPLOAD ... done\n");
> > +   puts("Ctrl+C to exit ...\n");
> 
> combine into a single puts() ?
Ok, will be done
> 
> > +static int dfu_fill_entity(struct dfu_entity *dfu, char* s, int
> > alt,
> > +   char *interface, int num)
> > +{
> > +   char *st = NULL;
> > +   int n = 0;
> > +
> > +   debug("%s: %s interface: %s num: %d\n", __func__, s,
> > interface, num); +
> > +   st = dfu_extract_token(&s, &n);
> > +   strncpy((char *) &dfu->name, st, n);
> 
> what's with the pointless cast ?  just do:
>   strncpy(dfu->name, st, n);
Yes, you are right.

> 
> also, "n" here is wrong.  it should be sizeof(dfu->name), not
> (presumably) the length of st.  considering this is the 2nd time i
> noticed this bug in the dfu patchset, you might want to do a grep on
> your patches to see if your other string related usage is wrong.

I will double-check the string operations.

> 
> > +void dfu_free_entities(void)
> > +{
> > +   struct dfu_entity *dfu = NULL, *p = NULL;
> 
> no point in assigning to NULL here

Will remove.
> 
> > +static char *dfu_get_dev_type(enum dfu_device_type t)
> 
> static const char *...
Will correct.
> 
> > +{
> > +   static char *dev_t[] = {NULL, "MMC", "ONENAND", "NAND" };
> 
> static const char * const dev_t[] = {...}
Ok
> 
> > +static char *dfu_get_layout(enum dfu_device_type l)
> 
> static const char *...
> 
Ok
> > +{
> > +   static char *dfu_layout[] = {NULL, "RAW_ADDR", "FAT",
> > "EXT" };
> 
> static const char * const dfu_layout[] = {...}
> 
OK
> > +void dfu_show_entities(void)
> > +{
> > +   struct dfu_entity *dfu = NULL;
> 
> no point in assigning to NULL
OK
> 
> > +struct dfu_entity *dfu_get_entity(int alt)
> > +{
> > +   struct dfu_entity *dfu = NULL;
> 
> no point in assigning to NULL
OK
> -mike



-- 
Best regards,

Lukasz Majewski

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Tom Rini]

On Sat, Jul 21, 2012 at 03:27:30AM +0200, Marek Vasut wrote:
> Dear Tom Rini,
> 
> > On Wed, Jul 18, 2012 at 09:21:40AM +0200, Wolfgang Denk wrote:
> > 
> > [snip]
> > 
> > > And Jenkins... well, we have been using this for some time internally
> > > to run test builds for U-Boot.  I can tell you a thing or two about
> > > it, and Marek has his own story to tell about his experiences when he
> > > added to the build matrix.
> > > 
> > > As is, we try hard to get rid of Jenkins, because it does not scale
> > > well to the type of builds we want to be able to do.  Marek even
> > > started setting up his own test build framework...
> > 
> > I told Marek on IRC that I don't understand this, given a lot of the
> > things I've made Jenkins do before and that at the end of the day it's
> > $whatever-pass/fail-logic
> 
> Not really, what about the warning-logic ? Aka. I actually need jenkins to do 
> tristate results. How, I didn't figure out.

Yes, you can have the build go "yellow" for warnings.

> > on top of a bash script to do the building and
> > testing.
> 
> So in the end, jenkins is just an executor, bringing in pile of java overhead 
> and possible random breakage. I use MAKEALL in my script, which does exactly 
> what I need ... and even tests MAKEALL ;-)

Yes, you're writing your own overhead and dealing with bugs in that
rather than using an existing project :)

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Tom Rini]

On Sat, Jul 21, 2012 at 02:28:45PM +1000, Graeme Russ wrote:

[snip]
> I don't think a protracted 'tool x' doesn't do this and 'tool y' doesn't do
> that is going to get us anywhere.

Agreed, even if I did just reply to Marek :)

> What we need to do is define exactly what we want out of the patch
> management, automated build, etc. tools. We can then see if there are any
> tools which already exist which fit our needs. If no existing tools fit,
> look at the ones that come closest and investigate what would be required
> to get them to a state that they would.
> 
> We already know that git is a perfect fit for source code management, and
> the mailing list is how we will continue to submit, review and discuss
> patches. So that gives a good starting point.
> 
> Patch Management:
>  - Integrate with existing email work flow. It must pick up patches from
>the mailing list, and any output it generates must get posted to the
>mailing list
>  - Reliably track revisions of patches (mark superseded version as such)
>  - Automatically run sanity checks (checkpatch, test apply, etc.)
>  - Track which repo patches below to

Also track which maintainer(s) a patch belongs to and allow for people
to opt-in to some notice about patches being assigned to them.

>  - Rerun sanity checks on unapplied patches when new patches are applied
>to the associated repo
>  - Track patch pre-requisite requirements (need to specify such requirments
>in the patch itself)
>  - Track ack'd, nack'd, tested, etc, posted to the mailing list
>  - Group multi-patch sets and retain the 0/x patch as it usually contains
>relevant information
> 
> Automatic Build:
>  - Nightly MAKEALL with output sent to mailing list (only need to run if a
>new patch has been applied)
>  - MAKEALL against each repo
>  - Automatic build test of patches which pass through the sanity checks of
>the patch management tool. This one is really tricky as a MAKEALL for
>each patch posted to the ML is going to require too many CPU cycles.
>We need a way to determine what configurations a particular patch is
>going to impact and only test against them

I would phrase the last one a little differently.  Allow a job to be
submitted that consists of repository X and patches 1-N.  For a given
repository we can say here's the full and representative short build
list of targets.

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

Re: [U-Boot] [PATCH 2/2] mpc85xx: Initial SP alignment is wrong.

[Scott Wood]

On 07/21/2012 10:06 AM, Joakim Tjernlund wrote:
> 
> Scott Wood  wrote on 2012/07/20 23:11:33:
>>
>> On 07/20/2012 04:20 AM, Joakim Tjernlund wrote:
>>> PowerPC mandates SP to be 16 bytes aligned.
>>> Furthermore, a stack frame is added, pointing to the reset vector
>>> which is just get in the way when gdb is walking the stack because
>>> the reset vector may not accessible depending on emulator settings.
>>> Also use a temp register so gdb doesn't pick up intermediate values.
>>>
>>> Signed-off-by: Joakim Tjernlund 
>>> ---
>>>  arch/powerpc/cpu/mpc85xx/start.S |   16 +---
>>>  1 files changed, 5 insertions(+), 11 deletions(-)
>>>
>>> diff --git arch/powerpc/cpu/mpc85xx/start.S arch/powerpc/cpu/mpc85xx/start.S
>>> index 8d66cf1..8c75af9 100644
>>> --- arch/powerpc/cpu/mpc85xx/start.S
>>> +++ arch/powerpc/cpu/mpc85xx/start.S
>>> @@ -848,18 +848,12 @@ version_string:
>>> .globl   _start_cont
>>>  _start_cont:
>>> /* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/
>>> -   lis   r1,CONFIG_SYS_INIT_RAM_ADDR@h
>>> -   ori   r1,r1,CONFIG_SYS_INIT_SP_OFFSET@l
>>> -
>>> +   lis   r2,(CONFIG_SYS_INIT_RAM_ADDR)@h
>>> +   ori   r2,r2,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
>>
>> Please don't use r2 as a general purpose register -- even if it's early
>> enough that we haven't started using it for its fixed purpose yet.
> 
> I guess that would be a tiny improvement, but it is nothing compared
> with the r1 abuse in this file :)

Yeah, I just wanted to discourage making it worse.

>>> +   stw   r0,-4(r2)   /* Store a NULL LR */
>>> +   stw   r0,0(r2)   /* Store a NULL Back Chain */
>>> +   mr   r1,r2  /* Transfer to SP(r1) */
>>
>> Why are you storing anything below the stack pointer?  LR goes above the
>> backchain, not below -- and it's not valid anyway for the current stack
>> frame.  If you want to have a terminating stack frame with a NULL LR,
>> you need to create a second stack frame, like the code currently does.
> 
> Right, it should be +4 where the NULL LR should be. As you said, it doesn't 
> matter
> because it is not valid for this stack frame and could be left out.
> 
> I do not want to create a frame as the current code does, it
> might create an memory access to 0xfffc which I don't want.

How would that happen?

> How about this then:
> 
>   lis r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
>   ori r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
>   li  r0,0
>   stw r0,0(r3)/* Terminate Back Chain */
>   stw r0,+4(r3)   /* NULL LR, to be nice. */
>   mr  r1,r3   /* Transfer to SP(r1) */
> 
> or if that reset address is wanted:
>   lis r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
>   ori r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
>   li  r0,0
>   stw r0,0(r3)/* Terminate Back Chain */
>   stw r0,+4(r3)   /* NULL LR, to be nice. */
>   stwur3,-16(r3)  /* save back chain and move SP */
>   lis r0,RESET_VECTOR@h
>   ori r0,RESET_VECTOR@l
>   stw r0,+20(r3)  /* save return address */
>   mr  r1,r3   /* Transfer to SP(r1) */
> 
> I would have to test with the emulator if both are OK or if there will
> be an access to RESET_VECTOR(I don't have that connected ATM).

How about:

lis r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
ori r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
li  r0,0
stw r0,0(r3)/* Terminate Back Chain */
stw r0,4(r3)/* NULL LR, to be nice. */
stwur3,-16(r3)  /* Create new stack frame
 * so NULL LR is valid
 */
mr  r1,r3   /* Transfer to SP(r1) */

-Scott


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

Re: [U-Boot] [PATCH v2 2/5] ehci-hcd: Boost transfer speed

[Benoît Thébaudeau]

On Monday 23 July 2012 15:35:25 Stefan Herbrechtsmeier wrote:
> Am 20.07.2012 17:35, schrieb Benoît Thébaudeau:
> > On Friday 20 July 2012 17:15:13 Stefan Herbrechtsmeier wrote:
> >> Am 20.07.2012 17:03, schrieb Benoît Thébaudeau:
> >>> On Friday 20 July 2012 16:51:33 Stefan Herbrechtsmeier wrote:
>  Am 20.07.2012 15:56, schrieb Benoît Thébaudeau:
> > Dear Marek Vasut,
> >
> > On Friday 20 July 2012 15:44:01 Marek Vasut wrote:
> >>> On Friday 20 July 2012 13:37:37 Stefan Herbrechtsmeier wrote:
>  Am 20.07.2012 13:26, schrieb Benoît Thébaudeau:
> > +   int xfr_bytes = min(left_length,
> > +   (QT_BUFFER_CNT * 4096 -
> > +((uint32_t)buf_ptr & 
> > 4095)) &
> > +   ~4095);
>  Why you align the length to 4096?
> >>> It's to guarantee that each transfer length is a multiple of
> >>> the
> >>> max packet
> >>> length. Otherwise, early short packets are issued, which
> >>> breaks
> >>> the
> >>> transfer and results in time-out error messages.
> >> Early short packets ? What do you mean?
> > During a USB transfer, all packets must have a length of max
> > packet
> > length for
> > the pipe/endpoint, except the final one that can be a short
> > packet.
> > Without the
> > alignment I make for xfr_bytes, short packets can occur within
> > a
> > transfer,
> > because the hardware starts a new packet for each new queued
> > qTD
> > it
> > handles.
>  But if I am right, the max packet length is 512 for bulk and
>  1024
>  for
>  Interrupt transfer.
> >>> There are indeed different max packet lengths for different
> >>> transfer types, but
> >>> it does not matter since the chosen alignment guarantees a
> >>> multiple
> >>> of all these
> >>> possible max packet lengths.
> >> But thereby you limit the transfer to 4 qT buffers for unaligned
> >> transfers.
> > Not exactly. The 5 qt_buffers are used for page-unaligned buffers,
> > but that
> > results in only 4 full pages of unaligned data, requiring 5 aligned
> > pages.
> Sorry I mean 4 full pages of unaligned data.
> >
> > For page-aligned buffers, the 5 qt_buffers result in 5 full pages
> > of aligned
> > data.
> Sure.
> >
> > The unaligned case could be a little bit improved to always use as
> > many packets
> > as possible per qTD, but that would over-complicate things for a
> > very negligible
> > speed and memory gain.
> In my use case (fragmented file on usb storage)  the gain would be
> nearly 20%. The reason is that the data are block aligned (512) and
> could be aligned to 4096 with the first transfer (5 qt_buffers).

Can you explain where this gain would come from? In both cases, the data in USB
transfers would be organized in the same way, and it would be accessed in memory
also in the same way (regarding bursts). The only difference would be the fetch
time of a little bit more qTDs, which is extremely fast and insignificant
compared to the transfer time of the payload, which remains unchanged.

Moreover, in your use case, if you are e.g. using FAT, on the one hand, the
buffers in fat.c are never aligned to more than the DMA min alignment, and on
the other hand, if you can align your user buffers to 512 bytes, you can also
align them directly to 4 kB.

> My suggestion would be to truncate the xfr_bytes with the max
> wMaxPacketSize (1024) and for the qtd_count use:
> 
> if ((uint32_t)buffer & 1023)/* wMaxPacketSize unaligned */
>  qtd_count += DIV_ROUND_UP(((uint32_t)buffer & 4095) +
>  length, (QT_BUFFER_CNT - 1) * 4096);
> else/* wMaxPacketSize aligned */
>  qtd_count += DIV_ROUND_UP(((uint32_t)buffer & 4095) +
>  length, QT_BUFFER_CNT * 4096);
> 
> This allows 50% of unaligned block data (512) to be transferred with
> min
> qTDs.

That would also require a realignment-to-page stage. This is specific code for
specific buffer alignment from the upper layers. We could also skip the
realignment to page and always keep the same qTD transfer size except for the
last one, by adding as many packets as possible for the buffer alignment.

But I still don't see a significant reason to complicate code to do that.

BTW, the 15x speed gain that I gave in my patch description was compared to an
older version of the original code that used 20 blocks per transfer in
usb_storage.c. This is now 40 blocks per transfer with a page-aligned buffer, so
the speed gain compared to the current code should be rather about 7x. I should
update that.

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

Re: [U-Boot] [PATCH 2/2] mpc85xx: Initial SP alignment is wrong.

[Joakim Tjernlund]

Scott Wood  wrote on 2012/07/23 18:52:28:

> From: Scott Wood 
> To: Joakim Tjernlund ,
> Cc: 
> Date: 2012/07/23 18:52
> Subject: Re: [U-Boot] [PATCH 2/2] mpc85xx: Initial SP alignment is wrong.
>
> On 07/21/2012 10:06 AM, Joakim Tjernlund wrote:
> >
> > Scott Wood  wrote on 2012/07/20 23:11:33:
> >>
> >> On 07/20/2012 04:20 AM, Joakim Tjernlund wrote:
> >>> PowerPC mandates SP to be 16 bytes aligned.
> >>> Furthermore, a stack frame is added, pointing to the reset vector
> >>> which is just get in the way when gdb is walking the stack because
> >>> the reset vector may not accessible depending on emulator settings.
> >>> Also use a temp register so gdb doesn't pick up intermediate values.
> >>>
> >>> Signed-off-by: Joakim Tjernlund 
> >>> ---
> >>>  arch/powerpc/cpu/mpc85xx/start.S |   16 +---
> >>>  1 files changed, 5 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git arch/powerpc/cpu/mpc85xx/start.S 
> >>> arch/powerpc/cpu/mpc85xx/start.S
> >>> index 8d66cf1..8c75af9 100644
> >>> --- arch/powerpc/cpu/mpc85xx/start.S
> >>> +++ arch/powerpc/cpu/mpc85xx/start.S
> >>> @@ -848,18 +848,12 @@ version_string:
> >>> .globl   _start_cont
> >>>  _start_cont:
> >>> /* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/
> >>> -   lis   r1,CONFIG_SYS_INIT_RAM_ADDR@h
> >>> -   ori   r1,r1,CONFIG_SYS_INIT_SP_OFFSET@l
> >>> -
> >>> +   lis   r2,(CONFIG_SYS_INIT_RAM_ADDR)@h
> >>> +   ori   r2,r2,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
> >>
> >> Please don't use r2 as a general purpose register -- even if it's early
> >> enough that we haven't started using it for its fixed purpose yet.
> >
> > I guess that would be a tiny improvement, but it is nothing compared
> > with the r1 abuse in this file :)
>
> Yeah, I just wanted to discourage making it worse.
>
> >>> +   stw   r0,-4(r2)   /* Store a NULL LR */
> >>> +   stw   r0,0(r2)   /* Store a NULL Back Chain */
> >>> +   mr   r1,r2  /* Transfer to SP(r1) */
> >>
> >> Why are you storing anything below the stack pointer?  LR goes above the
> >> backchain, not below -- and it's not valid anyway for the current stack
> >> frame.  If you want to have a terminating stack frame with a NULL LR,
> >> you need to create a second stack frame, like the code currently does.
> >
> > Right, it should be +4 where the NULL LR should be. As you said, it doesn't 
> > matter
> > because it is not valid for this stack frame and could be left out.
> >
> > I do not want to create a frame as the current code does, it
> > might create an memory access to 0xfffc which I don't want.
>
> How would that happen?
>
> > How about this then:
> >
> >lis   r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
> >ori   r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
> >li   r0,0
> >stw   r0,0(r3)   /* Terminate Back Chain */
> >stw   r0,+4(r3)   /* NULL LR, to be nice. */
> >mr   r1,r3  /* Transfer to SP(r1) */
> >
> > or if that reset address is wanted:
> >lis   r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
> >ori   r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
> >li   r0,0
> >stw   r0,0(r3)   /* Terminate Back Chain */
> >stw   r0,+4(r3)   /* NULL LR, to be nice. */
> >stwu   r3,-16(r3)   /* save back chain and move SP */
> >lis   r0,RESET_VECTOR@h
> >ori   r0,RESET_VECTOR@l
> >stw   r0,+20(r3)   /* save return address */
> >mr   r1,r3  /* Transfer to SP(r1) */
> >
> > I would have to test with the emulator if both are OK or if there will
> > be an access to RESET_VECTOR(I don't have that connected ATM).
>
> How about:
>
> lis   r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
> ori   r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
> li   r0,0
> stw   r0,0(r3)   /* Terminate Back Chain */
> stw   r0,4(r3)   /* NULL LR, to be nice. */
>stwu   r3,-16(r3)   /* Create new stack frame
>  * so NULL LR is valid
>  */
> mr   r1,r3  /* Transfer to SP(r1) */

This also confuses gdb
(gdb) bt
#0  cpu_init_early_f () at cpu_init_early.c:96
#1  0xeff80098 in _start_cont () at start.S:863
Backtrace stopped: frame did not save the PC

that extra stwu creates an improper call chain.
We have the initial stack frame already without the stwu

 Jocke

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

Re: [U-Boot] Sparc build warnings

[Marek Vasut]

Dear Mike Frysinger,

> On Sunday 22 July 2012 17:29:49 Peter Tyser wrote:
> > Most the the warnings look pretty trivial to fix, so I could gin
> > something up, but I don't have a Sparc toolchain to actually test any
> > modifications.
> 
> http://dev.gentoo.org/~vapier/u-boot/sparc.tar.xz
> -mike

One of your crazy toolchain collection? Wasn't someone interested to have these?

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Marek Vasut]

Dear Tom Rini,

> On Sat, Jul 21, 2012 at 03:27:30AM +0200, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> > > On Wed, Jul 18, 2012 at 09:21:40AM +0200, Wolfgang Denk wrote:
> > > 
> > > [snip]
> > > 
> > > > And Jenkins... well, we have been using this for some time internally
> > > > to run test builds for U-Boot.  I can tell you a thing or two about
> > > > it, and Marek has his own story to tell about his experiences when he
> > > > added to the build matrix.
> > > > 
> > > > As is, we try hard to get rid of Jenkins, because it does not scale
> > > > well to the type of builds we want to be able to do.  Marek even
> > > > started setting up his own test build framework...
> > > 
> > > I told Marek on IRC that I don't understand this, given a lot of the
> > > things I've made Jenkins do before and that at the end of the day it's
> > > $whatever-pass/fail-logic
> > 
> > Not really, what about the warning-logic ? Aka. I actually need jenkins
> > to do tristate results. How, I didn't figure out.
> 
> Yes, you can have the build go "yellow" for warnings.

How?

> > > on top of a bash script to do the building and
> > > testing.
> > 
> > So in the end, jenkins is just an executor, bringing in pile of java
> > overhead and possible random breakage. I use MAKEALL in my script, which
> > does exactly what I need ... and even tests MAKEALL ;-)
> 
> Yes, you're writing your own overhead and dealing with bugs in that
> rather than using an existing project :)

Well, jenkins just crashed so badly I didn't manage to get it back in a working 
state, you know ...

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

Re: [U-Boot] [PATCH 2/2] mpc85xx: Initial SP alignment is wrong.

[Scott Wood]

On 07/23/2012 12:11 PM, Joakim Tjernlund wrote:
> 
> 
> Scott Wood  wrote on 2012/07/23 18:52:28:
> 
>> From: Scott Wood 
>> To: Joakim Tjernlund ,
>> Cc: 
>> Date: 2012/07/23 18:52
>> Subject: Re: [U-Boot] [PATCH 2/2] mpc85xx: Initial SP alignment is wrong.
>>
>> On 07/21/2012 10:06 AM, Joakim Tjernlund wrote:
>>>
>>> Scott Wood  wrote on 2012/07/20 23:11:33:

 On 07/20/2012 04:20 AM, Joakim Tjernlund wrote:
> PowerPC mandates SP to be 16 bytes aligned.
> Furthermore, a stack frame is added, pointing to the reset vector
> which is just get in the way when gdb is walking the stack because
> the reset vector may not accessible depending on emulator settings.
> Also use a temp register so gdb doesn't pick up intermediate values.
>
> Signed-off-by: Joakim Tjernlund 
> ---
>  arch/powerpc/cpu/mpc85xx/start.S |   16 +---
>  1 files changed, 5 insertions(+), 11 deletions(-)
>
> diff --git arch/powerpc/cpu/mpc85xx/start.S 
> arch/powerpc/cpu/mpc85xx/start.S
> index 8d66cf1..8c75af9 100644
> --- arch/powerpc/cpu/mpc85xx/start.S
> +++ arch/powerpc/cpu/mpc85xx/start.S
> @@ -848,18 +848,12 @@ version_string:
> .globl   _start_cont
>  _start_cont:
> /* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/
> -   lis   r1,CONFIG_SYS_INIT_RAM_ADDR@h
> -   ori   r1,r1,CONFIG_SYS_INIT_SP_OFFSET@l
> -
> +   lis   r2,(CONFIG_SYS_INIT_RAM_ADDR)@h
> +   ori   r2,r2,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */

 Please don't use r2 as a general purpose register -- even if it's early
 enough that we haven't started using it for its fixed purpose yet.
>>>
>>> I guess that would be a tiny improvement, but it is nothing compared
>>> with the r1 abuse in this file :)
>>
>> Yeah, I just wanted to discourage making it worse.
>>
> +   stw   r0,-4(r2)   /* Store a NULL LR */
> +   stw   r0,0(r2)   /* Store a NULL Back Chain */
> +   mr   r1,r2  /* Transfer to SP(r1) */

 Why are you storing anything below the stack pointer?  LR goes above the
 backchain, not below -- and it's not valid anyway for the current stack
 frame.  If you want to have a terminating stack frame with a NULL LR,
 you need to create a second stack frame, like the code currently does.
>>>
>>> Right, it should be +4 where the NULL LR should be. As you said, it doesn't 
>>> matter
>>> because it is not valid for this stack frame and could be left out.
>>>
>>> I do not want to create a frame as the current code does, it
>>> might create an memory access to 0xfffc which I don't want.
>>
>> How would that happen?
>>
>>> How about this then:
>>>
>>>lis   r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
>>>ori   r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
>>>li   r0,0
>>>stw   r0,0(r3)   /* Terminate Back Chain */
>>>stw   r0,+4(r3)   /* NULL LR, to be nice. */
>>>mr   r1,r3  /* Transfer to SP(r1) */
>>>
>>> or if that reset address is wanted:
>>>lis   r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
>>>ori   r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
>>>li   r0,0
>>>stw   r0,0(r3)   /* Terminate Back Chain */
>>>stw   r0,+4(r3)   /* NULL LR, to be nice. */
>>>stwu   r3,-16(r3)   /* save back chain and move SP */
>>>lis   r0,RESET_VECTOR@h
>>>ori   r0,RESET_VECTOR@l
>>>stw   r0,+20(r3)   /* save return address */
>>>mr   r1,r3  /* Transfer to SP(r1) */
>>>
>>> I would have to test with the emulator if both are OK or if there will
>>> be an access to RESET_VECTOR(I don't have that connected ATM).
>>
>> How about:
>>
>> lis   r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
>> ori   r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
>> li   r0,0
>> stw   r0,0(r3)   /* Terminate Back Chain */
>> stw   r0,4(r3)   /* NULL LR, to be nice. */
>>stwu   r3,-16(r3)   /* Create new stack frame
>>  * so NULL LR is valid
>>  */
>> mr   r1,r3  /* Transfer to SP(r1) */
> 
> This also confuses gdb
> (gdb) bt
> #0  cpu_init_early_f () at cpu_init_early.c:96
> #1  0xeff80098 in _start_cont () at start.S:863
> Backtrace stopped: frame did not save the PC
> 
> that extra stwu creates an improper call chain.
> We have the initial stack frame already without the stwu

Well, we do want it to stop the backtrace at that point. :-)

...but I was a bit confused when I thought it would help terminate
things.  The NULL LR only helps prevent finding something worse, if
something happens to do a backtrace immediately after the first stwu but
before a real LR is saved.

-Scott


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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Tom Rini]

On 07/23/2012 10:17 AM, Marek Vasut wrote:

Dear Tom Rini,


On Sat, Jul 21, 2012 at 03:27:30AM +0200, Marek Vasut wrote:

Dear Tom Rini,


On Wed, Jul 18, 2012 at 09:21:40AM +0200, Wolfgang Denk wrote:

[snip]


And Jenkins... well, we have been using this for some time internally
to run test builds for U-Boot.  I can tell you a thing or two about
it, and Marek has his own story to tell about his experiences when he
added to the build matrix.

As is, we try hard to get rid of Jenkins, because it does not scale
well to the type of builds we want to be able to do.  Marek even
started setting up his own test build framework...


I told Marek on IRC that I don't understand this, given a lot of the
things I've made Jenkins do before and that at the end of the day it's
$whatever-pass/fail-logic


Not really, what about the warning-logic ? Aka. I actually need jenkins
to do tristate results. How, I didn't figure out.


Yes, you can have the build go "yellow" for warnings.


How?


Post build stuff and promoted builds.  I'm hopeful once I get a few 
patch series polished up and posted for v2012.11 I can go back and give 
my Jenkins instance some more attention.



on top of a bash script to do the building and
testing.


So in the end, jenkins is just an executor, bringing in pile of java
overhead and possible random breakage. I use MAKEALL in my script, which
does exactly what I need ... and even tests MAKEALL ;-)


Yes, you're writing your own overhead and dealing with bugs in that
rather than using an existing project :)


Well, jenkins just crashed so badly I didn't manage to get it back in a working
state, you know ...


Never had that happen, sorry :)

--
Tom

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

Re: [U-Boot] [PATCH 1/2] net: fec_mxc: Fix setting of RCR for xMII

[Benoît Thébaudeau]

Hi Andy,

On Mon, Jul 23, 2012 at 04:11:22AM, Duan Fugang-B38611 wrote:
> With flow control (FCE) feature, it depends on the hardware support.
> I.MX serial Ethernet ip (FEC, enet) can support the features, and it
> don't need to enable flow control in 100Mbps transition in fact.
> As our test result, if Ethernet rx bandwidth more than 140Mbps, FCE
> feature can be helpful to resolve FIFO overruns issue.
> In uboot, Ethernet has no the  similar cases needed so big bandwidth,
> so it don't care FCE feature.

OK.

> With fec_open enables full-duplex in TCR regardless of xcv_type, it
> is not reasonable.
> The good method must be use auto-negotiation and check phy duplex
> status,  you can refer to net/mxc_fec.c file.

I agree. I don't have time to fix this right now. Perhaps you or someone else
can handle this. There does not seem to be any bug tracking system in U-Boot, so
I don't know if something specific should be done to report this. Anyway, this
does not seem to be an issue for current hardware using this driver, so there is
no emergency.

I also noticed that fec_eth_phy_config calls phy_connect with
PHY_INTERFACE_MODE_RGMII regardless of xcv_type, which does not seem
appropriate.

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Marek Vasut]

Dear Tom Rini,

> On 07/23/2012 10:17 AM, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> >> On Sat, Jul 21, 2012 at 03:27:30AM +0200, Marek Vasut wrote:
> >>> Dear Tom Rini,
> >>> 
>  On Wed, Jul 18, 2012 at 09:21:40AM +0200, Wolfgang Denk wrote:
>  
>  [snip]
>  
> > And Jenkins... well, we have been using this for some time internally
> > to run test builds for U-Boot.  I can tell you a thing or two about
> > it, and Marek has his own story to tell about his experiences when he
> > added to the build matrix.
> > 
> > As is, we try hard to get rid of Jenkins, because it does not scale
> > well to the type of builds we want to be able to do.  Marek even
> > started setting up his own test build framework...
>  
>  I told Marek on IRC that I don't understand this, given a lot of the
>  things I've made Jenkins do before and that at the end of the day it's
>  $whatever-pass/fail-logic
> >>> 
> >>> Not really, what about the warning-logic ? Aka. I actually need jenkins
> >>> to do tristate results. How, I didn't figure out.
> >> 
> >> Yes, you can have the build go "yellow" for warnings.
> > 
> > How?
> 
> Post build stuff and promoted builds.  I'm hopeful once I get a few
> patch series polished up and posted for v2012.11 I can go back and give
> my Jenkins instance some more attention.

But then, do we really need to poke into this now? Maybe we should look more 
into the PW first

>  on top of a bash script to do the building and
>  testing.
> >>> 
> >>> So in the end, jenkins is just an executor, bringing in pile of java
> >>> overhead and possible random breakage. I use MAKEALL in my script,
> >>> which does exactly what I need ... and even tests MAKEALL ;-)
> >> 
> >> Yes, you're writing your own overhead and dealing with bugs in that
> >> rather than using an existing project :)
> > 
> > Well, jenkins just crashed so badly I didn't manage to get it back in a
> > working state, you know ...
> 
> Never had that happen, sorry :)

"Never happened to me" or almost like "Works for me" kind of bloody sentence ;-)

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

Re: [U-Boot] [PATCH V3 1/2] Add env vars describing U-Boot target board

[Stephen Warren]

On 07/12/2012 12:10 AM, Wolfgang Denk wrote:
> Dear Joe Hershberger,
> 
> In message 
>  you 
> wrote:
>>
 It also breaks a number of ARM boards...

 LOG/at91sam9263ek_norflash_boot.ERR:3:/home/joe/u-boot/include/config.h:5:0:
 warning: "CONFIG_SYS_BOARD" redefined [enabled by default]
>>> I don't see any of these doing a MAKEALL -s at91 on either 
>>> u-boot-tegra/master or u-boot-arm/master, with gcc 4.6.2 and 4.4.1.
>>
>> I noticed them when building u-boot-net/next (which is based on
>> u-boot/master).  Building with Sourcery gcc 4.6.1.  MAKEALL -a arm
>>
>> It may be caused by something else.  I just noticed it and it seemed related.
> 
> I had the same problem.  In my case it happenend when I ran an
> out-of-tree build from a directory in which I had run an in-tree build
> before.  Running "make mrproper" in the repository fixed the
> out-of-tree build.
> 
> Yes, these should not be influencing each other, but they do.  It
> appears there is a bad #include somewhere.  I didn't have time to look
> into that yet.

Is this issue considered resolved then, or is there still some fix I
need to investigate?

Sorry, I've been away on vacation the last 2 weeks.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] ext2fs: fix warning: 'blocknxt' may be used uninitialized

[Tom Rini]

On Sun, Jul 08, 2012 at 10:55:16PM +0200, Wolfgang Denk wrote:
> Dear Kim Phillips,
> 
> In message <20120703174156.a1082309c2b205216606a...@freescale.com> you wrote:
> > This warning was introduced in 436da3c "ext2load: increase read
> > speed":
> > 
> > ext2fs.c: In function 'ext2fs_read_file':
> > ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this func=
> > tion [-Wuninitialized]
> > 
> > this change makes it go away.
> > 
> > Cc: Eric Nelson 
> > Cc: Thierry Reding 
> > Cc: Jason Cooper 
> > Cc: Andreas Bie=DFmann 
> > Cc: Reinhard Arlt 
> > Signed-off-by: Kim Phillips 
> > ---
> > v2: changed to Thierry's recommendation in:
> > 
> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
> > 
> > build-tested only - please ack
> > 
> >  fs/ext2/ext2fs.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Applied, thanks.

This doesn't fix the warning for ELDK 4.2 toolchains (gcc 4.2.2):
ext2fs.c: In function 'ext2fs_read_file':
ext2fs.c:443: warning: 'blocknxt' may be used uninitialized in this
function

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Tom Rini]

On 07/23/2012 11:11 AM, Marek Vasut wrote:
> Dear Tom Rini,
> 
>> On 07/23/2012 10:17 AM, Marek Vasut wrote:
>>> Dear Tom Rini,
>>>
 On Sat, Jul 21, 2012 at 03:27:30AM +0200, Marek Vasut wrote:
> Dear Tom Rini,
>
>> On Wed, Jul 18, 2012 at 09:21:40AM +0200, Wolfgang Denk wrote:
>>
>> [snip]
>>
>>> And Jenkins... well, we have been using this for some time internally
>>> to run test builds for U-Boot.  I can tell you a thing or two about
>>> it, and Marek has his own story to tell about his experiences when he
>>> added to the build matrix.
>>>
>>> As is, we try hard to get rid of Jenkins, because it does not scale
>>> well to the type of builds we want to be able to do.  Marek even
>>> started setting up his own test build framework...
>>
>> I told Marek on IRC that I don't understand this, given a lot of the
>> things I've made Jenkins do before and that at the end of the day it's
>> $whatever-pass/fail-logic
>
> Not really, what about the warning-logic ? Aka. I actually need jenkins
> to do tristate results. How, I didn't figure out.

 Yes, you can have the build go "yellow" for warnings.
>>>
>>> How?
>>
>> Post build stuff and promoted builds.  I'm hopeful once I get a few
>> patch series polished up and posted for v2012.11 I can go back and give
>> my Jenkins instance some more attention.
> 
> But then, do we really need to poke into this now? Maybe we should look more 
> into the PW first

Me or the community?  I'm going to poke Jenkins regardless since it's
something I've got setup already (and I've contributed a few changes and
a plugin, in a past life).  Is it the right answer for the community?
TBD :)  Is it the first thing we should address?  No, the patch
collection / management problem should indeed come first.

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

Re: [U-Boot] Invalid Netconsole source MAC address [was: Re: [STATUS] v2012.07-rc1 is out - release date July 23]

[Joe Hershberger]

Hi Michael,

On Sat, Jul 21, 2012 at 1:04 PM, Michael Walle  wrote:
>> Hi,
>>
>> Am Dienstag 10 Juli 2012, 09:31:42 schrieb Wolfgang Denk:
>> > Hi everybody,
>> >
>> > this is to let you know that the v2012.07-rc1 prerelease is out.
>> >
>> > Please help testing, so we can fix the remaining issues before the
>> > release, which I decided to shift by a week, i. e. the new schedule
>> > for the release is July 23.
>>
>> I just noticed, that netconsole isnt working anymore for stdout. The source
>> mac address is set to 00:00:00:00:00:00 in the udp packet which is sent by
>> u- boot :(
>>
>> But haven't figured out yet why it NetOurEther isn't initialized.
>>
>> @Joe: would be nice if the fix would make it into this release.
>
> Mh i guess NetLoop isn't called and thus NetOurEther is never initialized.
> Similar issue like d7310c7e63ca9ffd42527dc9735cb505cbe908b7. Initializing
> NetOurEther in net_init() fixes the problem.

I tested this on Panda board and wireshark reports the correct source
MAC address.

Please provide details of which board and driver you are using.

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

Re: [U-Boot] [PATCH V3 1/2] Add env vars describing U-Boot target board

[Wolfgang Denk]

Dear Tom,

In message <5fbf8e85ca34454794f0f7ecba79798f379d86f...@hqmail04.nvidia.com> you 
wrote:
> 
> > > I had the same problem.  In my case it happenend when I ran an
> > > out-of-tree build from a directory in which I had run an in-tree build
> > > before.  Running "make mrproper" in the repository fixed the
> > > out-of-tree build.
> > >
> > > Yes, these should not be influencing each other, but they do.  It
> > > appears there is a bad #include somewhere.  I didn't have time to look
> > > into that yet.
> > 
> > Is this issue considered resolved then, or is there still some fix I need to
> > investigate?

This isssue is not resolved, as far as I can tell.  Just nobody
appears to have time to look into it.


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
Hacking's just another word for nothing left to kludge.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 11/19] tegra: Add LCD support to Nvidia boards

[Stephen Warren]

On 07/10/2012 10:58 PM, Simon Glass wrote:
> Hi Stephen,
> 
> On Fri, Jun 15, 2012 at 1:47 AM, Stephen Warren  > wrote:
> 
> On 06/13/2012 10:19 AM, Simon Glass wrote:
> > Add calls to the LCD driver from Nvidia board code.
> 
> > diff --git a/board/nvidia/common/board.c b/board/nvidia/common/board.c
> 
> > @@ -87,6 +88,9 @@ int board_init(void)
> 
> > +#ifdef CONFIG_VIDEO_TEGRA2
> > + tegra_lcd_check_next_stage(gd->blob, 0);
> > +#endif
> 
> This seems to be conflating video support with LCD support. It would be
> quite possible to have a board with no LCD, yet supporting display over
> HDMI for example. In other words, shouldn't the ifdef above be something
> more like:
> 
> #if define(CONFIG_LCD_SUPPORT)
> register_lcd_driver();
> #endif
> #if defined(CONFIG_VIDEO_TEGRA2)
> tegra_display_init(...);
> #endif
> 
> and internal to tegra_display_init(), the DT is searched for LCD
> controller nodes, and if any are found, they're matched to the LCD
> driver registered by the first call above.
> 
> 
> Yes that sounds great, but again we don't really have this
> infrastructure in U-Boot. We would be inventing it just for Tegra, and I
> would prefer to wait until the device model stuff is done before being
> too fancy.

What is "the device model stuff" you mention?

> We don't have an HDMI driver at present, so perhaps if/when that appears
> in U-Boot it would be a good time to add support for that?

Certainly adding code for HDMI can wait until later. However, I do think
that we should use the correct ifdefs up-front, so that e.g. adding HDMI
support only means adding a bunch of code, not going through the
existing code and untangling conflated ifdefs.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 06/10] dm: Move OMAP GPIO driver to drivers/gpio/

[Tom Rini]

On Sat, Jul 21, 2012 at 05:02:23PM +0200, Marek Vasut wrote:

> Signed-off-by: Marek Vasut 
> Cc: Wolfgang Denk 
> Cc: Albert Aribaud 
> Cc: U-Boot DM 
> Cc: Tom Rini 

Acked-by: Tom Rini 

-- 
Tom


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

Re: [U-Boot] [PATCH 10/10] dm: Select CONFIG_SPL_GPIO_SUPPORT on OMAP

[Tom Rini]

On Sat, Jul 21, 2012 at 05:02:27PM +0200, Marek Vasut wrote:

> This fixes the breakage with SPL on most OMAP boards after the GPIO
> driver was moved.
> 
> Signed-off-by: Marek Vasut 
> Cc: Wolfgang Denk 
> Cc: Albert Aribaud 
> Cc: U-Boot DM 
> Cc: Tom Rini 

The change is fine so

Acked-by: Tom Rini 

But please re-order in the series so that there is no breakage.  I do
hate bisect failing run-time when we know we could have not :)

-- 
Tom


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

Re: [U-Boot] [PATCH v7 00/15] split tegra20 arm7 code into separate SPL

[Tom Warren]

Tegra devs,

Since I've not seen any objections (or discussion, really, beyond Simon/Allen), 
I'm going to apply u-boot-tegra/next to tegra/master (i.e. the SPL patches will 
now be de rigueur for u-boot-tegra going forward).

If you have Tegra patches that you are working on, or are in the middle of 
review/revision on the list (Simon's LCD and NAND), then you'll need to 
rework/rebase them on top of u-boot-tegra/master (w/the SPL changes) from this 
point on.

Thanks,

Tom

> -Original Message-
> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass
> Sent: Thursday, July 19, 2012 1:09 PM
> To: Tom Warren
> Cc: Allen Martin; swar...@wwwdotorg.org; thierry.red...@avionic-design.de;
> u-boot@lists.denx.de; Igor Grinberg; Konstantin Sinyuk
> Subject: Re: [PATCH v7 00/15] split tegra20 arm7 code into separate SPL
> 
> Hi Tom / Allen,
> 
> On Thu, Jul 19, 2012 at 4:37 PM, Tom Warren  wrote:
> > Allen,
> >
> >> -Original Message-
> >> From: Allen Martin [mailto:amar...@nvidia.com]
> >> Sent: Wednesday, July 18, 2012 5:02 PM
> >> To: Tom Warren
> >> Cc: swar...@wwwdotorg.org; s...@chromium.org; thierry.reding@avionic-
> >> design.de; u-boot@lists.denx.de
> >> Subject: Re: [PATCH v7 00/15] split tegra20 arm7 code into separate
> >> SPL
> >>
> >> On Tue, Jul 17, 2012 at 12:32:53PM -0700, Tom Warren wrote:
> >> > Allen,
> >> >
> >> > > -Original Message-
> >> > > From: Allen Martin [mailto:amar...@nvidia.com]
> >> > > Sent: Monday, July 16, 2012 4:02 PM
> >> > > To: Tom Warren; swar...@wwwdotorg.org; s...@chromium.org;
> >> > > thierry.red...@avionic-design.de
> >> > > Cc: u-boot@lists.denx.de; Allen Martin
> >> > > Subject: [PATCH v7 00/15] split tegra20 arm7 code into separate
> >> > > SPL
> >> > >
> >> > > This patch series fixes a long standing problem with the tegra20
> >> > > u-boot build.  Tegra20 contains an ARM7TDMI boot processor and a
> >> > > Cortex A9 main processor.  Prior to this patch series this was
> >> > > accomplished by #ifdefing out any armv7 code from the early boot
> >> > > sequence and creating a single binary that runs on both both the
> >> > > ARM7TDMI and A9.  This was very fragile as changes to compiler
> >> > > options or any additions or rearranging of the early boot code
> >> > > could add additional armv7 specific code causing it to fail on the
> ARM7TDMI.
> >> > >
> >> > > This patch series pulls all the armv4t code out into a separate
> >> > > SPL that does nothing more than initialize the A9 and transfer
> >> > > control to it.  The resultint SPL and armv7 u-boot are
> >> > > concatenated together into a single image.
> >> > >
> >> > > This patch series is also available from:
> >> > > git://github.com/arm000/u-boot.git
> >> > > branch: tegra-spl-v7
> >> > >
> >> >
> >> > Applied to u-boot-tegra/next AOK, tested on my Seaboard AOK, so:
> >> > Tested-by: Tom Warren 
> >> >
> >> > Note that I was confused by the final binary name
> >> > (u-boot-dtb-tegra.bin),
> >> since I'm used to flashing u-boot-dtb.bin.
> >> >
> >> > We need to come to a consensus about the final binary name for
> >> > Tegra U-
> >> Boot (I'd thought we had, and that it would be u-boot-dtb.bin, since
> >> that's what most devs are used to looking for in Tegra builds).
> 
> I think so.
> 
> >> >
> >>
> >> Yeah, I'd like some stability there too.  The -dtb rule is not tegra
> >> specific, which is why I didn't want to modify or remove it.  I think
> >> we're the only one that uses it though, so maybe it's not so bad.
> 
> Not for long :-)
> 
> >>
> >> > Also, one nit: I see the 2 sign-on strings (U-Boot SPL 2012.04.xxx,
> >> > and
> >> then U-Boot 2012.04.xxx), separated by 2 lines. I think it'd look
> >> better if you had them one right after the other, i.e. eliminate the
> extra linefeeds.
> >> >
> 
> >>
> >> The extra lines come from display_banner() which is ARM generic from
> >> the main u-boot.  I assume they are there to separate the banner from
> >> any junk that was on your screen before you rebooted, so it would
> >> make sense to move them to the SPL banner instead if you have SPL
> enabled.
> >> I'll make a separate patch for that in a week after I get back from
> >> vacation.
> 
> I suspect you could remove the extra line by not printing a \n in SPL.
> The other one might be a bit tricky as I think it is in U-Boot proper as you
> say.
> 
> Also do we need the full version tag on the SPL version?
> 
> >>
> >> -Allen
> >
> > Cool, thanks. Until then:
> >
> > Tegra2 SPL patches have been applied to u-boot-tegra/next & pushed to
> Denx. I'm going to hold off putting it into tegra/master and generating a
> pull request for awhile to allow all Tegra devs to test it, comment, etc.,
> since it's a major change to the Tegra build.
> >
> > If possible, please post any new Tegra changes against tegra/next (i.e.
> using Allen's SPL file locations).
> 
> I have a few minor comments on the series now that I have made time to go
> through it in final form:
> 
> 1. In the r

Re: [U-Boot] Invalid Netconsole source MAC address [was: Re: [STATUS] v2012.07-rc1 is out - release date July 23]

[Michael Walle]

Hi Joe,

Am Montag 23 Juli 2012, 21:30:28 schrieb Joe Hershberger:
> On Sat, Jul 21, 2012 at 1:04 PM, Michael Walle  wrote:
> > Mh i guess NetLoop isn't called and thus NetOurEther is never
> > initialized. Similar issue like
> > d7310c7e63ca9ffd42527dc9735cb505cbe908b7. Initializing NetOurEther in
> > net_init() fixes the problem.
> 
> I tested this on Panda board and wireshark reports the correct source
> MAC address.
> 
> Please provide details of which board and driver you are using.

Board: LS-CHLv2/kirkwood arm; ethaddr set to some valid ethernet address ;)

If NetLoop isn't called the internal ethernet address is not initialized. 
Hopefully the following sequence triggers the bug:
 - boot the board, _dont_ do any network interaction
 - setenv stdout nc
 - type sth on the serial console

--> now the packets are send with source MAC == 00:00:00:00:00:00.

If you look at the code NetOurEther is only initialized in NetLoop and i guess 
NetLoop() isn't called for outgoing NetConsole packets.

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Tom Rini]

On Sat, Jul 21, 2012 at 04:40:27PM +0200, Marek Vasut wrote:

[snip]
> The other problem is how to find the boards that actually need rebuild on per-
> patch basis. And for generic patches, we'll need to do MAKEALL across all 
> architectures anyway, which takes a bit of time.

I think we (custodians) need to define representative sets.  For TI
stuff, you don't need to hit every omap3 board, but just a handful to be
good enough.  And while my PowerPC is rusty, I know we don't need to
build as many combinations of boards as we do to be happy in an
every-patch build (just nightly / once there's changes live on wd's
master branch would be the world).

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

[U-Boot] [PATCHv2 1/2] mpc85xx: Initial SP alignment is wrong.

[Joakim Tjernlund]

PowerPC mandates SP to be 16 bytes aligned.
Furthermore, a stack frame is added, pointing to the reset vector
which may in the way when gdb is walking the stack because
the reset vector may not accessible depending on emulator settings.
Also use a temp register so gdb doesn't pick up intermediate values.

Signed-off-by: Joakim Tjernlund 
---

 v2 - Address Scott Wood's comments
 arch/powerpc/cpu/mpc85xx/start.S |   16 +---
 1 files changed, 5 insertions(+), 11 deletions(-)

diff --git arch/powerpc/cpu/mpc85xx/start.S arch/powerpc/cpu/mpc85xx/start.S
index 8d66cf1..4973682 100644
--- arch/powerpc/cpu/mpc85xx/start.S
+++ arch/powerpc/cpu/mpc85xx/start.S
@@ -848,18 +848,12 @@ version_string:
.globl  _start_cont
 _start_cont:
/* Setup the stack in initial RAM,could be L2-as-SRAM or L1 dcache*/
-   lis r1,CONFIG_SYS_INIT_RAM_ADDR@h
-   ori r1,r1,CONFIG_SYS_INIT_SP_OFFSET@l
-
+   lis r3,(CONFIG_SYS_INIT_RAM_ADDR)@h
+   ori r3,r3,((CONFIG_SYS_INIT_SP_OFFSET-16)&~0xf)@l /* Align to 16 */
li  r0,0
-   stwur0,-4(r1)
-   stwur0,-4(r1)   /* Terminate call chain */
-
-   stwur1,-8(r1)   /* Save back chain and move SP */
-   lis r0,RESET_VECTOR@h   /* Address of reset vector */
-   ori r0,r0,RESET_VECTOR@l
-   stwur1,-8(r1)   /* Save back chain and move SP */
-   stw r0,+12(r1)  /* Save return addr (underflow vect) */
+   stw r0,0(r3)/* Terminate Back Chain */
+   stw r0,+4(r3)   /* NULL return address. */
+   mr  r1,r3   /* Transfer to SP(r1) */
 
GET_GOT
bl  cpu_init_early_f
-- 
1.7.3.4

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

[U-Boot] [PATCHv2 2/2] powerpc: Stack Pointer not properly aligned

[Joakim Tjernlund]

The code first aligns the SP to 16 then subtract 8, making it
8 bytes aligned. Furthermore the initial stack frame not
quite correct either.

Signed-off-by: Joakim Tjernlund 
---

 v2 - Address Scott Wood's comments

 arch/powerpc/lib/board.c |5 ++---
 1 files changed, 2 insertions(+), 3 deletions(-)

diff --git arch/powerpc/lib/board.c arch/powerpc/lib/board.c
index d5b75e5..a46942c 100644
--- arch/powerpc/lib/board.c
+++ arch/powerpc/lib/board.c
@@ -521,9 +521,8 @@ void board_init_f(ulong bootflag)
addr_sp -= 16;
addr_sp &= ~0xF;
s = (ulong *) addr_sp;
-   *s-- = 0;
-   *s-- = 0;
-   addr_sp = (ulong) s;
+   *s = 0; /* Terminate back chain */
+   *++s = 0; /* NULL return address */
debug("Stack Pointer at: %08lx\n", addr_sp);
 
/*
-- 
1.7.3.4

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

Re: [U-Boot] [PATCH 2/2] mpc85xx: Initial SP alignment is wrong.

[Joakim Tjernlund]

Scott Wood  wrote on 2012/07/23 19:28:20:
>
> On 07/23/2012 12:11 PM, Joakim Tjernlund wrote:
> >
> >


> ...but I was a bit confused when I thought it would help terminate
> things.  The NULL LR only helps prevent finding something worse, if
> something happens to do a backtrace immediately after the first stwu but
> before a real LR is saved.

So I just sent v2, now I am offline for a few days/a week.

 Jocke

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Tom Rini]

On Mon, Jul 23, 2012 at 08:20:15AM +0200, Wolfgang Denk wrote:
> Dear Marek Vasut,
> 
> In message <201207230347.31993.ma...@denx.de> you wrote:
> >
> > > Yes, I know. Hmmm, maybe if every 24 hours the auto build infrastructure:
> > >  - Runs a MAKEALL on the mainline repo (if any patches have been 
> > > committed)
> > 
> > Certainly ... it takes 16 hours to do so on my dedicated machine though 
> > (more 
> > now, since I started building sparc too ;-D ). But WD has some pretty 
> > badass 
> > machines that can do it really quick :-)
> 
> Not nearly quick enough for all arches and all boards and and all repos...
> 
> > > - All patches applied to sub-repo's (i.e. do a git-pull of each
> > > sub-repo) - If the mainline MAKEALL is clean but the 'patched' MAKEALL is
> > > not, use git bisect to identify the first patch that breaks the build
> > 
> > Hm yea ... serverfarm needed here. Badass machines and badass cluster is a 
> > difference ;-)
> 
> Sponsors needed to pay for such a infrastructure...
> 
> > You have c) twice in there (nit :) ). Still, we'd need a pretty badass 
> > buildsetup for that, right? But indeed, such an algo sounds nice.
> 
> I wish we had unlimited resources...
> 
> But then - U-Boot is _much_ smaller than Linux, and they do not do
> anything like that, yet they manage to keep going.  What are we doing
> wrong / differently?

I think it boils down to community size.  There's a lot of people
building and testing random combinations.  There's just not much of that
today for U-Boot.

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

Re: [U-Boot] [PATCH 10/10] dm: Select CONFIG_SPL_GPIO_SUPPORT on OMAP

[Marek Vasut]

Dear Tom Rini,

> On Sat, Jul 21, 2012 at 05:02:27PM +0200, Marek Vasut wrote:
> > This fixes the breakage with SPL on most OMAP boards after the GPIO
> > driver was moved.
> > 
> > Signed-off-by: Marek Vasut 
> > Cc: Wolfgang Denk 
> > Cc: Albert Aribaud 
> > Cc: U-Boot DM 
> > Cc: Tom Rini 
> 
> The change is fine so
> 
> Acked-by: Tom Rini 
> 
> But please re-order in the series so that there is no breakage.  I do
> hate bisect failing run-time when we know we could have not :)

Sure, if you can pick 10/10 first, 06/10 afterwards as we discussed on IRC, 
that'd be great. This is not really a series and I should have posted it as 
such, I admit.

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

Re: [U-Boot] Invalid Netconsole source MAC address [was: Re: [STATUS] v2012.07-rc1 is out - release date July 23]

[Joe Hershberger]

Hi Michael,

On Mon, Jul 23, 2012 at 3:41 PM, Michael Walle  wrote:
>
> Hi Joe,
>
> Am Montag 23 Juli 2012, 21:30:28 schrieb Joe Hershberger:
>> On Sat, Jul 21, 2012 at 1:04 PM, Michael Walle  wrote:
>> > Mh i guess NetLoop isn't called and thus NetOurEther is never
>> > initialized. Similar issue like
>> > d7310c7e63ca9ffd42527dc9735cb505cbe908b7. Initializing NetOurEther in
>> > net_init() fixes the problem.
>>
>> I tested this on Panda board and wireshark reports the correct source
>> MAC address.
>>
>> Please provide details of which board and driver you are using.
>
> Board: LS-CHLv2/kirkwood arm; ethaddr set to some valid ethernet address ;)
>
> If NetLoop isn't called the internal ethernet address is not initialized.
> Hopefully the following sequence triggers the bug:
>  - boot the board, _dont_ do any network interaction
>  - setenv stdout nc
>  - type sth on the serial console
>
> --> now the packets are send with source MAC == 00:00:00:00:00:00.
>
> If you look at the code NetOurEther is only initialized in NetLoop and i guess
> NetLoop() isn't called for outgoing NetConsole packets.

Thanks for pointing this out.  I was able to reproduce it on panda and
have a fix for it.  I'll post it shortly.

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Marek Vasut]

Dear Tom Rini,

> On Sat, Jul 21, 2012 at 04:40:27PM +0200, Marek Vasut wrote:
> 
> [snip]
> 
> > The other problem is how to find the boards that actually need rebuild on
> > per- patch basis. And for generic patches, we'll need to do MAKEALL
> > across all architectures anyway, which takes a bit of time.
> 
> I think we (custodians) need to define representative sets.  For TI
> stuff, you don't need to hit every omap3 board, but just a handful to be
> good enough.  And while my PowerPC is rusty, I know we don't need to
> build as many combinations of boards as we do to be happy in an
> every-patch build (just nightly / once there's changes live on wd's
> master branch would be the world).

Good idea ... USB is generally properly isolated part, yet it can impact crazy 
boards, like MPC83xx (well, I still have my shallow grave around, which I left 
just by WD's sheer grace ;-) ).

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Marek Vasut]

Dear Tom Rini,

> On Mon, Jul 23, 2012 at 08:20:15AM +0200, Wolfgang Denk wrote:
> > Dear Marek Vasut,
> > 
> > In message <201207230347.31993.ma...@denx.de> you wrote:
> > > > Yes, I know. Hmmm, maybe if every 24 hours the auto build 
infrastructure:
> > > >  - Runs a MAKEALL on the mainline repo (if any patches have been
> > > >  committed)
> > > 
> > > Certainly ... it takes 16 hours to do so on my dedicated machine though
> > > (more now, since I started building sparc too ;-D ). But WD has some
> > > pretty badass machines that can do it really quick :-)
> > 
> > Not nearly quick enough for all arches and all boards and and all
> > repos...
> > 
> > > > - All patches applied to sub-repo's (i.e. do a git-pull of each
> > > > 
> > > > sub-repo) - If the mainline MAKEALL is clean but the 'patched'
> > > > MAKEALL is not, use git bisect to identify the first patch that
> > > > breaks the build
> > > 
> > > Hm yea ... serverfarm needed here. Badass machines and badass cluster
> > > is a difference ;-)
> > 
> > Sponsors needed to pay for such a infrastructure...
> > 
> > > You have c) twice in there (nit :) ). Still, we'd need a pretty badass
> > > buildsetup for that, right? But indeed, such an algo sounds nice.
> > 
> > I wish we had unlimited resources...
> > 
> > But then - U-Boot is _much_ smaller than Linux, and they do not do
> > anything like that, yet they manage to keep going.  What are we doing
> > wrong / differently?
> 
> I think it boils down to community size.  There's a lot of people
> building and testing random combinations.  There's just not much of that
> today for U-Boot.

Yea ... I think our community is kinda broken :-(

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Marek Vasut]

Dear Tom Rini,

> On 07/23/2012 11:11 AM, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> >> On 07/23/2012 10:17 AM, Marek Vasut wrote:
> >>> Dear Tom Rini,
> >>> 
>  On Sat, Jul 21, 2012 at 03:27:30AM +0200, Marek Vasut wrote:
> > Dear Tom Rini,
> > 
> >> On Wed, Jul 18, 2012 at 09:21:40AM +0200, Wolfgang Denk wrote:
> >> 
> >> [snip]
> >> 
> >>> And Jenkins... well, we have been using this for some time
> >>> internally to run test builds for U-Boot.  I can tell you a thing
> >>> or two about it, and Marek has his own story to tell about his
> >>> experiences when he added to the build matrix.
> >>> 
> >>> As is, we try hard to get rid of Jenkins, because it does not scale
> >>> well to the type of builds we want to be able to do.  Marek even
> >>> started setting up his own test build framework...
> >> 
> >> I told Marek on IRC that I don't understand this, given a lot of the
> >> things I've made Jenkins do before and that at the end of the day
> >> it's $whatever-pass/fail-logic
> > 
> > Not really, what about the warning-logic ? Aka. I actually need
> > jenkins to do tristate results. How, I didn't figure out.
>  
>  Yes, you can have the build go "yellow" for warnings.
> >>> 
> >>> How?
> >> 
> >> Post build stuff and promoted builds.  I'm hopeful once I get a few
> >> patch series polished up and posted for v2012.11 I can go back and give
> >> my Jenkins instance some more attention.
> > 
> > But then, do we really need to poke into this now? Maybe we should look
> > more into the PW first
> 
> Me or the community?  I'm going to poke Jenkins regardless since it's
> something I've got setup already (and I've contributed a few changes and
> a plugin, in a past life).  Is it the right answer for the community?
> TBD :)  Is it the first thing we should address?  No, the patch
> collection / management problem should indeed come first.

Just what I had in mind :)

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

Re: [U-Boot] Antwort: Re: NetConsole & TFTP

[Joe Hershberger]

Hi Thomas,

On Mon, Mar 26, 2012 at 5:24 AM, Thomas Pohl  wrote:
> Dear Wolfgang,
>
>>Hm... you are not running mainline code, right?  Because we always
>>have a single network interface active at any time.
>
> I am using mainline code (u-boot v2011.12) with
> P2020RDB-PC_SPIFLASH_config. Unfortunately it does not work as I thought,
> but fortunately we may have a solution (patch) to solve the problem.

Please share your results with us.  What was the problem and how did you fix it?

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Marek Vasut]

Dear Eric Nelson,

> > Yea ... I think our community is kinda broken :-(
> 
> Hey. We heard that...
> 
> Careful what you say on an open mic!

Oh man ... I guess it sounded bad indeed, I should have though about the 
wording 
more, sorry.

I mean, we messed up the management (and I wonder who'll start bashing me for 
this one), resulting in the community being misguided sometimes. Making it hard 
to learn how to contribute too (too many rules etc). Custodians being 
overloaded, warding people off because the review takes too long ... stuff like 
that is what I meant.

So we have too much to improve, yet too less time to do that.

Ad community, there's a lot of people obviously, who contribute regularly (of 
course, such as yourself for example). But I wonder if there's enough of us to 
maintain such a big codebase we have. Besides, people care about linux a lot 
more than about uboot, pushing many more of the maintaining tasks on 
custodians. 
Or maybe it's the structure that doesn't work well enough to handle the flow. 
Honestly, I'm getting lost in it myself.

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

[U-Boot] [PATCH] net: Make sure the ethaddr is updated in net_init()

[Joe Hershberger]

NetConsole may call NetSendUDPPacket before NetLoop is called.  This
will cause the source MAC address (NetOurEther) to be wrong.  Instead
of only changing it in NetLoop, move it to NetLoopInit so that it is
also updated when net_init() is called (especially by nc_start()).

Signed-off-by: Joe Hershberger 
Reported-by: Michael Walle 
---
 net/net.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/net/net.c b/net/net.c
index 9de7d92..e8ff066 100644
--- a/net/net.c
+++ b/net/net.c
@@ -256,6 +256,7 @@ static void NetInitLoop(void)
 #endif
env_changed_id = env_id;
}
+   memcpy(NetOurEther, eth_get_dev()->enetaddr, 6);
 
return;
 }
@@ -322,8 +323,6 @@ int NetLoop(enum proto_t protocol)
}
 
 restart:
-   memcpy(NetOurEther, eth_get_dev()->enetaddr, 6);
-
net_set_state(NETLOOP_CONTINUE);
 
/*
-- 
1.6.0.2

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

Re: [U-Boot] [PATCH] net: Make sure the ethaddr is updated in net_init()

[Joe Hershberger]

Hi Michael,

On Mon, Jul 23, 2012 at 6:11 PM, Joe Hershberger  wrote:
> NetConsole may call NetSendUDPPacket before NetLoop is called.  This
> will cause the source MAC address (NetOurEther) to be wrong.  Instead
> of only changing it in NetLoop, move it to NetLoopInit so that it is
> also updated when net_init() is called (especially by nc_start()).
>
> Signed-off-by: Joe Hershberger 
> Reported-by: Michael Walle 
> ---

Please test this and verify that it solves your issue.

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

Re: [U-Boot] Notes from the U-Boot BOF Meeting in Geneva 2012/07/12

[Eric Nelson]

On 07/23/2012 04:06 PM, Marek Vasut wrote:

Dear Eric Nelson,


Yea ... I think our community is kinda broken :-(


Hey. We heard that...

Careful what you say on an open mic!


Oh man ... I guess it sounded bad indeed, I should have though about the wording
more, sorry.

I mean, we messed up the management (and I wonder who'll start bashing me for
this one), resulting in the community being misguided sometimes. Making it hard
to learn how to contribute too (too many rules etc). Custodians being
overloaded, warding people off because the review takes too long ... stuff like
that is what I meant.

So we have too much to improve, yet too less time to do that.

Ad community, there's a lot of people obviously, who contribute regularly (of
course, such as yourself for example). But I wonder if there's enough of us to
maintain such a big codebase we have. Besides, people care about linux a lot
more than about uboot, pushing many more of the maintaining tasks on custodians.
Or maybe it's the structure that doesn't work well enough to handle the flow.
Honestly, I'm getting lost in it myself.



Hi Marek,

I think you misunderstood. I was smiling and laughing when I shot you that note.

All of this discussion about process is welcome and positive, and from where
I stand, things ain't that broken...

U-Boot has a tremendous amount of value to a lot of folks, including those that
don't always chime in or feed back.

Those of you that focus on it every day deserve kudos.

Regards,


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

[U-Boot] RFC - PatchTrack Specification

[Graeme Russ]

Hi All,

Here's a quick-and-dirty specification for a patch tracking tool...

PatchTrack is designed to help alleviate some of the load from custodians
manging a email based work flow accepting patches from a large community
of contributors

Functionality:
 - Monitor an electronic mailing list, extracting patches as they are
   posted to the list
 - Group patchsets that are posted using x/y style numbering. The patches
   within the set are grouped under the 0/y patch
 - Run arbitrarily defined stand-alone sanity checks on each patch. For
   example, the 'checkpatch' script can be run to check that each incoming
   patch obeys the style rules of the project
 - Associate each patch with a git repository. Association is determined
   by tags in the patch subject header
 - Maintain the revision history of each patch
 - Maintain community comments sent to the mailing list for each patch
 - Collect Ack'd, Nack'd, Tested, etc. community feedback (the feedback
   tags are configurable)
 - Maintain a 'patch stack' of unapplied patches for each configure
   repository. The patch stack is maintained as a 'first in, first served'
   list of patches
 - Test that each patch stack applies to the HEAD of the associated git
   repository
 - Re-test that the patch stack applies whenever the HEAD of the
   associated git repository changes


Interface:
The primary interface to PatchTrack is emails extracted from a configured
mailbox.

PatchTrack also provides a web-based interface which allows a user to
visualise the patch stack for each repository. For each configured
repository, the web interface will display associated patches in
chronologically ordered rows. Each row is a single patch. patch sets
are grouped together using the timestamp of the fist patch. The following
information is displayed in each row:
 - Patch name/subject
 - Author
 - Number of received Ack, Nack, Tested, etc. feedbacks

The colour of each row indicates the 'quality' of the patch:
 - Red indicates the patch does not apply cleanly. Red patches are not
   actually in the patch stack but are displayed for completeness
 - Orange indicates that the patch does apply but has failed one or more
   of the configured sanity checks
 - Yellow indicates that the patch applies and passed all configured sanity
   checks
 - Green indicates that the patch has been accepted by a maintainer. All
   green patches are placed at the top of the stack (i.e. they are always
   applied first) in order of acceptance (not submission order)
 - White indicates that the patch has been applied to the repository

Clicking on any row will expand the row (clicking again will collapse the
row). An expanded row displays the following information:
 - Ack'd, Nack'd, Tested, etc. tags
 - Sanity check results
 - Patch apply result
 - Comments
 - Patch body

The web interface will provide an authenticated login. When a maintainer of
a repository is logged in, they can:
 - Reject a patch, removing it from the patch stack entirely
 - Accept a patch. When a patch is accepted, PatchTrack will check that the
   patch applies cleanly to the HEAD of previously accepted patches
 - Apply the top 'x' accepted patches the git repository
 - Purge applied patches from PatchTrack
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/4] net: sh_eth: clean up for the SH7757's code

[Shimoda, Yoshihiro]

Hi,

Thank you for the reply. I will wait until it is merged.

Best regards,
Yoshihiro Shimoda

2012/07/23 15:27, Nobuhiro Iwamatsu wrote:
> Hi,
> 
> Perhaps, your patch already are in Joe' patch queue, I think.
>   http://patchwork.ozlabs.org/patch/167486/
> 
> Nobuhiro
> 
> 2012/7/23 Shimoda, Yoshihiro :
>> Hi Iwamatsu-san,
>>
>> Thank for the test and Acked-by:
>>
>> Today I checked remotes/origin/{master,next} in u-boot-net.git,
>> but, the patches have not applied yet.
>> Should I resend the patches?
>>
>> Best regards,
>> Yoshihiro Shimoda
>>
>> 2012/06/29 10:55, Nobuhiro Iwamatsu wrote:
>>> Tested-off-by: Nobuhiro Iwamatsu 
>>> Acked-by: Nobuhiro Iwamatsu 
>>>
>>> 2012/6/27 Shimoda, Yoshihiro :
 The SH7757's ETHER can work using the SH7724's setting. So, the patch
 modifies it.

 Signed-off-by: Yoshihiro Shimoda 
 ---
  drivers/net/sh_eth.c |9 +
  drivers/net/sh_eth.h |   14 ++
  2 files changed, 3 insertions(+), 20 deletions(-)

 diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
 index bb57e4d..1825059 100644
 --- a/drivers/net/sh_eth.c
 +++ b/drivers/net/sh_eth.c
 @@ -376,12 +376,7 @@ static int sh_eth_config(struct sh_eth_dev *eth, bd_t 
 *bd)
outl((FIFO_F_D_RFF | FIFO_F_D_RFD), FCFTR(port));

/* Configure e-mac registers */
 -#if defined(CONFIG_CPU_SH7757)
 -   outl(ECSIPR_BRCRXIP | ECSIPR_PSRTOIP | ECSIPR_LCHNGIP |
 -   ECSIPR_MPDIP | ECSIPR_ICDIP, ECSIPR(port));
 -#else
outl(0, ECSIPR(port));
 -#endif

/* Set Mac address */
val = dev->enetaddr[0] << 24 | dev->enetaddr[1] << 16 |
 @@ -395,14 +390,12 @@ static int sh_eth_config(struct sh_eth_dev *eth, 
 bd_t *bd)
  #if !defined(CONFIG_CPU_SH7757) && !defined(CONFIG_CPU_SH7724)
outl(0, PIPR(port));
  #endif
 -#if !defined(CONFIG_CPU_SH7724)
 +#if !defined(CONFIG_CPU_SH7724) && !defined(CONFIG_CPU_SH7757)
outl(APR_AP, APR(port));
outl(MPR_MP, MPR(port));
  #endif
  #if defined(CONFIG_CPU_SH7763) || defined(CONFIG_CPU_SH7734)
outl(TPAUSER_TPAUSE, TPAUSER(port));
 -#elif defined(CONFIG_CPU_SH7757)
 -   outl(TPAUSER_UNLIMITED, TPAUSER(port));
  #endif

  #if defined(CONFIG_CPU_SH7734)
 diff --git a/drivers/net/sh_eth.h b/drivers/net/sh_eth.h
 index 50f4b69..5276be3 100644
 --- a/drivers/net/sh_eth.h
 +++ b/drivers/net/sh_eth.h
 @@ -319,7 +319,7 @@ enum EESR_BIT {
EESR_FTC  = 0x0020, EESR_TDE  = 0x0010,
EESR_TFE  = 0x0008, EESR_FRC  = 0x0004,
EESR_RDE  = 0x0002, EESR_RFE  = 0x0001,
 -#if defined(CONFIG_CPU_SH7724) && !defined(CONFIG_CPU_SH7757)
 +#if defined(CONFIG_CPU_SH7724) || defined(CONFIG_CPU_SH7757)
EESR_CND  = 0x0800,
  #endif
EESR_DLC  = 0x0400,
 @@ -426,9 +426,7 @@ enum FELIC_MODE_BIT {
  #if defined(CONFIG_CPU_SH7763) || defined(CONFIG_CPU_SH7734)
  #define ECMR_CHG_DM(ECMR_TRCCM | ECMR_RZPF | ECMR_ZPF | ECMR_PFR | 
 ECMR_RXF | \
ECMR_TXF | ECMR_MCT)
 -#elif CONFIG_CPU_SH7757
 -#define ECMR_CHG_DM(ECMR_ZPF)
 -#elif CONFIG_CPU_SH7724
 +#elif CONFIG_CPU_SH7724 || CONFIG_CPU_SH7757
  #define ECMR_CHG_DM (ECMR_ZPF | ECMR_PFR | ECMR_RXF | ECMR_TXF)
  #else
  #define ECMR_CHG_DM(ECMR_ZPF | ECMR_PFR | ECMR_RXF | ECMR_TXF | 
 ECMR_MCT)
 @@ -473,20 +471,12 @@ enum ECSIPR_STATUS_MASK_BIT {

  /* APR */
  enum APR_BIT {
 -#ifdef CONFIG_CPU_SH7757
 -   APR_AP = 0x0001,
 -#else
APR_AP = 0x0004,
 -#endif
  };

  /* MPR */
  enum MPR_BIT {
 -#ifdef CONFIG_CPU_SH7757
 -   MPR_MP = 0x0001,
 -#else
MPR_MP = 0x0006,
 -#endif
  };

  /* TRSCER */
 --
 1.7.1
>>>
>>
>>
>> --
>> Yoshihiro Shimoda 
>> EC No.
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
> 
> 
> 


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

[U-Boot] [PATCH] sh: modify checkcpu() for SH-4A

[Shimoda, Yoshihiro]

Even if using CPU is SH-4A, the previous code always put "SH4".
This patch fixes it.

Signed-off-by: Yoshihiro Shimoda 
---
 arch/sh/cpu/sh4/cpu.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/sh/cpu/sh4/cpu.c b/arch/sh/cpu/sh4/cpu.c
index f136758..7da1ef7 100644
--- a/arch/sh/cpu/sh4/cpu.c
+++ b/arch/sh/cpu/sh4/cpu.c
@@ -29,7 +29,11 @@

 int checkcpu(void)
 {
+#ifdef CONFIG_SH4A
+   puts("CPU: SH-4A\n");
+#else
puts("CPU: SH4\n");
+#endif
return 0;
 }

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

Re: [U-Boot] [PATCH] arm: rmobile: kzm9g: Fix CONFIG_BAUDRATE setting

[Nobuhiro Iwamatsu]

Hi,

Applied to rmobile branch.

Best regards,
  Nobuhiro

2012/7/20 Tetsuyuki Kobayshi :
> From: Tetsuyuki Kobayashi 
>
> The value of CONFIG_BAUDRATE is treated as string and put as initial value of 
> environment variable. If it begin with '(', it is wrongly parsed to 0 in 
> number. So I removed '(' and ')'.
>
> Signed-off-by: Tetsuyuki Kobayashi 
> ---
> Hi, Iwamatsu-san
>
> This is a kind of regression. The initial value of environment variable of 
> barud rate is wrong. When you flash U-Boot to a new board, serial console 
> doesn't work because board rate is set to 0. If you save environment 
> variables in old version U-Boot, you don't aware this problem.
>
>
>  include/configs/kzm9g.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/configs/kzm9g.h b/include/configs/kzm9g.h
> index bd157d9..14f088f 100644
> --- a/include/configs/kzm9g.h
> +++ b/include/configs/kzm9g.h
> @@ -46,7 +46,7 @@
>  #define CONFIG_CMD_FAT
>  #define CONFIG_CMD_BOOTZ
>
> -#define CONFIG_BAUDRATE(115200)
> +#define CONFIG_BAUDRATE115200
>  #define CONFIG_BOOTARGS"root=/dev/null console=ttySC4,115200"
>  #define CONFIG_INTEGRATOR
>  #define CONFIG_ARCH_CINTEGRATOR
> --
> 1.7.9.5
>
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] sh: modify checkcpu() for SH-4A

[Nobuhiro Iwamatsu]

Applied, thanks.

Best regards,
  Nobuhiro

2012/7/24 Shimoda, Yoshihiro :
> Even if using CPU is SH-4A, the previous code always put "SH4".
> This patch fixes it.
>
> Signed-off-by: Yoshihiro Shimoda 
> ---
>  arch/sh/cpu/sh4/cpu.c |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)
>
> diff --git a/arch/sh/cpu/sh4/cpu.c b/arch/sh/cpu/sh4/cpu.c
> index f136758..7da1ef7 100644
> --- a/arch/sh/cpu/sh4/cpu.c
> +++ b/arch/sh/cpu/sh4/cpu.c
> @@ -29,7 +29,11 @@
>
>  int checkcpu(void)
>  {
> +#ifdef CONFIG_SH4A
> +   puts("CPU: SH-4A\n");
> +#else
> puts("CPU: SH4\n");
> +#endif
> return 0;
>  }
>
> --
> 1.7.1



-- 
Nobuhiro Iwamatsu
   iwamatsu at {nigauri.org / debian.org}
   GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [V2 14/15] S3C64XX: Move s3c6400.h to cpu.h to support s3c6410 board

[Minkyu Kang]

Dear Zhong Hongbo,

On 14 July 2012 01:11, Zhong Hongbo  wrote:
> From: Zhong Hongbo 
>
> Signed-off-by: Zhong Hongbo 
> ---
> Change for V2:
> - New.
> ---
>  arch/arm/cpu/arm1176/s3c64xx/pwm.c  |2 +-
>  arch/arm/cpu/arm1176/s3c64xx/reset.S|2 +-
>  arch/arm/cpu/arm1176/s3c64xx/speed.c|2 +-
>  arch/arm/cpu/arm1176/s3c64xx/srom.c |2 +-
>  arch/arm/cpu/arm1176/s3c64xx/timer.c|2 +-
>  arch/arm/include/asm/arch-s3c64xx/cpu.h |   83 ++
>  arch/arm/include/asm/arch-s3c64xx/s3c6400.h |   84 
> ---
>  board/samsung/smdk6400/lowlevel_init.S  |2 +-
>  board/samsung/smdk6400/mem_init.S   |2 +-
>  board/samsung/smdk6400/smdk6400.c   |2 +-
>  drivers/mtd/nand/s3c64xx.c  |2 +-
>  drivers/serial/s3c64xx.c|2 +-
>  drivers/usb/host/s3c64xx-hcd.c  |2 +-
>  13 files changed, 94 insertions(+), 95 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-s3c64xx/cpu.h
>  delete mode 100644 arch/arm/include/asm/arch-s3c64xx/s3c6400.h
>
> diff --git a/arch/arm/cpu/arm1176/s3c64xx/pwm.c 
> b/arch/arm/cpu/arm1176/s3c64xx/pwm.c
> index d1d70ff..02822fc 100644
> --- a/arch/arm/cpu/arm1176/s3c64xx/pwm.c
> +++ b/arch/arm/cpu/arm1176/s3c64xx/pwm.c
> @@ -28,7 +28,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>
>  int pwm_enable(int pwm_id)
> diff --git a/arch/arm/cpu/arm1176/s3c64xx/reset.S 
> b/arch/arm/cpu/arm1176/s3c64xx/reset.S
> index 9e5ee84..ee96d6c 100644
> --- a/arch/arm/cpu/arm1176/s3c64xx/reset.S
> +++ b/arch/arm/cpu/arm1176/s3c64xx/reset.S
> @@ -21,7 +21,7 @@
>   * MA 02111-1307 USA
>   */
>
> -#include 
> +#include 
>
>  .globl reset_cpu
>  reset_cpu:
> diff --git a/arch/arm/cpu/arm1176/s3c64xx/speed.c 
> b/arch/arm/cpu/arm1176/s3c64xx/speed.c
> index 05b44b9..5e68090 100644
> --- a/arch/arm/cpu/arm1176/s3c64xx/speed.c
> +++ b/arch/arm/cpu/arm1176/s3c64xx/speed.c
> @@ -32,7 +32,7 @@
>
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>
>  #define APLL 0
> diff --git a/arch/arm/cpu/arm1176/s3c64xx/srom.c 
> b/arch/arm/cpu/arm1176/s3c64xx/srom.c
> index f1b2b34..92fb7af 100644
> --- a/arch/arm/cpu/arm1176/s3c64xx/srom.c
> +++ b/arch/arm/cpu/arm1176/s3c64xx/srom.c
> @@ -25,7 +25,7 @@
>  #include 
>  #include 
>  #include 
> -#include 
> +#include 
>  /*
>   * s3c64xx_config_sromc() - select the proper SROMC Bank and configure the
>   * band width control and bank control registers
> diff --git a/arch/arm/cpu/arm1176/s3c64xx/timer.c 
> b/arch/arm/cpu/arm1176/s3c64xx/timer.c
> index 47d7731..eebd0c0 100644
> --- a/arch/arm/cpu/arm1176/s3c64xx/timer.c
> +++ b/arch/arm/cpu/arm1176/s3c64xx/timer.c
> @@ -25,7 +25,7 @@
>
>  #include 
>  #include 
> -#include 
> +#include 
>  #include 
>  #include 
>
> diff --git a/arch/arm/include/asm/arch-s3c64xx/cpu.h 
> b/arch/arm/include/asm/arch-s3c64xx/cpu.h
> new file mode 100644
> index 000..5c8dd9d
> --- /dev/null
> +++ b/arch/arm/include/asm/arch-s3c64xx/cpu.h
> @@ -0,0 +1,83 @@
> +/*
> + * (C) Copyright 2007
> + * Byungjae Lee, Samsung Erectronics, bj...@samsung.com.
> + *  - only support for S3C6400
> + *
> + * (C) Copyright 2008
> + * Guennadi Liakhovetki, DENX Software Engineering, 
> + *
> + * 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
> + */
> +
> +/
> + * NAME: s3c64XX.h
> + *
> + * Based on S3C64XX User's manual Rev 0.0
> + /
> +
> +#ifndef __ASM_ARCH_CPU_H__
> +#define __ASM_ARCH_CPU_H__
> +
> +#if defined(CONFIG_SYNC_MODE) && defined(CONFIG_S3C6400)
> +#error CONFIG_SYNC_MODE unavailable on S3C6400, please, fix your 
> configuration!
> +#endif
> +
> +#define S3C64XX_UART_CHANNELS  3
> +#define S3C64XX_SPI_CHANNELS   2
> +
> +#include 
> +
> +#define ELFIN_CLOCK_POWER_BASE 0x7e00f000
> +#define ELFIN_GPIO_BASE0x7f008000
> +#define ELFIN_SROM_BASE0x7000
> +#define ELFIN_DMC0_BASE0x7e00
> +#define ELFIN_DMC1_BASE0x7e001000
> +#define ELFIN_MEM_SYS_CFG  0x7e00f120
> +#define ELFIN_NAND_BASE0x7020
> +#define ELFIN_VIC0_BAS

Re: [U-Boot] RFC - PatchTrack Specification

[Marek Vasut]

Dear Graeme Russ,

> Hi All,
> 
> Here's a quick-and-dirty specification for a patch tracking tool...

And here comes our RMK of U-Boot world, the philosopher ;-)

> PatchTrack is designed to help alleviate some of the load from custodians
> manging a email based work flow accepting patches from a large community
> of contributors
> 
> Functionality:
>  - Monitor an electronic mailing list, extracting patches as they are
>posted to the list
>  - Group patchsets that are posted using x/y style numbering. The patches
>within the set are grouped under the 0/y patch
>  - Run arbitrarily defined stand-alone sanity checks on each patch. For
>example, the 'checkpatch' script can be run to check that each incoming
>patch obeys the style rules of the project
>  - Associate each patch with a git repository. Association is determined
>by tags in the patch subject header
>  - Maintain the revision history of each patch
>  - Maintain community comments sent to the mailing list for each patch
>  - Collect Ack'd, Nack'd, Tested, etc. community feedback (the feedback
>tags are configurable)
>  - Maintain a 'patch stack' of unapplied patches for each configure
>repository. The patch stack is maintained as a 'first in, first served'
>list of patches
>  - Test that each patch stack applies to the HEAD of the associated git
>repository

But if you stack the patches, they tend to interfere with each other ... so you 
might also want to try applying them in the order they arrived or something. 
But 
hey, it's 6:20 am in here, don't expect too constructive comment now.

>  - Re-test that the patch stack applies whenever the HEAD of the
>associated git repository changes

Yup, sounds very nice and about what we need. Leaving out the build testing was 
good idea, though working it in later might be necessary.

> 
> Interface:
> The primary interface to PatchTrack is emails extracted from a configured
> mailbox.

I told you, emails can be forged.

> PatchTrack also provides a web-based interface which allows a user to
> visualise the patch stack for each repository. For each configured
> repository, the web interface will display associated patches in
> chronologically ordered rows. Each row is a single patch. patch sets
> are grouped together using the timestamp of the fist patch. The following
> information is displayed in each row:
>  - Patch name/subject
>  - Author
>  - Number of received Ack, Nack, Tested, etc. feedbacks

Patchwork can be tweaked to do this, right?

> The colour of each row indicates the 'quality' of the patch:
>  - Red indicates the patch does not apply cleanly. Red patches are not
>actually in the patch stack but are displayed for completeness
>  - Orange indicates that the patch does apply but has failed one or more
>of the configured sanity checks
>  - Yellow indicates that the patch applies and passed all configured sanity
>checks

Why not make it "yellow" -- patch has warnings ; "green" -- patch passed checks 
;  -- patch is frozen (aka. accepted)

>  - Green indicates that the patch has been accepted by a maintainer. All
>green patches are placed at the top of the stack (i.e. they are always
>applied first) in order of acceptance (not submission order)
>  - White indicates that the patch has been applied to the repository
> 
> Clicking on any row will expand the row (clicking again will collapse the
> row). An expanded row displays the following information:
>  - Ack'd, Nack'd, Tested, etc. tags
>  - Sanity check results
>  - Patch apply result
>  - Comments
>  - Patch body
> 
> The web interface will provide an authenticated login. When a maintainer of
> a repository is logged in, they can:
>  - Reject a patch, removing it from the patch stack entirely
>  - Accept a patch. When a patch is accepted, PatchTrack will check that the
>patch applies cleanly to the HEAD of previously accepted patches
>  - Apply the top 'x' accepted patches the git repository
>  - Purge applied patches from PatchTrack

Mm mm ... I like this, do you plan to hack on it? :)

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

Re: [U-Boot] [PATCH v2] ext2fs: fix warning: 'blocknxt' may be used uninitialized

[Thierry Reding]

On Mon, Jul 23, 2012 at 11:56:00AM -0700, Tom Rini wrote:
> On Sun, Jul 08, 2012 at 10:55:16PM +0200, Wolfgang Denk wrote:
> > Dear Kim Phillips,
> > 
> > In message <20120703174156.a1082309c2b205216606a...@freescale.com> you 
> > wrote:
> > > This warning was introduced in 436da3c "ext2load: increase read
> > > speed":
> > > 
> > > ext2fs.c: In function 'ext2fs_read_file':
> > > ext2fs.c:458:19: warning: 'blocknxt' may be used uninitialized in this 
> > > func=
> > > tion [-Wuninitialized]
> > > 
> > > this change makes it go away.
> > > 
> > > Cc: Eric Nelson 
> > > Cc: Thierry Reding 
> > > Cc: Jason Cooper 
> > > Cc: Andreas Bie=DFmann 
> > > Cc: Reinhard Arlt 
> > > Signed-off-by: Kim Phillips 
> > > ---
> > > v2: changed to Thierry's recommendation in:
> > > 
> > > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/134043
> > > 
> > > build-tested only - please ack
> > > 
> > >  fs/ext2/ext2fs.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > Applied, thanks.
> 
> This doesn't fix the warning for ELDK 4.2 toolchains (gcc 4.2.2):
> ext2fs.c: In function 'ext2fs_read_file':
> ext2fs.c:443: warning: 'blocknxt' may be used uninitialized in this
> function

I've seen older toolchains fail a lot at detecting situations like this.
I think starting with 4.5 things got a lot better.

Thierry


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

Re: [U-Boot] [PATCH 08/10] dm: tegra: Staticize local functions in usb.c

[Simon Glass]

On Sat, Jul 21, 2012 at 4:02 PM, Marek Vasut  wrote:
> Signed-off-by: Marek Vasut 
> Cc: Simon Glass 
> Cc: Tom Warren 
> Cc: Wolfgang Denk 
> Cc: Albert Aribaud 
> Cc: U-Boot DM 

Ooops.

Acked-by: Simon Glass 

> ---
>  arch/arm/cpu/armv7/tegra2/usb.c |7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/tegra2/usb.c b/arch/arm/cpu/armv7/tegra2/usb.c
> index 5f2b243..ea7f701 100644
> --- a/arch/arm/cpu/armv7/tegra2/usb.c
> +++ b/arch/arm/cpu/armv7/tegra2/usb.c
> @@ -158,7 +158,8 @@ static void set_host_mode(struct fdt_usb *config)
> }
>  }
>
> -void usbf_reset_controller(struct fdt_usb *config, struct usb_ctlr *usbctlr)
> +static void usbf_reset_controller(struct fdt_usb *config,
> +   struct usb_ctlr *usbctlr)
>  {
> /* Reset the USB controller with 2us delay */
> reset_periph(config->periph_id, 2);
> @@ -382,8 +383,8 @@ int tegrausb_stop_port(void)
> return 0;
>  }
>
> -int fdt_decode_usb(const void *blob, int node, unsigned osc_frequency_mhz,
> -  struct fdt_usb *config)
> +static int fdt_decode_usb(const void *blob, int node,
> +   unsigned osc_frequency_mhz, struct fdt_usb *config)
>  {
> const char *phy, *mode;
>
> --
> 1.7.10.4
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 08/10] dm: tegra: Staticize local functions in usb.c

[Marek Vasut]

Dear Simon Glass,

> On Sat, Jul 21, 2012 at 4:02 PM, Marek Vasut  wrote:
> > Signed-off-by: Marek Vasut 
> > Cc: Simon Glass 
> > Cc: Tom Warren 
> > Cc: Wolfgang Denk 
> > Cc: Albert Aribaud 
> > Cc: U-Boot DM 
> 
> Acked-by: Simon Glass 

Simon, can you please pick up this one separatelly through your tree? I already 
agreed with Tom to rip this apart as it's not really a series, but rather a 
dump 
of random patches and cleanups. This is basically the first chapter of my 
crusade towards making you crazy from breakage ... I mean ... cleaning up 
drivers scattered across arch/ directory and moving them to drivers/ directory 
...

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