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
Reviewed-by: Marek Behún
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
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 14:58:59 +0200
Pali Rohár wrote:
> Static inline function _debug_uart_init() should avoid calling external
> (non-inline) functions.
Why?
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 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.
> >
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 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 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
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 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
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 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
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
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
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
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
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 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:
> > >
> &
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
> 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 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
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 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 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 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 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 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 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, 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, 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 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 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
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 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).
> >
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 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 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 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
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 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
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 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 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 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 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 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 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 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 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 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:
> > > >
I created a gcc bug for this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99559
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:
> > >
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 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 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 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 21:00:00 +0800
Bin Meng wrote:
>
> --start-group is useless now.
>
> > $(u-boot-main)
> > \
> > - --end-group
> > \
> > + --no-wh
800
> > > Bin Meng wrote:
> > >
> > > > Hi Marek,
> > > >
> > > > On Mon, Mar 8, 2021 at 9:24 PM Marek Behún wrote:
> > > > >
> > > > > On Mon, 8 Mar 2021 19:32:10 +0800
> > > > > Bin Meng wrote:
On Mon, 8 Mar 2021 19:32:10 +0800
Bin Meng wrote:
> On Mon, Mar 8, 2021 at 7:18 PM Marek Behun wrote:
> >
> > On Mon, 8 Mar 2021 18:44:58 +0800
> > Bin Meng wrote:
> >
> > > Could you investigate why?
> >
> > I could, but I don't unde
On Mon, 8 Mar 2021 11:55:32 +0100
Pali Rohár wrote:
> On Monday 08 March 2021 18:40:58 Bin Meng wrote:
> > On Mon, Mar 8, 2021 at 6:23 PM Pali Rohár wrote:
> > >
> > > On Monday 08 March 2021 11:19:33 Marek Behun wrote:
> > > > On Mon, 8 Mar 2021
On Mon, 8 Mar 2021 11:55:32 +0100
Pali Rohár wrote:
> On Monday 08 March 2021 18:40:58 Bin Meng wrote:
> > On Mon, Mar 8, 2021 at 6:23 PM Pali Rohár wrote:
> > >
> > > On Monday 08 March 2021 11:19:33 Marek Behun wrote:
> > > > On Mon, 8 Mar 2021
On Mon, 8 Mar 2021 18:44:58 +0800
Bin Meng wrote:
> Could you investigate why?
I could, but I don't understand why exactly I should
- Linux is also using --whole-archive
- it is working
- I have other things I would like to work on
Maybe you could look into this? :)
Marek
On Mon, 8 Mar 2021 18:31:26 +0800
Bin Meng wrote:
> On Mon, Mar 8, 2021 at 5:26 PM Marek Behun wrote:
> >
> > On Mon, 8 Mar 2021 15:47:38 +0800
> > Bin Meng wrote:
> >
> > > Hi Marek,
> > >
> > > On Sun, Mar 7, 2021 at 12:59 PM Marek
On Mon, 8 Mar 2021 18:29:29 +0800
Bin Meng wrote:
> On Mon, Mar 8, 2021 at 5:23 PM Marek Behun wrote:
> >
> > On Mon, 8 Mar 2021 15:27:41 +0800
> > Bin Meng wrote:
> >
> > > > #define __ADDRESSABLE(sym) \
> > > > sta
On Mon, 8 Mar 2021 15:56:01 +0800
Bin Meng wrote:
> Hi Marek,
>
> On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote:
> >
> > It seems that sometimes (happening on ARM64, for example with
> > turris_mox_defconfig) GCC, when linking with LTO, changes the symbol
> > names of some functions, for ex
On Mon, 8 Mar 2021 17:16:03 +0800
Bin Meng wrote:
> Hi Marek,
>
> On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote:
> >
> > Currently we use incremental linking (ld -r) to link several object
> > files from one directory into one built-in.o object file containing the
> > linked code from that
On Mon, 8 Mar 2021 15:47:38 +0800
Bin Meng wrote:
> Hi Marek,
>
> On Sun, Mar 7, 2021 at 12:59 PM Marek Behun wrote:
> >
> > I forgot to drop this patch. It is not needed, please ignore it.
> >
>
> Why is this not needed anymore?
It was not needed at a
On Mon, 8 Mar 2021 15:27:41 +0800
Bin Meng wrote:
> > #define __ADDRESSABLE(sym) \
> > static void * __section(".discard.addressable") __used \
> > - __PASTE(__addressable_##sym, __LINE__) = (void *)&sym;
> > + __UNIQUE_ID(__PASTE(__addressable_,sym)) = (void
On Mon, 8 Mar 2021 15:09:51 +0800
Bin Meng wrote:
> Hi Marek,
>
> On Sun, Mar 7, 2021 at 12:26 PM Marek Behún wrote:
> >
> > The api_public.h header file undefined macro CONFIG_SYS_64BIT_LBA.
> >
> > But api/api_storage.c includes this header before including part.h,
> > causing the type of lba
On Mon, 8 Mar 2021 07:58:30 +0100
Stefan Roese wrote:
> Hi Marek,
>
> On 08.03.21 07:46, Marek Behun wrote:
> > And BTW do you have time to test this series on some ARM boards?
>
> I can test this on the theadorable Armada XP board, which also uses
> SPL. Do you have
And BTW do you have time to test this series on some ARM boards?
> Reviewed-by: Stefan Roese
Thanks, Stefan.
Do you want to merge this into your repo u-boot-marvell, or shall Tom
merge this once this series is mature?
Marek
On Sun, 7 Mar 2021 14:04:35 +0100
Marek Behun wrote:
> Hmm, maybe this should be split into 2 commits.
I have divided this into 2 commits and pushed into my github branch
On Sun, 7 Mar 2021 10:14:07 -0600
Adam Ford wrote:
> On Sat, Mar 6, 2021 at 10:26 PM Marek Behún wrote:
> >
> > Enable LTO for some boards that were tested by people on U-Boot Mailing
> > List.
> >
>
> I have also confirmed this works on the r8a774a1_beacon board as well
> and boots without i
Hmm, maybe this should be split into 2 commits.
On Sun, 7 Mar 2021 13:31:11 +0100
Pali Rohár wrote:
> On Sunday 07 March 2021 13:26:36 Marek Behun wrote:
> > On Sun, 7 Mar 2021 06:02:16 +0100
> > Marek Vasut wrote:
> >
> > > On 3/7/21 5:58 AM, Marek Behun wrote:
> > > > On Sun, 7 Mar 2021
On Sun, 7 Mar 2021 06:02:16 +0100
Marek Vasut wrote:
> On 3/7/21 5:58 AM, Marek Behun wrote:
> > On Sun, 7 Mar 2021 05:46:24 +0100
> > Marek Vasut wrote:
> >
> >> On 3/7/21 5:25 AM, Marek Behún wrote:
> >>> When compiling with LTO, th
THX
I forgot to drop this patch. It is not needed, please ignore it.
Marek
On Sun, 7 Mar 2021 05:46:24 +0100
Marek Vasut wrote:
> On 3/7/21 5:25 AM, Marek Behún wrote:
> > When compiling with LTO, the compiler fails with an error saying that
> > `crc_table` causes a section type conflict with `efi_var_buf`.
> >
> > This is because both are declared to be in the same se
On Sun, 7 Mar 2021 05:47:56 +0100
Marek Vasut wrote:
> On 3/7/21 5:25 AM, Marek Behún wrote:
> > This is how Linux does this now, see Linux commit 339f29d91acf.
> >
> > Signed-off-by: Marek Behún
> > ---
> > scripts/checkpatch.pl | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
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 Sat, 6 Mar 2021 22:38:52 +0100
> > Pali Rohár wrote:
> >
> > > On Saturday 06 March 2021 22:19:22 Marek Behun wrote:
> > > >
On Fri, 5 Mar 2021 18:21:51 +0100
Heinrich Schuchardt wrote:
> On 05.03.21 16:37, Marek Behun wrote:
> > On Fri, 5 Mar 2021 11:00:45 +0800
> > Bin Meng wrote:
> >
> >> On Wed, Mar 3, 2021 at 12:13 PM Marek Behún wrote:
> >>>
> >>> When
On Sat, 6 Mar 2021 21:11:34 -0500
Tom Rini wrote:
> On Sun, Mar 07, 2021 at 02:27:33AM +0100, Marek Behun wrote:
>
> > Hello Tom,
> >
> > I seem to run into an error on Azure's CI for U-Boot that I cannot
> > reproduce locally.
> >
> > It concer
[sorry for the spam, I accidentally sent this e-mail from my personal
address]
Hello Tim,
you are listed as maintainer of i.MX8MM Venice board in U-Boot.
I am currently working on LTO support for U-Boot, and I have
encountered a problem with i.MX8MM Venice board:
when LTO is enabled, the linking
Hello Tom,
I seem to run into an error on Azure's CI for U-Boot that I cannot
reproduce locally.
It concerns my LTO work https://github.com/u-boot/u-boot/pull/57
The test
u-boot.u-boot (test.py xilinx_zynq_virt)
is failing with this log
https://dev.azure.com/u-boot/a1096300-2999-4ec4-a21a-4c22
Hello Tim,
you are listed as maintainer of i.MX8MM Venice board in U-Boot.
I am currently working on LTO support for U-Boot, and I have
encountered a problem with i.MX8MM Venice board:
when LTO is enabled, the linking process for SPL does not throw away
relocation information, making the resultin
On Sat, 6 Mar 2021 22:38:52 +0100
Pali Rohár wrote:
> On Saturday 06 March 2021 22:19:22 Marek Behun wrote:
> > On Sat, 6 Mar 2021 22:00:45 +0100
> > Pali Rohár wrote:
> >
> > > On Saturday 06 March 2021 21:54:00 Marek Behun wrote:
> > > > On S
On Fri, 5 Mar 2021 08:37:28 -0500
Tom Rini wrote:
> On Fri, Mar 05, 2021 at 09:34:42PM +0800, Bin Meng wrote:
> > Hi Marek,
> >
> > On Fri, Mar 5, 2021 at 2:17 AM Marek Behun wrote:
> > >
> > > On Thu, 4 Mar 2021 18:57:11 +0800
> >
On Sat, 6 Mar 2021 22:00:45 +0100
Pali Rohár wrote:
> On Saturday 06 March 2021 21:54:00 Marek Behun wrote:
> > On Sat, 6 Mar 2021 21:41:14 +0100
> > Pali Rohár wrote:
> >
> > > On Saturday 06 March 2021 15:08:13 Tom Rini wrote:
> > > > Perhaps we&
On Sat, 6 Mar 2021 21:41:14 +0100
Pali Rohár wrote:
> On Saturday 06 March 2021 15:08:13 Tom Rini wrote:
> > Perhaps we'll default to yes on some SoCs. The omap3 thing is a bit
> > odd, but we'll see what happens on real N900 hardware.
>
> Hello!
>
> Could you send me a link to git repo / br
; > On 05.03.21 12:25, Adam Ford wrote:
> > > > > On Thu, Mar 4, 2021 at 4:33 PM Marek Behun
> > > > > wrote:
> > > > >>
> > > > >> On Thu, 4 Mar 2021 16:18:03 -0600
> > > > >> Adam Ford wrote:
> >
On Fri, 5 Mar 2021 09:58:34 -0700
Simon Glass wrote:
> Hi Marek,
>
> On Fri, 5 Mar 2021 at 09:50, Marek Behun wrote:
> >
> > On Fri, 5 Mar 2021 09:39:53 -0700
> > Simon Glass wrote:
> >
> > > Hi Marek,
> > >
> > > On Fri, 5 Mar 20
On Fri, 5 Mar 2021 09:39:53 -0700
Simon Glass wrote:
> Hi Marek,
>
> On Fri, 5 Mar 2021 at 08:37, Marek Behun wrote:
> >
> > On Fri, 5 Mar 2021 11:00:45 +0800
> > Bin Meng wrote:
> >
> > > On Wed, Mar 3, 2021 at 12:13 PM Marek Behún wrote:
&
On Fri, 5 Mar 2021 11:04:08 +0800
Bin Meng wrote:
> On Wed, Mar 3, 2021 at 12:13 PM Marek Behún wrote:
> >
> > Use the `__visible` macro to declare entires and lists declared by
> > ll_entry_declare() and ll_entry_declare_list() externally visible, so
> > that when building with LTO the compiler
On Fri, 5 Mar 2021 21:34:42 +0800
Bin Meng wrote:
> Hi Marek,
>
> On Fri, Mar 5, 2021 at 2:17 AM Marek Behun wrote:
> >
> > On Thu, 4 Mar 2021 18:57:11 +0800
> > Bin Meng wrote:
> >
> > > Hi Marek,
> > >
> > > On Wed, Mar 3, 2021
On Fri, 5 Mar 2021 11:00:45 +0800
Bin Meng wrote:
> On Wed, Mar 3, 2021 at 12:13 PM Marek Behún wrote:
> >
> > When building with LTO, the system libc's `errno` variable used in
> > arch/sandbox/cpu/os.c conflicts with U-Boot's `errno` (defined in
> > lib/errno.c) with the following error:
> >
1 - 100 of 227 matches
Mail list logo
