Why sbrk clear the increased memory region
Recently, I'm using barebox in a deep embedded project, and need some funtctions in libc/libm, So I linked barebox with newlib But whenever newlib call sbrk with negtive `increment`, barebox crash. The reason is sbrk clean memory region using `increment`. Why sbrk must clear the increased memory region? 8<- From dbaa658b60fe413e1d1818afad13a53e7ad000ce Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E5=BC=A0=E5=BF=A0=E5=B1=B1?= Date: Mon, 22 Apr 2019 11:01:33 +0800 Subject: [PATCH] only clear memory when increasing head size MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: 张忠山 --- common/memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common/memory.c b/common/memory.c index 8f0b59891..0a8700d28 100644 --- a/common/memory.c +++ b/common/memory.c @@ -122,7 +122,7 @@ void *sbrk(ptrdiff_t increment) void *old = sbrk_no_zero(increment); /* Only clear increment, if valid address was returned */ - if (old != NULL) + if ((old != NULL) && (increment > 0)) memset(old, 0, increment); return old; -- 2.21.0 -- Best Regards, zzs ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v3 14/15] ARM: at91: microchip-ksz9477: provide board code fallback
Hello Sam,
On 2/4/19 20:01, Sam Ravnborg wrote:
> Hi Ahmad.
>
> On Mon, Apr 01, 2019 at 12:18:22PM +0200, Ahmad Fatoum wrote:
>> The newly added device tree based first stage fails to load the second
>> stage from MMC, which might be in relation to a preceding atmel_mci
>> "command/data timeout" message.
>
> I had similar troubles with MMC on at91sam9263.
> After some digging the fix was simple:
> See 5feabc1e6737742f1cf6a1c41921f68b4dbb5c10 ("arm: at91: fix clock to mci1
> for at91sam9263")
Might be clock related. But if I need to fit drivers into the PBL
as well, device tree in first-stage won't be viable anyway,
so I probably won't look further into this.
>
> Maybe you are hit by something as simple as this?
>
>> +
>> +static const struct devfs_partition sama5d3_xplained_nand0_partitions[] = {
>> +{
>> +.offset = 0x0,
>> +.size = SZ_256K,
>> +.flags = DEVFS_PARTITION_FIXED,
>> +.name = "at91bootstrap_raw",
>> +.bbname = "at91bootstrap",
>> +},
> Strange partition name now we use barebox as first stage.
Indeed.
>
>
>> +++ b/arch/arm/configs/microchip_ksz9477_evb_bootstrap_mmc_defconfig
>
> Naming confuses me.
> Do we stick to the name "first stage" or do we use "bootstrap"?
> For me they are the same, but I get confused when we use both.
For the at91sam9261ek the bootstrap defconfig is the one defining
AT91_BOOTSTRAP, so I figured I should follow suit..
>
>
> Sam
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v3 10/15] images: at91: differentiate between first and second stage images
Hello Sam,
On 2/4/19 19:49, Sam Ravnborg wrote:
> Hi Ahmad.
>
> On Mon, Apr 01, 2019 at 12:18:18PM +0200, Ahmad Fatoum wrote:
>> Incoming microchip-ksz9477-evb first stage will add one more entry point
>> for the first stage. As there is a little reason to use the same piggy
>> data for both images (BOOT.BIN, the first stage, is limited to 64K), have
>> CONFIG_AT91_LOAD_BAREBOX_SRAM decide which stage should be built.
>>
>> Signed-off-by: Ahmad Fatoum
>> ---
>> arch/arm/mach-at91/Kconfig | 2 +-
>> images/Makefile.at91 | 12 +---
>> 2 files changed, 10 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig
>> index 8e1bf0629ab7..60f427d7d483 100644
>> --- a/arch/arm/mach-at91/Kconfig
>> +++ b/arch/arm/mach-at91/Kconfig
>> @@ -615,7 +615,7 @@ config AT91_BOOTSTRAP
>> select BOOTSTRAP
>>
>> config AT91_LOAD_BAREBOX_SRAM
>> -bool "at91 load barebox in sram"
>> +bool "at91 barebox image will be loaded into SRAM"
>> depends on SHELL_NONE || HAVE_AT91_LOAD_BAREBOX_SRAM
>> default y if SHELL_NONE
>>
>> diff --git a/images/Makefile.at91 b/images/Makefile.at91
>> index acdb591d2452..3f1dd57f6c58 100644
>> --- a/images/Makefile.at91
>> +++ b/images/Makefile.at91
>> @@ -4,12 +4,18 @@
>>
>> pblb-$(CONFIG_MACH_AT91SAM9X5EK) += start_at91sam9x5ek
>> FILE_barebox-at91sam9x5ek.img = start_at91sam9x5ek.pblb
>> -image-$(CONFIG_MACH_AT91SAM9X5EK) += barebox-at91sam9x5ek.img
>> +at91-barebox-$(CONFIG_MACH_AT91SAM9X5EK) += barebox-at91sam9x5ek.img
>>
>> pblb-$(CONFIG_MACH_AT91SAM9263EK) += start_at91sam9263ek
>> FILE_barebox-at91sam9263ek.img = start_at91sam9263ek.pblb
>> -image-$(CONFIG_MACH_AT91SAM9263EK) += barebox-at91sam9263ek.img
>> +at91-barebox-$(CONFIG_MACH_AT91SAM9263EK) += barebox-at91sam9263ek.img
>>
>> pblb-$(CONFIG_MACH_MICROCHIP_KSZ9477_EVB) += start_sama5d3_xplained_ung8071
>> FILE_barebox-microchip-ksz9477-evb.img = start_sama5d3_xplained_ung8071.pblb
>> -image-$(CONFIG_MACH_MICROCHIP_KSZ9477_EVB) +=
>> barebox-microchip-ksz9477-evb.img
>> +at91-barebox-$(CONFIG_MACH_MICROCHIP_KSZ9477_EVB) +=
>> barebox-microchip-ksz9477-evb.img
>> +
>> +ifdef CONFIG_AT91_LOAD_BAREBOX_SRAM
>> +image-y += $(at91-boot-bin-y)
>> +else
>> +image-y += $(at91-barebox-y)
>> +endif
>
> I cannot follow what you do in the line "image-y += $(at91-boot-bin-y)".
> Could you try to elaborate.
I got the idea from images/Makefile.omap3, there multi-images are split
into two, separated by a Kconfig option, so you can either select building
all first stage multi-image bareboxes or build all second stages. This allows
separate entry points for each and enables use of ed04a7c3c ("pbl multiimage:
Allow to check image sizes") Sascha added.
To differentiate between first and second stage I used the
CONFIG_AT91_LOAD_BAREBOX_SRAM macro. Looking at it again, at91sam9x5ek and
at91sam9263ek should've had their entry points split as well for uniformity.
I talked about this with Sascha and his opinion is that we shouldn't have
stages at all. Everything needed for low level bootstrap (SDRAM init and
MMC access) should be made to fit into the PBL instead.
That way we can rename the PBL to BOOT.BIN and use the full barebox as
second stage. This means I'll need to strip down the drivers in v4..
Cheers
Ahmad
>
> Sam
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v3 01/15] LICENSES: add BSD-1-Clause license
On 1/4/19 14:20, Roland Hieber wrote: > On Mon, Apr 01, 2019 at 12:18:09PM +0200, Ahmad Fatoum wrote: >> Incoming sama5d3 bootstrap code has been ported from the at91bootstrap >> project and is licensed under a 1-clause BSD license. To remove >> boilerplate legal text there, place the license at a fixed location >> and only note SPDX-License-Identifier and Copyright in the source files. >> >> Signed-off-by: Ahmad Fatoum >> --- >> LICENSES/preferred/BSD-1-Clause | 15 +++ >> 1 file changed, 15 insertions(+) >> create mode 100644 LICENSES/preferred/BSD-1-Clause >> >> diff --git a/LICENSES/preferred/BSD-1-Clause >> b/LICENSES/preferred/BSD-1-Clause >> new file mode 100644 >> index ..f80acdf3b15f >> --- /dev/null >> +++ b/LICENSES/preferred/BSD-1-Clause >> @@ -0,0 +1,15 @@ >> +Valid-License-Identifier: BSD-1-Clause >> +SPDX-URL: https://spdx.org/licenses/BSD-1-Clause.html >> +Usage-Guide: >> + To use the BSD 1-clause License put the following SPDX tag/value pair >> + into a comment according to the placement guidelines in the licensing >> + rules documentation: >> +SPDX-License-Identifier: BSD-1-Clause >> +License-Text: >> + >> +Copyright (c) All rights reserved. >> + >> +Redistribution and use in source and binary forms, with or without >> modification, are permitted provided that the following conditions are met: >> + >> +1. Redistributions of source code must retain the above copyright notice, >> this list of conditions and the following disclaimer. >> +THIS SOFTWARE IS PROVIDED BY Berkeley Software Design, Inc. "AS IS" AND ANY >> EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED >> WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE >> DISCLAIMED. IN NO EVENT SHALL Berkeley Software Design, Inc. BE LIABLE FOR >> ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL >> DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR >> SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER >> CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT >> LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY >> OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH >> DAMAGE. > > I would replace "Berkeley Software Design, Inc." with "the copyright > holder" here. In the link given in the SPDX-URL field these parts are > marked as placeholders in red text, which does not transfer well over to > plain text. :) Oh forgot to change that. Thanks, will do. > > I would also hard-line-wrap the text to 80 characters to make it better > readable, but I guess that is a matter of personal preference. > > - Roland > -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
