* [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline
@ 2015-09-28 8:33 Hannes Schmelzer
2015-09-28 9:06 ` Bin Meng
0 siblings, 1 reply; 10+ messages in thread
From: Hannes Schmelzer @ 2015-09-28 8:33 UTC (permalink / raw)
To: u-boot
Since we don't have for sure a valid IP-setup during
board_late_init(...) because it maybe allready stored in environment or
not, we cannot form a proper vxWorks bootline at this place.
So we move to the way, forming the bootline just before
executing/launching vxWorks with "go <address>".
At this time we have a valid IP-setup for sure because it is either in
environment or defined through CONFIG_PREBOOT command.
To do this, we overload the __weak function "do_go_exec(...)" with our
own and do the job.
Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
---
board/BuR/kwb/board.c | 23 ++++++++++++++---------
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/board/BuR/kwb/board.c b/board/BuR/kwb/board.c
index 039ec20..703a474 100644
--- a/board/BuR/kwb/board.c
+++ b/board/BuR/kwb/board.c
@@ -281,6 +281,19 @@ int board_late_init(void)
} else {
puts("ERROR: i2c_set_bus_speed failed! (scratchregister)\n");
}
+ /*
+ * reset VBAR registers to its reset location, VxWorks 6.9.3.2 does
+ * expect that vectors are there, original u-boot moves them to _start
+ */
+ __asm__("ldr r0,=0x20000");
+ __asm__("mcr p15, 0, r0, c12, c0, 0"); /* Set VBAR */
+
+ return 0;
+}
+#endif /* CONFIG_BOARD_LATE_INIT */
+unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
+ char * const argv[])
+{
/* setup vxworks bootline */
char *vxworksbootline = (char *)VXWORKS_BOOTLINE;
sprintf(vxworksbootline,
@@ -295,13 +308,5 @@ int board_late_init(void)
(u32)getenv_ulong("vx_romfsbase", 16, 0),
(u32)getenv_ulong("vx_romfssize", 16, 0));
- /*
- * reset VBAR registers to its reset location, VxWorks 6.9.3.2 does
- * expect that vectors are there, original u-boot moves them to _start
- */
- __asm__("ldr r0,=0x20000");
- __asm__("mcr p15, 0, r0, c12, c0, 0"); /* Set VBAR */
-
- return 0;
+ return entry(argc, argv);
}
-#endif /* CONFIG_BOARD_LATE_INIT */
--
1.9.1
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline
2015-09-28 8:33 [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline Hannes Schmelzer
@ 2015-09-28 9:06 ` Bin Meng
2015-09-28 9:17 ` Hannes Schmelzer
0 siblings, 1 reply; 10+ messages in thread
From: Bin Meng @ 2015-09-28 9:06 UTC (permalink / raw)
To: u-boot
Hi Hannes,
On Mon, Sep 28, 2015 at 4:33 PM, Hannes Schmelzer <oe5hpm@oevsv.at> wrote:
> Since we don't have for sure a valid IP-setup during
> board_late_init(...) because it maybe allready stored in environment or
> not, we cannot form a proper vxWorks bootline at this place.
>
> So we move to the way, forming the bootline just before
> executing/launching vxWorks with "go <address>".
> At this time we have a valid IP-setup for sure because it is either in
> environment or defined through CONFIG_PREBOOT command.
>
> To do this, we overload the __weak function "do_go_exec(...)" with our
> own and do the job.
>
> Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
>
I don't understand the technical details here on this board, but can
we use the generic 'bootvx' command to handle the VxWorks bootline?
> ---
>
> board/BuR/kwb/board.c | 23 ++++++++++++++---------
> 1 file changed, 14 insertions(+), 9 deletions(-)
>
> diff --git a/board/BuR/kwb/board.c b/board/BuR/kwb/board.c
> index 039ec20..703a474 100644
> --- a/board/BuR/kwb/board.c
> +++ b/board/BuR/kwb/board.c
> @@ -281,6 +281,19 @@ int board_late_init(void)
> } else {
> puts("ERROR: i2c_set_bus_speed failed! (scratchregister)\n");
> }
> + /*
> + * reset VBAR registers to its reset location, VxWorks 6.9.3.2 does
> + * expect that vectors are there, original u-boot moves them to _start
> + */
> + __asm__("ldr r0,=0x20000");
> + __asm__("mcr p15, 0, r0, c12, c0, 0"); /* Set VBAR */
> +
> + return 0;
> +}
> +#endif /* CONFIG_BOARD_LATE_INIT */
> +unsigned long do_go_exec(ulong (*entry)(int, char * const []), int argc,
> + char * const argv[])
> +{
> /* setup vxworks bootline */
> char *vxworksbootline = (char *)VXWORKS_BOOTLINE;
> sprintf(vxworksbootline,
> @@ -295,13 +308,5 @@ int board_late_init(void)
> (u32)getenv_ulong("vx_romfsbase", 16, 0),
> (u32)getenv_ulong("vx_romfssize", 16, 0));
>
> - /*
> - * reset VBAR registers to its reset location, VxWorks 6.9.3.2 does
> - * expect that vectors are there, original u-boot moves them to _start
> - */
> - __asm__("ldr r0,=0x20000");
> - __asm__("mcr p15, 0, r0, c12, c0, 0"); /* Set VBAR */
> -
> - return 0;
> + return entry(argc, argv);
> }
> -#endif /* CONFIG_BOARD_LATE_INIT */
> --
> 1.9.1
Regards,
Bin
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline
2015-09-28 9:06 ` Bin Meng
@ 2015-09-28 9:17 ` Hannes Schmelzer
2015-09-28 9:20 ` Bin Meng
0 siblings, 1 reply; 10+ messages in thread
From: Hannes Schmelzer @ 2015-09-28 9:17 UTC (permalink / raw)
To: u-boot
> Hi Hannes,
Hi Bin,
thanks for reply.
>
> On Mon, Sep 28, 2015 at 4:33 PM, Hannes Schmelzer <oe5hpm@oevsv.at>
wrote:
> > Since we don't have for sure a valid IP-setup during
> > board_late_init(...) because it maybe allready stored in environment
or
> > not, we cannot form a proper vxWorks bootline at this place.
> >
> > So we move to the way, forming the bootline just before
> > executing/launching vxWorks with "go <address>".
> > At this time we have a valid IP-setup for sure because it is either in
> > environment or defined through CONFIG_PREBOOT command.
> >
> > To do this, we overload the __weak function "do_go_exec(...)" with our
> > own and do the job.
> >
> > Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
> >
>
> I don't understand the technical details here on this board, but can
> we use the generic 'bootvx' command to handle the VxWorks bootline?
At first i had a look to this, but unfortunately it is not useable for my
case, because we are passing
serveral things more through the bootline to our vxWorks kernel.
Especially o=... contains several information like framebuffer address,
factory-settings address and so on.
Further we have FTP-Filesystem, so we pass additional arguments (
u=vxWorksFTP pw=vxWorks).
>
> > ---
> >
> > board/BuR/kwb/board.c | 23 ++++++++++++++---------
> > 1 file changed, 14 insertions(+), 9 deletions(-)
> >
> > diff --git a/board/BuR/kwb/board.c b/board/BuR/kwb/board.c
> > index 039ec20..703a474 100644
> > --- a/board/BuR/kwb/board.c
> > +++ b/board/BuR/kwb/board.c
> > @@ -281,6 +281,19 @@ int board_late_init(void)
> > } else {
> > puts("ERROR: i2c_set_bus_speed failed!
(scratchregister)\n");
> > }
> > + /*
> > + * reset VBAR registers to its reset location, VxWorks 6.9.3.2
does
> > + * expect that vectors are there, original u-boot moves them
to _start
> > + */
> > + __asm__("ldr r0,=0x20000");
> > + __asm__("mcr p15, 0, r0, c12, c0, 0"); /* Set VBAR */
> > +
> > + return 0;
> > +}
> > +#endif /* CONFIG_BOARD_LATE_INIT */
> > +unsigned long do_go_exec(ulong (*entry)(int, char * const []), int
argc,
> > + char * const argv[])
> > +{
> > /* setup vxworks bootline */
> > char *vxworksbootline = (char *)VXWORKS_BOOTLINE;
> > sprintf(vxworksbootline,
> > @@ -295,13 +308,5 @@ int board_late_init(void)
> > (u32)getenv_ulong("vx_romfsbase", 16, 0),
> > (u32)getenv_ulong("vx_romfssize", 16, 0));
> >
> > - /*
> > - * reset VBAR registers to its reset location, VxWorks 6.9.3.2
does
> > - * expect that vectors are there, original u-boot moves them
to _start
> > - */
> > - __asm__("ldr r0,=0x20000");
> > - __asm__("mcr p15, 0, r0, c12, c0, 0"); /* Set VBAR */
> > -
> > - return 0;
> > + return entry(argc, argv);
> > }
> > -#endif /* CONFIG_BOARD_LATE_INIT */
> > --
> > 1.9.1
>
> Regards,
> Bin
best regards,
Hannes
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline
2015-09-28 9:17 ` Hannes Schmelzer
@ 2015-09-28 9:20 ` Bin Meng
2015-09-28 9:28 ` [U-Boot] Antwort: Re: " Hannes Schmelzer
0 siblings, 1 reply; 10+ messages in thread
From: Bin Meng @ 2015-09-28 9:20 UTC (permalink / raw)
To: u-boot
Hi Hannes,
On Mon, Sep 28, 2015 at 5:17 PM, Hannes Schmelzer
<Hannes.Schmelzer@br-automation.com> wrote:
>> Hi Hannes,
> Hi Bin,
> thanks for reply.
>
>>
>> On Mon, Sep 28, 2015 at 4:33 PM, Hannes Schmelzer <oe5hpm@oevsv.at>
> wrote:
>> > Since we don't have for sure a valid IP-setup during
>> > board_late_init(...) because it maybe allready stored in environment
> or
>> > not, we cannot form a proper vxWorks bootline at this place.
>> >
>> > So we move to the way, forming the bootline just before
>> > executing/launching vxWorks with "go <address>".
>> > At this time we have a valid IP-setup for sure because it is either in
>> > environment or defined through CONFIG_PREBOOT command.
>> >
>> > To do this, we overload the __weak function "do_go_exec(...)" with our
>> > own and do the job.
>> >
>> > Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
>> >
>>
>> I don't understand the technical details here on this board, but can
>> we use the generic 'bootvx' command to handle the VxWorks bootline?
>
> At first i had a look to this, but unfortunately it is not useable for my
> case, because we are passing
> serveral things more through the bootline to our vxWorks kernel.
> Especially o=... contains several information like framebuffer address,
> factory-settings address and so on.
> Further we have FTP-Filesystem, so we pass additional arguments (
> u=vxWorksFTP pw=vxWorks).
>
Could you please try this patch series [1] instead?
With that series, we can construct VxWorks bootline from U-Boot env.
Like you can store your additional bootline info to U-Boot env
variable "othbootargs", like
=> setenv othbootargs u=vxWorksFTP pw=vxWorks o=fb_addr=xxx factory_setting=yyy
[1] http://patchwork.ozlabs.org/patch/523276/
Regards,
Bin
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] Antwort: Re: Re: [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline
2015-09-28 9:20 ` Bin Meng
@ 2015-09-28 9:28 ` Hannes Schmelzer
2015-09-28 10:08 ` [U-Boot] " Bin Meng
0 siblings, 1 reply; 10+ messages in thread
From: Hannes Schmelzer @ 2015-09-28 9:28 UTC (permalink / raw)
To: u-boot
> Hi Hannes,
Hi,
>
> On Mon, Sep 28, 2015 at 5:17 PM, Hannes Schmelzer
> <Hannes.Schmelzer@br-automation.com> wrote:
> >> Hi Hannes,
> > Hi Bin,
> > thanks for reply.
> >
> >>
> >> On Mon, Sep 28, 2015 at 4:33 PM, Hannes Schmelzer <oe5hpm@oevsv.at>
> > wrote:
> >> > Since we don't have for sure a valid IP-setup during
> >> > board_late_init(...) because it maybe allready stored in
environment
> > or
> >> > not, we cannot form a proper vxWorks bootline at this place.
> >> >
> >> > So we move to the way, forming the bootline just before
> >> > executing/launching vxWorks with "go <address>".
> >> > At this time we have a valid IP-setup for sure because it is either
in
> >> > environment or defined through CONFIG_PREBOOT command.
> >> >
> >> > To do this, we overload the __weak function "do_go_exec(...)" with
our
> >> > own and do the job.
> >> >
> >> > Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
> >> >
> >>
> >> I don't understand the technical details here on this board, but can
> >> we use the generic 'bootvx' command to handle the VxWorks bootline?
> >
> > At first i had a look to this, but unfortunately it is not useable for
my
> > case, because we are passing
> > serveral things more through the bootline to our vxWorks kernel.
> > Especially o=... contains several information like framebuffer
address,
> > factory-settings address and so on.
> > Further we have FTP-Filesystem, so we pass additional arguments (
> > u=vxWorksFTP pw=vxWorks).
> >
>
> Could you please try this patch series [1] instead?
>
> With that series, we can construct VxWorks bootline from U-Boot env.
> Like you can store your additional bootline info to U-Boot env
> variable "othbootargs", like
>
> => setenv othbootargs u=vxWorksFTP pw=vxWorks o=fb_addr=xxx
factory_setting=yyy
I will have a closer look to this.
The framebuffer base is stored at this time in gd->fb_base
sprintf(vxworksbootline,
"%s h=%s e=%s:%s g=%s %s o=0x%08x;0x%08x;0x%08x;0x%08x",
DEFAULT_BOOTLINE,
getenv("serverip"),
getenv("ipaddr"), getenv("netmask"),
getenv("gatewayip"),
VXWORKS_USER,
(unsigned int) gd->fb_base-0x20,
(u32)getenv_ulong("vx_memtop", 16, gd->fb_base-0x20),
(u32)getenv_ulong("vx_romfsbase", 16, 0),
(u32)getenv_ulong("vx_romfssize", 16, 0));
do you thank that i cal realize a bootline like this with current tools?
>
>
> [1] http://patchwork.ozlabs.org/patch/523276/
>
> Regards,
> Bin
best regars,
Hannes
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline
2015-09-28 9:28 ` [U-Boot] Antwort: Re: " Hannes Schmelzer
@ 2015-09-28 10:08 ` Bin Meng
2015-09-28 10:12 ` Hannes Schmelzer
0 siblings, 1 reply; 10+ messages in thread
From: Bin Meng @ 2015-09-28 10:08 UTC (permalink / raw)
To: u-boot
Hi Hannes,
On Mon, Sep 28, 2015 at 5:28 PM, Hannes Schmelzer
<Hannes.Schmelzer@br-automation.com> wrote:
>> Hi Hannes,
> Hi,
>
>>
>> On Mon, Sep 28, 2015 at 5:17 PM, Hannes Schmelzer
>> <Hannes.Schmelzer@br-automation.com> wrote:
>> >> Hi Hannes,
>> > Hi Bin,
>> > thanks for reply.
>> >
>> >>
>> >> On Mon, Sep 28, 2015 at 4:33 PM, Hannes Schmelzer <oe5hpm@oevsv.at>
>> > wrote:
>> >> > Since we don't have for sure a valid IP-setup during
>> >> > board_late_init(...) because it maybe allready stored in
> environment
>> > or
>> >> > not, we cannot form a proper vxWorks bootline at this place.
>> >> >
>> >> > So we move to the way, forming the bootline just before
>> >> > executing/launching vxWorks with "go <address>".
>> >> > At this time we have a valid IP-setup for sure because it is either
> in
>> >> > environment or defined through CONFIG_PREBOOT command.
>> >> >
>> >> > To do this, we overload the __weak function "do_go_exec(...)" with
> our
>> >> > own and do the job.
>> >> >
>> >> > Signed-off-by: Hannes Schmelzer <oe5hpm@oevsv.at>
>> >> >
>> >>
>> >> I don't understand the technical details here on this board, but can
>> >> we use the generic 'bootvx' command to handle the VxWorks bootline?
>> >
>> > At first i had a look to this, but unfortunately it is not useable for
> my
>> > case, because we are passing
>> > serveral things more through the bootline to our vxWorks kernel.
>> > Especially o=... contains several information like framebuffer
> address,
>> > factory-settings address and so on.
>> > Further we have FTP-Filesystem, so we pass additional arguments (
>> > u=vxWorksFTP pw=vxWorks).
>> >
>>
>> Could you please try this patch series [1] instead?
>>
>> With that series, we can construct VxWorks bootline from U-Boot env.
>> Like you can store your additional bootline info to U-Boot env
>> variable "othbootargs", like
>>
>> => setenv othbootargs u=vxWorksFTP pw=vxWorks o=fb_addr=xxx
> factory_setting=yyy
> I will have a closer look to this.
> The framebuffer base is stored at this time in gd->fb_base
>
> sprintf(vxworksbootline,
> "%s h=%s e=%s:%s g=%s %s o=0x%08x;0x%08x;0x%08x;0x%08x",
> DEFAULT_BOOTLINE,
> getenv("serverip"),
> getenv("ipaddr"), getenv("netmask"),
> getenv("gatewayip"),
> VXWORKS_USER,
> (unsigned int) gd->fb_base-0x20,
> (u32)getenv_ulong("vx_memtop", 16, gd->fb_base-0x20),
> (u32)getenv_ulong("vx_romfsbase", 16, 0),
> (u32)getenv_ulong("vx_romfssize", 16, 0));
>
> do you thank that i cal realize a bootline like this with current tools?
>
Yes, I think you can do something like setenv("othbootargs",
addtional_bootlines) where addtional_bootlines holds the value for
frame buffer address from gd->fb_base.
>>
>>
>> [1] http://patchwork.ozlabs.org/patch/523276/
>>
Regards,
Bin
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline
2015-09-28 10:08 ` [U-Boot] " Bin Meng
@ 2015-09-28 10:12 ` Hannes Schmelzer
2015-09-28 10:13 ` Bin Meng
0 siblings, 1 reply; 10+ messages in thread
From: Hannes Schmelzer @ 2015-09-28 10:12 UTC (permalink / raw)
To: u-boot
> Hi Hannes,
Hi,
> >>
> >> Could you please try this patch series [1] instead?
> >>
> >> With that series, we can construct VxWorks bootline from U-Boot env.
> >> Like you can store your additional bootline info to U-Boot env
> >> variable "othbootargs", like
> >>
> >> => setenv othbootargs u=vxWorksFTP pw=vxWorks o=fb_addr=xxx
> > factory_setting=yyy
> > I will have a closer look to this.
> > The framebuffer base is stored at this time in gd->fb_base
> >
> > sprintf(vxworksbootline,
> > "%s h=%s e=%s:%s g=%s %s
o=0x%08x;0x%08x;0x%08x;0x%08x",
> > DEFAULT_BOOTLINE,
> > getenv("serverip"),
> > getenv("ipaddr"), getenv("netmask"),
> > getenv("gatewayip"),
> > VXWORKS_USER,
> > (unsigned int) gd->fb_base-0x20,
> > (u32)getenv_ulong("vx_memtop", 16, gd->fb_base-0x20),
> > (u32)getenv_ulong("vx_romfsbase", 16, 0),
> > (u32)getenv_ulong("vx_romfssize", 16, 0));
> >
> > do you thank that i cal realize a bootline like this with current
tools?
> >
>
> Yes, I think you can do something like setenv("othbootargs",
> addtional_bootlines) where addtional_bootlines holds the value for
> frame buffer address from gd->fb_base.
OK, the plan would be:
a) setup some othbootargs out from board.c (because gd->fb_base isn't
accessible through cli)
b) call bootvx instead go ... to start vxWorks kernel
right?
>
> Regards,
> Bin
regards,
Hannes
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline
2015-09-28 10:12 ` Hannes Schmelzer
@ 2015-09-28 10:13 ` Bin Meng
[not found] ` <56091F9A.5050506@schmelzer.or.at>
0 siblings, 1 reply; 10+ messages in thread
From: Bin Meng @ 2015-09-28 10:13 UTC (permalink / raw)
To: u-boot
Hi Hannes,
On Mon, Sep 28, 2015 at 6:12 PM, Hannes Schmelzer
<Hannes.Schmelzer@br-automation.com> wrote:
>> Hi Hannes,
> Hi,
>
>> >>
>> >> Could you please try this patch series [1] instead?
>> >>
>> >> With that series, we can construct VxWorks bootline from U-Boot env.
>> >> Like you can store your additional bootline info to U-Boot env
>> >> variable "othbootargs", like
>> >>
>> >> => setenv othbootargs u=vxWorksFTP pw=vxWorks o=fb_addr=xxx
>> > factory_setting=yyy
>> > I will have a closer look to this.
>> > The framebuffer base is stored at this time in gd->fb_base
>> >
>> > sprintf(vxworksbootline,
>> > "%s h=%s e=%s:%s g=%s %s
> o=0x%08x;0x%08x;0x%08x;0x%08x",
>> > DEFAULT_BOOTLINE,
>> > getenv("serverip"),
>> > getenv("ipaddr"), getenv("netmask"),
>> > getenv("gatewayip"),
>> > VXWORKS_USER,
>> > (unsigned int) gd->fb_base-0x20,
>> > (u32)getenv_ulong("vx_memtop", 16, gd->fb_base-0x20),
>> > (u32)getenv_ulong("vx_romfsbase", 16, 0),
>> > (u32)getenv_ulong("vx_romfssize", 16, 0));
>> >
>> > do you thank that i cal realize a bootline like this with current
> tools?
>> >
>>
>> Yes, I think you can do something like setenv("othbootargs",
>> addtional_bootlines) where addtional_bootlines holds the value for
>> frame buffer address from gd->fb_base.
>
> OK, the plan would be:
>
> a) setup some othbootargs out from board.c (because gd->fb_base isn't
> accessible through cli)
> b) call bootvx instead go ... to start vxWorks kernel
>
> right?
>
Yes, that's correct.
Regards,
Bin
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline
[not found] ` <CAEUhbmUBdTr=fLiHtpZjEJXjOOqTuBFJeX0O2Ambk9CANj_=Cw@mail.gmail.com>
@ 2015-09-29 5:58 ` Hannes Schmelzer
2015-09-29 6:10 ` Bin Meng
0 siblings, 1 reply; 10+ messages in thread
From: Hannes Schmelzer @ 2015-09-29 5:58 UTC (permalink / raw)
To: u-boot
Hi Bin,
works now well.
Also the thing with bootvx and the bootline works fine.
I will send some v2 of my patch today.
many thanks and best regards,
Hannes
On 29.09.2015 04:46, Bin Meng wrote:
> Hi Hannes,
>
> On Mon, Sep 28, 2015 at 8:01 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>> Hi Hannes,
>>
>> On Mon, Sep 28, 2015 at 7:08 PM, Hannes Schmelzer
>> <hannes@schmelzer.or.at> wrote:
>>> Hi Bin,
>>>
>>> i am not able to apply your patch from
>>> http://patchwork.ozlabs.org/patch/523289/
>>> to most current master.
>>>
>>> schmelzerh at hpm-debian ~/work/u-boot $ git am
>>> U-Boot-v2-01-13-Reorder-defconfigs-with-savedefconfig.patch
>>> Applying: Reorder defconfigs with 'savedefconfig'
>>> error: patch failed: configs/e2220-1170_defconfig:9
>>> error: configs/e2220-1170_defconfig: patch does not apply
>>> error: patch failed: configs/p2371-0000_defconfig:9
>>> error: configs/p2371-0000_defconfig: patch does not apply
>>> error: patch failed: configs/p2571_defconfig:9
>>> error: configs/p2571_defconfig: patch does not apply
>>> Patch failed at 0001 Reorder defconfigs with 'savedefconfig'
>>>
>>> maybe you've to rebase your working branch.
>>>
>> Sorry. Yes, I forgot to rebase. Will send a new patch soon.
>>
> The patch#1 has been merged into u-boot/master. Please apply patch
> 2-13 on top of latest mainline in the series and have a try.
>
> Regards,
> Bin
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline
2015-09-29 5:58 ` Hannes Schmelzer
@ 2015-09-29 6:10 ` Bin Meng
0 siblings, 0 replies; 10+ messages in thread
From: Bin Meng @ 2015-09-29 6:10 UTC (permalink / raw)
To: u-boot
Hi Hannes,
On Tue, Sep 29, 2015 at 1:58 PM, Hannes Schmelzer
<hannes@schmelzer.or.at> wrote:
> Hi Bin,
>
> works now well.
> Also the thing with bootvx and the bootline works fine.
Great to hear! Maybe you can add a 'Tested-by' tag to my series if you like.
>
> I will send some v2 of my patch today.
>
> many thanks and best regards,
> Hannes
>
>
> On 29.09.2015 04:46, Bin Meng wrote:
>>
>> Hi Hannes,
>>
>> On Mon, Sep 28, 2015 at 8:01 PM, Bin Meng <bmeng.cn@gmail.com> wrote:
>>>
>>> Hi Hannes,
>>>
>>> On Mon, Sep 28, 2015 at 7:08 PM, Hannes Schmelzer
>>> <hannes@schmelzer.or.at> wrote:
>>>>
>>>> Hi Bin,
>>>>
>>>> i am not able to apply your patch from
>>>> http://patchwork.ozlabs.org/patch/523289/
>>>> to most current master.
>>>>
>>>> schmelzerh at hpm-debian ~/work/u-boot $ git am
>>>> U-Boot-v2-01-13-Reorder-defconfigs-with-savedefconfig.patch
>>>> Applying: Reorder defconfigs with 'savedefconfig'
>>>> error: patch failed: configs/e2220-1170_defconfig:9
>>>> error: configs/e2220-1170_defconfig: patch does not apply
>>>> error: patch failed: configs/p2371-0000_defconfig:9
>>>> error: configs/p2371-0000_defconfig: patch does not apply
>>>> error: patch failed: configs/p2571_defconfig:9
>>>> error: configs/p2571_defconfig: patch does not apply
>>>> Patch failed at 0001 Reorder defconfigs with 'savedefconfig'
>>>>
>>>> maybe you've to rebase your working branch.
>>>>
>>> Sorry. Yes, I forgot to rebase. Will send a new patch soon.
>>>
>> The patch#1 has been merged into u-boot/master. Please apply patch
>> 2-13 on top of latest mainline in the series and have a try.
>>
Regards,
Bin
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-09-29 6:10 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-09-28 8:33 [U-Boot] [PATCH] board/BuR/kwb: implement board-specific do_go_exec to form vxWorks bootline Hannes Schmelzer
2015-09-28 9:06 ` Bin Meng
2015-09-28 9:17 ` Hannes Schmelzer
2015-09-28 9:20 ` Bin Meng
2015-09-28 9:28 ` [U-Boot] Antwort: Re: " Hannes Schmelzer
2015-09-28 10:08 ` [U-Boot] " Bin Meng
2015-09-28 10:12 ` Hannes Schmelzer
2015-09-28 10:13 ` Bin Meng
[not found] ` <56091F9A.5050506@schmelzer.or.at>
[not found] ` <CAEUhbmXsXKV_TjxawYckT2+H6x1XqO2BN7DrCrQq3QrKvaLP7Q@mail.gmail.com>
[not found] ` <CAEUhbmUBdTr=fLiHtpZjEJXjOOqTuBFJeX0O2Ambk9CANj_=Cw@mail.gmail.com>
2015-09-29 5:58 ` Hannes Schmelzer
2015-09-29 6:10 ` Bin Meng
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.