* [U-Boot] [PATCH v4 0/2] spl: full-featured heap cleanups @ 2019-04-01 20:01 Simon Goldschmidt 2019-04-01 20:01 ` [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram Simon Goldschmidt 2019-04-01 20:01 ` [U-Boot] [PATCH v4 2/2] dlmalloc: be compatible to tiny printf Simon Goldschmidt 0 siblings, 2 replies; 18+ messages in thread From: Simon Goldschmidt @ 2019-04-01 20:01 UTC (permalink / raw) To: u-boot Since clearing BSS before board_init_r is clearly not accepted, let's just fix 2 bugs in dlmalloc and I'll handle the socfpga_a10 cleanup in a different way (see discussions in v1 to v3 of this series...). Changes in v4: - dumped clearing BSS before SPL board_init_f, only real bugfixes remain Changes in v3: - fixed summary ("stack" -> "heap") - enable CONFIG_SPL_CLEAR_BSS_F for socfpga_arria10 using full malloc early in SPL - rebased Simon Goldschmidt (2): dlmalloc: fix malloc range at end of ram dlmalloc: be compatible to tiny printf common/dlmalloc.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) -- 2.17.1 ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-01 20:01 [U-Boot] [PATCH v4 0/2] spl: full-featured heap cleanups Simon Goldschmidt @ 2019-04-01 20:01 ` Simon Goldschmidt 2019-04-24 3:54 ` Simon Glass 2019-04-01 20:01 ` [U-Boot] [PATCH v4 2/2] dlmalloc: be compatible to tiny printf Simon Goldschmidt 1 sibling, 1 reply; 18+ messages in thread From: Simon Goldschmidt @ 2019-04-01 20:01 UTC (permalink / raw) To: u-boot If the malloc range passed to mem_malloc_init() is at the end of address range and 'start + size' overflows to 0, following allocations fail as mem_malloc_end is zero (which looks like uninitialized). Fix this by subtracting 1 of 'start + size' overflows to zero. Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> --- Changes in v4: None Changes in v3: None common/dlmalloc.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/common/dlmalloc.c b/common/dlmalloc.c index edaad299bb..51d3bd671a 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -603,6 +603,10 @@ void mem_malloc_init(ulong start, ulong size) mem_malloc_start = start; mem_malloc_end = start + size; mem_malloc_brk = start; + if (start && size && !mem_malloc_end) { + /* overflow: malloc area is at end of address range */ + mem_malloc_end--; + } debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start, mem_malloc_end); -- 2.17.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-01 20:01 ` [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram Simon Goldschmidt @ 2019-04-24 3:54 ` Simon Glass 2019-04-24 11:26 ` Tom Rini 0 siblings, 1 reply; 18+ messages in thread From: Simon Glass @ 2019-04-24 3:54 UTC (permalink / raw) To: u-boot On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> wrote: > > If the malloc range passed to mem_malloc_init() is at the end of address > range and 'start + size' overflows to 0, following allocations fail as > mem_malloc_end is zero (which looks like uninitialized). > > Fix this by subtracting 1 of 'start + size' overflows to zero. > > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > --- > > Changes in v4: None > Changes in v3: None > > common/dlmalloc.c | 4 ++++ > 1 file changed, 4 insertions(+) Reviewed-by: Simon Glass <sjg@chromium.org> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-24 3:54 ` Simon Glass @ 2019-04-24 11:26 ` Tom Rini 2019-04-24 11:49 ` Simon Goldschmidt 0 siblings, 1 reply; 18+ messages in thread From: Tom Rini @ 2019-04-24 11:26 UTC (permalink / raw) To: u-boot On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > <simon.k.r.goldschmidt@gmail.com> wrote: > > > > If the malloc range passed to mem_malloc_init() is at the end of address > > range and 'start + size' overflows to 0, following allocations fail as > > mem_malloc_end is zero (which looks like uninitialized). > > > > Fix this by subtracting 1 of 'start + size' overflows to zero. > > > > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > > --- > > > > Changes in v4: None > > Changes in v3: None > > > > common/dlmalloc.c | 4 ++++ > > 1 file changed, 4 insertions(+) > > Reviewed-by: Simon Glass <sjg@chromium.org> So, the problem with this patch is that it increases the generic malloc code size ever so slightly and blows up smartweb :( -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190424/4c2bd12e/attachment.sig> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-24 11:26 ` Tom Rini @ 2019-04-24 11:49 ` Simon Goldschmidt 2019-04-24 11:52 ` Tom Rini 0 siblings, 1 reply; 18+ messages in thread From: Simon Goldschmidt @ 2019-04-24 11:49 UTC (permalink / raw) To: u-boot On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <trini@konsulko.com> wrote: > > On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > > On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > > <simon.k.r.goldschmidt@gmail.com> wrote: > > > > > > If the malloc range passed to mem_malloc_init() is at the end of address > > > range and 'start + size' overflows to 0, following allocations fail as > > > mem_malloc_end is zero (which looks like uninitialized). > > > > > > Fix this by subtracting 1 of 'start + size' overflows to zero. > > > > > > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > > > --- > > > > > > Changes in v4: None > > > Changes in v3: None > > > > > > common/dlmalloc.c | 4 ++++ > > > 1 file changed, 4 insertions(+) > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > So, the problem with this patch is that it increases the generic malloc > code size ever so slightly and blows up smartweb :( Ehrm, ok, so how do we proceed? Regards, Simon ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-24 11:49 ` Simon Goldschmidt @ 2019-04-24 11:52 ` Tom Rini 2019-04-24 23:58 ` Simon Glass 0 siblings, 1 reply; 18+ messages in thread From: Tom Rini @ 2019-04-24 11:52 UTC (permalink / raw) To: u-boot On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <trini@konsulko.com> wrote: > > > > On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > > > On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > > > <simon.k.r.goldschmidt@gmail.com> wrote: > > > > > > > > If the malloc range passed to mem_malloc_init() is at the end of address > > > > range and 'start + size' overflows to 0, following allocations fail as > > > > mem_malloc_end is zero (which looks like uninitialized). > > > > > > > > Fix this by subtracting 1 of 'start + size' overflows to zero. > > > > > > > > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > > > > --- > > > > > > > > Changes in v4: None > > > > Changes in v3: None > > > > > > > > common/dlmalloc.c | 4 ++++ > > > > 1 file changed, 4 insertions(+) > > > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > So, the problem with this patch is that it increases the generic malloc > > code size ever so slightly and blows up smartweb :( > > Ehrm, ok, so how do we proceed? A good question. Take a look at spl/u-boot-spl.map on smartweb and see if, of the malloc functions it doesn't discard there's something that maybe could be optimized somewhere? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190424/998a9a69/attachment.sig> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-24 11:52 ` Tom Rini @ 2019-04-24 23:58 ` Simon Glass 2019-04-25 7:32 ` Simon Goldschmidt 0 siblings, 1 reply; 18+ messages in thread From: Simon Glass @ 2019-04-24 23:58 UTC (permalink / raw) To: u-boot Hi, On Wed, 24 Apr 2019 at 05:53, Tom Rini <trini@konsulko.com> wrote: > > On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > > On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > > > > On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > > > > <simon.k.r.goldschmidt@gmail.com> wrote: > > > > > > > > > > If the malloc range passed to mem_malloc_init() is at the end of address > > > > > range and 'start + size' overflows to 0, following allocations fail as > > > > > mem_malloc_end is zero (which looks like uninitialized). > > > > > > > > > > Fix this by subtracting 1 of 'start + size' overflows to zero. > > > > > > > > > > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > > > > > --- > > > > > > > > > > Changes in v4: None > > > > > Changes in v3: None > > > > > > > > > > common/dlmalloc.c | 4 ++++ > > > > > 1 file changed, 4 insertions(+) > > > > > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > > > So, the problem with this patch is that it increases the generic malloc > > > code size ever so slightly and blows up smartweb :( > > > > Ehrm, ok, so how do we proceed? > > A good question. Take a look at spl/u-boot-spl.map on smartweb and see > if, of the malloc functions it doesn't discard there's something that > maybe could be optimized somewhere? I wonder if we should have a Kconfig option like SPL_CHECKS which enables these sorts of minor checks, which may only fix one board at the cost of code size? Then it could be enabled by default, but disabled on this board? Regards, Simon ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-24 23:58 ` Simon Glass @ 2019-04-25 7:32 ` Simon Goldschmidt 2019-04-25 10:50 ` Tom Rini 0 siblings, 1 reply; 18+ messages in thread From: Simon Goldschmidt @ 2019-04-25 7:32 UTC (permalink / raw) To: u-boot On Thu, Apr 25, 2019 at 1:59 AM Simon Glass <sjg@chromium.org> wrote: > > Hi, > > On Wed, 24 Apr 2019 at 05:53, Tom Rini <trini@konsulko.com> wrote: > > > > On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > > > On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > > > > > On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > > > > > <simon.k.r.goldschmidt@gmail.com> wrote: > > > > > > > > > > > > If the malloc range passed to mem_malloc_init() is at the end of address > > > > > > range and 'start + size' overflows to 0, following allocations fail as > > > > > > mem_malloc_end is zero (which looks like uninitialized). > > > > > > > > > > > > Fix this by subtracting 1 of 'start + size' overflows to zero. > > > > > > > > > > > > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > > > > > > --- > > > > > > > > > > > > Changes in v4: None > > > > > > Changes in v3: None > > > > > > > > > > > > common/dlmalloc.c | 4 ++++ > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > > > > > So, the problem with this patch is that it increases the generic malloc > > > > code size ever so slightly and blows up smartweb :( > > > > > > Ehrm, ok, so how do we proceed? > > > > A good question. Take a look at spl/u-boot-spl.map on smartweb and see > > if, of the malloc functions it doesn't discard there's something that > > maybe could be optimized somewhere? > > I wonder if we should have a Kconfig option like SPL_CHECKS which > enables these sorts of minor checks, which may only fix one board at > the cost of code size? > > Then it could be enabled by default, but disabled on this board? For a bigger change, this might be an idea, but for a change that I can cut down to 16 or even 8 bytes code size increasement, I don't think having a new option would be good. Anyway, I just tried at work and I don't get the overflow. Tom, which gcc are you using to get the size error? It works for me on Debian 9 but doesn't work with Ubuntu (both times, default cross compiler toolchain installed). Regards, Simon ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-25 7:32 ` Simon Goldschmidt @ 2019-04-25 10:50 ` Tom Rini 2019-04-25 19:24 ` Simon Goldschmidt 0 siblings, 1 reply; 18+ messages in thread From: Tom Rini @ 2019-04-25 10:50 UTC (permalink / raw) To: u-boot On Thu, Apr 25, 2019 at 09:32:22AM +0200, Simon Goldschmidt wrote: > On Thu, Apr 25, 2019 at 1:59 AM Simon Glass <sjg@chromium.org> wrote: > > > > Hi, > > > > On Wed, 24 Apr 2019 at 05:53, Tom Rini <trini@konsulko.com> wrote: > > > > > > On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > > > > On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <trini@konsulko.com> wrote: > > > > > > > > > > On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > > > > > > On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > > > > > > <simon.k.r.goldschmidt@gmail.com> wrote: > > > > > > > > > > > > > > If the malloc range passed to mem_malloc_init() is at the end of address > > > > > > > range and 'start + size' overflows to 0, following allocations fail as > > > > > > > mem_malloc_end is zero (which looks like uninitialized). > > > > > > > > > > > > > > Fix this by subtracting 1 of 'start + size' overflows to zero. > > > > > > > > > > > > > > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > > > > > > > --- > > > > > > > > > > > > > > Changes in v4: None > > > > > > > Changes in v3: None > > > > > > > > > > > > > > common/dlmalloc.c | 4 ++++ > > > > > > > 1 file changed, 4 insertions(+) > > > > > > > > > > > > Reviewed-by: Simon Glass <sjg@chromium.org> > > > > > > > > > > So, the problem with this patch is that it increases the generic malloc > > > > > code size ever so slightly and blows up smartweb :( > > > > > > > > Ehrm, ok, so how do we proceed? > > > > > > A good question. Take a look at spl/u-boot-spl.map on smartweb and see > > > if, of the malloc functions it doesn't discard there's something that > > > maybe could be optimized somewhere? > > > > I wonder if we should have a Kconfig option like SPL_CHECKS which > > enables these sorts of minor checks, which may only fix one board at > > the cost of code size? > > > > Then it could be enabled by default, but disabled on this board? > > For a bigger change, this might be an idea, but for a change that I can cut > down to 16 or even 8 bytes code size increasement, I don't think having a > new option would be good. > > Anyway, I just tried at work and I don't get the overflow. Tom, which gcc > are you using to get the size error? It works for me on Debian 9 but doesn't > work with Ubuntu (both times, default cross compiler toolchain installed). I'm using the gcc-7.3 from kernel.org that we use in travis/etc. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190425/8a2f8ce9/attachment.sig> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-25 10:50 ` Tom Rini @ 2019-04-25 19:24 ` Simon Goldschmidt 2019-04-29 13:06 ` Heiko Schocher 0 siblings, 1 reply; 18+ messages in thread From: Simon Goldschmidt @ 2019-04-25 19:24 UTC (permalink / raw) To: u-boot Am 25.04.2019 um 12:50 schrieb Tom Rini: > On Thu, Apr 25, 2019 at 09:32:22AM +0200, Simon Goldschmidt wrote: >> On Thu, Apr 25, 2019 at 1:59 AM Simon Glass <sjg@chromium.org> wrote: >>> >>> Hi, >>> >>> On Wed, 24 Apr 2019 at 05:53, Tom Rini <trini@konsulko.com> wrote: >>>> >>>> On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: >>>>> On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <trini@konsulko.com> wrote: >>>>>> >>>>>> On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: >>>>>>> On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt >>>>>>> <simon.k.r.goldschmidt@gmail.com> wrote: >>>>>>>> >>>>>>>> If the malloc range passed to mem_malloc_init() is at the end of address >>>>>>>> range and 'start + size' overflows to 0, following allocations fail as >>>>>>>> mem_malloc_end is zero (which looks like uninitialized). >>>>>>>> >>>>>>>> Fix this by subtracting 1 of 'start + size' overflows to zero. >>>>>>>> >>>>>>>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> >>>>>>>> --- >>>>>>>> >>>>>>>> Changes in v4: None >>>>>>>> Changes in v3: None >>>>>>>> >>>>>>>> common/dlmalloc.c | 4 ++++ >>>>>>>> 1 file changed, 4 insertions(+) >>>>>>> >>>>>>> Reviewed-by: Simon Glass <sjg@chromium.org> >>>>>> >>>>>> So, the problem with this patch is that it increases the generic malloc >>>>>> code size ever so slightly and blows up smartweb :( >>>>> >>>>> Ehrm, ok, so how do we proceed? >>>> >>>> A good question. Take a look at spl/u-boot-spl.map on smartweb and see >>>> if, of the malloc functions it doesn't discard there's something that >>>> maybe could be optimized somewhere? >>> >>> I wonder if we should have a Kconfig option like SPL_CHECKS which >>> enables these sorts of minor checks, which may only fix one board at >>> the cost of code size? >>> >>> Then it could be enabled by default, but disabled on this board? >> >> For a bigger change, this might be an idea, but for a change that I can cut >> down to 16 or even 8 bytes code size increasement, I don't think having a >> new option would be good. >> >> Anyway, I just tried at work and I don't get the overflow. Tom, which gcc >> are you using to get the size error? It works for me on Debian 9 but doesn't >> work with Ubuntu (both times, default cross compiler toolchain installed). > > I'm using the gcc-7.3 from kernel.org that we use in travis/etc. Ok, so I have gcc-7.3 on my Ubuntu machine as well. I don't know why 6.3 seems to produce smaller binaries (I thought they were getting smaller with new versions, not larger). However, I've stripped down that patch to +8 Bytes only and sent v5. Regards, Simon ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-25 19:24 ` Simon Goldschmidt @ 2019-04-29 13:06 ` Heiko Schocher 2019-04-29 13:16 ` Simon Goldschmidt 2019-04-29 13:19 ` Tom Rini 0 siblings, 2 replies; 18+ messages in thread From: Heiko Schocher @ 2019-04-29 13:06 UTC (permalink / raw) To: u-boot Hello Simon, Am 25.04.2019 um 21:24 schrieb Simon Goldschmidt: > Am 25.04.2019 um 12:50 schrieb Tom Rini: >> On Thu, Apr 25, 2019 at 09:32:22AM +0200, Simon Goldschmidt wrote: >>> On Thu, Apr 25, 2019 at 1:59 AM Simon Glass <sjg@chromium.org> wrote: >>>> >>>> Hi, >>>> >>>> On Wed, 24 Apr 2019 at 05:53, Tom Rini <trini@konsulko.com> wrote: >>>>> >>>>> On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: >>>>>> On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <trini@konsulko.com> wrote: >>>>>>> >>>>>>> On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: >>>>>>>> On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt >>>>>>>> <simon.k.r.goldschmidt@gmail.com> wrote: >>>>>>>>> >>>>>>>>> If the malloc range passed to mem_malloc_init() is at the end of address >>>>>>>>> range and 'start + size' overflows to 0, following allocations fail as >>>>>>>>> mem_malloc_end is zero (which looks like uninitialized). >>>>>>>>> >>>>>>>>> Fix this by subtracting 1 of 'start + size' overflows to zero. >>>>>>>>> >>>>>>>>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Changes in v4: None >>>>>>>>> Changes in v3: None >>>>>>>>> >>>>>>>>> common/dlmalloc.c | 4 ++++ >>>>>>>>> 1 file changed, 4 insertions(+) >>>>>>>> >>>>>>>> Reviewed-by: Simon Glass <sjg@chromium.org> >>>>>>> >>>>>>> So, the problem with this patch is that it increases the generic malloc >>>>>>> code size ever so slightly and blows up smartweb :( >>>>>> >>>>>> Ehrm, ok, so how do we proceed? >>>>> >>>>> A good question. Take a look at spl/u-boot-spl.map on smartweb and see >>>>> if, of the malloc functions it doesn't discard there's something that >>>>> maybe could be optimized somewhere? >>>> >>>> I wonder if we should have a Kconfig option like SPL_CHECKS which >>>> enables these sorts of minor checks, which may only fix one board at >>>> the cost of code size? >>>> >>>> Then it could be enabled by default, but disabled on this board? >>> >>> For a bigger change, this might be an idea, but for a change that I can cut >>> down to 16 or even 8 bytes code size increasement, I don't think having a >>> new option would be good. >>> >>> Anyway, I just tried at work and I don't get the overflow. Tom, which gcc >>> are you using to get the size error? It works for me on Debian 9 but doesn't >>> work with Ubuntu (both times, default cross compiler toolchain installed). >> >> I'm using the gcc-7.3 from kernel.org that we use in travis/etc. > > Ok, so I have gcc-7.3 on my Ubuntu machine as well. I don't know why 6.3 seems to produce smaller > binaries (I thought they were getting smaller with new versions, not larger). > > However, I've stripped down that patch to +8 Bytes only and sent v5. Thanks! Sorry for digging so late in, but I was on vacation... Hmm.. the smartweb board has only 4k sram for SPL, and I have no chance to convert it to DM to get rid of some compiler warnings ... I am unsure what to do now with this hardware ... bye, Heiko -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: hs at denx.de ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-29 13:06 ` Heiko Schocher @ 2019-04-29 13:16 ` Simon Goldschmidt 2019-04-29 13:20 ` Tom Rini 2019-04-29 13:19 ` Tom Rini 1 sibling, 1 reply; 18+ messages in thread From: Simon Goldschmidt @ 2019-04-29 13:16 UTC (permalink / raw) To: u-boot Hello Heiko, On Mon, Apr 29, 2019 at 3:06 PM Heiko Schocher <hs@denx.de> wrote: > > Hello Simon, > > Am 25.04.2019 um 21:24 schrieb Simon Goldschmidt: > > Am 25.04.2019 um 12:50 schrieb Tom Rini: > >> On Thu, Apr 25, 2019 at 09:32:22AM +0200, Simon Goldschmidt wrote: > >>> On Thu, Apr 25, 2019 at 1:59 AM Simon Glass <sjg@chromium.org> wrote: > >>>> > >>>> Hi, > >>>> > >>>> On Wed, 24 Apr 2019 at 05:53, Tom Rini <trini@konsulko.com> wrote: > >>>>> > >>>>> On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > >>>>>> On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <trini@konsulko.com> wrote: > >>>>>>> > >>>>>>> On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > >>>>>>>> On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > >>>>>>>> <simon.k.r.goldschmidt@gmail.com> wrote: > >>>>>>>>> > >>>>>>>>> If the malloc range passed to mem_malloc_init() is at the end of address > >>>>>>>>> range and 'start + size' overflows to 0, following allocations fail as > >>>>>>>>> mem_malloc_end is zero (which looks like uninitialized). > >>>>>>>>> > >>>>>>>>> Fix this by subtracting 1 of 'start + size' overflows to zero. > >>>>>>>>> > >>>>>>>>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > >>>>>>>>> --- > >>>>>>>>> > >>>>>>>>> Changes in v4: None > >>>>>>>>> Changes in v3: None > >>>>>>>>> > >>>>>>>>> common/dlmalloc.c | 4 ++++ > >>>>>>>>> 1 file changed, 4 insertions(+) > >>>>>>>> > >>>>>>>> Reviewed-by: Simon Glass <sjg@chromium.org> > >>>>>>> > >>>>>>> So, the problem with this patch is that it increases the generic malloc > >>>>>>> code size ever so slightly and blows up smartweb :( > >>>>>> > >>>>>> Ehrm, ok, so how do we proceed? > >>>>> > >>>>> A good question. Take a look at spl/u-boot-spl.map on smartweb and see > >>>>> if, of the malloc functions it doesn't discard there's something that > >>>>> maybe could be optimized somewhere? > >>>> > >>>> I wonder if we should have a Kconfig option like SPL_CHECKS which > >>>> enables these sorts of minor checks, which may only fix one board at > >>>> the cost of code size? > >>>> > >>>> Then it could be enabled by default, but disabled on this board? > >>> > >>> For a bigger change, this might be an idea, but for a change that I can cut > >>> down to 16 or even 8 bytes code size increasement, I don't think having a > >>> new option would be good. > >>> > >>> Anyway, I just tried at work and I don't get the overflow. Tom, which gcc > >>> are you using to get the size error? It works for me on Debian 9 but doesn't > >>> work with Ubuntu (both times, default cross compiler toolchain installed). > >> > >> I'm using the gcc-7.3 from kernel.org that we use in travis/etc. > > > > Ok, so I have gcc-7.3 on my Ubuntu machine as well. I don't know why 6.3 seems to produce smaller > > binaries (I thought they were getting smaller with new versions, not larger). > > > > However, I've stripped down that patch to +8 Bytes only and sent v5. > > Thanks! > > Sorry for digging so late in, but I was on vacation... > > Hmm.. the smartweb board has only 4k sram for SPL, and I have no chance > to convert it to DM to get rid of some compiler warnings ... > > I am unsure what to do now with this hardware ... And things even get worse: as I wrote in the other thread, after updating to Ubuntu 19.04 as build system, I get gcc 8.3 as cross compiler and smartweb fails to build with that compiler (as the SPL binary is exactly 4k now). Regards, Simon ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-29 13:16 ` Simon Goldschmidt @ 2019-04-29 13:20 ` Tom Rini 0 siblings, 0 replies; 18+ messages in thread From: Tom Rini @ 2019-04-29 13:20 UTC (permalink / raw) To: u-boot On Mon, Apr 29, 2019 at 03:16:02PM +0200, Simon Goldschmidt wrote: > Hello Heiko, > > On Mon, Apr 29, 2019 at 3:06 PM Heiko Schocher <hs@denx.de> wrote: > > > > Hello Simon, > > > > Am 25.04.2019 um 21:24 schrieb Simon Goldschmidt: > > > Am 25.04.2019 um 12:50 schrieb Tom Rini: > > >> On Thu, Apr 25, 2019 at 09:32:22AM +0200, Simon Goldschmidt wrote: > > >>> On Thu, Apr 25, 2019 at 1:59 AM Simon Glass <sjg@chromium.org> wrote: > > >>>> > > >>>> Hi, > > >>>> > > >>>> On Wed, 24 Apr 2019 at 05:53, Tom Rini <trini@konsulko.com> wrote: > > >>>>> > > >>>>> On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > > >>>>>> On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <trini@konsulko.com> wrote: > > >>>>>>> > > >>>>>>> On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > > >>>>>>>> On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > > >>>>>>>> <simon.k.r.goldschmidt@gmail.com> wrote: > > >>>>>>>>> > > >>>>>>>>> If the malloc range passed to mem_malloc_init() is at the end of address > > >>>>>>>>> range and 'start + size' overflows to 0, following allocations fail as > > >>>>>>>>> mem_malloc_end is zero (which looks like uninitialized). > > >>>>>>>>> > > >>>>>>>>> Fix this by subtracting 1 of 'start + size' overflows to zero. > > >>>>>>>>> > > >>>>>>>>> Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > > >>>>>>>>> --- > > >>>>>>>>> > > >>>>>>>>> Changes in v4: None > > >>>>>>>>> Changes in v3: None > > >>>>>>>>> > > >>>>>>>>> common/dlmalloc.c | 4 ++++ > > >>>>>>>>> 1 file changed, 4 insertions(+) > > >>>>>>>> > > >>>>>>>> Reviewed-by: Simon Glass <sjg@chromium.org> > > >>>>>>> > > >>>>>>> So, the problem with this patch is that it increases the generic malloc > > >>>>>>> code size ever so slightly and blows up smartweb :( > > >>>>>> > > >>>>>> Ehrm, ok, so how do we proceed? > > >>>>> > > >>>>> A good question. Take a look at spl/u-boot-spl.map on smartweb and see > > >>>>> if, of the malloc functions it doesn't discard there's something that > > >>>>> maybe could be optimized somewhere? > > >>>> > > >>>> I wonder if we should have a Kconfig option like SPL_CHECKS which > > >>>> enables these sorts of minor checks, which may only fix one board at > > >>>> the cost of code size? > > >>>> > > >>>> Then it could be enabled by default, but disabled on this board? > > >>> > > >>> For a bigger change, this might be an idea, but for a change that I can cut > > >>> down to 16 or even 8 bytes code size increasement, I don't think having a > > >>> new option would be good. > > >>> > > >>> Anyway, I just tried at work and I don't get the overflow. Tom, which gcc > > >>> are you using to get the size error? It works for me on Debian 9 but doesn't > > >>> work with Ubuntu (both times, default cross compiler toolchain installed). > > >> > > >> I'm using the gcc-7.3 from kernel.org that we use in travis/etc. > > > > > > Ok, so I have gcc-7.3 on my Ubuntu machine as well. I don't know why 6.3 seems to produce smaller > > > binaries (I thought they were getting smaller with new versions, not larger). > > > > > > However, I've stripped down that patch to +8 Bytes only and sent v5. > > > > Thanks! > > > > Sorry for digging so late in, but I was on vacation... > > > > Hmm.. the smartweb board has only 4k sram for SPL, and I have no chance > > to convert it to DM to get rid of some compiler warnings ... > > > > I am unsure what to do now with this hardware ... > > And things even get worse: as I wrote in the other thread, after updating to > Ubuntu 19.04 as build system, I get gcc 8.3 as cross compiler and smartweb > fails to build with that compiler (as the SPL binary is exactly 4k now). Which reminds me that fixing the various warnings we get with gcc-8.x would be a good general thing to do. :( -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190429/99548995/attachment.sig> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-29 13:06 ` Heiko Schocher 2019-04-29 13:16 ` Simon Goldschmidt @ 2019-04-29 13:19 ` Tom Rini 2019-04-29 15:53 ` Simon Glass 1 sibling, 1 reply; 18+ messages in thread From: Tom Rini @ 2019-04-29 13:19 UTC (permalink / raw) To: u-boot On Mon, Apr 29, 2019 at 03:06:39PM +0200, Heiko Schocher wrote: > Hello Simon, > > Am 25.04.2019 um 21:24 schrieb Simon Goldschmidt: > >Am 25.04.2019 um 12:50 schrieb Tom Rini: > >>On Thu, Apr 25, 2019 at 09:32:22AM +0200, Simon Goldschmidt wrote: > >>>On Thu, Apr 25, 2019 at 1:59 AM Simon Glass <sjg@chromium.org> wrote: > >>>> > >>>>Hi, > >>>> > >>>>On Wed, 24 Apr 2019 at 05:53, Tom Rini <trini@konsulko.com> wrote: > >>>>> > >>>>>On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > >>>>>>On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <trini@konsulko.com> wrote: > >>>>>>> > >>>>>>>On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > >>>>>>>>On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > >>>>>>>><simon.k.r.goldschmidt@gmail.com> wrote: > >>>>>>>>> > >>>>>>>>>If the malloc range passed to mem_malloc_init() is at the end of address > >>>>>>>>>range and 'start + size' overflows to 0, following allocations fail as > >>>>>>>>>mem_malloc_end is zero (which looks like uninitialized). > >>>>>>>>> > >>>>>>>>>Fix this by subtracting 1 of 'start + size' overflows to zero. > >>>>>>>>> > >>>>>>>>>Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > >>>>>>>>>--- > >>>>>>>>> > >>>>>>>>>Changes in v4: None > >>>>>>>>>Changes in v3: None > >>>>>>>>> > >>>>>>>>> common/dlmalloc.c | 4 ++++ > >>>>>>>>> 1 file changed, 4 insertions(+) > >>>>>>>> > >>>>>>>>Reviewed-by: Simon Glass <sjg@chromium.org> > >>>>>>> > >>>>>>>So, the problem with this patch is that it increases the generic malloc > >>>>>>>code size ever so slightly and blows up smartweb :( > >>>>>> > >>>>>>Ehrm, ok, so how do we proceed? > >>>>> > >>>>>A good question. Take a look at spl/u-boot-spl.map on smartweb and see > >>>>>if, of the malloc functions it doesn't discard there's something that > >>>>>maybe could be optimized somewhere? > >>>> > >>>>I wonder if we should have a Kconfig option like SPL_CHECKS which > >>>>enables these sorts of minor checks, which may only fix one board at > >>>>the cost of code size? > >>>> > >>>>Then it could be enabled by default, but disabled on this board? > >>> > >>>For a bigger change, this might be an idea, but for a change that I can cut > >>>down to 16 or even 8 bytes code size increasement, I don't think having a > >>>new option would be good. > >>> > >>>Anyway, I just tried at work and I don't get the overflow. Tom, which gcc > >>>are you using to get the size error? It works for me on Debian 9 but doesn't > >>>work with Ubuntu (both times, default cross compiler toolchain installed). > >> > >>I'm using the gcc-7.3 from kernel.org that we use in travis/etc. > > > >Ok, so I have gcc-7.3 on my Ubuntu machine as well. I don't know why 6.3 > >seems to produce smaller binaries (I thought they were getting smaller > >with new versions, not larger). > > > >However, I've stripped down that patch to +8 Bytes only and sent v5. > > Thanks! > > Sorry for digging so late in, but I was on vacation... > > Hmm.. the smartweb board has only 4k sram for SPL, and I have no chance > to convert it to DM to get rid of some compiler warnings ... > > I am unsure what to do now with this hardware ... Well, with regards to SPL + DM, this is one of the cases wherein we just have-to allow for the SPL driver code at least to be a one-off. If the "whatever ROM loads of our code" stage can set things up enough such that we can hand off to a full U-Boot, that's great. If not, this is then a case where TPL comes in to play, and that really is as one-off as needed, to load a more general SPL and so forth. But, I'm fine with saying smartweb keeps and maintains whatever SPL code it needs to use. It's just that in this case, it's not at all a DM thing, it's a change in malloc. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190429/db4a845c/attachment.sig> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram 2019-04-29 13:19 ` Tom Rini @ 2019-04-29 15:53 ` Simon Glass 0 siblings, 0 replies; 18+ messages in thread From: Simon Glass @ 2019-04-29 15:53 UTC (permalink / raw) To: u-boot Hi, On Mon, 29 Apr 2019 at 07:19, Tom Rini <trini@konsulko.com> wrote: > > On Mon, Apr 29, 2019 at 03:06:39PM +0200, Heiko Schocher wrote: > > Hello Simon, > > > > Am 25.04.2019 um 21:24 schrieb Simon Goldschmidt: > > >Am 25.04.2019 um 12:50 schrieb Tom Rini: > > >>On Thu, Apr 25, 2019 at 09:32:22AM +0200, Simon Goldschmidt wrote: > > >>>On Thu, Apr 25, 2019 at 1:59 AM Simon Glass <sjg@chromium.org> wrote: > > >>>> > > >>>>Hi, > > >>>> > > >>>>On Wed, 24 Apr 2019 at 05:53, Tom Rini <trini@konsulko.com> wrote: > > >>>>> > > >>>>>On Wed, Apr 24, 2019 at 01:49:52PM +0200, Simon Goldschmidt wrote: > > >>>>>>On Wed, Apr 24, 2019 at 1:27 PM Tom Rini <trini@konsulko.com> wrote: > > >>>>>>> > > >>>>>>>On Tue, Apr 23, 2019 at 09:54:10PM -0600, Simon Glass wrote: > > >>>>>>>>On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt > > >>>>>>>><simon.k.r.goldschmidt@gmail.com> wrote: > > >>>>>>>>> > > >>>>>>>>>If the malloc range passed to mem_malloc_init() is at the end of address > > >>>>>>>>>range and 'start + size' overflows to 0, following allocations fail as > > >>>>>>>>>mem_malloc_end is zero (which looks like uninitialized). > > >>>>>>>>> > > >>>>>>>>>Fix this by subtracting 1 of 'start + size' overflows to zero. > > >>>>>>>>> > > >>>>>>>>>Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > > >>>>>>>>>--- > > >>>>>>>>> > > >>>>>>>>>Changes in v4: None > > >>>>>>>>>Changes in v3: None > > >>>>>>>>> > > >>>>>>>>> common/dlmalloc.c | 4 ++++ > > >>>>>>>>> 1 file changed, 4 insertions(+) > > >>>>>>>> > > >>>>>>>>Reviewed-by: Simon Glass <sjg@chromium.org> > > >>>>>>> > > >>>>>>>So, the problem with this patch is that it increases the generic malloc > > >>>>>>>code size ever so slightly and blows up smartweb :( > > >>>>>> > > >>>>>>Ehrm, ok, so how do we proceed? > > >>>>> > > >>>>>A good question. Take a look at spl/u-boot-spl.map on smartweb and see > > >>>>>if, of the malloc functions it doesn't discard there's something that > > >>>>>maybe could be optimized somewhere? > > >>>> > > >>>>I wonder if we should have a Kconfig option like SPL_CHECKS which > > >>>>enables these sorts of minor checks, which may only fix one board at > > >>>>the cost of code size? > > >>>> > > >>>>Then it could be enabled by default, but disabled on this board? > > >>> > > >>>For a bigger change, this might be an idea, but for a change that I can cut > > >>>down to 16 or even 8 bytes code size increasement, I don't think having a > > >>>new option would be good. > > >>> > > >>>Anyway, I just tried at work and I don't get the overflow. Tom, which gcc > > >>>are you using to get the size error? It works for me on Debian 9 but doesn't > > >>>work with Ubuntu (both times, default cross compiler toolchain installed). > > >> > > >>I'm using the gcc-7.3 from kernel.org that we use in travis/etc. > > > > > >Ok, so I have gcc-7.3 on my Ubuntu machine as well. I don't know why 6.3 > > >seems to produce smaller binaries (I thought they were getting smaller > > >with new versions, not larger). > > > > > >However, I've stripped down that patch to +8 Bytes only and sent v5. > > > > Thanks! > > > > Sorry for digging so late in, but I was on vacation... > > > > Hmm.. the smartweb board has only 4k sram for SPL, and I have no chance > > to convert it to DM to get rid of some compiler warnings ... > > > > I am unsure what to do now with this hardware ... > > Well, with regards to SPL + DM, this is one of the cases wherein we just > have-to allow for the SPL driver code at least to be a one-off. If the > "whatever ROM loads of our code" stage can set things up enough such > that we can hand off to a full U-Boot, that's great. If not, this is > then a case where TPL comes in to play, and that really is as one-off as > needed, to load a more general SPL and so forth. I think DM in SPL is a good thing, so long as there is space. If not, then we should allow non-DM also. I wonder if we need our policy to be written down somewhere? > > But, I'm fine with saying smartweb keeps and maintains whatever SPL code > it needs to use. It's just that in this case, it's not at all a DM > thing, it's a change in malloc. Regards, Simon ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 2/2] dlmalloc: be compatible to tiny printf 2019-04-01 20:01 [U-Boot] [PATCH v4 0/2] spl: full-featured heap cleanups Simon Goldschmidt 2019-04-01 20:01 ` [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram Simon Goldschmidt @ 2019-04-01 20:01 ` Simon Goldschmidt 2019-04-24 3:54 ` Simon Glass 2019-04-24 13:31 ` [U-Boot] [U-Boot, v4, " Tom Rini 1 sibling, 2 replies; 18+ messages in thread From: Simon Goldschmidt @ 2019-04-01 20:01 UTC (permalink / raw) To: u-boot Convert debug output from '%#lx' to '0x%lx' to be compatible with tiny printf used in SPL. Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> --- Changes in v4: - dumped clearing BSS before SPL board_init_f, only real bugfixes remain Changes in v3: - fixed summary ("stack" -> "heap") - enable CONFIG_SPL_CLEAR_BSS_F for socfpga_arria10 using full malloc early in SPL - rebased common/dlmalloc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/dlmalloc.c b/common/dlmalloc.c index 51d3bd671a..af6f43dcc9 100644 --- a/common/dlmalloc.c +++ b/common/dlmalloc.c @@ -608,7 +608,7 @@ void mem_malloc_init(ulong start, ulong size) mem_malloc_end--; } - debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start, + debug("using memory 0x%lx-0x%lx for malloc()\n", mem_malloc_start, mem_malloc_end); #ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT memset((void *)mem_malloc_start, 0x0, size); -- 2.17.1 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* [U-Boot] [PATCH v4 2/2] dlmalloc: be compatible to tiny printf 2019-04-01 20:01 ` [U-Boot] [PATCH v4 2/2] dlmalloc: be compatible to tiny printf Simon Goldschmidt @ 2019-04-24 3:54 ` Simon Glass 2019-04-24 13:31 ` [U-Boot] [U-Boot, v4, " Tom Rini 1 sibling, 0 replies; 18+ messages in thread From: Simon Glass @ 2019-04-24 3:54 UTC (permalink / raw) To: u-boot On Mon, 1 Apr 2019 at 14:01, Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> wrote: > > Convert debug output from '%#lx' to '0x%lx' to be compatible with tiny > printf used in SPL. > > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> > --- > > Changes in v4: > - dumped clearing BSS before SPL board_init_f, only real bugfixes remain > > Changes in v3: > - fixed summary ("stack" -> "heap") > - enable CONFIG_SPL_CLEAR_BSS_F for socfpga_arria10 using full malloc > early in SPL > - rebased > > common/dlmalloc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Reviewed-by: Simon Glass <sjg@chromium.org> ^ permalink raw reply [flat|nested] 18+ messages in thread
* [U-Boot] [U-Boot, v4, 2/2] dlmalloc: be compatible to tiny printf 2019-04-01 20:01 ` [U-Boot] [PATCH v4 2/2] dlmalloc: be compatible to tiny printf Simon Goldschmidt 2019-04-24 3:54 ` Simon Glass @ 2019-04-24 13:31 ` Tom Rini 1 sibling, 0 replies; 18+ messages in thread From: Tom Rini @ 2019-04-24 13:31 UTC (permalink / raw) To: u-boot On Mon, Apr 01, 2019 at 10:01:50PM +0200, Simon Goldschmidt wrote: > Convert debug output from '%#lx' to '0x%lx' to be compatible with tiny > printf used in SPL. > > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt@gmail.com> Applied to u-boot/master, thanks! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.denx.de/pipermail/u-boot/attachments/20190424/3dcab9ad/attachment.sig> ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2019-04-29 15:53 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-04-01 20:01 [U-Boot] [PATCH v4 0/2] spl: full-featured heap cleanups Simon Goldschmidt 2019-04-01 20:01 ` [U-Boot] [PATCH v4 1/2] dlmalloc: fix malloc range at end of ram Simon Goldschmidt 2019-04-24 3:54 ` Simon Glass 2019-04-24 11:26 ` Tom Rini 2019-04-24 11:49 ` Simon Goldschmidt 2019-04-24 11:52 ` Tom Rini 2019-04-24 23:58 ` Simon Glass 2019-04-25 7:32 ` Simon Goldschmidt 2019-04-25 10:50 ` Tom Rini 2019-04-25 19:24 ` Simon Goldschmidt 2019-04-29 13:06 ` Heiko Schocher 2019-04-29 13:16 ` Simon Goldschmidt 2019-04-29 13:20 ` Tom Rini 2019-04-29 13:19 ` Tom Rini 2019-04-29 15:53 ` Simon Glass 2019-04-01 20:01 ` [U-Boot] [PATCH v4 2/2] dlmalloc: be compatible to tiny printf Simon Goldschmidt 2019-04-24 3:54 ` Simon Glass 2019-04-24 13:31 ` [U-Boot] [U-Boot, v4, " Tom Rini
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.