On Thu, 29 Apr 2021 08:46:36 +0200
Stefan Roese wrote:
> >phy: marvell: add RX training command
>
> Applied to u-boot-marvell/master
>
> Thanks,
> Stefan
Stefan, do you think it would make sense to at least create a special
mechanism for these platform commands? For example via a top-level
On Mon, 3 May 2021 17:10:51 -0600
Simon Glass wrote:
> Use the common function to avoid code duplication.
>
> Signed-off-by: Simon Glass
Is this tested? Why only zstd?
marek
On Wed, 5 May 2021 11:19:13 +0200
Pali Rohár wrote:
> > "bubt" is special and cannot be changed easily without breaking update
> > scripts using it AFAICT. As it's pretty old and used in the Marvell code
> > base for quite some time - including all the documentation about
> > updating.
>
> I s
On Wed, 5 May 2021 09:15:10 +0200
Stefan Roese wrote:
> Rename the misleading cmd "rx_training" to "mvebu_comphy_rx_training" to
> avoid confusion and mixup with DDR3/4 training. This makes it clear,
> that this command is platform specific and handles the COMPHY RX
> training.
>
> Also depend
On Sun, 9 May 2021 09:14:14 -0500
Adam Ford wrote:
> On Sat, Mar 6, 2021 at 10:06 PM Marek Behun wrote:
> >
> > On Sat, 6 Mar 2021 21:45:02 -0600
> > Adam Ford wrote:
> >
> > > On Sat, Mar 6, 2021 at 3:49 PM Marek Behun wrote:
> > > >
> &
On 2023-11-27 06:57, Maxim Uvarov wrote:
Decrease allowed binary size to fit lwip code.
u-boot-with-spl.kwb exceeds file size limit:
limit: 0xf6000 bytes
actual: 0xf8600 bytes
excess: 0x2600 bytes
Signed-off-by: Maxim Uvarov
---
configs/turris_omnia_defconfig | 1 +
1 file changed, 1 in
On Sun, 30 Aug 2020 08:38:32 +0200
Andre Heider wrote:
> Hi Marek,
>
> On 19/08/2020 11:57, Marek Behún wrote:
> > This commit fixes initialization of COMPHY on EspressoBin.
> >
> > Commit 22f418935be4 ("phy: marvell: a3700: Use comphy_mux on Armada
> > 37xx.") introduced usage of comphy_mux on
On Sun, 6 Sep 2020 11:32:47 +0200
Pali Rohár wrote:
> Adding Marek to loop.
>
> On Saturday 05 September 2020 14:07:44 Andre Heider wrote:
> > Required for the generic distro mechanism.
> >
> > Linux ships with 4 variants:
> > marvell/armada-3720-espressobin-v7-emmc.dtb
> > marvell/armada-3720-
On Sun, 6 Sep 2020 20:48:57 +0200
Andre Heider wrote:
> On 06/09/2020 18:12, Marek Behun wrote:
> > On Sun, 6 Sep 2020 11:32:47 +0200
> > Pali Rohár wrote:
> >
> >> Adding Marek to loop.
> >>
> >> On Saturday 05 September 2020 14:07:44 Andr
On Mon, 7 Sep 2020 18:26:04 -0400
Tom Rini wrote:
> On Wed, Jun 24, 2020 at 06:02:49PM +0200, Marek Behún wrote:
>
> > From: Qu Wenruo
> >
> > This patch uses generic code from btrfs-progs to read one super block
> > from block device.
> [snip]
> > +/* Provide a compatibility layer to make c
On Tue, 9 Mar 2021 21:00:00 +0800
Bin Meng wrote:
>
> --start-group is useless now.
>
> > $(u-boot-main)
> > \
> > - --end-group
> > \
> > + --no-wh
On Tue, 9 Mar 2021 21:30:26 +0800
Bin Meng wrote:
> > +config LTO
> > + bool "Enable Link Time Optimizations"
> > + depends on ARCH_SUPPORTS_LTO
> > + default n
>
> nits: this line is not needed as the default value is n if omitted
This is for consistency. The other options
On Tue, 9 Mar 2021 23:24:01 +0800
Bin Meng wrote:
> On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote:
> >
> > When building with LTO, move $(PLATFORM_LIBS) into the --start-group /
> > --end-group list.
>
> This should be --whole-archive
>
> > Otherwise some functions declared in assembly m
On Wed, 10 Mar 2021 11:40:42 +0800
Bin Meng wrote:
> On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote:
> >
> > When building with LTO, using -ffunction-sections/-fdata-sections is not
> > useful anymore.
> >
> > Signed-off-by: Marek Behún
> > ---
> > arch/arm/config.mk | 8 ++--
> > 1 fil
On Fri, 12 Mar 2021 14:48:04 +0800
Bin Meng wrote:
> On Fri, Mar 12, 2021 at 2:45 PM Marek Behun wrote:
> >
> > On Wed, 10 Mar 2021 11:40:42 +0800
> > Bin Meng wrote:
> >
> > > On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote:
> > > >
On Fri, 12 Mar 2021 14:48:04 +0800
Bin Meng wrote:
> On Fri, Mar 12, 2021 at 2:45 PM Marek Behun wrote:
> >
> > On Wed, 10 Mar 2021 11:40:42 +0800
> > Bin Meng wrote:
> >
> > > On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote:
> > > >
On Fri, 12 Mar 2021 15:19:26 +0800
Bin Meng wrote:
> On Fri, Mar 12, 2021 at 3:11 PM Marek Behun wrote:
> >
> > On Fri, 12 Mar 2021 14:48:04 +0800
> > Bin Meng wrote:
> >
> > > On Fri, Mar 12, 2021 at 2:45 PM Marek Behun wrote:
> > >
I created a gcc bug for this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99559
On Fri, 12 Mar 2021 08:18:44 -0500
Tom Rini wrote:
> On Fri, Mar 12, 2021 at 08:29:05AM +0100, Marek Behun wrote:
> > On Fri, 12 Mar 2021 15:19:26 +0800
> > Bin Meng wrote:
> >
> > > On Fri, Mar 12, 2021 at 3:11 PM Marek Behun wrote:
> > > >
On Fri, 12 Mar 2021 15:21:05 +0100
Harald Seiler wrote:
> Hi Marek,
>
> On Fri, 2021-03-12 at 11:33 +0100, Marek Behún wrote:
> > Hello,
> >
> > I am sending version 2 of patches adding support for LTO to U-Boot.
> >
> > This series was tested by Github/Azure CI at
> > https://github.com/u-b
On Fri, 12 Mar 2021 16:11:13 +0100
Harald Seiler wrote:
> On Fri, 2021-03-12 at 16:07 +0100, Harald Seiler wrote:
> > On Fri, 2021-03-12 at 15:26 +0100, Marek Behun wrote:
> > > On Fri, 12 Mar 2021 15:21:05 +0100
> > > Harald Seiler wrote:
> > >
>
On Fri, 12 Mar 2021 08:34:41 -0800
Tim Harvey wrote:
> On Fri, Mar 12, 2021 at 5:47 AM Marek Behún wrote:
> >
> > Enable LTO for some boards that were tested by people on U-Boot Mailing
> > List.
> >
> > Signed-off-by: Marek Behún
> > Tested-by: Adam Ford
> > Tested-by: Pali Rohár
> > Tested-
On Fri, 12 Mar 2021 18:19:08 +0100
Heinrich Schuchardt wrote:
> On 12.03.21 18:03, Marek Behun wrote:
> > On Fri, 12 Mar 2021 08:34:41 -0800
> > Tim Harvey wrote:
> >
> >> On Fri, Mar 12, 2021 at 5:47 AM Marek Behún wrote:
> >>>
> >>>
On Sat, 13 Mar 2021 09:23:05 -0600
Adam Ford wrote:
> I have tested this on omap35_logic_somlv and the LTO flag removal
> isn't necessary for the clock.o
> Having the clock built with LTO saves 239 bytes in SPL with my
> compiler. It's not a huge savings, but in SPL, we need as much as
> possibl
On Fri, 12 Mar 2021 15:47:12 -0500
Tom Rini wrote:
> On Fri, Mar 12, 2021 at 06:36:05PM +0100, Marek Behun wrote:
> > On Fri, 12 Mar 2021 18:19:08 +0100
> > Heinrich Schuchardt wrote:
> >
> > > On 12.03.21 18:03, Marek Behun wrote:
> > > > On F
On Fri, 12 Mar 2021 17:42:35 +0100
Heinrich Schuchardt wrote:
> On 12.03.21 11:34, Marek Behún wrote:
> > When linking with LTO, the compiler complains about type mismatch of
> > variables `__efi_runtime_start`, `__efi_runtime_stop`,
> > `__efi_runtime_rel_start` and `__efi_runtime_rel_stop`:
> >
On Fri, 12 Mar 2021 10:01:34 -0800
Tim Harvey wrote:
> Marek / Heinrich,
>
> Yes, 'make -j1' does work.
>
> Tim
Tim, could you try make -j8, but change the toplevel Makefile:
find string "-flto=jobserver" and change it to "-flto".
Does make -j8 fail then?
Thank you.
Marek
On Mon, 15 Mar 2021 21:12:32 -0400
Tom Rini wrote:
> On Mon, Mar 15, 2021 at 10:42:31AM +0100, Marek Behun wrote:
> > On Fri, 12 Mar 2021 15:47:12 -0500
> > Tom Rini wrote:
> >
> > > On Fri, Mar 12, 2021 at 06:36:05PM +0100, Marek Behun wrote:
> > &g
On Tue, 16 Mar 2021 19:28:46 +0530
Pratyush Yadav wrote:
> On 16/03/21 01:25PM, Marek Behún wrote:
> > There is a serious bug in regmap_read() and regmap_write() functions
> > where an uint pointer is cast to (void *) which is then cast to (u8 *),
> > (u16 *), (u32 *) or (u64 *), depending on reg
Simon, Heiko, Bin,
Pratyush discovered that the solution implemented by the patch
regmap: fix a serious pointer casting bug
is wrong. The cpu_to_le32() / le32_to_cpu() shifts data to the correct
position, but on big endian machines it also reverses byte order.
Somehow this went right through my
On Tue, 16 Mar 2021 20:59:55 +0530
Pratyush Yadav wrote:
> On 16/03/21 03:15PM, Marek Behun wrote:
> > On Tue, 16 Mar 2021 19:28:46 +0530
> > Pratyush Yadav wrote:
> >
> > > On 16/03/21 01:25PM, Marek Behún wrote:
> > > > There is a serious bug in
On Tue, 16 Mar 2021 22:04:17 +0530
Pratyush Yadav wrote:
> > + switch (map->width) {
> > + case REGMAP_SIZE_8:
> > + *valp = u.v8;
> > + break;
> > + case REGMAP_SIZE_16:
> > + *valp = u.v16;
> > + break;
> > + case REGMAP_SIZE_32:
> > + *
On Wed, 24 Mar 2021 10:20:05 +0100
Stefan Roese wrote:
> PHY_INTERFACE_MODE_SGMII_2500
What the hell is this mode???
AFAIK something like this does not actually exist.
On Wed, 24 Mar 2021 09:55:04 +
Kostya Porotchkin wrote:
> Hi, Marek,
>
> > -Original Message-
> > From: Marek Behun
> > Sent: Wednesday, March 24, 2021 12:44
> > To: Stefan Roese
> > Cc: u-boot@lists.denx.de; Kostya Porotchkin ; Stefan
> >
On Wed, 24 Mar 2021 13:09:00 +
Stefan Chulski wrote:
> > > >
> > > > SGMII uses the same coding as 1000base-x, but the latter works only
> > > > with one speed (1000mbps), while the former can also work in 10mbps
> > > > and 100mbps (by repeating each byte 100 or 10 times, respectively).
> >
Please be also aware the we have the following patch U-Boot
commit 545591132aa701ff1262bb309fbcd0c3ff0acd75
Author: Marek Behún
Date: Wed Aug 19 11:57:25 2020 +0200
arm64: dts: armada-3720-espressobin: fix COMPHY nodes
This commit fixes initialization of COMPHY on EspressoBin.
On Wed, 24 Mar 2021 15:06:34 +0100
Stefan Roese wrote:
> From: Igal Liberman
>
> This patch adds support for running RX training using new command called
> "rx_training"
> Usage:
> rx_training - rx_training
>
> RX training allows to improve link quality (for SFI mode)
> by running training s
On Wed, 24 Mar 2021 16:36:10 +
Stefan Chulski wrote:
> > > > > > SGMII uses the same coding as 1000base-x, but the latter works
> > > > > > only with one speed (1000mbps), while the former can also work
> > > > > > in 10mbps and 100mbps (by repeating each byte 100 or 10 times,
> > respectiv
On Thu, 25 Mar 2021 13:38:13 +1300
Simon Glass wrote:
> Hi Marek,
>
> On Wed, 17 Mar 2021 at 04:19, Marek Behun wrote:
> >
> > Simon, Heiko, Bin,
> >
> > Pratyush discovered that the solution implemented by the patch
> > regmap: fix a serious pointer ca
On Thu, 25 Mar 2021 15:41:55 +1300
Simon Glass wrote:
> eHi Marek,
>
> On Thu, 25 Mar 2021 at 13:46, Marek Behun wrote:
> >
> > On Thu, 25 Mar 2021 13:38:13 +1300
> > Simon Glass wrote:
> >
> > > Hi Marek,
> > >
> > > On Wed, 17 Ma
On Thu, 8 Apr 2021 10:24:22 +0200
Stefan Roese wrote:
> Hi Stefan,
> Hi Marek,
>
> On 25.03.21 13:59, Stefan Chulski wrote:
> >> Could you please ask internally at Marvell?
> >> We are trying to get to the bottom of this because we are stuck in
> >> development of code for Amethyst. We need to g
On Thu, 8 Apr 2021 19:18:09 +
Stefan Chulski wrote:
> >
> > Stefan, you suggest to drop this define from PHY_INTERFACE enum which we
> > can't easily do with other drivers (like NXP) also referencing this macro.
> >
> > How to continue then?
> >
> > Thanks,
> > Stefan
>
> Probably we sh
On Tue, 24 Mar 2020 19:03:30 +0800
Qu Wenruo wrote:
> Sorry for the delayed reply. (Stupid filter setup).
>
> Currently most Uboot boards should use the same page size setup for its
> kernel, and most btrfs uses 4K sector size.
>
> So for Uboot it should be no problem.
>
> Although the best pr
On Thu, 19 Mar 2020 20:33:19 +0800
Qu Wenruo wrote:
> [BUG]
The subject line should not contain uboot keyword. If you check git log
for fs/btrfs, the commits always start with:
fs: btrfs:
Also please don't use [BUG] [CAUSE] and [FIX] in commit messages.
You could have also added myself to CC
On Wed, 25 Mar 2020 16:27:16 +0800
Qu Wenruo wrote:
> On 2020/3/25 下午4:09, Marek Behun wrote:
> > On Thu, 19 Mar 2020 20:33:19 +0800
> > Qu Wenruo wrote:
> >
> >> [BUG]
> >
> > The subject line should not contain uboot keyword. If you check gi
On Wed, 25 Mar 2020 12:00:20 +0100
Marek Behun wrote:
> I also did not collaborate with Linux btrfs authors when writing this
> driver. These are the reasons why I don't see much point in adding
> linux-btrfs mailing list to Cc, since they may have never seen the
> codebase.
n general in mainline U-Boot. Though I
> have to admit, that I didn't test any of those ports recently. I
> added Marek Behun to Cc, as he did submit most of the Turris Mox
> stuff and has more recent experience than I do.
>
> > Because that https://github.com/MarvellEmbedde
On Wed, 25 Mar 2020 18:48:50 +0100
Marek Behun wrote:
> One thing that may need reworking (to become compatible with Linux) is
> the comphy driver. Linux' comphy driver for this SOC uses smccc calls
> to ARM Trusted Firmware, but U-Boot does not, and instead initializes
> SE
On Thu, 26 Mar 2020 13:35:54 +0800
Qu Wenruo wrote:
> Just a cleanup. These immediate numbers make my eyes hurt.
>
> Signed-off-by: Qu Wenruo
> Cc: Marek Behun
> ---
> fs/btrfs/compression.c | 22 --
> 1 file changed, 12 insertions(+), 10 deletions(-)
ctor size
> support.
>
> Signed-off-by: Qu Wenruo
> Cc: Marek Behun
> ---
> fs/btrfs/super.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/fs/btrfs/super.c b/fs/btrfs/super.c
> index 2dc4a6fcd7a3..b693a073fc0b 100644
> --- a/fs/btrfs/super.c
>
do proper page
> boundary skip to fix it.
>
> Please note that, current code base doesn't parse fs_info thus we can't
> grab sector size easily, so it uses PAGE_SIZE, and relying on fs open
> time check to exclude unsupported sector size.
>
> Signed-off-by: Qu
Sorry, dont apply this. I've sent v2.
Marek
On Thu, 2 Apr 2020 14:18:24 +0200
Stefan Roese wrote:
> Hi Moritz,
>
> On 02.04.20 13:30, Moritz Berghof wrote:
> > it's really great that you answered so fast and helpfully, thank you!
> >
> > It's great you want get the board ported to mainline. Me too.
> >
> >
> > I build the U-boot mainli
Hi Moritz,
which version of EspressoBin do you have? How much RAM, is it DDR3 or
DDR4? How many RAM chips are there?
Marek
On Tue, 18 May 2021 00:39:39 +0200
Marek Vasut wrote:
> The superblock buffer must be cache aligned, since it might be used
> in DMA context, allocate it using ALLOC_CACHE_ALIGN_BUFFER() just
> like it was done in btrfs_read_superblock() and read_tree_node().
>
> This fixes this output on boot a
> I don't see a changelog here but this is v4. Are you using patman?
Changelog is in cover letter. Unfortunately I am not using patman yet.
Marek
On Mon, 24 May 2021 11:40:53 -0400
Tom Rini wrote:
> On Fri, May 21, 2021 at 12:56:41PM -0400, Tom Rini wrote:
> > On Fri, May 21, 2021 at 06:00:31PM +0200, Marek Behún wrote:
> > > On Fri, 21 May 2021 10:11:47 -0400
> > > Tom Rini wrote:
> > >
> > > > On Thu, May 20, 2021 at 01:56:29PM -05
On Mon, 24 May 2021 13:44:38 -0400
Tom Rini wrote:
> On Mon, May 24, 2021 at 01:09:19PM -0400, Tom Rini wrote:
> > On Mon, May 24, 2021 at 05:58:55PM +0200, Marek Behun wrote:
> > > On Mon, 24 May 2021 11:40:53 -0400
> > > Tom Rini wrote:
> > >
> &
Tom, Simon,
now that LTO is merged I am working on
Support SPI NORs and OF partitions in `mtd list`
but CI fails for some boards, see
https://github.com/u-boot/u-boot/pull/55
The reason is that there are still several boards which do not use
CONFIG_DM.
On the previous version Simon commented
On Wed, 26 May 2021 01:27:56 +0200
Marek Behun wrote:
> Tom, Simon,
>
> now that LTO is merged I am working on
> Support SPI NORs and OF partitions in `mtd list`
>
> but CI fails for some boards, see
> https://github.com/u-boot/u-boot/pull/55
>
> The reason is t
On Thu, 10 Jun 2021 16:07:05 +0200
Pali Rohár wrote:
> On Thursday 10 June 2021 07:12:53 Stefan Roese wrote:
> > Hi Pali,
> >
> > On 08.06.21 11:51, Pali Rohár wrote:
> > > On Monday 07 June 2021 16:34:50 Marek Behún wrote:
> > > > Add nodes for SPI NOR partitions to the device tree of Turri
Hi Stefan,
Pali discovered this issue with the bootcmd_rescue code for Omnia & MOX.
The patch is a therefore a fix. Is is still possible to send this for
v2021.07 ? Sorry for the inconvenience.
Marek
Hello,
this is announcement of mox-imager [1], a firmware uploader / manipulator
for Marvell's Armada 3720 SOC.
For most of you who use the SOC on boards other than Turris MOX, the
most useful feature probably is that it can upload a firmware via UART
at higher baudrates than Marvell's original W
On Tue, 29 Jun 2021 09:41:25 +
"Roland Gaudig (OSS)" wrote:
> I think just passing the format string directly to sprintf should be
> avoided because it is unsafe. For example
>
> => setexpr foo fmt %s 0x
>
> would surely lead to access on memory location outside the variable
> whe
Dear Tom, Sean, Wolfgang and others,
here are some of my opinions for this discussion
- I agree with Wolfgang that there are far better options than
a Tcl-like shell, if we want to add another language
- I also think that instead of adding another language, it is more
preferable to improve t
On Wed, 27 Jan 2021 14:47:58 +0100
David Sterba wrote:
> If it's a series then please mention u-boot in the cover letter, no need
> to change the patches, I'll go check CC if I'm too confused about the
> patch.
I would suggest using subject prefix [PATCH u-boot]
On Wed, 3 Feb 2021 08:32:45 +0900
Jaehoon Chung wrote:
> On 2/3/21 2:37 AM, Marek Behún wrote:
> > This is needed to parse more capabilities such as `non-removable`.
> >
> > Commit da18c62b6e6a ("mmc: sdhci: Implement SDHCI card detect") caused
> > a regression on Turris Omnia, because mv_sdhci
On Mon, 25 Jan 2021 15:25:31 +0100
Stefan Roese wrote:
> This patch changes the PCI config routines in the Armada XP / 38x driver
> to not allow access to the PCIe root ports.
>
> While updating the Armada XP based theadorable to the latest mainline
> and testing it with the DM PCI driver I noti
Maybe we should ask kernel people. It seems that Thomas Petazzoni may
be able to answer, since he is author of the following kernel patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4ac99011e542d06ea2bda10063502583c6d7991
On Mon, 8 Feb 2021 17:24:16 +0100
Stefan Roese wrote:
> Hi Marek,
>
> On 08.02.21 17:04, Marek Behún wrote:
> > This syncs drivers/ddr/marvell/a38x/ with the mv-ddr-devel branch
> > of https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell.git.
> > Specifically this syncs with commit fae3f6
btw tested on Turris Omnia
This patch is needed on some Turris Omnia boards with Samsung DDR chips,
otherwise DDR training fails in ~60% of cases.
Marvell send us this patch for testing, I have updated it a little.
Please test this on other A38x boards.
If it doesn't break anything on other boards, we can apply it and sen
On Mon, 8 Feb 2021 20:11:06 +
Chris Packham wrote:
> Hi Marek,
>
> Do you have this in a repo I can pull from? I've got a couple of boards
> I can give this a spin on.
https://gitlab.nic.cz/turris/turris-omnia-uboot/
branch v2021.04-rc-mv-ddr-14.0.0
also please test branch v2021.04-rc-mv-
On Mon, 8 Feb 2021 20:14:26 +
Chris Packham wrote:
> On 9/02/21 8:15 am, Marek Behun wrote:
> > This patch is needed on some Turris Omnia boards with Samsung DDR chips,
> > otherwise DDR training fails in ~60% of cases.
> >
> > Marvell send us this patch for t
Reviewed-by: Marek Behún
Reviewed-by: Marek Behún
Reviewed-by: Marek Behún
Reviewed-by: Marek Behún
Stefan,
these patches should probably have a different From: - i.e. the
original authors should be preserved (from the first Signed-off-by
tags), for example:
motib
Baruch Siach
heaterC
But some of these are not full names, so I don't know whether I should
resend this or not.
What do y
On Tue, 9 Feb 2021 01:08:54 +
Chris Packham wrote:
> On 9/02/21 1:16 pm, Chris Packham wrote:
> > On 9/02/21 9:18 am, Marek Behun wrote:
> >> On Mon, 8 Feb 2021 20:11:06 +
> >> Chris Packham wrote:
> >>
> >>> Hi Marek,
> >>>
On Tue, 9 Feb 2021 06:50:35 +
Chris Packham wrote:
> On 9/02/21 3:07 pm, Marek Behun wrote:
> > On Tue, 9 Feb 2021 01:08:54 +
> > Chris Packham wrote:
> >
> >> On 9/02/21 1:16 pm, Chris Packham wrote:
> >>> On 9/02/21 9:18 am, Marek Behun w
On Tue, 9 Feb 2021 06:50:35 +
Chris Packham wrote:
> On 9/02/21 3:07 pm, Marek Behun wrote:
> > On Tue, 9 Feb 2021 01:08:54 +
> > Chris Packham wrote:
> >
> >> On 9/02/21 1:16 pm, Chris Packham wrote:
> >>> On 9/02/21 9:18 am, Marek Behun w
On Wed, 10 Feb 2021 08:09:14 +0800
Qu Wenruo wrote:
> On 2021/2/10 上午1:33, Marek Behún wrote:
> > When the btrfs_read_fs_root() function is searching a ROOT_ITEM with
> > location key offset other than -1, it currently fails via BUG_ON.
> >
> > The offset can have other value than -1, though. Thi
On Wed, 10 Feb 2021 14:48:23 +0100
Patrice CHOTARD wrote:
> +Patrick
>
> Hi All
>
> I have tested this series on stm32mp1-ev1 board which embeds 1 nand and 2
> identical spi-nor.
> spi-nor DT node is the following:
>
> &qspi {
> pinctrl-names = "default", "sleep";
> pinctrl-0 = <
On Wed, 10 Feb 2021 15:31:56 +0100
Patrice CHOTARD wrote:
> > So one solution is to use device-tree name to select the NOR, but still
> > print the name determined from SPI ID somewhere.
> >
> > Second solution is to allow selecting the SPI by number, i.e. (the n-th
> > enumerated SPI).
>
> a
On Wed, 10 Feb 2021 15:31:56 +0100
Patrice CHOTARD wrote:
> and what about @ as shown in my previous email
> ?
And there is a second problem with this: this can be bad for automatic
U-Boot scripts.
For example on Turris Omnia there are boards which were manufactured
with a Macronix SPI-NOR, an
On Wed, 10 Feb 2021 09:20:11 +0800
Qu Wenruo wrote:
> You're correct, the kernel is using new schema, btrfs_get_fs_root(),
> which only requires root objectid and completely get rid of the
> offset/type, which is far less possible to call with wrong parameters.
>
> It would be a good timing to
On Sun, 11 Jul 2021 09:46:19 +0900
Masami Hiramatsu wrote:
> Add partition information to the spi-nor flash.
> This is required for accessing NOR flash via mtdparts.
>
> Signed-off-by: Masami Hiramatsu
> ---
> Changes in v2:
> - Add new lines to separate the partitions.
> ---
> .../dts/synq
Tom,
there are 16 boards left with CONFIG_SPI_FLASH
(git grep CONFIG_SPI_FLASH=y)
and Makefile says this was supposed to be deprecated in v2019.07.
Are we going to remove them so that we can simplify the SPI subsystem?
Marek
On Mon, 12 Jul 2021 16:01:13 +0200
Marek Behun wrote:
> Tom,
>
> there are 16 boards left with CONFIG_SPI_FLASH
> (git grep CONFIG_SPI_FLASH=y)
> and Makefile says this was supposed to be deprecated in v2019.07.
>
> Are we going to remove them so that we can simpl
On Mon, 12 Jul 2021 10:10:14 -0400
Tom Rini wrote:
> On Mon, Jul 12, 2021 at 04:01:13PM +0200, Marek Behun wrote:
>
> > Tom,
> >
> > there are 16 boards left with CONFIG_SPI_FLASH
> > (git grep CONFIG_SPI_FLASH=y)
> > and Makefile says this was s
On Wed, 21 Jul 2021 09:56:07 +0200
Patrick Delaunay wrote:
> With LTO activated, the buildman tools failed with an error on my
> configuration (Ubuntu 20.04, stm32mp15_trusted_defconfig) with the error:
>
> ../arm-linux-gnueabi/bin/nm:
> scripts/gen_ll_addressable_symbols.sh: file format n
On Wed, 21 Jul 2021 21:46:56 +0530
Jagan Teki wrote:
> Hi Marek,
>
> On Thu, Jul 15, 2021 at 5:21 AM Marek Behún wrote:
> >
> > Hello,
> >
> > I accidentally forgot to send this series to U-Boot's mailing list last
> > time, meaning it did not end up in patchwork, so now I am resending it.
> >
Hi Jagan,
On Wed, 21 Jul 2021 21:46:56 +0530
Jagan Teki wrote:
> Found the build error with CI [1], would you please check?
>
> [1] https://source.denx.de/u-boot/custodians/u-boot-spi/-/pipelines/8345
>
> Jagan.
OK I think I've found out what is the problem. I've pushed new version
into githu
On Mon, 26 Jul 2021 14:58:59 +0200
Pali Rohár wrote:
> Static inline function _debug_uart_init() should avoid calling external
> (non-inline) functions.
Why?
On Mon, 26 Jul 2021 14:58:58 +0200
Pali Rohár wrote:
> CONFIG_BAUDRATE should be used for setting the baudrate for the early debug
> UART. This replaces current hardcoded 115200 value.
>
> Signed-off-by: Pali Rohár
Reviewed-by: Marek Behun
On Mon, 26 Jul 2021 16:58:04 +0200
Pali Rohár wrote:
> On Monday 26 July 2021 16:55:22 Marek Behun wrote:
> > On Mon, 26 Jul 2021 14:58:59 +0200
> > Pali Rohár wrote:
> >
> > > Static inline function _debug_uart_init() should avoid calling externa
Hi Stefan,
Chris put his Tested-by on this series and noone else replyied to it.
What do you think about this?
The only thing that may be problematic is that this series does not
preserve original commit authors (the ones who authored these commitsin
mv-ddr) in the From header, only in the first
On Mon, 22 Feb 2021 16:01:10 +0100
Petr Štetiar wrote:
> Currently it's not possible to write anything into eMMC from U-Boot, so
> fix this by disabling the default write protection.
>
> Cc: Marek Behún
> Signed-off-by: Petr Štetiar
> ---
> arch/arm/dts/armada-385-turris-omnia.dts | 1 +
> 1
On Mon, 22 Feb 2021 17:03:22 +0100
Marek Behun wrote:
> On Mon, 22 Feb 2021 16:01:10 +0100
> Petr Štetiar wrote:
> > --- a/arch/arm/dts/armada-385-turris-omnia.dts
> > +++ b/arch/arm/dts/armada-385-turris-omnia.dts
> > @@ -85,6 +85,7 @@
> >
1 - 100 of 227 matches
Mail list logo
