Re: [PATCH v2 4/4] boards: qemu-virt: support passing in FIT public key

[Jan Lübbe]

On Fri, 2023-02-10 at 17:53 +0100, Ahmad Fatoum wrote:
> FIT public key is usually passed in via board DT. Usual way to use
> barebox with QEMU Virt however is to use DT supplied by Qemu and apply
> overlay to it. mkimage doesn't generate overlay DTB though. To make
> barbebox Qemu Virt behave like other boards, let's define a dummy DT
> that includes CONFIG_BOOTM_FITIMAGE_PUBKEY, which is merged with the
> barebox live device tree.
> 
> Suggested-by: Jan Lübbe 
> Signed-off-by: Ahmad Fatoum 

For the whole series:

Tested-by: Jan Lübbe 

> ---
> v1 -> v2:
>   - no changes
> ---
>  common/boards/qemu-virt/Makefile| 2 +-
>  common/boards/qemu-virt/board.c | 7 ++-
>  common/boards/qemu-virt/fitimage-pubkey.dts | 7 +++
>  3 files changed, 14 insertions(+), 2 deletions(-)
>  create mode 100644 common/boards/qemu-virt/fitimage-pubkey.dts
> 
> diff --git a/common/boards/qemu-virt/Makefile 
> b/common/boards/qemu-virt/Makefile
> index 88184e9a7969..00bfdfbda696 100644
> --- a/common/boards/qemu-virt/Makefile
> +++ b/common/boards/qemu-virt/Makefile
> @@ -1,7 +1,7 @@
>  # SPDX-License-Identifier: GPL-2.0-only
>  
>  obj-y += board.o
> -obj-y += overlay-of-flash.dtb.o
> +obj-y += overlay-of-flash.dtb.o fitimage-pubkey.dtb.o
>  ifeq ($(CONFIG_RISCV),y)
>  DTC_CPP_FLAGS_overlay-of-flash.dtb := -DRISCV_VIRT=1
>  endif
> diff --git a/common/boards/qemu-virt/board.c b/common/boards/qemu-virt/board.c
> index ec92ae94aec9..2669e9de5a2a 100644
> --- a/common/boards/qemu-virt/board.c
> +++ b/common/boards/qemu-virt/board.c
> @@ -35,10 +35,11 @@ static inline void arm_virt_init(void) {}
>  #endif
>  
>  extern char __dtb_overlay_of_flash_start[];
> +extern char __dtb_fitimage_pubkey_start[];
>  
>  static int virt_probe(struct device *dev)
>  {
> - struct device_node *overlay;
> + struct device_node *overlay, *pubkey;
>   void (*init)(void);
>  
>   init = device_get_match_data(dev);
> @@ -47,6 +48,10 @@ static int virt_probe(struct device *dev)
>  
>   overlay = of_unflatten_dtb(__dtb_overlay_of_flash_start, INT_MAX);
>   of_overlay_apply_tree(dev->of_node, overlay);
> +
> + pubkey = of_unflatten_dtb(__dtb_fitimage_pubkey_start, INT_MAX);
> + of_merge_nodes(dev->of_node, pubkey);
> +
>   /* of_probe() will happen later at of_populate_initcall */
>  
>   return 0;
> diff --git a/common/boards/qemu-virt/fitimage-pubkey.dts 
> b/common/boards/qemu-virt/fitimage-pubkey.dts
> new file mode 100644
> index ..497799fa4b60
> --- /dev/null
> +++ b/common/boards/qemu-virt/fitimage-pubkey.dts
> @@ -0,0 +1,7 @@
> +/dts-v1/;
> +
> +#ifdef CONFIG_BOOTM_FITIMAGE_PUBKEY
> +#include CONFIG_BOOTM_FITIMAGE_PUBKEY
> +#endif
> +
> +/{ };

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH 2/4] bbremote: Convert to python3

[Jan Lübbe]

On Tue, 2022-09-06 at 12:20 +0200, Sascha Hauer wrote:
> This is the long overdue conversion from python2 to python3.
> 
> Signed-off-by: Sascha Hauer 
> ---
>  scripts/bbremote  |  2 +-
>  scripts/remote/controller.py  | 21 +++--
>  scripts/remote/main.py    |  8 
>  scripts/remote/messages.py    | 15 +--
>  scripts/remote/ratp.py    |  4 ++--
>  scripts/remote/ratpfs.py  |  4 ++--
>  scripts/remote/threadstdio.py |  4 ++--
>  7 files changed, 35 insertions(+), 23 deletions(-)
> 
> diff --git a/scripts/bbremote b/scripts/bbremote
> index bc5351dbae..1eeabd08d1 100755
> --- a/scripts/bbremote
> +++ b/scripts/bbremote
> @@ -1,3 +1,3 @@
> -#!/usr/bin/env python2
> +#!/usr/bin/env python3
>  
>  import remote.main
> diff --git a/scripts/remote/controller.py b/scripts/remote/controller.py
> index b4493591dd..a3ae260558 100644
> --- a/scripts/remote/controller.py
> +++ b/scripts/remote/controller.py
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env python2
> +#!/usr/bin/env python3
>  # -*- coding: utf-8 -*-
>  
>  from __future__ import absolute_import, division, print_function
> @@ -8,7 +8,7 @@ import logging
>  import sys
>  import os
>  from threading import Thread
> -from Queue import Queue, Empty
> +from queue import Queue, Empty
>  from .ratpfs import RatpFSServer
>  from .messages import *
>  from .ratp import RatpError
> @@ -105,7 +105,7 @@ class Controller(Thread):
>  self.rxq = None
>  self.conn.connect(timeout=5.0)
>  self._txq = Queue()
> -    self._stop = False
> +    self._stopit = False

Is this rename needed?

>  self.fsserver = RatpFSServer()
>  
>  def _send(self, bbpkt):
> @@ -147,24 +147,24 @@ class Controller(Thread):
>  return 0
>  
>  def command(self, cmd):
> -    self._send(BBPacketCommand(cmd=cmd))
> +    self._send(BBPacketCommand(cmd=cmd.encode()))
>  r = self._expect(BBPacketCommandReturn, timeout=None)
>  logging.info("Command: %r", r)
>  return r.exit_code
>  
>  def getenv(self, varname):
> -    self._send(BBPacketGetenv(varname=varname))
> +    self._send(BBPacketGetenv(varname=varname.encode()))
>  r = self._expect(BBPacketGetenvReturn)
>  return r.text
>  
>  def md(self, path, addr, size):
> -    self._send(BBPacketMd(path=path, addr=addr, size=size))
> +    self._send(BBPacketMd(path=path.encode(), addr=addr, size=size))
>  r = self._expect(BBPacketMdReturn)
>  logging.info("Md return: %r", r)
>  return (r.exit_code,r.data)
>  
>  def mw(self, path, addr, data):
> -    self._send(BBPacketMw(path=path, addr=addr, data=data))
> +    self._send(BBPacketMw(path=path.encode(), addr=addr, data=data))
>  r = self._expect(BBPacketMwReturn)
>  logging.info("Mw return: %r", r)
>  return (r.exit_code,r.written)
> @@ -208,7 +208,7 @@ class Controller(Thread):
>  def run(self):
>  assert self.rxq is not None
>  try:
> -    while not self._stop:
> +    while not self._stopit:
>  # receive
>  pkt = self.conn.recv()
>  if pkt:
> @@ -235,15 +235,16 @@ class Controller(Thread):
>  Thread.start(self)
>  
>  def stop(self):
> -    self._stop = True
> +    self._stopit = True
>  self.join()
> -    self._stop = False
> +    self._stopit = False
>  self.rxq = None
>  
>  def send_async(self, pkt):
>  self._txq.put(pkt)
>  
>  def send_async_console(self, text):
> +    assert isinstance(text, bytes)
>  self._txq.put(BBPacketConsoleMsg(text=text))
>  
>  def send_async_ping(self):
> diff --git a/scripts/remote/main.py b/scripts/remote/main.py
> index cef5d92ee2..b99dba180a 100644
> --- a/scripts/remote/main.py
> +++ b/scripts/remote/main.py
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env python2
> +#!/usr/bin/env python3
>  
>  from __future__ import absolute_import, division, print_function
>  
> @@ -7,7 +7,7 @@ import os
>  import argparse
>  import binascii
>  import logging
> -from Queue import Queue
> +from queue import Queue
>  from .ratp import RatpError
>  
>  try:
> @@ -162,8 +162,8 @@ def handle_console(args):
>  ctrl = get_controller(args)
>  ctrl.export(args.export)
>  ctrl.start(queue)
> -    ctrl.send_async_console('\r')
> -    cons = ConsoleInput(queue, exit='\x14')  # CTRL-T
> +    ctrl.send_async_console(b'\r')
> +    cons = ConsoleInput(queue, exit=b'\x14')  # CTRL-T
>  cons.start()
>  try:
>  while True:
> diff --git a/scripts/remote/messages.py b/scripts/remote/messages.py
> index abd331c8b6..ae36189d4c 100644
> --- a/scripts/remote/messages.py
> +++ b/scripts/remote/messages.py
> @@ -1,4 +1,4 @@
> -#!/usr/bin/env python2
> +#!/usr/bin/env python3
>  # -*- coding: utf-8 -*-
>  
>  from __future__ import absolute_import, division, print_function
> @@ -41,12 +41,13 @@ class 

Re: [PATCH v2 10/13] test: add first sample tests

[Jan Lübbe]

On Wed, 2021-06-02 at 13:35 +0200, Ahmad Fatoum wrote:
> > > +def get_config(command):
> > > +    """Returns the enabled config options of barebox, either from
> > > +    a running instance if supported or by looking into .config
> > > +    in the build directory.
> > > +    Args:
> > > +    command (BareboxDriver): An instance of the BareboxDriver
> > > +    Returns:
> > > +    list: list of the enabled config options
> > > +    """
> > > +    assert isinstance(command, BareboxDriver)
> > > +
> > > +    out, err, returncode = command.run("cat /env/data/config")
> > > +    if returncode != 0:
> > > +    try:
> > > +    with open(os.environ['LG_BUILDDIR'] + "/.config") as f:
> > 
> > Please don't use the LG_ namespace currently used by labgrid, this
> > variable is introduced by your wrapper script, something like
> > BB_LG_BUILDDIR indicates that this is only used in the barebox test
> > scripts.
> 
> Labgrid filters out anything that doesn't start with LG_ AFAIK.

No. The filter is only for the environment templating. We don't touch the
os.environ dictionary.

Regards,
Jan
-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
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 09/10] RISC-V: add LiteX SoC and linux-on-litex-vexriscv support

[Jan Lübbe]

On Tue, 2021-05-25 at 10:19 +0300, Antony Pavlov wrote:
> LiteX is a Migen-based System on Chip, supporting softcore
> VexRiscv CPU, a 32-bits Linux Capable RISC-V CPU.
> 
> See https://github.com/enjoy-digital/litex and
> https://github.com/litex-hub/linux-on-litex-vexriscv
> for details.

What are your steps for testing this? We have a few ECPIX-5 here, so we should
be able to reproduce this.

Regards,
Jan

> Signed-off-by: Antony Pavlov 
> ---
>  arch/riscv/Kconfig.socs  |  14 +++
>  arch/riscv/boards/Makefile   |   1 +
>  arch/riscv/boards/litex-linux/Makefile   |   3 +
>  arch/riscv/boards/litex-linux/lowlevel.c |  22 
>  arch/riscv/dts/Makefile  |   1 +
>  arch/riscv/dts/litex-linux.dts   |  92 +
>  arch/riscv/dts/litex_soc_linux.dtsi  |  49 +
>  arch/riscv/include/asm/debug_ll.h|   3 +
>  arch/riscv/include/asm/debug_ll_litex.h  | 123 +++
>  common/Kconfig   |   4 +
>  images/Makefile.riscv|   4 +
>  11 files changed, 316 insertions(+)
> 
> diff --git a/arch/riscv/Kconfig.socs b/arch/riscv/Kconfig.socs
> index 67d19caeb3..3ae66776f0 100644
> --- a/arch/riscv/Kconfig.socs
> +++ b/arch/riscv/Kconfig.socs
> @@ -42,4 +42,18 @@ config BOARD_HIFIVE
>  
> 
> 
> 
>  endif
>  
> 
> 
> 
> +config SOC_LITEX
> + bool "LiteX SoCs"
> + depends on ARCH_RV32I
> + select HAS_ASM_DEBUG_LL
> + select HAS_NMON
> + select USE_COMPRESSED_DTB
> + select RISCV_TIMER
> +
> +config BOARD_LITEX_LINUX
> + bool "litex linux board"
> + depends on SOC_LITEX
> + select RISCV_M_MODE
> + def_bool y
> +
>  endmenu
> diff --git a/arch/riscv/boards/Makefile b/arch/riscv/boards/Makefile
> index 99f22f32b4..0468871fde 100644
> --- a/arch/riscv/boards/Makefile
> +++ b/arch/riscv/boards/Makefile
> @@ -1,3 +1,4 @@
>  # SPDX-License-Identifier: GPL-2.0
>  obj-$(CONFIG_BOARD_ERIZO_GENERIC)+= erizo/
>  obj-$(CONFIG_BOARD_HIFIVE)   += hifive/
> +obj-$(CONFIG_BOARD_LITEX_LINUX)  += litex-linux/
> diff --git a/arch/riscv/boards/litex-linux/Makefile 
> b/arch/riscv/boards/litex-linux/Makefile
> new file mode 100644
> index 00..3d217ffe0b
> --- /dev/null
> +++ b/arch/riscv/boards/litex-linux/Makefile
> @@ -0,0 +1,3 @@
> +# SPDX-License-Identifier: GPL-2.0
> +
> +pbl-y += lowlevel.o
> diff --git a/arch/riscv/boards/litex-linux/lowlevel.c 
> b/arch/riscv/boards/litex-linux/lowlevel.c
> new file mode 100644
> index 00..da23ef5633
> --- /dev/null
> +++ b/arch/riscv/boards/litex-linux/lowlevel.c
> @@ -0,0 +1,22 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +ENTRY_FUNCTION(start_litex_linux, a0, a1, a2)
> +{
> + extern char __dtb_z_litex_linux_start[];
> + void *fdt;
> +
> + barebox_nmon_entry();
> +
> + putc_ll('>');
> +
> + /* On POR, we are running from read-only memory here. */
> +
> + fdt = __dtb_z_litex_linux_start + get_runtime_offset();
> +
> + barebox_riscv_machine_entry(0x4000, SZ_256M, fdt);
> +}
> diff --git a/arch/riscv/dts/Makefile b/arch/riscv/dts/Makefile
> index 17fdc9445b..683038189f 100644
> --- a/arch/riscv/dts/Makefile
> +++ b/arch/riscv/dts/Makefile
> @@ -7,5 +7,6 @@ obj- += dummy.o
>  pbl-$(CONFIG_BOARD_ERIZO_GENERIC) += erizo-generic.dtb.o
>  pbl-$(CONFIG_BOARD_HIFIVE) += hifive-unmatched-a00.dtb.o \
>    hifive-unleashed-a00.dtb.o
> +pbl-$(CONFIG_BOARD_LITEX_LINUX) += litex-linux.dtb.o
>  
> 
> 
> 
>  clean-files := *.dtb *.dtb.S .*.dtc .*.pre .*.dts
> diff --git a/arch/riscv/dts/litex-linux.dts b/arch/riscv/dts/litex-linux.dts
> new file mode 100644
> index 00..d21fa57e30
> --- /dev/null
> +++ b/arch/riscv/dts/litex-linux.dts
> @@ -0,0 +1,92 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +
> +#include "litex_soc_linux.dtsi"
> +
> +#include 
> +
> +/ {
> + model = "LiteX VexRiscV-SoC-Linux";
> + compatible = "litex,vexriscv-soc-linux";
> +
> + aliases {
> + rom = 
> + sram = 
> + };
> +
> + /* ARTY board */
> + rom: rom@ {
> + compatible = "mmio-sram";
> + reg = <0x 0x8000>;
> + read-only;
> + };
> +
> + sram: sram@2000 {
> + compatible = "mmio-sram";
> + reg = <0x2000 0x4000>;
> + };
> +
> + main_ram: memory@4000 {
> + device_type = "memory";
> + reg = <0x4000 0x1000>;
> + };
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +};
> +
> + {
> + status = "okay";
> +
> + spiflash: w25q128@0 {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + compatible = "winbond,w25q128", "jedec,spi-nor";
> + spi-max-frequency = <10400>;
> + reg = <0>;
> + };
> +};
> +
> +/ {
> +

Re: [PATCH 7/9] RISC-V: add initial LiteX SoC support

[Jan Lübbe]

On Wed, 2021-05-05 at 13:08 +0300, Antony Pavlov wrote:
> LiteX is a Migen-based System on Chip, supporting softcore
> VexRiscv CPU, a 32-bits Linux Capable RISC-V CPU.
> 
> See https://github.com/enjoy-digital/litex and
> https://github.com/litex-hub/linux-on-litex-vexriscv
> for details.
> 
> Signed-off-by: Antony Pavlov 
> ---
> 
> 


> +config MACH_LITEX
> + bool "litex family"
> + select ARCH_RV32I
> + select HAS_DEBUG_LL
> + select HAS_NMON
> + select USE_COMPRESSED_DTB
> + select RISCV_SBI
> +


Hmm, there is also https://github.com/litex-hub/linux-on-litex-rocket/ which
uses the 64-bit RocketChip CPU. How would that fit into this naming scheme?
Would it be a different MACH?

> +/dts-v1/;
> +
> +/ {
> + compatible = "litex,vexriscv-soc-linux";
> +
> + #address-cells = <1>;
> 

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
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] mci: core: add device parameter for eMMC boot ack

[Jan Lübbe]

On Mon, 2020-05-18 at 09:08 +0200, Sascha Hauer wrote:
> There's only one correct setting for each board or SoC. Instead of
> letting the user choose between right and wrong, can't we add a hook
> to be called from the board/SoC code? A device tree property might be
> an option as well, something like barebox,enable-boot-ack.
> 
> There are also bits to change the bus width after power up which
> might need adjustments which would mean another parameter with the
> current approach.

If I remember the i.MX6 eMMC boot process correctly, there is no single
correct configuration, even for a fixed HW layout. The eFUSE and eMMC
EXT-CDS configuration just needs to match.

Instead of trying to handle all the corner cases correctly (which is
hard to test without permanently fusing HW), I'd prefer to just make it
straight-forward to set and inspect these values (via a command or
device parameters). Then these would be set once during board
manufacturing/bring-up.

After bring-up, the value in DT would be redundant configuration and
could lead to confusion if it conflicts with the FUSEs.

Regards,
Jan
-- 
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: imx6ul (phytec Segin board) USB/DFU

[Jan Lübbe]

On Wed, 2018-11-28 at 15:53 +0100, Erwin Rol wrote:
> Than when barebox runs I want to put that same USB port in DFU mode
> and update the nand flash (barebox, env, kernel, rootfs) via DFU.

If using DFU isn't a strict requirement, fastboot might be a better
alternative (support for barebox-update, ubiformat, command execution,
widely available host tool).

Regards,
Jan
-- 
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] of: Add .of suffix to device names from devicetree

