* [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
[parent not found: <56091F9A.5050506@schmelzer.or.at>]
[parent not found: <CAEUhbmXsXKV_TjxawYckT2+H6x1XqO2BN7DrCrQq3QrKvaLP7Q@mail.gmail.com>]
[parent not found: <CAEUhbmUBdTr=fLiHtpZjEJXjOOqTuBFJeX0O2Ambk9CANj_=Cw@mail.gmail.com>]
* [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.