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
> ---
>
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 ++
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:
> > > + co
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 ar
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.
>
> Sig
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 l
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,
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 implementatio
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
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
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 n
On Thu, 2018-05-03 at 10:42 +0200, Andreas Schmidt wrote:
> > Your use-case sound like you'd need a way to add a more specific DT
> > board compatible at runtime.
>
> We need a decision witch DT has to be load at runtime. But they are all
> compatible with the barebox DT. We have only one barebox
On Wed, 2018-05-02 at 10:46 -0700, Andrey Smirnov wrote:
> On Wed, May 2, 2018 at 7:42 AM, Jan Lübbe 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 informati
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
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
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 pre
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 framewo
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 d
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
On Wed, 2017-08-16 at 10:17 +0200, Uwe Kleine-König wrote:
> Hallo Jan,
>
> On Tue, Aug 15, 2017 at 11:47:37AM +0200, Jan Luebbe wrote:
> > The PLL setup is needed to use the USB ports in Linux.
> >
> > This code is ported from mainline U-Boot arch/arm/mach-mvebu/cpu.c.
>
> Actually this is a wo
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.
> >
On Mo, 2016-08-22 at 15:10 +0200, Yegor Yefremov wrote:
> What is "bbremote listen" for?
It will setup a RATP connection in the 'listen' state. We used it for
testing during development. Maybe it could be reused for running
loopback tests locally.
Regards,
Jan
--
Pengutronix e.K.
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.pengutroni
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:
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 direc
On So, 2016-01-17 at 17:07 -0800, Andrey Smirnov wrote:
> >
> > Signed-off-by: Jan Lübbe
> > Signed-off-by: Sascha Hauer
>
> With fixes above,
>
> Tested-by: Andrey Smirnov
These fixes look fine,
Acked-by:
erified 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
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;
> >> > +
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_ALIG
On Di, 2015-10-20 at 10:39 +0200, Marc Kleine-Budde wrote:
> This patch adds hmac support to the raw backend.
hmac is misspelled hamc in the subject.
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.
On Mo, 2015-08-24 at 13:32 +0200, Daniel Schultz wrote:
> This tools can read/write to the extended CSD register of MMC devices.
Is this enough to use the "Enhanced User Data Area" and partitioning
features of recent eMMCs? I seem to remember that the standard requires
setting the ERASE_GROUP_DEF
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
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]
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 appli
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
On Do, 2015-07-16 at 10:51 +0200, Daniel Schultz wrote:
> The dmtimer0 is too inaccurate to be used for measurements.
> We switch to the more accurate dmtimer2.
What are you trying to measure? Is the resolution or the accuracy too
low?
> +#define CLK_M_OSC2500
> +static int dmtimer_init(
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 def
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 compil
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
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 a
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
> en
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 cou
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 w
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
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'
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 rou
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
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 intend
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 \t", "digest to use")
> +BAREBOX_CMD_HELP_OPT
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 pra
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
>
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 g
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 di
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
randoml
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 secu
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
Hi,
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 k
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
> sec
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
>
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
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
> > >
> > &g
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
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.
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
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/m
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);
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.
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 !=
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, 0x81
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
On Fr, 2015-01-30 at 08:40 +0100, Sascha Hauer wrote:
> On Thu, Jan 29, 2015 at 08:25:54PM +0100, Robert Jarzmik wrote:
> > Sascha Hauer writes:
> >
> > > On Thu, Jan 29, 2015 at 10:12:46AM +0100, Wjatscheslaw Stoljarski
> wrote:
> > >> Hello,
> > >>
> > >> If I try to read from first 4k RAM on
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 ca
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
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
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 w
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
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. ;)
--
Pe
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
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 CON
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
>
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
> 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
writ
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 helpi
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
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_xf
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
Just for comparison, the current u-boot mainline does somethin
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
> ---
> arch/arm/boards/beaglebone/lowlevel.c
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
> > ---
> can we m
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 i
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 legac
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
> >
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
> +
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
On Tue, 2013-04-16 at 23:32 +0200, Vicente Bergas wrote:
> Signed-off-by: Vicente Bergas
> ---
> arch/arm/mach-omap/omap4_generic.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm/mach-omap/omap4_generic.c
> b/arch/arm/mach-omap/omap4_generic.c
> index b3
On Tue, 2013-04-02 at 09:41 +0200, "Breixo López García" wrote:
> malloc space: 0x80b0 -> 0x80ff (size 5 MB)
>
> stack space: 0x80af8000 -> 0x80b0 (size 32 kB)
>
> running /env/bin/init...
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-m
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-512
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)
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 + pendi
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?
>
> bar
1 - 100 of 123 matches
Mail list logo