[Jan Lübbe]

On Wed, 2018-11-14 at 09:52 +0100, Sascha Hauer wrote:
> Previous implementation used to add a number to the device names
> for devices registered from the device tree which did not have a 'reg'
> property, thus a device node named "state" resulted in a device name
> "state.". Current implementation skips that number and we get a
> device named "state". This conflicts with our barebox state
> implementation which tries to register a device named "state" itself.
> We could rename the state device nodes of all our device trees, but it
> causes less trouble to rename the devices.
> 
> This adds a ".of" suffix to the device names for devices registered from
> the device tree which also has the nice effect that they now can easily
> be recognized.
> 
> Fixes: 7e497d48acbd11 ("of: Port latest of_device_make_bus_id()
> implementation")

This looks like it should the fix the problem I saw in my integration
test.

Thanks,
Jan
-- 
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: bootchooser: constant decrement of remaining_attempts

[Jan Lübbe]

On Wed, 2018-10-10 at 09:14 +0200, Sascha Hauer wrote:
> Hi Patrick,
> 
> +Cc Jan and Enrico
> 
> On Tue, Oct 09, 2018 at 06:37:25PM +0200, Patrick Huesmann wrote:
> > Hi,
> > 
> > I'm building a RAUC- & bootchooser-based firmware update solution.
> > The scenario is symmetric rootfs slots, manual update, userspace
> > (RAUC) marks as good.
> > It seems to work well, however I noticed that it's always decrementing
> > and resetting the remaining_attempts of the booted system, not only
> > when there's an update, but also during regular boot-ups.
> > 
> > I thought that the RAUC/bootchooser combo was mainly about providing a
> > safeguard against accidentally "bricking" the system with corrupt or
> > incomplete firmware updates.
> > However, the logic of decrementing and later resetting the
> > remaining_attempts is apparently not limited to the period between
> > performing the update and the validation (mark as good) of that
> > update, but also running all the other times the system is booted.
> > 
> > This can have some undesirable side effects:
> > 
> > 1) When the boot process is interrupted for any reason (power issues,
> > brown-out resets, users unplugging the gadget while it boots, etc.)
> > more than three times in a row (assuming a remaining_attempts reset
> > value of 3), then bootchooser will happily switch to the fall-back
> > target, even though there's nothing wrong with the actual target at
> > all.
> 
> I think what you want here is the global.bootchooser.reset_attempts=power-on
> option. With this option bootchooser will reset the remaining attempts
> to the default value with each power on reset, meaning that the primary
> target will only become invalid when the watchdog bites you three times
> in a row, but not when the device is turned off in between.

If you want to ensure that the old system is not booted anymore, you
should set its priority to zero.

Leaving the old image enabled is useful in cases where you want to
protect against problems that occur some time after the update.

> > I guess this can be worked around by syncing the fall-back target to
> > the last updated one, after the last update has been verified as good.
> > However this brings additional cost & complexity, and feels more like
> > a hack than a proper solution.
> > 
> > 2) In every complete boot cycle, there are two writes to the
> > barebox-state partition (bootchooser decrementing the
> > remaining_attempts, then userspace resetting the remaining_attempts
> > when it marks the target as good). For systems that boot up & power
> > down a lot, this will generate lots of unnecessary flash writes over
> > time. Probably it won't be enough to actually wear out the flash, but
> > still it doesn't "feel" quite right. (I jumped through hoops to have a
> > proper read-only root and would like to limit the overall number of
> > flash writes when possible).
> > 
> > I'm thinking of an option that limits the remaining_attempts logic to
> > the phase when barebox attempts to boot a newly flashed update, until
> > that update is marked as good later in userspace. There could be an
> > extra (optional) variable in the barebox-state, that allows the
> > userspace to deliberately enable/disable the remaining_attempts logic
> > in barebox.
> 
> I don't think such an option is available at the moment. Maybe we could
> declare remaining_attempts=INT_MAX as infinite attempts. Whenever that
> value is found the remaining_attempts counter wouldn't be decreased.
> 
> After an update userspace could then set the remaining_attempts counter
> of the new system to three and the new system would set it to INT_MAX
> when successfully booted.

INT_MAX would need to be relative to the actual type defined in the
state variable (u32 vs. u8). An alternative would be to have a global
flag to en-/disable counting.

Currently there is one way to avoid writes to flash in the successful
case: Use a watchdog and call bootchooser -s, which will cause it to
skip decrementing if it boots the same target as previously. It seems
that's not documented, though. :/

Regards,
Jan
-- 
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: MFGtools support in barebox

[Jan Lübbe]

On Thu, 2018-07-19 at 07:08 +0200, Oleksij Rempel wrote:
> >   Aside from this issue, are you aware of any method of
> > flashing the barebox  on NAND from Linux(after the kernel was loaded
> > successfully on the target) ?
> > barebox_update does not exist in Linux obviously and porting it is not
> > so trivial, on top of that I don't think I am able to access the nand
> > device from Linux, but only MTD partitions .
> > I have tried  nandwrite and kobs-ng commands but I was not successful.
> 
> barebox_update is a wrapper to: take a image and write it to predefined
> project or board specific location.
> If you have access to this location from linux, you can do it from linux
> as well.

Note that i.MX6, barebox_update also generates additional headers for
the ROM loader (such as a small bad block table). A raw barebox image
without these headers cannot be booted by the ROM from NAND. This is
the reason why simple nandwrite doesn't work.

Regards,
Jan
-- 
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: MFGtools support in barebox

[Jan Lübbe]

On Wed, 2018-07-18 at 15:53 +0200, Bastian Stender wrote:
> Hi,
> 
> On 07/18/2018 03:01 PM, Oleksij Rempel wrote:
> > you email is in the list. (well, different version of it are already
> > in the list). Please wait if some one can respond here.
> > 
> > I'm not an expert, but probably what you need is
> > https://github.com/rauc
> 
> Have a look here:
> 
> http://rauc.readthedocs.io/en/latest/advanced.html#updating-the-bootloader
> 
> Updating barebox on NAND is not yet implemented. It would certainly be a
> nice feature to have. Have a look in section 7.6.2 if you want to do that.

Speaking with my rauc maintainer hat on...

Writing barebox to NAND on an i.MX6 can't be done by generic methods,
so for rauc we would want to call something like barebox-update which
then handles the details. In any case, rauc is not intended for initial
installation in the factory, but for updating in the field.

Instead of MFGtools, we usually load barebox via imx-usb-loader. That
is configured to start the fastboot gadget, which we then use to write
barebox (via barebox_update) and the rootfs.

Regards,
Jan
-- 
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 v2 03/10] ARM: i.MX6: Record reset reason as a part of startup

[Jan Lübbe]

On Wed, 2018-05-02 at 10:46 -0700, Andrey Smirnov wrote:
> On Wed, May 2, 2018 at 7:42 AM, Jan Lübbe <j...@pengutronix.de> wrote:
> > There is already code in drivers/watchdog/imxwd.c to handle this.
> > Is that obsolete now?
> 
> AFAIK, watchdog IP block doesn't have as precise information about
> reset source as SRSR register on i.MX SoCs that have the latter.
> There, this code supersedes imxwd.c. OTHO  SoCs that don't have SRSR
> (i.MX21, i.MX31, etc) still rely on code imxwd.c  for reset source
> detection.
> 
> Hope this answers your question.

Yes, thanks. I didn't realize that these were different registers.

Regards,
Jan
-- 
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 v2 03/10] ARM: i.MX6: Record reset reason as a part of startup

[Jan Lübbe]

There is already code in drivers/watchdog/imxwd.c to handle this. Is
that obsolete now?

On Fri, 2018-04-20 at 18:05 -0700, Andrey Smirnov wrote:
> Signed-off-by: Andrey Smirnov 
> ---
>  arch/arm/mach-imx/imx6.c  | 13 -
>  arch/arm/mach-imx/include/mach/reset-reason.h |  2 ++
>  2 files changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-imx/imx6.c b/arch/arm/mach-imx/imx6.c
> index 88165adee..49610bf08 100644
> --- a/arch/arm/mach-imx/imx6.c
> +++ b/arch/arm/mach-imx/imx6.c
> @@ -19,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -173,10 +174,20 @@ int imx6_cpu_revision(void)
>   return soc_revision;
>  }
>  
> +static const struct imx_reset_reason imx6_reset_reasons[] = {
> + { IMX_SRC_SRSR_IPP_RESET, RESET_POR,  0 },
> + { IMX_SRC_SRSR_WDOG1_RESET,   RESET_WDG,  0 },
> + { IMX_SRC_SRSR_JTAG_RESET,RESET_JTAG, 0 },
> + { IMX_SRC_SRSR_JTAG_SW_RESET, RESET_JTAG, 0 },
> + { IMX_SRC_SRSR_WARM_BOOT, RESET_RST,  0 },
> + { /* sentinel */ }
> +};
> +
>  int imx6_init(void)
>  {
>   const char *cputypestr;
>   u32 mx6_silicon_revision;
> + void __iomem *src = IOMEM(MX6_SRC_BASE_ADDR);
>  
>   imx6_init_lowlevel();
>  
> @@ -221,7 +232,7 @@ int imx6_init(void)
>   }
>  
>   imx_set_silicon_revision(cputypestr, mx6_silicon_revision);
> -
> + imx_set_reset_reason(src + IMX6_SRC_SRSR,
> imx6_reset_reasons);
>   imx6_setup_ipu_qos();
>   imx6ul_enet_clk_init();
>  
> diff --git a/arch/arm/mach-imx/include/mach/reset-reason.h
> b/arch/arm/mach-imx/include/mach/reset-reason.h
> index 39afc4b28..f2544a303 100644
> --- a/arch/arm/mach-imx/include/mach/reset-reason.h
> +++ b/arch/arm/mach-imx/include/mach/reset-reason.h
> @@ -14,6 +14,8 @@
>  #define IMX_SRC_SRSR_TEMPSENSE_RESET BIT(9)
>  #define IMX_SRC_SRSR_WARM_BOOT   BIT(16)
>  
> +#define IMX6_SRC_SRSR0x008
> +
>  struct imx_reset_reason {
>   uint32_t mask;
>   enum reset_src_type type;
-- 
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] blspec: add checking of optional key machine-id

[Jan Lübbe]

On Sun, 2018-04-29 at 18:01 +0200, Andreas Schmidt wrote:
> I guess, for such an use case Bootloader Spec specify "machine-id"
> key. This patch implement the support for machine-id key.

The way I read https://www.freedesktop.org/wiki/Specifications/BootLoad
erSpec/ is that the "machine-id" field should contain the ID from
/etc/machine-id, which is basically a UUID:
"machine-id shall contain the machine ID of the OS /etc/machine-id.
This is useful for boot loaders and applications to filter out boot
entries, for example to show only a single newest kernel per OS, or to
group items by OS, or to maybe filter out the currently booted OS in
UIs that want to show only other installed operating systems."

Your use-case sound like you'd need a way to add a more specific DT
board compatible at runtime. Then the existing selection logic would
handle your case as well.

Regards,
Jan
-- 
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 v1 6/6] watchdog: add watchdog poller

[Jan Lübbe]

Hi Oleksij,

On Thu, 2018-03-08 at 15:16 +0100, Oleksij Rempel wrote:
> > Also, it should be documented explicitly, that this will cause barebox
> > to keep triggering the watchdog, even when it drops to the shell after
> > a boot error. This makes it unsuitable for unattended use.
> 
> I would prefer to use controlled reboot over uncontrolled watchdog reset.
> For example it would be better to have boot and fail strategy. In case
> of network boot, it would be better to retry download in some time and
> not cause watchdog reset. If retry count exceeded then some thing should
> be done. It can be power off, reboot, fall back to CLI.

In my experience, the watchdog is used as a last resort to handle any
*unanticipated* problems. So, by definition, there isn't any code to
handle these problems. The way to do this is that the watchdog is only
triggered when the boot process has made actual progress towards a
running system. For example:
- once barebox probes the watchdog driver
- from the shell init scripts
- after loading the kernel, just before jumping to the kernel

This way, there is no possible way which could cause barebox to just
wait on the prompt: an idle or hung system will always be restarted via
the watchdog.

> The reason for controlled reboot is the fact that the reset impact (or
> Reset Sensitivity) is different for every product and source of reset.
> 
> This example is take from MiniRISC EZ4021-FC documentation:
>   SoftTAP Ctrl
> ModuleReset   Reset   PrRst   ERstTRSTReset
> CPU   yes yes yes no  no  no
> CP0   yes yes yes no  no  no
> ICCi  yes yes yes no  no  no
> DCC   yes yes yes no  no  no
> BIU   yes yes yes no  no  no
> MMU   yes no  no  no  no  no
> MDU   yes yes yes no  no  no
> EJTAG iface:
> - DMA/CPU Acc yes yes yes yes yes yes
>   logic   
> - Protocol engine yes no  no  yes yes yes
> - Breakpoint  yes no  no  yes no  no
> - PC trace yes no no yes no no

It is not clear to me from this table which reset is triggered by the
hardware watchdog. I would expect that it is the first column, which
resets everything.

> Most Atheros/QCA WiSoCs will not reset complete SoC even with watchdog
> triggered reset.

If you can't be sure that the watchdog resets enough to recover from
any transient problem, you cannot rely on it at all (and should
possibly use an external watchdog).

Regards,
Jan
-- 
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 v1 6/6] watchdog: add watchdog poller

[Jan Lübbe]

Hi Oleksij,

On Thu, 2018-03-08 at 12:05 +0100, Oleksij Rempel wrote:
> In some cases it is practical to supervise as match as possible of
s/match/much/
> barebox execution with watchdog (or multiple watchdogs). This
 ^ the  ^ a
> patch provide async poller for watchdog core framework which can
  ^-s an
> be enabled by user and store this configuration to nv.
   ^the   ^-s

Also, does this patch make the poller support required for using
watchdogs? It unconditionally calls the poller_* functions.

Also, it should be documented explicitly, that this will cause barebox
to keep triggering the watchdog, even when it drops to the shell after
a boot error. This makes it unsuitable for unattended use.

I'd prefer to make this optional at compile time.

> 
> Signed-off-by: Oleksij Rempel 
> ---
>  drivers/watchdog/wd_core.c | 54
> --
>  include/watchdog.h |  4 
>  2 files changed, 52 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/watchdog/wd_core.c b/drivers/watchdog/wd_core.c
> index 3162dd59c..6f1cadaf8 100644
> --- a/drivers/watchdog/wd_core.c
> +++ b/drivers/watchdog/wd_core.c
> @@ -31,6 +31,16 @@ static const char *watchdog_name(struct watchdog
> *wd)
>   return "unknown";
>  }
>  
> +static int _watchdog_set_timeout(struct watchdog *wd, unsigned
> timeout)
> +{
> + if (timeout > wd->timeout_max)
> + return -EINVAL;
> +
> + pr_debug("setting timeout on %s to %ds\n",
> watchdog_name(wd), timeout);
> +
> + return wd->set_timeout(wd, timeout);
> +}
> +
>  static int watchdog_set_cur(struct param_d *param, void *priv)
>  {
>   struct watchdog *wd = priv;
> @@ -41,6 +51,37 @@ static int watchdog_set_cur(struct param_d *param,
> void *priv)
>   return 0;
>  }
>  
> +static void watchdog_poller_cb(void *priv);
> +
> +static void watchdog_poller_start(struct watchdog *wd)
> +{
> + _watchdog_set_timeout(wd, wd->timeout_cur);
> + poller_call_async(>poller, 500 * MSECOND,
> + watchdog_poller_cb, wd);
> +
> +}
> +
> +static void watchdog_poller_cb(void *priv)
> +{
> + struct watchdog *wd = priv;
> +
> + if (wd->poller_enable)
> + watchdog_poller_start(wd);
> +}
> +
> +static int watchdog_set_poller(struct param_d *param, void *priv)
> +{
> + struct watchdog *wd = priv;
> +
> +
> + if (wd->poller_enable)
> + watchdog_poller_start(wd);
> + else
> + poller_async_cancel(>poller);
> +
> + return 0;
> +}
> +
>  int watchdog_register(struct watchdog *wd)
>  {
>  
> @@ -63,6 +104,10 @@ int watchdog_register(struct watchdog *wd)
>   dev_add_param_uint32(>dev, "timeout_cur",
> watchdog_set_cur, NULL,
>   >timeout_cur, "%u", wd);
>  
> + poller_async_register(>poller);
> + dev_add_param_bool(>dev, "poller_enable",
> watchdog_set_poller, NULL,
> + >poller_enable, wd);
Isn't the usage of the poller an implementation detail? Perhaps calls
this something like "auto_trigger"?

> +
>   list_add_tail(>list, _list);
>  
>   pr_debug("registering watchdog %s with priority %d\n",
> watchdog_name(wd),
> @@ -74,6 +119,8 @@ EXPORT_SYMBOL(watchdog_register);
>  
>  int watchdog_deregister(struct watchdog *wd)
>  {
> + poller_async_cancel(>poller);
> + poller_async_unregister(>poller);
>   unregister_device(>dev);
>   list_del(>list);
>  
> @@ -109,12 +156,7 @@ int watchdog_set_timeout(unsigned timeout)
>   if (!wd)
>   return -ENODEV;
>  
> - if (timeout > wd->timeout_max)
> - return -EINVAL;
> -
> - pr_debug("setting timeout on %s to %ds\n",
> watchdog_name(wd), timeout);
> -
> - return wd->set_timeout(wd, timeout);
> + return _watchdog_set_timeout(wd, timeout);
>  }
>  EXPORT_SYMBOL(watchdog_set_timeout);
>  
> diff --git a/include/watchdog.h b/include/watchdog.h
> index 2f1874c19..0db4263a3 100644
> --- a/include/watchdog.h
> +++ b/include/watchdog.h
> @@ -13,6 +13,8 @@
>  #ifndef INCLUDE_WATCHDOG_H
>  # define INCLUDE_WATCHDOG_H
>  
> +#include 
> +
>  struct watchdog {
>   int (*set_timeout)(struct watchdog *, unsigned);
>   const char *name;
> @@ -21,6 +23,8 @@ struct watchdog {
>   unsigned int priority;
>   unsigned int timeout_max;
>   unsigned int timeout_cur;
> + unsigned int poller_enable;
> + struct poller_async poller;
>   struct list_head list;
>  };
>  
-- 
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: barebox support for the TI IDK board

[Jan Lübbe]

Hi,

On Sun, 2018-02-04 at 13:16 +0100, Giorgio Dal Molin wrote:
> I've recently received the Industrial Development Kit TMDXIDK5728
> from Texas Instruments, with the AM5728 soc on it, and would like to
> boot a linux kernel with barebox.
> I had a look through the barebox git repo and found the dts and dtsi
> files for the IDK board, ported from the linux kernel repo.
> 
> My question is: is this board/soc really supported by barebox ?

No, barebox currently only supports the AM335x from the industrial IT
SoC series (found for example on the beaglebone). There is no code for
the AM4* and AM5* SoCs.

Regards,
Jan
-- 
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: nand dump

[Jan Lübbe]

On Thu, 2017-08-31 at 15:11 +0800, zjh wrote:
> Why not support nand dump?

You can just use cp to copy from the /dev/nand* devices to somewhere
else.

Regards,
Jan
-- 
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] of: base: add chosen node if it does not exist when adding initrd

[Jan Lübbe]

On Mo, 2016-12-12 at 06:47 +0100, Sascha Hauer wrote:
> On Thu, Dec 08, 2016 at 11:15:51AM +0100, Philipp Zabel wrote:
> > If the chosen node does not exist, of_add_initrd fails to pass the
> > initrd to the kernel. Instead it should create the chosen node, just
> > like of_fixup_bootargs does.
> > 
> > Signed-off-by: Philipp Zabel 
> > ---
> >  drivers/of/base.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> Applied, thanks

This is actually a fix for booting linux-next with initramfs on barebox
and is the cause of some boot failures in our kernel-ci lab:
https://storage.kernelci.org/next/next-20161206/arm-imx_v6_v7_defconfig/lab-pengutronix/boot-imx6dl-riotboard.html

Maybe this should be merged to master instead of next?

Regards,
Jan
-- 
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] scripts: make __init__.py nonempty

[Jan Lübbe]

On Fr, 2016-02-12 at 08:45 +0100, Sascha Hauer wrote:
> Otherwise they get removed by make distclean.
> 
> Signed-off-by: Sascha Hauer 

Looks good.

Jan
-- 
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: scripts/remote: make clean leftovers

[Jan Lübbe]

On Mi, 2016-02-03 at 08:55 +0100, Sascha Hauer wrote:
> On Tue, Jan 26, 2016 at 11:49:09AM +0100, Jan Lübbe wrote:
> > On Di, 2016-01-26 at 11:04 +0100, Yegor Yefremov wrote:
> > > After performing make distclean I've discovered following files being 
> > > removed:
> > > 
> > > Changes not staged for commit:
> > >   (use "git add/rm ..." to update what will be committed)
> > >   (use "git checkout -- ..." to discard changes in working 
> > > directory)
> > > 
> > > deleted:scripts/remote/__init__.py
> > > deleted:scripts/serial/tools/__init__.py
> > > deleted:scripts/serial/urlhandler/__init__.py
> > > 
> > > What should actually happen to these files?
> > 
> > Python uses these files to recognize the directory as containing a
> > module, so we need to keep them.
> 
> They get removed by make distclean, supposedly because they are empty.
> What should they contain? Is it ok to put a comment in them to make them
> non-empty?

Yes, just add a short comment documenting that they need to exist.


-- 
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: scripts/remote: make clean leftovers

[Jan Lübbe]

On Di, 2016-01-26 at 11:04 +0100, Yegor Yefremov wrote:
> After performing make distclean I've discovered following files being removed:
> 
> Changes not staged for commit:
>   (use "git add/rm ..." to update what will be committed)
>   (use "git checkout -- ..." to discard changes in working directory)
> 
> deleted:scripts/remote/__init__.py
> deleted:scripts/serial/tools/__init__.py
> deleted:scripts/serial/urlhandler/__init__.py
> 
> What should actually happen to these files?

Python uses these files to recognize the directory as containing a
module, so we need to keep them.

Regards,
Jan
-- 
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 6/8] host side for barebox remote control

[Jan Lübbe]

On So, 2016-01-17 at 17:07 -0800, Andrey Smirnov wrote:
> >
> > Signed-off-by: Jan Lübbe <j.lue...@pengutronix.de>
> > Signed-off-by: Sascha Hauer <s.ha...@pengutronix.de>
> 
> With fixes above,
> 
> Tested-by: Andrey Smirnov <andrew.smir...@gmail.com>

These fixes look fine,

Acked-by: Jan Lübbe <j.lue...@pengutronix.de>
-- 
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: Verified boot support with FIT

[Jan Lübbe]

On Do, 2016-01-14 at 21:03 +0100, Marc Kleine-Budde wrote:
> On 01/14/2016 08:30 PM, Simon Glass wrote:
> > Someone pointed me to this support that is being added in Barebox. I see
> > that it still has the copyright but does not attribute U-Boot. I'm just
> > checking if that is that an oversight?
> 
> I've Cc'ed Jan, who has written the code. Quoting from his first patch
> to the barebox mailinglist:
> 
> > this is the current work-in-progress state of my FIT support patches.
> > The FIT loading code has basically been rewritten from scratch, as the
> > original U-Boot code uses libfdt and barebox's DT support works on an
> > in-memory tree.

Yes, this is still correct for the recent submissions.

The barebox code only supports the signed configurations with hashed
images, as the goal was to use this for verified boot. Supporting only
this mode keeps the complexity down.

Simon, do you think it is a derived work of the U-Boot FIT code?

Regards,
Jan Lübbe
-- 
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 3/3] bootm: add initial FIT support

[Jan Lübbe]

On Mi, 2016-01-06 at 17:09 +0100, Marc Kleine-Budde wrote:
[...]
> >> +  /*
> >> +   * Put oftree/initrd close behind compressed kernel image to avoid
> >> +   * placing it outside of the kernels lowmem.
> >> +   */
> >> +  if (handle->initrd_size) {
> >> +  data->initrd_address = PAGE_ALIGN(data->os_res->end + SZ_1M);
> >> +  data->initrd_res = request_sdram_region("fit-initrd", 
> >> data->initrd_address, handle->initrd_size);
> >> +  if (!data->initrd_res) {
> >> +  ret = -ENOMEM;
> >> +  goto err_out;
> >> +  }
> >> +  memcpy((void *)data->initrd_res->start, handle->initrd, 
> >> handle->initrd_size);
> >> +  }
> >> +
> >> +  data->of_root_node = of_unflatten_dtb(handle->oftree);
> >> +  if (!data->of_root_node) {
> >> +  pr_err("unable to unflatten devicetree\n");
> >> +  ret = -EINVAL;
> >> +  goto err_out;
> >> +  }
> >> +
> >> +  /*
> >> +   * Put devicetree right after initrd if present or after the kernel
> >> +   * if not.
> >> +   */
> >> +  if (data->initrd_res)
> >> +  mem_free = PAGE_ALIGN(data->initrd_res->end);
> >> +  else
> >> +  mem_free = PAGE_ALIGN(data->os_res->end + SZ_1M);
> > Why the extra 1M?
> 
> Let's see if Jan remembers, he has coded this.

This is the same as in arch/arm/lib/bootm.c. I wanted to avoid having
different behaviors.

Regards,
Jan
-- 
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 3/3] bootm: add initial FIT support

[Jan Lübbe]

On Di, 2016-01-05 at 14:50 +0100, Marc Kleine-Budde wrote:
> >> > +static int fit_open_configuration(struct fit_handle *handle, int
> num)
> >> > +{
> >> > +   struct device_node *conf_node = NULL, *sig_node;
> >> > +   char unit_name[10];
> >> > +   const char *unit, *desc;
> >> > +   int ret, level;
> >> > +
> >> > +   conf_node = of_get_child_by_name(handle->root,
> "configurations");
> >> > +   if (!conf_node)
> >> > +   return -ENOENT;
> >> > +
> >> > +   if (num) {
> >> > +   snprintf(unit_name, sizeof(unit_name), "conf@%d",
> num);
> > 
> > This is not working for my *.its file:
> >
> https://github.com/visionsystemsgmbh/onrisc_br_bsp/blob/master/board/vscom/baltos/kernel-fit.its
> > U-Boot is working with bootm ${loadaddr}#conf${board_name}
> > 
> > For Barebox I've changed this line to
> > 
> > snprintf(unit_name, sizeof(unit_name), "conf%d@1", num)
> > 
> > This is how I start Linux: bootm /boot/kernel-fit.itb@
> $global.board.id
> > 
> > What is the standard for providing FIT configuration?
> 
> Don't know. Is there a spec in the u-boot sources, otherwise use the
> code.

I used the u-boot example ITS for reference (doc/uImage.FIT/multi.its).
The have the number after the @, so I used the same. Barebox's bootm
currently only supports a number to select between different "subimages"
as a legacy from uImages.

Your ITS has a @1 for every config/fdt. Why?

For selecting between different configurations depending on the board,
it would be nice to be able to reuse the DT board compatibles.

Regards,
Jan

-- 
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 1/3] commands: Add MMC ext. CSD register tool

[Jan Lübbe]

On Di, 2015-08-25 at 09:06 +0200, Sascha Hauer wrote:
 Your printfs are very inefficient. You should use something like:
 
 if (val)
 str = en;
 else
 str = dis;
 printf(Command queuing is %sabled\n, str);
 
 Same goes for many other printfs. This will result in much less
 similar strings in the binary.

or like this:
printf(Command queuing is %sabled\n, val ? en : dis);

-- 
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 v1] commands: Add dhrystone

[Jan Lübbe]

On Fr, 2015-07-24 at 13:41 +0200, Daniel Schultz wrote:
 At the end of the do_dhrystone function:
 
  if (user_time  TOO_SMALL_TIME) {
  number_of_runs = number_of_runs * 10;
  new_argv[0] = argv[0];
  sprintf(tmp_str, %i, number_of_runs);
  new_argv[1] = tmp_str;
  printf(Measured time too small to obtain meaningful results\n);
  printf(or a timer wrap happend. I will increase the number\n);
  printf(of runs by *10 to %d\n, number_of_runs);
  printf(user_time: %llu ns\n, user_time);
  do_dhrystone(2, new_argv);
  ...
 
 I'm sure there is a better solution.

Why not just loop for a few seconds?

Regards,
Jan
-- 
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 2/2] ARM: am335x: Changed timer

[Jan Lübbe]

On Fr, 2015-07-17 at 15:39 +0200, Daniel Schultz wrote:
 The dmtimer0 is too inaccurate to be used for measurements.
 We switch to the more accurate dmtimer2.

Ah, OK, after looking at the TRM again, the real reason for the
inaccuracy seems to be that the 32KiHz for dmtimer0 is *not* derived
from the RTC crystal, but from an internal RC oscillator.

The kernel uses dmtimer1 for the clocksource by switching it to the
M_OSC in the PRCM.

The dmtimer2 is used for clockevents and runs from M_OSC by default.
While we could set the dmtimer1 source to M_OSC in the clock setup, it
seems simpler to just use dmtimer2.

The commit message should explain the reasoning behind the switch.

Regards,
Jan
-- 
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 2/7] drivers: i2c: Only register available devices

[Jan Lübbe]

On Fr, 2015-07-17 at 13:13 +0200, Teresa Remmet wrote:
 -   for_each_child_of_node(adap-dev.device_node, n) {
 +   for_each_available_child_of_node(adap-dev.device_node, n) {
 struct i2c_board_info info = {};

I've submitted an identical patch last week, which was applied by
Sascha.

Regards,
Jan
-- 
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: Compiling barebox for newest Yocto/meta-freescale

[Jan Lübbe]

On Di, 2015-06-23 at 21:30 +0200, Lucas Stach wrote:
 Also you don't have a hard-float only environment, your toolchain is
 perfectly able to build with the soft-float ABI, it's just that Yocto
 apparently passes the mfloat-abi=hard flag everywhere instead of
 setting a reasonable toolchain default.

I have the same problem now, as well (triggered by setting
DEFAULTTUNE=cortexa8hf-neon).

The kernel uses the same -msoft-float in arch/arm/Makefile as we do in
barebox. As Lucas said, this is actually important for correct behavior.

Yocto handles this by building the kernel with CC=${KERNEL_CC}
LD=${KERNEL_LD} instead (see kernel.bbclass and kernel-arch.bbclass).
For barebox I now have:
do_compile () {
unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS MACHINE
oe_runmake CC=${KERNEL_CC} LD=${KERNEL_LD}
}

These settings make it impossible to build the barebox target userspace
tools from scripts/, though. This is because the --sysroot parameter is
passed by Yocto only in ${CC} and not in ${KERNEL_CC}, so the target
userspace tools will fail to find their standard headers. So I have as a
temporary workaround:
do_configure_prepend() {
cp ${WORKDIR}/defconfig ${S}/.config
# do not compile tools when using KERNEL_CC/KERNEL_LD
echo CONFIG_BAREBOXENV_TARGET=n  ${S}/.config
echo CONFIG_BAREBOXCRC32_TARGET=n  ${S}/.config
echo CONFIG_KERNEL_INSTALL_TARGET=n  ${S}/.config
echo CONFIG_IMD_TARGET=n  ${S}/.config
oe_runmake oldconfig
}

To compile the target userspace tools, we'll need to use ${CC} instead,
which is currently not supported by our (or the kernel's) kbuild. It
seems that we currently build these tools with -msoft-float as well,
which causes no problems because we don't use float math, but it's not
correct either.

Gyorgy, could you point us to the Yocto side of the discussion, if it
was on some list?

Regards,
Jan
-- 
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: Compiling barebox for newest Yocto/meta-freescale

[Jan Lübbe]

Hi,

On Mo, 2015-06-22 at 17:18 +0200, György Kövesdi wrote:
 I have a i.MX6 based board and want to compile barebox using Yocto.
 It was successful so far, but something is changed in the gcc behaviour.
 The first thing is that some arch-specific parameters must be passed, or 
 else the compilation fails. I could fix it, but there is another problem.

I had to change
-   oe_runmake
+   oe_runmake CC=$CC
for recent yocto versions. What was your fix?

 The option -mfloat-abi=soft is used in barebox compilation, which 
 seems not supported by gcc. Adding -mfloat-abi=hard is not enough, the 
 original -mfloat-abi=soft should be removed. Unfortunately, i could 
 not find where this option is added and how to remove it.
 Can anybody help me to fix it?

Which yocto and gcc version are you using? Could you show us the actual
error messages and yocto recipe?

Regards,
Jan
-- 
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: [RFC 2/4] Add rsa support

[Jan Lübbe]

Hi Jean-Christophe,

On Di, 2015-03-17 at 11:48 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
  Could you explain your image format in a bit more detail? How your
  intend to defend against a mix-and-match attack?
 
 One of the format we are using can only be one configure signed or/and
 encrypted so no mix-and-match attack

Sorry, it's still not clear to me. Do you mean you would use FIT in that
case (it supports signed configurations)? Or do you mean that you are
using several formats, one of which uses signed/encrypted configurations
of kernel/initramfs/dt?

I want to understand how your image formats would be used in the larger
context of a BSP or distribution. Please describe which image formats
you want to support (in addition to FIT). How are they structured? How
are they generated? Are they already supported by other software? 

Thanks,
Jan
-- 
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 0/9 v4] prepare for rsa support

[Jan Lübbe]

On Di, 2015-03-17 at 12:49 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
   The following patch series prepare for the adding of the rsa digest
   support
 
   This will allow to verify a rsa signature of a file
 
   Introduction of a new command digest to handle the digest and check
 
   The next patch series will add RSA and keystore support

Thanks, this looks good to me now.

Regards,
Jan
-- 
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: [RFC 2/4] Add rsa support

[Jan Lübbe]

On Di, 2015-03-17 at 13:39 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
  I want to understand how your image formats would be used in the larger
  context of a BSP or distribution. Please describe which image formats
  you want to support (in addition to FIT). How are they structured? How
  are they generated? Are they already supported by other software? 
 Today we use a bpk formoat
 
 in bpk format you can store different data for each hw_id, each data have a
 specific type.
 
 we add a new type for the signature.
 
 we do a sha512 of the other data of one hw_id and signed it with a rsa4096
 we use 1 unique rsa key per HW_ID
 
 as soon as one of the file of a specific hw_id is open we check the signature
 
 The code is no public yet but this is handled at FS level
 
 and we allow only to open data that have been verified or decrypted if we use
 AES

Thanks for the explanation, it's clearer now.

Regards,
Jan
-- 
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: [RFC 3/4] FIT: add FIT image support

[Jan Lübbe]

On Mo, 2015-03-16 at 14:51 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
   The other pb I see is this one where and do you plan to store the RO x509
   the trusted one.
  
  Sorry, I can't parse this.
 where do we store the trusted keys/cert need to be secured or inaccessible
 except crypto API

(The following depends on prohibiting any unauthenticated access to the
barebox console.)

If you just use a chain of signed code like with HAB on i.MX, every cert
is verified by the previous step (up to the SRK table hash), so there is
no need to additionally protect certs against modification. Any modified
cert would result in a verification error. In this setup there is no
secret information on the device at all.

When doing this without support from the SoC's ROM code, you could store
barebox (with compiled-in master public key(s)) in RO flash. Against an
attacker without physical access, this results in the same security
properties. You couldn't update the RO barebox, tough (only boot another
one second stage).

Regards,
Jan
-- 
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: [RFC 3/4] FIT: add FIT image support

[Jan Lübbe]

On Mo, 2015-03-16 at 13:19 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 On 13:08 Mon 16 Mar , Jan Lübbe wrote:
  On Mo, 2015-03-16 at 12:14 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
   On 11:19 Mon 16 Mar , Jan Lübbe wrote:
Later I'd like to have optional support to switch barebox into a
non-secure or developer mode at runtime, which would make hardware
secrets inaccessible. That could be triggered when a prompt appears or
when booting for a different source (such as USB fastboot).
   
   yeah, I like the idea but for this will have to put a lot of protection 
   so you
   can not read/write some part of the memory included barebox itself (in 
   RAM)
   
   As in the kernel we have no memmory protection from the shell.
  
  Not necessarily. For example on the MX6 you can trigger a security
  violation in the CAAM from software. That will clear the OTPMK in its
  Key-RAM. From that point on you can run any software but you will not be
  able to decrypt any secret data which was encrypted with the OTPMK.
  
  On hardware which supports something like this, debugging hardware
  problems is easy and there is no danger of leaking any secret
  information. If something is useful/possible in any specific project
  obviously depends on the threat model and hardware capabilities.
 
 I knonw about the imx6 but that does not mean all the SoC
 unfortunatly.

Yes, every SoC is different. But we should be able to use HW features
when the are available, as sometimes the HW is selected specifically to
used these security features.

 The other pb I see is this one where and do you plan to store the RO x509
 the trusted one.

Sorry, I can't parse this.

 if you use on OTP this means this is enough to ensure secured boot as if you
 can not modify the primary cert of key. No one can brake it. But as you load
 it in ram you need to be sure no one modify it. Even in unlock mode to do only
 allow to boot secure images by expected key.

I should have been more clear: The use case here is to ensure that the
OTPMK-AES-HW-Key is only available when booting with a correct boot
chain. It's OK to boot something else (only the OTPMK needs to be
cleared).

This is a very different goal from making sure that only correctly
signed code is executed.

Both cases need mostly the same verified boot features, only the policy
(especially what to do on signature errors) is different.

 So you may not have secured place to store the cert or key in ram but only
 RAM. so we do need to forbidden this memory acces to everyone except the
 crypto API. if we want ot allow dev mode.

On MX6 this can be done by the HW. Doing this (without TrustZone) purely
in SW seems extremely difficult.

 the main problem is not console but env you need to drop RW env 
 support
 and use only RO one, except for keyring support where you will a RW 
 env but
 not executable and only accesable by crypto API
 
 otherwise you need to use a secured digest such as HMAC/CMAC/OMAC 
 support
 to sign the env at runtime and ensure the symetric key is secured
 or encrypt it via aes (did this in the past)

For an upcoming project we'll add HMAC support to the state storage Marc
recently submitted.
   I've a patch too I need to send it
  
  For environment or state storage?
 envfs

Nice. :)

  
   but I prefer to wait we have keystore support as this will store the key 
   for
   the HMAC otherwise we need to use HW HMAC that store the key in the soc
  
  Another possibility is to use the HW AES key and a compiled in value to
  derive a per-device HMAC secret. The same approach can also be used in
  Linux for deriving the IMA/EVM HMAC secret.
 this for me need to be integrated in the keystore to be transparent for the
 rest of the API

That shouldn't be hard. We can look at this in detail after you've
posted that API.

Regards,
Jan
-- 
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 07/10] password: add pbkdf2 support

[Jan Lübbe]

On Mo, 2015-03-16 at 13:10 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 On 12:58 Mon 16 Mar , Jan Lübbe wrote:
 Personnaly I'll prefer
 
 a random 64 bytes | sha256 | take first 32bytes. | pbkdf2 1 round

Running SHA-256 on random data is useless for security.
   SHA256 is to improve the entrpopy not security
  
  Running a deterministic algorithm cannot increase entropy (only reduce
  it).
 
 check the kennel algo for PRGN

PRNG? That is a different use case. The kernel takes sources of entropy
and uses those to seed an CSPRNG:
http://www.2uo.de/myths-about-urandom/

 and youp will see why I want to use a sha

Having high entropy and appearing random are different properties. As
SHA-256 is deterministic it *cannot* increase entropy:
http://en.wikipedia.org/wiki/Entropy_(information_theory)

Just get
hash-size bytes from /dev/urandom on the host. We could generate a
file with the compile-time SALT which is then included.

On the running barebox, we could use SHA to hash the old password file
together with the current timer value. At least until we have something
better.

 result a 64 bytes password file salt 32 byeskey 32 bytes

Yes. As we select the algorithm at compile time, we don't the to save it
in the file.
   
   this is for barebox as we may not have any passwd file
  
  The same applies also to the default_passwd compiled in variable.
  
  Currently we have:
  PASSWD_FILE := $(shell cd $(srctree); find $(CONFIG_PASSWORD_DEFAULT) -type 
  f)
  cmd_pwd_h = echo -n static const char default_passwd[] = \  $@; \
  cat $ | tr -d '\n'  $@; \
  echo \;  $@
  
  include/generated/passwd.h: $(PASSWD_FILE)
  $(call if_changed,pwd_h)
  
  This would need to run the hash/pbkdf2 and store salt+key.
 
 no as the current current code expect you to give the correct file format for
 the currently use password
 
 so today the output of openssl

Ah, sorry I misread the code here. I though that the plaintext password
was in the config. CONFIG_PASSWORD_DEFAULT must be the name of a file in
the srctree with the format matching the selected hash algo?

 but yes we may need to do more here

It seems there is no standard tool to create password hashes which
supports all the algorithms we want to have.

So the current way is to use barebox itself to create the default
password file? Should be have a host tool for that or is barebox sandbox
enough?

Regards,
Jan
-- 
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: [RFC 3/4] FIT: add FIT image support

[Jan Lübbe]

On Fr, 2015-03-13 at 18:00 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
  While sha1 is considered broken.
 it's broken and sha256 not yet but in 10 years strongly suspected
 even in brut force
 
 That's why FIPS work on SHA-2

SHA256 is part of the SHA-2 family [1]. Keccak is the winner of the
SHA-3 competition.

Regards,
Jan

[1] http://en.wikipedia.org/wiki/SHA-2
-- 
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 07/10] password: add pbkdf2 support

[Jan Lübbe]

On Mo, 2015-03-16 at 12:01 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 On 11:49 Mon 16 Mar , Jan Lübbe wrote:
  On Mo, 2015-03-16 at 11:15 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
   We will use barebox_password as salt and 1 round to generate a
   64 bytes key.
  
  The purpose of a salt is to protect a against dictionary or
  rainbow-table (precomputed) attacks. That means that the Salt must be
  randomly generated and saved with the password.
 This will be a enough stong enven with static one to protect against
 reverse hack for barebox protection
 
 Use a 32 byte pass try to do an attack agaist dictionary.
 it will take you more than 10 years to break it
  
  For setting a new password in barebox, even a low entropy salt will make
  attacks significantly more expensive. So we should add some entropy from
  user interaction timing in that case.
 yes we could do this too
  
  For hashing a password at compile time, we should get the salt from the
  host system.
 yes
 
 do we really need it?

Yes, definitely. We must use the algorithms as they are intended to be
used.

If we try to move users away from RSA2048 because it will be vulnerable
in the future, we should not go against established practice for
password salts by hard-coding it. 

Regards,
Jan
-- 
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 07/10] password: add pbkdf2 support

[Jan Lübbe]

On Mo, 2015-03-16 at 12:52 +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
 On 12:41 Mon 16 Mar , Jan Lübbe wrote:
  On Mo, 2015-03-16 at 12:25 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
Yes, definitely. We must use the algorithms as they are intended to be
used.

If we try to move users away from RSA2048 because it will be vulnerable
in the future, we should not go against established practice for
password salts by hard-coding it. 
   I'm not against it but with the barebox entropy did not see the point to 
   use
   it.
   
   so how do we generate the salt? what length
   
   Personnaly I'll prefer
   
   a random 64 bytes | sha256 | take first 32bytes. | pbkdf2 1 round
  
  Running SHA-256 on random data is useless for security.
 SHA256 is to improve the entrpopy not security

Running a deterministic algorithm cannot increase entropy (only reduce
it).

  Just get
  hash-size bytes from /dev/urandom on the host. We could generate a
  file with the compile-time SALT which is then included.
  
  On the running barebox, we could use SHA to hash the old password file
  together with the current timer value. At least until we have something
  better.
  
   result a 64 bytes password file salt 32 byeskey 32 bytes
  
  Yes. As we select the algorithm at compile time, we don't the to save it
  in the file.
 
 this is for barebox as we may not have any passwd file

The same applies also to the default_passwd compiled in variable.

Currently we have:
PASSWD_FILE := $(shell cd $(srctree); find $(CONFIG_PASSWORD_DEFAULT) -type f)
cmd_pwd_h = echo -n static const char default_passwd[] = \  $@; \
cat $ | tr -d '\n'  $@; \
echo \;  $@

include/generated/passwd.h: $(PASSWD_FILE)
$(call if_changed,pwd_h)

This would need to run the hash/pbkdf2 and store salt+key.

Regards,
Jan
-- 
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: [RFC 2/4] Add rsa support

[Jan Lübbe]

On Mo, 2015-03-16 at 11:27 +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
 On 11:00 Mon 16 Mar , Jan Lübbe wrote:
  On Fr, 2015-03-13 at 16:49 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
   you just need to have a unique ID on the HW and then use a x509 object
   to store it. then signed it with you CA. As only validated keys can be
   used, you can easly give a generated key for a specific HW.
   And this key will be valid only for this HW.
  
  Yes, this sounds useful. So you'd have a board-specific way to check the
  unique ID constraint in an intermediate cert against the HW ID?
 yes more or less but but at the key itself as you will have to upload the
 key to the board. And the key will only be accepted to be stored as it will
 be valid and have the HW ID.

OK. Sounds good to me.

 And for the record remember if you want to use module in secured boot mode
 for the kernel you will have to use x509 certificate anyway.
 
 So why not to use the same principal.
 
 u-boot way is not what is doing today on the market for authentication
 format. Today it's x509 or PGP.
 
 So I do prefer to stay as standard as possible, this does not mean we can not
 support the FTD stuff. But IMHO it's not the right way.

x509 only defines the certificate format, not how it is used to sign
kernel, initramfs and device tree.

The kernel defines its own format based on ELF and store the signature
inside. That can't be reused directly for the kernel itself, initramfs
or DTB. UEFI has again its own format.

We don't want to sign kernel, initramfs and DTB individually, as this
would allow an attacker to mix-and-match these to trigger a
vulnerability. So we need to have some format which supports signing a
given configuration consisting of specific kernel, initramfs and DTB.

FIT handles this requirement. It also supports having multiple
configurations (each signed) referencing for example the same kernel
+initramfs but different DTBs for a set of similar boards.

What is the image format you intend to use with x509 certs?

Regards,
Jan
-- 
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: [RFC 3/4] FIT: add FIT image support

[Jan Lübbe]

On Mo, 2015-03-16 at 12:14 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 On 11:19 Mon 16 Mar , Jan Lübbe wrote:
  Later I'd like to have optional support to switch barebox into a
  non-secure or developer mode at runtime, which would make hardware
  secrets inaccessible. That could be triggered when a prompt appears or
  when booting for a different source (such as USB fastboot).
 
 yeah, I like the idea but for this will have to put a lot of protection so you
 can not read/write some part of the memory included barebox itself (in RAM)
 
 As in the kernel we have no memmory protection from the shell.

Not necessarily. For example on the MX6 you can trigger a security
violation in the CAAM from software. That will clear the OTPMK in its
Key-RAM. From that point on you can run any software but you will not be
able to decrypt any secret data which was encrypted with the OTPMK.

On hardware which supports something like this, debugging hardware
problems is easy and there is no danger of leaking any secret
information. If something is useful/possible in any specific project
obviously depends on the threat model and hardware capabilities.

   the main problem is not console but env you need to drop RW env support
   and use only RO one, except for keyring support where you will a RW env 
   but
   not executable and only accesable by crypto API
   
   otherwise you need to use a secured digest such as HMAC/CMAC/OMAC support
   to sign the env at runtime and ensure the symetric key is secured
   or encrypt it via aes (did this in the past)
  
  For an upcoming project we'll add HMAC support to the state storage Marc
  recently submitted.
 I've a patch too I need to send it

For environment or state storage?

 but I prefer to wait we have keystore support as this will store the key for
 the HMAC otherwise we need to use HW HMAC that store the key in the soc

Another possibility is to use the HW AES key and a compiled in value to
derive a per-device HMAC secret. The same approach can also be used in
Linux for deriving the IMA/EVM HMAC secret.

Regards,
Jan
-- 
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: [RFC 3/4] FIT: add FIT image support

[Jan Lübbe]

Hi Jean-Christophe,

On Fr, 2015-03-13 at 17:08 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 On 16:41 Fri 13 Mar , Jan Lübbe wrote:
  On Fr, 2015-03-13 at 15:28 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
It's not the job of barebox to define security policies, it must fit
well into the larger security design, which may require compromises.
   
   I disagree, disable by default non secure feature is require to pass
   secure boot certification
  
  Is there a specific certification you are targeting?
 
 yes but can not give details all under NDA, a book of more than 500 pages
 for bootloader/linux/kernel  co

OK, that's unfortunate. Still I'd like to have some documentation on the
overall design of Barebox's verified boot. That doesn't mean you have to
write it all by yourself. ;)

  How do you intend to handle console access in verified boot mode?
  Allowing access to md/mw would break any security.
 
 it's already mainline for month, check password support
 
 as I put it in production more than 1 years ago
 
 or simple disable input console all time, the code is here

So currently we have:
1) use password
2) disable console

Later I'd like to have optional support to switch barebox into a
non-secure or developer mode at runtime, which would make hardware
secrets inaccessible. That could be triggered when a prompt appears or
when booting for a different source (such as USB fastboot).

 the main problem is not console but env you need to drop RW env support
 and use only RO one, except for keyring support where you will a RW env but
 not executable and only accesable by crypto API
 
 otherwise you need to use a secured digest such as HMAC/CMAC/OMAC support
 to sign the env at runtime and ensure the symetric key is secured
 or encrypt it via aes (did this in the past)

For an upcoming project we'll add HMAC support to the state storage Marc
recently submitted.

 ww may have to get secured malloac with part where the md/mw and any other
 API can not touch only the crypto API
 
 but this will be for later

Yes.

 I'll send a patch to use the pbkdf2 for password

Nice.

Regards,
Jan
-- 
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 04/10] command: add generic digest command

[Jan Lübbe]

On Mo, 2015-03-16 at 11:15 +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
 +BAREBOX_CMD_HELP_START(digest)
 +BAREBOX_CMD_HELP_TEXT(Calculate a digest over a FILE or a memory
 area.)
 +BAREBOX_CMD_HELP_TEXT(Options:)
 +BAREBOX_CMD_HELP_OPT (-a algo\t,  digest to use)
 +BAREBOX_CMD_HELP_OPT (-k key\t,  key as text)
 +BAREBOX_CMD_HELP_OPT (-K file\t,  key file)
 +BAREBOX_CMD_HELP_OPT (-s sig\t,  digest)
 +BAREBOX_CMD_HELP_OPT (-S file\t,  digest flie)
 +BAREBOX_CMD_HELP_END

We're mixing different terms here: digest and signature

Signature is usually used in the context of public key crypto, digest is
mostly used with for hashes. The command uses both interchangeably.

How about:
-a algo   hash or signature algorithm to use
-k keyuse supplied key (ASCII or hex) for MAC
-K file   use key from file (binary) for MAC
-v hexverify data against supplied hex (hash, MAC or signature)
-V file   verify data against file (hash, MAC or signature)

Regards,
Jan
-- 
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 07/10] password: add pbkdf2 support

[Jan Lübbe]

On Mo, 2015-03-16 at 12:25 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
  Yes, definitely. We must use the algorithms as they are intended to be
  used.
  
  If we try to move users away from RSA2048 because it will be vulnerable
  in the future, we should not go against established practice for
  password salts by hard-coding it. 
 I'm not against it but with the barebox entropy did not see the point to use
 it.
 
 so how do we generate the salt? what length
 
 Personnaly I'll prefer
 
 a random 64 bytes | sha256 | take first 32bytes. | pbkdf2 1 round

Running SHA-256 on random data is useless for security. Just get
hash-size bytes from /dev/urandom on the host. We could generate a
file with the compile-time SALT which is then included.

On the running barebox, we could use SHA to hash the old password file
together with the current timer value. At least until we have something
better.

 result a 64 bytes password file salt 32 byeskey 32 bytes

Yes. As we select the algorithm at compile time, we don't the to save it
in the file.

Regards,
Jan
-- 
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: [RFC 3/4] FIT: add FIT image support

[Jan Lübbe]

On Mo, 2015-03-16 at 15:40 +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
 On 15:31 Mon 16 Mar , Jan Lübbe wrote:
  (The following depends on prohibiting any unauthenticated access to the
  barebox console.)
  
  If you just use a chain of signed code like with HAB on i.MX, every cert
  is verified by the previous step (up to the SRK table hash), so there is
  no need to additionally protect certs against modification. Any modified
  cert would result in a verification error. In this setup there is no
  secret information on the device at all.
  
  When doing this without support from the SoC's ROM code, you could store
  barebox (with compiled-in master public key(s)) in RO flash. Against an
  attacker without physical access, this results in the same security
  properties. You couldn't update the RO barebox, tough (only boot another
  one second stage).
 
 I agree with you I said the same
 
 my key point is if we do allow console access we need be sure at 100% that
 they can not tempered with the trusted key in RAM and barebox binary and
 malloc space

Yes. We would also need to disallow access to devices and non-verifying
boot commands.

Regards,
Jan
-- 
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: [RFC 2/4] Add rsa support

[Jan Lübbe]

On Mo, 2015-03-16 at 12:33 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 I do not like and do not want to use the FTD format to store the key
 but x509.

Yes, I think we are in agreement that we need to support both key
formats.

 Image format need to be 100% seperated from key format.

Of course.

 That's why I work on a framework so we do not care of both.
 
 Multiple image format with multiple image of key format.

Could you explain your image format in a bit more detail? How your
intend to defend against a mix-and-match attack?

Regards,
Jan
-- 
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 07/10] password: add pbkdf2 support

[Jan Lübbe]

On Mo, 2015-03-16 at 11:15 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 We will use barebox_password as salt and 1 round to generate a
 64 bytes key.

The purpose of a salt is to protect a against dictionary or
rainbow-table (precomputed) attacks. That means that the Salt must be
randomly generated and saved with the password.

For setting a new password in barebox, even a low entropy salt will make
attacks significantly more expensive. So we should add some entropy from
user interaction timing in that case.

For hashing a password at compile time, we should get the salt from the
host system.

Regards,
Jan
-- 
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 8/8] command: add hmac sum supportfor md5, sha1, sha224, sha256, sha384, sha512

[Jan Lübbe]

On Mi, 2015-03-11 at 17:53 +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
 diff --git a/include/digest.h b/include/digest.h
 index a26848c..fd47a7e 100644
 --- a/include/digest.h
 +++ b/include/digest.h
 @@ -54,11 +54,14 @@ struct digest *digest_alloc(char* name);
  void digest_free(struct digest *d);
  
  int digest_file_window(struct digest *d, char *filename,
 +  unsigned char *key, size_t keylen,
unsigned char *hash,
ulong start, ulong size);
  int digest_file(struct digest *d, char *filename,
 +  unsigned char *key, size_t keylen,
unsigned char *hash);

This is already in next, but I'd like to know why you added the
key/keylen args to each function instead of letting the caller use
digest_set_key()?

In the patch [PATCH 04/10] command: add generic digest command you add
another parameter (unsigned char *sig) to these functions, which is used
instead of the key parameter when verifying.

Maybe we are overloading them with to much different functionality? 

Regards,
Jan
-- 
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: [RFC 2/4] Add rsa support

[Jan Lübbe]

On Fr, 2015-03-13 at 11:25 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 On 11:10 Fri 13 Mar , Jan Lübbe wrote:
  On Fr, 2015-03-13 at 10:56 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
Having an ASN1 parser for DER/x509 is a huge amount of complexity I
would not want in a bootloader. Just take a look at the problems the
SSL-CAs and browsers had with different interpretations of the same
cert.
   
   der is nothing few under lines
  
  Sorry, I can't parse this.
  
   x509 a few more as it's based on DER
  
  Could you show me that code?
 let me finish to clean it
 and rebase it

Sure.

The FIT format (and corresponding public key in the bootloader's DT) has
been adopted by depthcharge and u-boot, because it handles the
requirements and nothing more.
   
   if you want to add this format you can but via the keychain loader not in 
   the
   code as today you do have soc such as imx that store the key in OTP as DER
  
  The IMX does not store keys in OTP. It stores a SHA(1 or 256) hash over
  a table of super root keys. This is irrelevant for barebox, as this is
  already handled by the ROM code.
 it's does as you can use it as hw IP to check the kernel

RSA checking in HABv4 (i.e. MX6) is done in software by the ROM code.
For the first step we should only support RSA in software to keep the
complexity down.

 yes you store a hash but you do can use it in barebox.

Yes, you could use it in barebox. What is the use case where you would
do this instead of having the key compiled-in (and verified together
with the code by the ROM)?

 other SoC (i can mention the name NDA) does store the key in the OTP of the
 SoC programmed at production time of the SoC itself.
 with HW RSA accelerator

OK, please leave HW RSA as a future step.

   and u-boot is not the best reference EVER.
  
  Depthcharge is much more relevant here, as it's used as a coreboot
  payload on chromebooks.
 
 does not make it more relevant is the term of key format
 
 the Standard are x509, PGP and der/pem for ages
 
 and as said we can support it but make it the only one NO WAY

I'd prefer PGP to x509 anyway. ;)

If we can have x509 and FIT (with key in DT) without too much additional
complexity and have each optional at compile time, I'm not against it.
I'll wait for your code.

What is your use-case for which you need to add keys at runtime?
   
   simple you want to allow user to put their own key
   or use a CA to handle allowed key
  
   if you want to replace grub this is critical
  
  We have customers which require that do not allow runtime loading of
  keys. So it should be possible to disable runtime loading at compile
  time. 
 yeah of cource but the feature need to be here IMHO

OK.

 and honestly to respect the opensource if you allow this you MIGHT be
 compliant with GPLv3

s/compliant/non-compliant/ ?

How you need to handle that in practice depends on the context of the
whole system.

 it's more user friendly
 For my own customer I always recommand to have a board uniq key that you
 can provide to each end customer upon request to it can install it's own
 linux. Even if the key is not replaceble.

Yes, that's nice if the production work flow in the factory can do this,
but it's not always possible.

Regards,
Jan
-- 
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: [RFC] digest: Add enum

[Jan Lübbe]

On Do, 2015-03-12 at 18:50 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 do as in the kernel use the string as we may want to add hw IP

You mean we should add a priority instead? The kernel also has separate
names for the algorithm and for the driver.

Regards,
Jan
-- 
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: [RFC 2/4] Add rsa support

[Jan Lübbe]

On Fr, 2015-03-13 at 10:56 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
  Having an ASN1 parser for DER/x509 is a huge amount of complexity I
  would not want in a bootloader. Just take a look at the problems the
  SSL-CAs and browsers had with different interpretations of the same
  cert.
 
 der is nothing few under lines

Sorry, I can't parse this.

 x509 a few more as it's based on DER

Could you show me that code?

  The FIT format (and corresponding public key in the bootloader's DT) has
  been adopted by depthcharge and u-boot, because it handles the
  requirements and nothing more.
 
 if you want to add this format you can but via the keychain loader not in the
 code as today you do have soc such as imx that store the key in OTP as DER

The IMX does not store keys in OTP. It stores a SHA(1 or 256) hash over
a table of super root keys. This is irrelevant for barebox, as this is
already handled by the ROM code.

 and u-boot is not the best reference EVER.

Depthcharge is much more relevant here, as it's used as a coreboot
payload on chromebooks.

  What is your use-case for which you need to add keys at runtime?
 
 simple you want to allow user to put their own key
 or use a CA to handle allowed key

 if you want to replace grub this is critical

We have customers which require that do not allow runtime loading of
keys. So it should be possible to disable runtime loading at compile
time. 

Regards,
Jan
-- 
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: [RFC 3/4] FIT: add FIT image support

[Jan Lübbe]

On Do, 2015-03-12 at 19:19 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 please do not send a new version except for fix
 
 I'm going to re-integrate it with the keystore  co

Could you describe your keystore design?

 and sha1,rsa2048 is considered weak in term of security
 and worse md4/md5
 
 for barebox I would only use
 at least sha256 with rs2048 or sha512 with rsa4096

Yes, of course. These were only used as an example and it's trivial to
switch to other hash algos or RSA key sizes. Also, the FIT format can
easily be extended to support ECC/Curve25519.

In some cases, where the SoC's ROM code only supports RSA2048 with SHA1,
using stronger settings in Barebox doesn't increase security. So there
we want to use the same settings as the ROM code.

Regards,
Jan
-- 
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: [RFC 3/4] FIT: add FIT image support

[Jan Lübbe]

On Fr, 2015-03-13 at 11:05 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 On 10:28 Fri 13 Mar , Jan Lübbe wrote:
  On Do, 2015-03-12 at 19:19 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
   please do not send a new version except for fix
   
   I'm going to re-integrate it with the keystore  co
  
  Could you describe your keystore design?
 
 I'll send the patch series soon
 
 code is better than 1000s of words
 
 with DER support and the fit

Thanks.

   and sha1,rsa2048 is considered weak in term of security
   and worse md4/md5
   
   for barebox I would only use
   at least sha256 with rs2048 or sha512 with rsa4096
  
  Yes, of course. These were only used as an example and it's trivial to
  switch to other hash algos or RSA key sizes. Also, the FIT format can
  easily be extended to support ECC/Curve25519.
 
 very slow vs rsa, but as we will use a generic framework we will just need to
 add the algo
 
 if you can break rsa4096, the chance you can break ECC are high too

Please see http://ed25519.cr.yp.to/ and
http://cr.yp.to/papers.html#rwsota. Curve22519 is very fast and has some
benefits over RSA.

I'm not arguing that either RSA or ECC are better for verified boot, we
should just keep in mind that supporting ECC later should fit the
design.

  In some cases, where the SoC's ROM code only supports RSA2048 with SHA1,
  using stronger settings in Barebox doesn't increase security. So there
  we want to use the same settings as the ROM code.
 
 agreed but I refuse to allow it unless we have no choice
 and emit a warning

I'm fine with a warning in Kconfig or during compile time. 

 and even I'll prefer to use stonger, yes this will increase the security.
 As a secure boot is as strong as it's weak link

It's not the job of barebox to define security policies, it must fit
well into the larger security design, which may require compromises.

Regards,
Jan
-- 
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: [RFC 2/4] Add rsa support

[Jan Lübbe]

On Fr, 2015-03-13 at 11:12 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 
 sorry mutt via ssh lost some character when typing
 
 der is few 100s line of code that's all
 
 and x509 just a few more
 
 as I do not plan to support all the options of x509 specially the non
 standard one

Do you intend to reject unknown/unimplemented parts of x509? Or just
ignore them?

-- 
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: [RFC 2/4] Add rsa support

[Jan Lübbe]

On Do, 2015-03-12 at 18:47 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 as state in my previous e-mail I will a keystore support
 
 but this dt format to handle no please
 
 we need to use the standard format as in the kernel or openssl
 
 DER and x509
 
 specially x509 as if we want to be able to add key at runtime we need
 to sign them we the trusted RO keys
 
 For the implementation of RSA I use the polarssl one and plan to add
 the kernel one
 
 and this implementation is limited to 4096 the polarssl one is not

Having an ASN1 parser for DER/x509 is a huge amount of complexity I
would not want in a bootloader. Just take a look at the problems the
SSL-CAs and browsers had with different interpretations of the same
cert.

The FIT format (and corresponding public key in the bootloader's DT) has
been adopted by depthcharge and u-boot, because it handles the
requirements and nothing more.

What is your use-case for which you need to add keys at runtime?

Regards,
Jan
-- 
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: [RFC 3/4] FIT: add FIT image support

[Jan Lübbe]

On Fr, 2015-03-13 at 15:28 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
  It's not the job of barebox to define security policies, it must fit
  well into the larger security design, which may require compromises.
 
 I disagree, disable by default non secure feature is require to pass
 secure boot certification

Is there a specific certification you are targeting?

How do you intend to handle console access in verified boot mode?
Allowing access to md/mw would break any security.

I was thinking about switching off access to the HW AES keys as soon as
a prompt appears. At least on MX28/MX6 that's possible and important.

Regards,
Jan
-- 
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 4/7] digest: add verify callback

[Jan Lübbe]

On Do, 2015-03-12 at 15:22 +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
 +int digest_generic_verity(struct digest *d, const unsigned char *md)
 ^^ shouldn't this be verify for consistency?

 +   int (*verify)(struct digest *d, const unsigned char *in);
  ^^
this is called md in the other prototypes
-- 
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 0/4] Device Tree Overlay Support

[Jan Lübbe]

On Mi, 2015-03-04 at 10:29 +0100, Jan Luebbe wrote:
 This adds support for device tree overlays as supported by Linux 4.0-rc1.
 Patches 2-4 update the included DTC with overlay support.

Sorry, I forgot to mention that this depends on Marc's sandbox-of
series.

Regards,
Jan
-- 
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 1/2] ARM: Allow to mask data aborts

[Jan Lübbe]

On Do, 2015-02-26 at 19:05 +0100, Sascha Hauer wrote:
 +int data_abort_unmask(void)
 +{
 +   arm_ignore_data_abort = 0;
 +
 +   return arm_data_abort_occured;
 +}

arm_data_abort_occured is set to arm_data_abort_occured when an abort
occurs. Should we return arm_data_abort_occured != 0?

Also occured is actually spelled occurred.

Thanks,
Jan
-- 
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 v2 3/3] ARM: socfpga: add Altera SoCFPGA Development Kit support

[Jan Lübbe]

On Mo, 2015-02-23 at 10:15 +0100, Steffen Trumtrar wrote:
 --- /dev/null
 +++ b/arch/arm/boards/altera-socdk/board.c
 @@ -0,0 +1,38 @@

 +static int ksz9021rn_phy_fixup(struct phy_device *dev)
 +{
 + phy_write(dev, 0x09, 0x0f00);
 +
 + /* rx skew */
 + phy_write(dev, 0x0b, 0x8105);
 + phy_write(dev, 0x0c, 0x);
 +
 + /* clk/ctrl skew */
 + phy_write(dev, 0x0b, 0x8104);
 + phy_write(dev, 0x0c, 0xa0d0);
 +
 + return 0;
 +}
 +
 +static int socfpga_console_init(void)
 +{
 + if (!of_machine_is_compatible(altr,socdk))
 + return 0;
 +
 + phy_register_fixup_for_uid(PHY_ID_KSZ9021, MICREL_PHY_ID_MASK,
 +ksz9021rn_phy_fixup);
 +
 + return 0;
 +}
 +console_initcall(socfpga_console_init);

 --- /dev/null
 +++ b/arch/arm/dts/socfpga_cyclone5_socdk.dts

 +gmac1 {
 + status = okay;
 + phy-mode = rgmii;
 +
 + rxd0-skew-ps = 0;
 + rxd1-skew-ps = 0;
 + rxd2-skew-ps = 0;
 + rxd3-skew-ps = 0;
 + txen-skew-ps = 0;
 + txc-skew-ps = 2600;
 + rxdv-skew-ps = 0;
 + rxc-skew-ps = 2000;
 +};

It seems that with the DT-based configuration of the skew values, the
phy_fixup in board.c is not necessary.
-- 
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] fixup! defaultenv: generate force-built-in (zero) environment file

[Jan Lübbe]

On Di, 2015-02-03 at 18:45 +0900, Masahiro Yamada wrote:
 Without this, out-of-tree build (O=option) fails.
 
 diff --git a/defaultenv/Makefile b/defaultenv/Makefile
 index 8a001ec..33e0ece 100644
 --- a/defaultenv/Makefile
 +++ b/defaultenv/Makefile
 @@ -24,7 +24,7 @@ $(obj)/barebox_default_env.h: 
 $(obj)/barebox_default_env$(DEFAULT_COMPRESSION_SU
   $(call if_changed,env_h)
  
  quiet_cmd_env_zero = ENVZ$@
 -cmd_env_zero = ($(srctree)/scripts/bareboxenv -z 
 $(CONFIG_DEFAULT_ENVIRONMENT_PATH) $@)
 +cmd_env_zero = ($(objtree)/scripts/bareboxenv -z 
 $(CONFIG_DEFAULT_ENVIRONMENT_PATH) $@)

I adapted this from the same file a few lines above:
quiet_cmd_env_default = ENV $@
cmd_env_default = ($(srctree)/scripts/genenv $(srctree) $(objtree) $@ 
$(CONFIG_DEFAULT_ENVIRONMENT_PATH))

Why didn't this fail for your?

Regards,
Jan
-- 
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 2/3] defaultenv-2: introduce /env/rc.d

[Jan Lübbe]

Hi Jean-Christophe,

On Tue, 2015-01-13 at 16:29 +0800, Jean-Christophe PLAGNIOL-VILLARD wrote:
 and this will allow also to have the same script at different order
 based on the board requirement.

So without links you should be able to use 'mv' instead of 'ln'.

If this doesn't work for your case, could you describe it in a bit more
detail?

Regards,
Jan
-- 
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: [RFC] gen-dtb-s: make metadata binary fields always little-endian

[Jan Lübbe]

Hi,

On Sat, 2014-08-02 at 09:45 +0400, Antony Pavlov wrote:
  
 compatlen=$($FDTGET -t s $dtb / compatible | wc -c)
 -   echo .int 0x640c8005
 -   echo .int  $compatlen
 +   echo .byte 0x05, 0x80, 0x0c, 0x64
 +   python -c print(\.byte 0x%02x, 0x%02x, 0x%02x, 0x%02x\\n\ 
 % ($compatlen  0xff, ($compatlen  8)  0xff, ($compatlen  16)  0xff, 
 ($compatlen  24)  0xff))

Rather than adding a build-time dependency on python, maybe we should
just handle this in C?

Regards,
Jan
-- 
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: envfs: provide an intentional way to ignore an existing external environment

[Jan Lübbe]

Hi Jürgen!

This looks good so far.

On Wed, 2014-07-30 at 12:20 +0200, Juergen Borleis wrote:
 This change set adds a new option to the saveenv command which will
 write an empty environment without content. But it will be marked as a
 placeholder and thus should be ignored and barebox falls back to its
 built-in default environment.

I haven't found where the environment loading is changed to implement
this behavior. Is a patch missing?

Thanks,
Jan
-- 
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: generated command references sometimes render a solid blob of text

[Jan Lübbe]

On Tue, 2014-07-01 at 16:26 +0200, Holger Schurig wrote:
 The Kconfig help entries (the source of the generated command
 reference) have been written before python-sphinx have been selected.

Actually, the command reference is generated by parsing the macros in
the .c files. The Kconfig entries were changed by hand.

 So basically we need to go over all of them and make sure that they
 render correctly. From my point of view, it doesn't harm if you see
 raw ReST formatting while inside make xconfig.

I don't think that the Kconfig entries need to contain the full command
documentation.

Regards,
Jan
-- 
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: AM335x NAND

[Jan Lübbe]

On Thu, 2014-06-26 at 22:58 +0200, Stefan Müller-Klieser wrote:
 So, should I port the features from the u-boot driver into barebox,
 e.g. ELM and HW BCH16 support, or are there different plans from the
 maintainer?

I've seen that the Phytec AM335x BSPs contain patches which add support
for the ELM. This wasn't mainlined, but might a good starting point.

Regards,
Jan
-- 
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 1/2] ARM: i.MX: edmqmx6: Copy fdt to SDRAM

[Jan Lübbe]

On Thu, 2014-01-30 at 10:40 +0100, Sascha Hauer wrote:
 @@ -136,26 +137,37 @@ static void sdram_init(void)
 writel(0x047f, 0x021e80a4);
 writel(0xc34f, 0x021e80a8);
 writel(0x0001, 0x021e8080);
 +   putc_ll('');
  } 

Some leftover debugging. ;)
-- 
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: howto load/save envfs from linux

[Jan Lübbe]

On Thu, 2013-11-07 at 17:08 +0800, zzs wrote:
 My final user program is a linux program, It want to change
 mac address of eth.
 
 So I must read and write back the data saved in envfs.
 
 Howto do that?

You can enable compilation of the bareboxenv tool in menuconfig. That
tool can read and write the envfs format from userspace.

Regards,
Jan
-- 
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: bootloader specification for barebox

[Jan Lübbe]

Hi,

On Mon, 2013-09-30 at 11:43 +0200, Sascha Hauer wrote:
 Sascha Hauer (4):
   add function to read single line files
   cdev: store dos partition type in struct cdev
   Implement bootloader spec support for barebox
   add kernel-install tool for bootloader Spec

I've tried these patches on my BeagleBones and they work as described.

Regards,
Jan
-- 
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: bootloader specification for barebox

[Jan Lübbe]

On Mon, 2013-10-14 at 05:43 -0400, Robert P. J. Day wrote:
 On Mon, 14 Oct 2013, Jan Lübbe wrote:
 
  Hi,
 
  On Mon, 2013-09-30 at 11:43 +0200, Sascha Hauer wrote:
   Sascha Hauer (4):
 add function to read single line files
 cdev: store dos partition type in struct cdev
 Implement bootloader spec support for barebox
 add kernel-install tool for bootloader Spec
 
  I've tried these patches on my BeagleBones and they work as described.
 
   oooh ... i'd like to test replacing u-boot with barebox on my
 beaglebone black, is there any magic involved?

You should just need to use am335x_beaglebone_mlo_small_defconfig for
MLO and am335x_beaglebone_defconfig for barebox.bin. Then you place them
in the FAT partition (same procedure as with u-boot).

Regards,
Jan
-- 
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: [SPAM] [PATCH] common: fix possible build problem without password support

[Jan Lübbe]

Hi,

On Mon, 2013-10-14 at 17:46 +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
   quiet_cmd_pwd_h = PWDH$@
  +ifdef CONFIG_PASSWORD
 
 ??
 
 so if no password then it do
 
 cmd_pwd_h = echo const char default_passwd[] = \\;  $@
 
 that's all
 
 so we do not need to check CONFIG_PASSSORD

No. Try adding 'set -x;' to the shell call and building without
CONFIG_PASSWORD. In that case CONFIG_PASSWORD_DEFAULT is not set.
An unset Kconfig variable is not equal to .

   ifneq ($(CONFIG_PASSWORD_DEFAULT),)
   PASSWD_FILE := $(shell cd $(srctree); find $(CONFIG_PASSWORD_DEFAULT) 
  -type f)

Try with:
PASSWD_FILE := $(shell set -x; cd $(srctree); echo `find 
$(CONFIG_PASSWORD_DEFAULT) -type f`)

   cmd_pwd_h = echo -n const char default_passwd[] = \  $@; \
  @@ -134,6 +135,7 @@ endif
   targets += include/generated/passwd.h
-- 
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: bareboxenv-target and spi nor flash crc problem

[Jan Lübbe]

On Fri, 2013-10-11 at 14:57 +0200, Vanhauwaert Wouter wrote:
 Hi, I want to use bareboxenv-target on my operating system
 My environment settings are stored on a m25p32 spi nor flash.
 I can load them perfectly by issueing command:
 bareboxenv-target -l /tmp/barebox /dev/mtd1 
 I change something and afterwards I do: bareboxenv-target -s /tmp/barebox 
 /dev/mtd1
 No problems so far
 However
 If I reboot, I get a wrong crc on env superblock and default environment is 
 loaded

You should use flash_erase (from mtd-utils) on the mtd partition before
writing to it.

Regards,
Jan Lübbe
-- 
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: FW: Writing to I2C device during Barebox boot

[Jan Lübbe]

On Wed, 2013-10-09 at 18:59 -0700, Ivor Kruger wrote:
 But this is where my linux knowledge is letting me down.
 
 How do I get a handle to the device in order to call the write_reg
 function?
 
 Your pointers and help is much appreciated.

Could you show us your code? That would make helping you much easier.
Please see 'man git-send-email' on how to send patches with git.

Regards,
Jan
-- 
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] i2c-omap: Update driver

[Jan Lübbe]

On Mon, 2013-09-30 at 10:16 +0200, Sascha Hauer wrote: 
 On Thu, Sep 26, 2013 at 01:40:24PM +0200, Jan Weitzel wrote:
  The driver didn't work well with at24 driver. NACKS are lost.
  Errors are lost in isr due to the local variable err. Also we didn't wait 
  for
  bus free in omap_i2c_xfer_msg.
  
  Fix issues and get other improvements from linux kernel
  
  Tested on OMAP4 and AM335x
  
  Signed-off-by: Jan Weitzel j.weit...@phytec.de
 
 Applied, thanks

When booting my BeagleBone with this, I see:
i2c-omap i2c-am33xx0: bus 0 rev84148224.11 at 100 kHz

The revision entry looks strange, but the at24 EEPROM continues to be
accessible. I've not yet looked at it in detail. Jan, do you have an
idea?

Regards,
Jan


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

Re: [PATCH 1/4] am33xx_generic: convert from switch to if/else

[Jan Lübbe]

On Wed, 2013-10-02 at 21:45 +0200, Lucas Stach wrote: 
 Am Mittwoch, den 02.10.2013, 21:30 +0200 schrieb Jan Luebbe:
  The function am33xx_get_cpu_rev may be called before barebox_arm_entry(),
  so we need to avoid switch statements. 
 
 Uhm, could you please be more verbose on _why_ we need to avoid switch
 statements at this stage? I might be running into the same failure with
 Tegra at some point if there's a real issue.

I believe the problem is that the table is accessed using absolute
addresses. Before the call to barebox_arm_entry() barebox may be running
at a different address.

Regards,
Jan


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

Re: [PATCH 1/3 for next] AM33xx: Cleanup of lowlevel code

[Jan Lübbe]

On Fri, 2013-08-23 at 09:00 +0200, Teresa Gámez wrote:
 There is a lot of duplicate lowlevel code between the
 am33xx boards. Move this code to am33xx_generic and
 create structs for sdram settings.
 
 Signed-off-by: Teresa Gámez t.ga...@phytec.de

Just for comparison, the current u-boot mainline does something similar:
http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-am33xx/ddr_defs.h;hb=HEAD

-- 
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] AM33xx: Make OSC frequency board depended

[Jan Lübbe]

On Tue, 2013-08-20 at 14:10 +0200, Teresa Gámez wrote:
 
 The oscillator frequency varies on different AM33xx boards.
 Pass the osc frequency from lowlevel board code
 to set the correct one on every board.
 
 Signed-off-by: Teresa Gámez t.ga...@phytec.de
 ---
  arch/arm/boards/beaglebone/lowlevel.c  |2 +-
  arch/arm/boards/pcm051/lowlevel.c  |2 +-
  arch/arm/mach-omap/am33xx_clock.c  |   26
 
  arch/arm/mach-omap/include/mach/am33xx-clock.h |8 +--
  4 files changed, 16 insertions(+), 22 deletions(-) 

Looks good, thanks.

Reviewed-by: Jan Luebbe j...@pengutronix.de
-- 
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: [SPAM] [PATCH] scripts: genenv: remove empty files from tempdir

[Jan Lübbe]

On Tue, 2013-05-28 at 12:55 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
 On 09:45 Tue 28 May , Jan Luebbe wrote:
  This allows leaving out default files from the environment by overriding
  them with empty files in the board or BSP.
  
  Signed-off-by: Jan Luebbe j...@pengutronix.de
  ---
 can we move it to the buildir and keep it
 
 and no need to have a uniq name everytime

Sorry, could you explain this again differently? I don't understand your
comment.

Regards,
Jan
-- 
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: 2013.05 breaking Linux boot on imx28 CFA-10036

[Jan Lübbe]

On Thu, 2013-05-23 at 11:46 +0200, Maxime Ripard wrote:
 I've tested lately both 2013.05.0 and the master of Barebox on the imx28
 cfa-10036 board we have.
 
 Everything works fine with 2013.04.0.
 
 The issue I have is that Barebox in itself works fine, however, Linux
 fails to boot after it has been started by Barebox, quite early and
 badly:
 
 http://code.bulix.org/s3z010-83581

Could you try the not-yet-released stable branch?
http://git.pengutronix.de/?p=barebox.git;a=shortlog;h=refs/heads/stable/v2013.05

-- 
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] ARM: OMAP5 processors support

[Jan Lübbe]

