Re: [PATCH 1/2] docs: mvebu can do 2nd stage booting

[Sascha Hauer]

On Fri, Jun 02, 2017 at 08:22:03PM +0200, Uwe Kleine-König wrote:
> Since commit
> 
>   823d08e3e261 ("kwbimage_v1: add support to boot a mvebu image")
> 
> barebox can use bootm to load a 2nd barebox image. Update the
> documentation accordingly.
> 
> Signed-off-by: Uwe Kleine-König 
> ---
>  Documentation/boards/mvebu.rst | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/boards/mvebu.rst b/Documentation/boards/mvebu.rst
> index b4f8e6043dac..4dfdc4a8f761 100644
> --- a/Documentation/boards/mvebu.rst
> +++ b/Documentation/boards/mvebu.rst
> @@ -28,8 +28,8 @@ initialisation that could be taken.
>  Booting second stage
>  
>  
> -This is currently not possible because barebox assumes the registers are 
> mapped
> -at 0xd000 as is the case when the boot ROM gives control to the 
> bootloader.
> +Since ``v2017.04.0`` barebox can boot a barebox image even if the register
> +window is moved. This is implemented by writing the actual window position 
> into the image where it is then picked up by the second stage bootloader.

Applied with an additional line break, thanks

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] ratp: avoid using already freed memory

[Sascha Hauer]

On Fri, Jun 02, 2017 at 05:48:28PM +0200, Aleksander Morgado wrote:
> If ratp_establish() fails we would be accessing the ratp_internal
> struct after having disposed it.
> 
> Signed-off-by: Aleksander Morgado 
> ---
>  lib/ratp.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks

Sascha

> 
> diff --git a/lib/ratp.c b/lib/ratp.c
> index d596a0e8b..22e83636f 100644
> --- a/lib/ratp.c
> +++ b/lib/ratp.c
> @@ -1658,6 +1658,8 @@ int ratp_establish(struct ratp *ratp, bool active, int 
> timeout_ms)
>   }
>  
>  out:
> + ri->in_ratp--;
> +
>   if (ret) {
>   free(ri->recvbuf);
>   free(ri->sendbuf);
> @@ -1665,8 +1667,6 @@ out:
>   ratp->internal = NULL;
>   }
>  
> - ri->in_ratp--;
> -
>   return ret;
>  }
>  
> -- 
> 2.13.0
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] fs: Makefile: Add parseopt to all builds

[Sascha Hauer]

On Fri, Jun 02, 2017 at 01:11:36PM +0200, Daniel Schultz wrote:
> parseopt.h was included to fs.c with commit 9248b, but parseopt.o has a
> dependency to CONFIG_FS_NFS.
> 
> Moved parseopt.o to the default build to eliminate build failures.
> 
> Signed-off-by: Daniel Schultz 
> ---
>  fs/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks

Sascha

> 
> diff --git a/fs/Makefile b/fs/Makefile
> index f2bb702..b3f929f 100644
> --- a/fs/Makefile
> +++ b/fs/Makefile
> @@ -4,11 +4,11 @@ obj-$(CONFIG_FS_RAMFS)  += ramfs.o
>  obj-y+= devfs-core.o
>  obj-$(CONFIG_FS_DEVFS)   += devfs.o
>  obj-$(CONFIG_FS_FAT) += fat/
> -obj-y+= fs.o
> +obj-y+= fs.o parseopt.o
>  obj-$(CONFIG_FS_UBIFS)   += ubifs/
>  obj-$(CONFIG_FS_TFTP)+= tftp.o
>  obj-$(CONFIG_FS_OMAP4_USBBOOT)   += omap4_usbbootfs.o
> -obj-$(CONFIG_FS_NFS) += nfs.o parseopt.o
> +obj-$(CONFIG_FS_NFS) += nfs.o
>  obj-$(CONFIG_FS_BPKFS) += bpkfs.o
>  obj-$(CONFIG_FS_UIMAGEFS)+= uimagefs.o
>  obj-$(CONFIG_FS_EFI)  += efi.o
> -- 
> 1.9.1
> 
> 
> ___
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH v3 3/4] arm: boards: phytec-som-am335x: Update boot scripts

[Sascha Hauer]

Hi Daniel,