On Thu, 2013-04-25 at 15:42 +0300, Uladzimir Bely wrote:
 25.04.2013 14:58, Jan Lübbe пишет:
  On Thu, 2013-04-25 at 12:09 +0300, Uladzimir Bely wrote:
  diff --git a/arch/arm/boards/omap5_sevm/env/config 
  b/arch/arm/boards/omap5_sevm/env/config
  new file mode 100644
  index 000..9752957
  --- /dev/null
  +++ b/arch/arm/boards/omap5_sevm/env/config
  @@ -0,0 +1,11 @@
  +#!/bin/sh
  +
  +machine=omap5
  +
  +autoboot_timeout=2
  +
  +bootargs=console=ttyO2,115200
  +
  +kernel_loc=disk
  +
  +PS1=\e[1;32mbarebox@\e[1;31m\h:\w\e[0m 
 
  Please use defaultenv-2.
 
 
 I'm not too familiar with barebox's defaultenv/defaultenv-2. Our work on
 omap5 was based mostly on omap5 code from U-Boot and omap4 code from barebox.
 Mostly, I used pcm049 as an example of omap4-based board in barebox. So
 arch/arm/boards/omap5_sevm/env/config looks like this one, but includes
 only most necessary thinks to load to barebox prompt.
 
 Please, give me a hint, which board can be used as an example of using
 defaultenv-2, maybe I'll do something.

Take a look at arch/arm/boards/beagle (omap3) or arch/arm/boards/panda
(omap4).

  diff --git a/arch/arm/mach-omap/Kconfig b/arch/arm/mach-omap/Kconfig
  index 42e5f4a..0ad3864 100644
  --- a/arch/arm/mach-omap/Kconfig
  +++ b/arch/arm/mach-omap/Kconfig
  @@ -41,6 +41,14 @@ config ARCH_OMAP4
 help
   Say Y here if you are using Texas Instrument's OMAP4 based platform
 
  +config ARCH_OMAP5
  +  bool OMAP5
  +  select CPU_V7
  +  select GENERIC_GPIO
  +  select OMAP_CLOCK_SOURCE_S32K
  +  help
  +Say Y here if you are using Texas Instrument's OMAP5 based platform
  +
config ARCH_AM33XX
 bool AM33xx
 select CPU_V7
  @@ -115,6 +123,7 @@ config BOARDINFO
 default Phytec phyCARD-A-L1 if MACH_PCAAL1
 default Phytec phyCARD-A-XL2 if MACH_PCAAXL2
 default Phytec phyCORE-AM335x if MACH_PCM051
  +  default Phytec phyCORE omap5_sevm if MACH_OMAP5_SEVM
 
choice
 prompt Select OMAP board
  @@ -177,6 +186,13 @@ config MACH_PCAAXL2
 help
   Say Y here if you are using a phyCARD-A-XL1 PCA-A-XL1
 
  +config MACH_OMAP5_SEVM
  +  bool Phytec phyCORE omap5_sevm
  +  depends on ARCH_OMAP5
  +  help
  +Say Y here if you are using Phytecs phyCORE omap5_sevm board
  +based on OMAP5
  +
config MACH_PCM051
 bool Phytec phyCORE pcm051
 select OMAP_CLOCK_ALL
 
  Isn't the OMAP5 sEVM from TI?
 
 
 We worked with OMAP5-based board, produced by Phytec (Phytec phyCORE-OMAP5),
 but, as I have mentioned above, code was partially ported from U-Boot's
 OMAP5-sevm board. I'll correct it.

The names should be consistent and match the hardware the new code you
are adding in this patch is intended for.

-- 
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] ARM: OMAP5 processors support

[Jan Lübbe]

On Fri, 2013-04-26 at 13:33 +0300, Uladzimir Bely wrote:
  diff --git a/arch/arm/mach-omap/Kconfig b/arch/arm/mach-omap/Kconfig
  index 42e5f4a..0ad3864 100644
  --- a/arch/arm/mach-omap/Kconfig
  +++ b/arch/arm/mach-omap/Kconfig
  @@ -41,6 +41,14 @@ config ARCH_OMAP4
 help
   Say Y here if you are using Texas Instrument's OMAP4 based platform
   
   
  +config MACH_OMAP5_SEVM
  +  bool Phytec phyCORE omap5_sevm
  +  depends on ARCH_OMAP5
  +  help
  +Say Y here if you are using Phytecs phyCORE omap5_sevm board
  +based on OMAP5
  +
   config MACH_PCM051
 bool Phytec phyCORE pcm051
 select OMAP_CLOCK_ALL
  
  Isn't the OMAP5 sEVM from TI?
  
 
 This question is more complicated. We use Phytec phyCORE OMAP4 board, but
 with OMAP5 SOC installed. We used omap5_sevm with number 3777 which already
 exists in arch/arm/tools. Kernel also was compiled for this mach-type.

So the board which you use for development is not generally available.
Maybe you could call it something like MACH_PCM049_OMAP5 or
MACH_PHYCORE_OMAP5_EVAL...?

 As I understand, new board (Phytec phyCORE OMAP5) must be added to this file
 (http://www.arm.linux.org.uk/developer/machines/download.php) first, and 
 barebox
 will use this updated file for this board too. Am I right? How can I add new
 board here correctly?

To request a new machine ID, use
http://www.arm.linux.org.uk/developer/machines/?action=new

Note that new legacy (non-Device-Tree) boards are no longer accepted
into the kernel! For DT-only boards no machine ID is needed at all.

Regards,
Jan Lübbe
-- 
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] ARM OMAP5: Basic support of Texas Instruments OMAP5 processors

[Jan Lübbe]

Hi,

you didn't respond to my comments in your new version, especially
regarding the code duplication in arch/arm/mach-omap/omap5_generic.c
(relative to omap4_generic.c).

Regards,
Jan

-- 
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] ARM: OMAP5 processors support

[Jan Lübbe]

On Thu, 2013-04-25 at 12:09 +0300, Uladzimir Bely wrote:
 diff --git a/arch/arm/boards/omap5_sevm/env/config 
 b/arch/arm/boards/omap5_sevm/env/config
 new file mode 100644
 index 000..9752957
 --- /dev/null
 +++ b/arch/arm/boards/omap5_sevm/env/config
 @@ -0,0 +1,11 @@
 +#!/bin/sh
 +
 +machine=omap5
 +
 +autoboot_timeout=2
 +
 +bootargs=console=ttyO2,115200
 +
 +kernel_loc=disk
 +
 +PS1=\e[1;32mbarebox@\e[1;31m\h:\w\e[0m 

Please use defaultenv-2.

 diff --git a/arch/arm/mach-omap/Kconfig b/arch/arm/mach-omap/Kconfig
 index 42e5f4a..0ad3864 100644
 --- a/arch/arm/mach-omap/Kconfig
 +++ b/arch/arm/mach-omap/Kconfig
 @@ -41,6 +41,14 @@ config ARCH_OMAP4
   help
 Say Y here if you are using Texas Instrument's OMAP4 based platform
  
 +config ARCH_OMAP5
 + bool OMAP5
 + select CPU_V7
 + select GENERIC_GPIO
 + select OMAP_CLOCK_SOURCE_S32K
 + help
 +   Say Y here if you are using Texas Instrument's OMAP5 based platform
 +
  config ARCH_AM33XX
   bool AM33xx
   select CPU_V7
 @@ -115,6 +123,7 @@ config BOARDINFO
   default Phytec phyCARD-A-L1 if MACH_PCAAL1
   default Phytec phyCARD-A-XL2 if MACH_PCAAXL2
   default Phytec phyCORE-AM335x if MACH_PCM051
 + default Phytec phyCORE omap5_sevm if MACH_OMAP5_SEVM
  
  choice
   prompt Select OMAP board
 @@ -177,6 +186,13 @@ config MACH_PCAAXL2
   help
 Say Y here if you are using a phyCARD-A-XL1 PCA-A-XL1
  
 +config MACH_OMAP5_SEVM
 + bool Phytec phyCORE omap5_sevm
 + depends on ARCH_OMAP5
 + help
 +   Say Y here if you are using Phytecs phyCORE omap5_sevm board
 +   based on OMAP5
 +
  config MACH_PCM051
   bool Phytec phyCORE pcm051
   select OMAP_CLOCK_ALL

Isn't the OMAP5 sEVM from TI?

-- 
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: [RFC PATCH 1/2] AM33XX: Move muxing defines to header file

[Jan Lübbe]

On Thu, 2013-03-14 at 08:30 +0100, Sascha Hauer wrote:
 Hi Teresa,
 
 On Tue, Mar 12, 2013 at 03:04:12PM +0100, Teresa Gámez wrote:
  The muxing in the am33xx_mux.c file is not generic as the muxing
  setup does not fit for every board. Move the structs and functions
  to the mach/am33xx-mux.h so board dependend mux setups can be
  created.
  
  Signed-off-by: Teresa Gámez t.ga...@phytec.de
 
 Looks good to me. Jan is more familiar with the am33xx. Jan,
 could you have a look on it?

I haven't tested it, but the approach seems good. When adding a new
board, I would probably have done the same.

The current PinMux is still a bit BeagleBone-specific, but that should
be fixed in a separate patch. (Or instead write a pinctrl-single driver
and configure PinMux via DT).

Regards,
Jan
-- 
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 00/11 v6] introduction of dmesg support

[Jan Lübbe]

You sent these patches to linux-arm-ker...@lists.infradead.org (again).

Regards,
Jan
-- 
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: Re: [PATCH 1/1] commands/ubi.c: Add support for VID header offset in ubiattach

[Jan Lübbe]

On Fri, 2013-02-15 at 10:54 -0500, Xavier Douville wrote:
 On 02/14/2013 11:23, Jan Lübbe wrote:
 
  Which kernel  barebox are you using?
 
 
 I am using kernel 3.2.0 and barebox 2012.11.0.
 Both with patches from Phytec (phyCORE-AM335x-PD12.1.1).

I'm not sure if that barebox is different to the latest one regarding
the GPMC NAND support...

Does it actually fail on your board without this patch?

I have here:

...
NAND device: Manufacturer ID: 0x2c, Chip ID: 0xda (Micron NAND 256MiB 3,3V 
8-bit), page size: 2048, OOB size: 64
...
barebox:/ devinfo nand0
resources:
driver: none
bus: none

Parameters:
size = 268435456
   erasesize = 131072
   writesize = 2048
 oobsize = 64 
barebox:/ ubiattach /dev/nand0.root
UBI: attaching mtd0 to ubi0
UBI: physical eraseblock size:   131072 bytes (128 KiB)
UBI: logical eraseblock size:126976 bytes
UBI: smallest flash I/O unit:2048
UBI: VID header offset:  2048 (aligned 2048)
UBI: data offset:4096
registering /dev/ubi0
registering root as /dev/ubi0.root
UBI: attached mtd0 to ubi0
UBI: MTD device name:nand0.root
UBI: MTD device size:96 MiB
UBI: number of good PEBs:768
UBI: number of bad PEBs: 0
UBI: max. allowed volumes:   128
UBI: wear-leveling threshold:4096
UBI: number of internal volumes: 1
UBI: number of user volumes: 1
UBI: available PEBs: 33
UBI: total number of reserved PEBs: 735
UBI: number of PEBs reserved for bad PEB handling: 7
UBI: max/mean erase counter: 15/8
barebox:/ 

So it figures out the VID offset correctly from the writesize of 2048.

Regards,
Jan
-- 
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 1/1] commands/ubi.c: Add support for VID header offset in ubiattach

[Jan Lübbe]

On Mon, 2013-02-11 at 16:21 +0100, Sascha Hauer wrote:
 I'm interested in this patch once it's clear that this option is needed.
 Right now I think that the work is better invested in making this option
 unneeded. Jan, do you have insights why this is needed?

Linux with current mainline + pending GPMC/ELM patches thinks it
supports sub-page reads/writes on 2k page NAND with BCH8. This is simply
wrong. By using root=ubi0:root ubi.mtd=nand0.root,2048
rootfstype=ubifs in the kernel cmdline, you will get this override in
the kernel.

The GMPC NAND driver in barebox correctly does not use sub-page-access
and works fine without overriding the VID header offset.

When building the UBIFS/UBI the offset must obviously be set correctly.

Which kernel  barebox are you using?

Regards,
Jan
-- 
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: Memory size issue

[Jan Lübbe]

On Tue, 2013-01-22 at 13:45 +0400, Alexander Shiyan wrote:
 Hello.
 
 I found a discrepancy between the size of memory in the system and
 report by meminfo.
 In the following example, the system registered 512M, but the meminfo
 shows only 256M.
 Error or so and originally intended?
 
 barebox@i.MX51:/ devinfo mem0
 resources:
 num   : 0
 name  : ram0
 start : 0x9000
 size  : 0x2000
 driver: mem
 bus: platform
 
 no info available for mem0
 no parameters available
 barebox@i.MX51:/ meminfo
 max system bytes = 245760
 system bytes = 245760
 in use bytes = 223200

This is 240kiB, not 256MiB. As meminfo shows only the memory used by
barebox, this is should not be the same as the SDRAM size.

Regards,
Jan
-- 
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: suddenly, i can't boot barebox on my beagle xM anymore [ISOLATED]

[Jan Lübbe]

Hi,

On Sun, 2012-12-02 at 04:24 -0500, Robert P. J. Day wrote:
 i've isolated the commit that introduces the apparent booting
 problem on my xM:
 
 $ git show 154496f
 commit 154496f736db54123c3f6daaba18809fab54ed9b
 Merge: 05d251f bd6d12b
 Author: Sascha Hauer s.ha...@pengutronix.de
 Date:   Fri Nov 16 14:02:49 2012 +0100
 
 Merge branch 'for-next/omap'

*snip*

   so something in that omap merge is causing this.

The merge itself does not actually introduce new code.

Could you try finding the commit with git bisect?

~/git/barebox $ git bisect start
~/git/barebox $ git bisect bad 154496f736db54123c3f6daaba18809fab54ed9b
~/git/barebox $ git bisect good 05d251f
Bisecting: 3 revisions left to test after this (roughly 2 steps)
[663c466794382f803a69414c935cf0a13d4f0761] ARM OMAP4 panda: switch to new 
environment
~/git/barebox $

Then test this checkout and tell git using git bisect good or git
bisect bad.

Thanks,
Jan
-- 
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: suddenly, i can't boot barebox on my beagle xM anymore [ISOLATED]

[Jan Lübbe]

On Mon, 2012-12-03 at 03:31 -0500, Robert P. J. Day wrote:
 *sigh* ... i *think* i figured out what's happening.  in order to
 play with barebox on my xM, until recently, i'd done nothing more than
 create a single FAT partition on a micro SD card, put MLO and
 barebox.bin on it, put it in my xM, and let it boot.  until that OMAP
 merge, it worked fine.
 
   as i read it, the new default environment for the xM *requires* a
 second (ext3) partition or the boot process simply hangs, am i reading
 that right?  if that's true, how can i adjust that so i can once again
 just boot to barebox without having a kernel and root fs created yet?

Only the kernel uses the second partition for its rootfs, barebox should
get to the prompt where you can interrupt autoboot anyway.

So figuring out the exact commit would be useful. The bisection should
take only a few steps. Sascha build-checks every revision, so all the
bisection steps should build fine.

Regards,
Jan
-- 
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 3/4] reset_resource: add wakeup source

[Jan Lübbe]

On Sat, 2012-10-13 at 15:49 +0200, Jean-Christophe PLAGNIOL-VILLARD wrote:
 +static const char * const wakeup_src_names[] = {
 + [WAKEUP_UKWNOWN] = unknown,
 + [WAKEUP_POWER] = power,
 + [WAKEUP_RTC] = rtc,
 + [WAKEUP_TIMER] = timer,
 + [WAKEUP_USER] = user,
 + [WAKEUP_WOL] = wakeup on lan,
 +};
 +
 +void set_wakeup_source(enum wakeup_src_type st)
 +{
 + setenv(global.system.wakeup, wakeup_src_names[st]);
 +}
 +EXPORT_SYMBOL(set_reset_source);

The EXPORT_SYMBOL should be for _wakeup_ instead of _reset_.

-- 
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 3/3] net/eth: fix link handling

[Jan Lübbe]

On Wed, 2012-09-26 at 14:43 +0200, Sascha Hauer wrote:
 The eth-active is for tracking whether a device is opened (thus we have
 to call eth-halt). With this patch eth-active == 0 could mean:
 
 a) device not opened
 b) opened, but no link
 
 This is asking for trouble. A bit only has two states, you should not
 encode three states in it.

Yes. We should not repeatedly open the device to check link status
again. A open (active==1) device with no link is perfectly valid, it
just can't be used for TX/RX.

So if we have an open device in TX/RX and
  link down: recheck link
  link up: recheck link if the last check is too old

This way we notice both link going down and up, while not wasting time
when we are waiting for link up.

Regards,
Jan
-- 
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] Makefile: add target to produce a SPL compatible uImage

[Jan Lübbe]

On Tue, 2012-09-25 at 14:29 +0200, Teresa Gamez wrote:
 Am 24.09.2012 14:49, schrieb Jan Lübbe:
  On Mon, 2012-09-24 at 14:37 +0200, Teresa Gamez wrote:
  I have tested it with my am335x patches. And it worked so far.
  But I have not done anything with the pbl image, yet.
  Could you explain me what it's actually for? And how I can test it?
  Thanks!
 
  PBL stands for Pre-Bootloader Image, which is used to have a compressed
  barebox binary. You can enable it in General Settings - memory layout
  - Pre-Bootloader image.
 
 Do I understand this correctly that this is suppose to be used to decrease
 the size of first stage bootloader binaries like the MLO on ti boards?

I don't think it is useful in the current form for the MLO case. The
problem there is that the SRAM would be too small to contain the
decompressed image (in addition to the compressed one). 

It saves some time when loading from slower flash and is useful when the
space for barebox in flash is limited some how (but you have enough
RAM).

For the MLO case we would need to have the DRAM setup in the
Pre-Bootloader and then decompress to DRAM. That should be possible, but
I'm not sure how much we'd gain (the compressed image would still be
limited by SRAM size).

Regards,
Jan
-- 
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] Makefile: add target to produce a SPL compatible uImage

[Jan Lübbe]

On Mon, 2012-09-24 at 14:37 +0200, Teresa Gamez wrote:
 I have tested it with my am335x patches. And it worked so far.
 But I have not done anything with the pbl image, yet.
 Could you explain me what it's actually for? And how I can test it?

Thanks!

PBL stands for Pre-Bootloader Image, which is used to have a compressed
barebox binary. You can enable it in General Settings - memory layout
- Pre-Bootloader image.

Regards,
Jan
-- 
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 1/2] Add bcm2835/Raspberry-Pi support

[Jan Lübbe]

Hi,

I've tried your patches and the boot fine:

barebox 2012.09.0-00168-g5a8f45d #1 Thu Sep 20 17:24:48 CEST 2012

Board: RaspberryPi (BCM2835/ARM1176JZF-S)
Malloc space: 0x0020 - 0x005f (size  4 MB)
Stack space : 0x0010 - 0x00108000 (size 32 kB)
Open /dev/env0 No such file or directory
no valid environment found on /dev/env0. Using default environment
running /env/bin/init...
RPi / devinfo 
devices:
` uart-pl0110
 ` cs0
` global
` mem0
 ` 0x-0x07ff: /dev/ram0
` ramfs0
` devfs0
` mem1
 ` 0x-0x2007: /dev/defaultenv
` mem2
 ` 0x-0xfffe: /dev/mem

drivers:
uart-pl011
 ramfs
 devfs
   mem
cramfs
RPi / 

The first patch has some white-space warnings which should be fixed:
$ git am ~/\[PATCH_1_2\]_Add_bcm2835_Raspberry-Pi_support.mbox
Applying: Add bcm2835/Raspberry-Pi support
/ptx/work/dude/jlu/raspi/barebox/.git/rebase-apply/patch:358: trailing 
whitespace.
.rate = UART0_CLOCK,
/ptx/work/dude/jlu/raspi/barebox/.git/rebase-apply/patch:410: space before tab 
in indent.
uint32_t rstc;
/ptx/work/dude/jlu/raspi/barebox/.git/rebase-apply/patch:411: trailing 
whitespace.

/ptx/work/dude/jlu/raspi/barebox/.git/rebase-apply/patch:415: trailing 
whitespace.

/ptx/work/dude/jlu/raspi/barebox/.git/rebase-apply/patch:595: trailing 
whitespace.

warning: squelched 1 whitespace error
warning: 6 lines add whitespace errors.

So feel free to add my Tested-By for the cleaned-up version:
Tested-By: Jan Luebbe j...@pengutronix.de

Regards,
Jan
-- 
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 1/2] Add bcm2835/Raspberry-Pi support

[Jan Lübbe]

Hi,

On Wed, 2012-09-19 at 12:00 +0200, Carlo Caione wrote:
 You need an sd card with a single partition fat32 with inside 
 bootcode.bin, loader.bin and start.elf (you can find the files here 
 https://github.com/raspberrypi/firmware/tree/master/boot)
 Then just copy barebox.bin on the card and rename it kernel.img.

Ok, I'll try that later today.

What are your next plans? The USB or SD controllers?

Regards,
Jan
-- 
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] omap: add SPI as a boot mode for xload

[Jan Lübbe]

Note that this applies on top of Jan Weitzel's 'xload: get barebox size
from barebox_arm_head'.
-- 
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 01/12] add barebox logo

[Jan Lübbe]

Hi,

On Thu, 2012-09-06 at 08:04 +0200, Jean-Christophe PLAGNIOL-VILLARD
wrote:
 skip as too big

This adds 18MB of binary logos to the tree, which is larger than the
complete current tree. Is this really necessary?

Perhaps we could build the required files on demand from an SVG or
something?

Regards,
Jan
-- 
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