On Fri, Jun 02, 2017 at 10:07:34AM +0200, Daniel Schultz wrote:
> Hi,
> 
> Am 17.05.2017 um 08:30 schrieb Sascha Hauer:
> > On Fri, May 12, 2017 at 01:07:18PM +0200, Daniel Schultz wrote:
> > > Expand the boot scripts with EMMC and add a default file source for
> > > expansions.
> > > 
> > > Removed "rw" and "rootwait" bootargs from existing boot scripts.
> > > Added "rootflags='data=journal'" bootarg to SD card boot script.
> > > 
> > > Signed-off-by: Daniel Schultz 
> > > ---
> > >   .../defaultenv-physom-am335x/boot/emmc  |  7 +++
> > >   .../phytec-som-am335x/defaultenv-physom-am335x/boot/mmc |  7 ---
> > >   .../defaultenv-physom-am335x/boot/nand  |  4 +++-
> > >   .../phytec-som-am335x/defaultenv-physom-am335x/boot/net | 17 
> > > +
> > >   .../phytec-som-am335x/defaultenv-physom-am335x/boot/spi |  4 +++-
> > >   .../defaultenv-physom-am335x/init/bootsource| 16 
> > > 
> > >   6 files changed, 46 insertions(+), 9 deletions(-)
> > >   create mode 100644 
> > > arch/arm/boards/phytec-som-am335x/defaultenv-physom-am335x/boot/emmc
> > >   create mode 100644 
> > > arch/arm/boards/phytec-som-am335x/defaultenv-physom-am335x/boot/net
> > > 
> > > diff --git 
> > > a/arch/arm/boards/phytec-som-am335x/defaultenv-physom-am335x/boot/emmc 
> > > b/arch/arm/boards/phytec-som-am335x/defaultenv-physom-am335x/boot/emmc
> > > new file mode 100644
> > > index 000..6ad5f87
> > > --- /dev/null
> > > +++ b/arch/arm/boards/phytec-som-am335x/defaultenv-physom-am335x/boot/emmc
> > > @@ -0,0 +1,7 @@
> > > +#!/bin/sh
> > > +
> > > +[ -e /env/config-expansions ] && /env/config-expansions
> > 
> > What do you have in these config-expansions or what do you expect to be
> > there?
> > 
> 
> These config-expanions files contain source commands for different
> expansions like HDMI, LCD, WiFi, ... and are written from Yocto. We don't
> want to bring these mainline, but without this line we have to overwrite
> each boot script file from Yocto.
> 
> Maybe this could be a good feature since we're not the only one with
> expansion configurations.

I am generally open to such expansions, I just want to understand what's
missing first.
In this case I'd like to understand why you can't add an init script to
/env/bin/init/ instead. If you want to extend the kernel commandline you
could also add a nv variable to /env/nv/linux.bootargs.yocto.

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

Re: [PATCH] console: only bidirectional consoles allow RATP

[Sascha Hauer]

Hi Aleksander,

On Thu, Jun 01, 2017 at 08:14:57PM +0200, Aleksander Morgado wrote:
> If a request to switch to RATP mode is received in an input-only
> console, ignore the request.
> 
> This actually also avoids segfaulting later on:
> 
> #0  0x in ?? ()
> #1  0x0040b2a4 in console_send (r=, 
> pkt=0x7fffd8ec, len=4) at common/ratp.c:102
> #2  0x0042ab99 in ratp_behaviour_a (pkt=0x77298780, 
> ri=0x772766d0) at lib/ratp.c:530
> #3  ratp_state_machine (pkt=0x77298780, ri=0x772766d0) at 
> lib/ratp.c:1384
> #4  ratp_poll (ratp=0x77277ed8) at lib/ratp.c:1561
> #5  0x0042b2ab in ratp_establish (ratp=ratp@entry=0x77277ed8, 
> active=active@entry=false, timeout_ms=timeout_ms@entry=100) at lib/ratp.c:1645
> #6  0x0040b888 in barebox_ratp (cdev=cdev@entry=0x77212bd0) 
> at common/ratp.c:470
> #7  0x004046c3 in getc_raw () at common/console.c:416
> ...
> 
> Signed-off-by: Aleksander Morgado 
> ---
> 
> Hey Sascha,
> 
> Looks like I may actually need to update the options to allow setting up 
> bidirectional consoles, instead of separate input/output ones. Otherwise I 
> won't be able to use RATP over the FIFO-based console. This patch fixes a 
> segfault happening in barebox sandbox when the input-only console receives a 
> request to switch to RATP mode, it ends up crashing afterwards when the 
> SYN/ACK response is to be sent via the non-existent output path.
> 
> Cheers!
> 
> ---
>  common/console.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/common/console.c b/common/console.c
> index f4c799fa5..f8677659e 100644
> --- a/common/console.c
> +++ b/common/console.c
> @@ -412,7 +412,9 @@ static int getc_raw(void)
>   if (cdev->tstc(cdev)) {
>   int ch = cdev->getc(cdev);
> 
> - if (IS_ENABLED(CONFIG_RATP) && ch == 0x01) {
> + if (IS_ENABLED(CONFIG_RATP) &&
> + ch == 0x01 &&
> + (cdev->f_active & CONSOLE_STDOUT)) {
>   barebox_ratp(cdev);

Can we add a test for the existence of cdev->getc and cdev->putc in
barebox_ratp() instead? It makes it more explicit that the ratp code
needs this and also works when somebody cally barebox_ratp() directly.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

RFC: barebox RATP C library?

[Aleksander Morgado]

Hey,

I've been playing a bit with the possibility of having a C library to
talk RATP with barebox, totally equivalent to what bbremote does in
python, but as a general C lib with a stable API that may be
integrated in other C/C++ applications.

>From my POV I see two options to try:
   a) build a library based on lib/ratp.c and common/ratp.c but
without directly sharing the source code; i.e. just take bits and
pieces from those implementations where necessary, and write the
library as any other userspace library.
   b) build a small library that allows including lib/ratp.c (and
maybe common/ratp.c) directly in the build, but which would require
those files to be updated in a way that allow being shared by a
separate library that isn't running in the whole barebox runtime
context.

I'm not sure if anyone has thoughts on this; I initially thought b)
would be definitely the way to go, but the current implementation
seems too tied to the actual barebox runtime, so maybe it's just
easier to setup a) and just share e.g. the barebox RATP message format
structs, enums and so on.

Comments, suggestions?

-- 
Aleksander
https://aleksander.es

___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox