On Thu, Jan 17, 2019 at 01:10:46PM -0800, Andrey Smirnov wrote:
> On Thu, Jan 17, 2019 at 8:16 AM Ian Abbott wrote:
> >
> >
> > I'm currently using Barebox 2018.12.0, but I don't see any relevant
> > changes in Barebox 2019.01.0 or barebox-next.
> >
>
> This should be fixed by:
> http://lists.inf
On Thu, Jan 17, 2019 at 05:21:37PM +0300, Alexander Shiyan wrote:
> Signed-off-by: Alexander Shiyan
> ---
> arch/arm/boards/advantech-mx6/lowlevel.c| 3 ---
> arch/arm/boards/beaglebone/board.c | 1 -
> arch/arm/boards/karo-tx25/lowlevel.c| 1 -
> arch/arm/boards/
Maximum file size on 64-bit system is 2^63-1 (9223372036854775807),
which takes more that 14 characters of space. In order to keep things
properly aligned adjust that spacing to 20 on 64-bit platforms.
Before:
ls -l /dev/
d- 0 .
d- 0 ..
crw---
Sync up implemenations of simple_str*() functions with their kernel
counterparts in order to convert the code to use plumbing from
kstrtox.c
Signed-off-by: Andrey Smirnov
---
lib/strtox.c | 102 ---
1 file changed, 48 insertions(+), 54 deletions(-)
Drop struct data which doesn't seem to serve any purpose in the code
and looks like a leftover.
Signed-off-by: Andrey Smirnov
---
lib/unlink-recursive.c | 27 +++
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/lib/unlink-recursive.c b/lib/unlink-recursive.
Both ARM and ARM64 have identical code for
dma_sync_single_for_cpu(). Move it to mmu-common.c so it can be shared.
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cpu/mmu-common.c | 8
arch/arm/cpu/mmu.c| 7 ---
arch/arm/cpu/mmu_64.c | 7 ---
3
Now that AArch64 version is calling arch_remap_range() it is identical
to ARM version in mmu.c. Move the definition to mmu-common.c to avoid
duplication.
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cpu/mmu-common.c | 8
arch/arm/cpu/mmu.c| 8
a
In order to avoid passing random/junky values to DMA/HW as well as to
allow simplifying memory initialization in individual drivers, change
dma_alloc_coherent() to guarantee that memory it returns is properly
zeroed out.
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cpu/m
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cpu/mmu-common.h | 11 +++
arch/arm/cpu/mmu.c| 11 ---
arch/arm/cpu/mmu_64.c | 11 ---
3 files changed, 11 insertions(+), 22 deletions(-)
diff --git a/arch/arm/cpu/mmu-common.h b/arch/arm/cp
Share sanity checking code in mmu_init() as well as code to detect if
MMU is on or not on both ARM and ARM64.
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cpu/mmu-common.c | 23 +--
arch/arm/cpu/mmu-common.h | 1 +
arch/arm/cpu/mmu.c| 16 ++--
Neither ARM nor ARM64 define any address mapping functions that differ
from default provided for no-MMU configuration. Drop all the extra
code and just rely on functions provided in asm/io.h
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cpu/mmu.c| 10 --
a
Although there are known problems caused by this, it seems prudent to
invalidate the region of memory we are about remap as
uncached. Additionaliy this matches how dma_alloc_coherent() is
implemented on ARM.
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cpu/mmu_64.c | 10
Both ARM and ARM64 implement almost identical algorithms in
dma_alloc_coherent(). Move the code to mmu-common.c, so it can be
shared.
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cpu/mmu-common.c | 21 +
arch/arm/cpu/mmu-common.h | 7 +++
arch/ar
Both ARM and ARM64 define DMA mapping/unmapping functions that are
exactly the same. Introduce mmu-common.c and move the code there so it
can be shared.
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cpu/Makefile | 2 +-
arch/arm/cpu/mmu-common.c | 25
Instead of calling map_region() explicitly, call arch_regmap_range()
instead to simplify the code. This also ensures that tlb_invalidate()
gets called when dma_free_coherent() is invoked.
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cpu/mmu_64.c | 6 ++
1 file change
Simplify the use of dma_inv_range() by changing its signature to
accept pointer to start of the data and data size. This change allows
us to avoid a whole bunch of repetitive arithmetic currently done by
all of the callers.
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cp
Everyone:
This series is a result of my attempt at changing the behaviour of
dma_alloc_coherent() to guarantee that memory it returns is zeroed
out. Mostly to avoid having to do that explicitly in driver code, but
also to match behaviour that that function has in Linux. While working
on that I not
Since map_region() is never called without being followed by
tlb_invalidate(), merge it with create_sections() to simplify the
code.
Reviewed-by: Sam Ravnborg
Signed-off-by: Andrey Smirnov
---
arch/arm/cpu/mmu_64.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a
> > > + unsigned long end = start + size - 1;
> > > +
> > > + v8_flush_dcache_range(start, end);
> > > +}
> > We should use the existing indirection with struct cache_fns
> > here, then we could share the code.
>
> AArch64 used to use struct cache_fns, but that approach was decided
> again
On Thu, Jan 17, 2019 at 10:40:39PM +0100, Sam Ravnborg wrote:
> Hi Andrey.
>
> > Everyone:
> >
> > This series is a result of my attempt at changing the behaviour of
> > dma_alloc_coherent() to guarantee that memory it returns is zeroed
> > out. Mostly to avoid having to do that explicitly in dri
On Thu, Jan 17, 2019 at 01:54:46PM -0800, Andrey Smirnov wrote:
> On Thu, Jan 17, 2019 at 1:23 PM Sam Ravnborg wrote:
> >
> > Hi Andrey.
> >
> > On Wed, Jan 16, 2019 at 10:38:36PM -0800, Andrey Smirnov wrote:
> > > Both ARM and ARM64 implement almost identical algorithms in
> > > dma_alloc_coheren
Hi Andrey.
On Thu, Jan 17, 2019 at 01:50:31PM -0800, Andrey Smirnov wrote:
> On Thu, Jan 17, 2019 at 1:28 PM Sam Ravnborg wrote:
> >
> > Hi Andrey.
> >
> > On Wed, Jan 16, 2019 at 10:38:37PM -0800, Andrey Smirnov wrote:
> > > Both ARM and ARM64 have identical code for
> > > dma_sync_single_for_cp
On Thu, Jan 17, 2019 at 1:36 PM Sam Ravnborg wrote:
>
> Hi Andrey.
>
> On Wed, Jan 16, 2019 at 10:38:40PM -0800, Andrey Smirnov wrote:
> > In order to avoid passing random/junky values to DMA/HW as well as to
> > allow simplifying memory initialization in individual drivers, chagnge
> chagnge => c
On Thu, Jan 17, 2019 at 1:40 PM Sam Ravnborg wrote:
>
> Hi Andrey.
>
> > Everyone:
> >
> > This series is a result of my attempt at changing the behaviour of
> > dma_alloc_coherent() to guarantee that memory it returns is zeroed
> > out. Mostly to avoid having to do that explicitly in driver code,
On Thu, Jan 17, 2019 at 1:23 PM Sam Ravnborg wrote:
>
> Hi Andrey.
>
> On Wed, Jan 16, 2019 at 10:38:36PM -0800, Andrey Smirnov wrote:
> > Both ARM and ARM64 implement almost identical algorithms in
> > dma_alloc_coherent(). Move the code to mmu-common.c, so it can be
> > shared.
> >
> > Signed-of
On Thu, Jan 17, 2019 at 1:28 PM Sam Ravnborg wrote:
>
> Hi Andrey.
>
> On Wed, Jan 16, 2019 at 10:38:37PM -0800, Andrey Smirnov wrote:
> > Both ARM and ARM64 have identical code for
> > dma_sync_single_for_cpu(). Move it to mmu-common.c so it can be shared.
> >
> > Signed-off-by: Andrey Smirnov
>
Hi Andrey.
> Everyone:
>
> This series is a result of my attempt at changing the behaviour of
> dma_alloc_coherent() to guarantee that memory it returns is zeroed
> out. Mostly to avoid having to do that explicitly in driver code, but
> also to match behaviour that that function has in Linux. Whi
Hi Andrey.
On Wed, Jan 16, 2019 at 10:38:40PM -0800, Andrey Smirnov wrote:
> In order to avoid passing random/junky values to DMA/HW as well as to
> allow simplifying memory initialization in individual drivers, chagnge
chagnge => change
> dma_alloc_coherent() to guarantee that memory it returs i
Hi Andrey.
On Wed, Jan 16, 2019 at 10:38:37PM -0800, Andrey Smirnov wrote:
> Both ARM and ARM64 have identical code for
> dma_sync_single_for_cpu(). Move it to mmu-common.c so it can be shared.
>
> Signed-off-by: Andrey Smirnov
> ---
> arch/arm/cpu/mmu-common.c | 8
> arch/arm/cpu/mmu.
Hi Andrey.
On Wed, Jan 16, 2019 at 10:38:36PM -0800, Andrey Smirnov wrote:
> Both ARM and ARM64 implement almost identical algorithms in
> dma_alloc_coherent(). Move the code to mmu-common.c, so it can be
> shared.
>
> Signed-off-by: Andrey Smirnov
> ---
> arch/arm/cpu/mmu-common.c | 21 +++
On Thu, Jan 17, 2019 at 8:16 AM Ian Abbott wrote:
>
> Hi,
>
> All the examples of "barebox,state" compatible nodes I can find in
> Barebox seem to follow this basic pattern:
>
> / {
>/* ... */
>aliases {
> /* ... */
> state = &state;
>};
>/* ... */
>state: state {
>
On Thu, Jan 17, 2019 at 05:26:18PM +0100, Sam Ravnborg wrote:
> Hi Serapim
>
> > BTW, am I right to suppose that all functions in `obj-y` marked
> > as `initcall` and `exitcall` are invoked in the beginning and in the
> > end of barebox main code respectively?
> Enabel initcall debug - then you ca
Hi Serapim
> BTW, am I right to suppose that all functions in `obj-y` marked
> as `initcall` and `exitcall` are invoked in the beginning and in the
> end of barebox main code respectively?
Enabel initcall debug - then you can see when they are called.
It is a very usefull debug tool.
Use the .map
Hi,
All the examples of "barebox,state" compatible nodes I can find in
Barebox seem to follow this basic pattern:
/ {
/* ... */
aliases {
/* ... */
state = &state;
};
/* ... */
state: state {
magic = <0xdeadbeef>; /* or whatever */
compatible = "barebox,state";
/*
17.01.2019, 16:28, "Sascha Hauer" :
> This is what barebox does by default.
Happy ya! Thanx :)
> PBL is for PreBootLoader. Yes, it's a self extracting image. During
> building of barebox a single barebox binary and one to many PBL images
> are built. Each PBL image is for one specific board. It
Signed-off-by: Alexander Shiyan
---
arch/arm/boards/advantech-mx6/lowlevel.c| 3 ---
arch/arm/boards/beaglebone/board.c | 1 -
arch/arm/boards/karo-tx25/lowlevel.c| 1 -
arch/arm/boards/mx31moboard/lowlevel.c | 1 -
arch/arm/boards/panda/board.c
Signed-off-by: Alexander Shiyan
---
arch/arm/mach-imx/imx27.c| 1 -
arch/arm/mach-imx/imx6.c | 4
arch/arm/mach-nomadik/8815.c | 1 -
3 files changed, 6 deletions(-)
diff --git a/arch/arm/mach-imx/imx27.c b/arch/arm/mach-imx/imx27.c
index 81b9f53..1c62449 100644
--- a/arch/arm/mach-
On Thu, Jan 17, 2019 at 02:28:45PM +0100, Sascha Hauer wrote:
> On Thu, Jan 17, 2019 at 03:44:22PM +0300, Серафим Долбилов wrote:
> > Reading Barebox's source code I found that `examle.dts` (e.g.) becomes
> > `example.dtb`, then `example.dtb.o`, and is finally linked into PBL,
> > being "catched" i
On Thu, Jan 17, 2019 at 03:44:22PM +0300, Серафим Долбилов wrote:
> 17.01.2019, 10:59, "Sascha Hauer" :
> > You can have any devicetree by adding it to arch/arm/dts/Makefile:
> >
> > pbl-dtb-$(CONFIG_MACH_FREESCALE_MX51_PDK) += imx51-babbage.dtb.o
> >
> > Then add a declaration for it (replace begi
17.01.2019, 10:59, "Sascha Hauer" :
> You can have any devicetree by adding it to arch/arm/dts/Makefile:
>
> pbl-dtb-$(CONFIG_MACH_FREESCALE_MX51_PDK) += imx51-babbage.dtb.o
>
> Then add a declaration for it (replace beginning of filename with
> __dtb_, .dtb.o with _start and '-' with '_'):
>
> ext
On 1/16/19 9:30 PM, Andrey Smirnov wrote:
> On Wed, Jan 16, 2019 at 1:34 AM Lucas Stach wrote:
>>
>> Hi Reyhaneh,
>>
>> Am Mittwoch, den 16.01.2019, 08:48 + schrieb Yazdani, Reyhaneh:
>>> Every one,
>>>
>>> In order to build a Barebox image to boot imx8mq-evk with HDMI, I have
>>> tried to
Hello Sam,
On 16/1/19 19:47, Sam Ravnborg wrote:
> Hi Ahmad.
>
> On Wed, Jan 16, 2019 at 06:45:48PM +0100, Ahmad Fatoum wrote:
>> This patch series imports the necessary infrastructure out of the
>> at91bootstrap project to support first stage usage on the SAMA5.
>
> Very nice, especillay as I h
Hello,
On 17/1/19 09:25, Sascha Hauer wrote:
> On Wed, Jan 16, 2019 at 06:45:57PM +0100, Ahmad Fatoum wrote:
>> From: Ahmad Fatoum
>>
>> We are limited to 64K in the first stage, but we still need MMC and FAT
>> support, so to make place, make the device tree support optional by
>> providing the
Hello Sam,
On 16/1/19 19:24, Sam Ravnborg wrote:
> Hi Ahmad.
>
> On Wed, Jan 16, 2019 at 06:45:51PM +0100, Ahmad Fatoum wrote:
>> Only at91sam9g45_reset.S and the header itself actually use
>> any of the macros defined within.
>>
>> Instead of adding missing definitions and adapting the incoming
On 17/1/19 09:11, Sascha Hauer wrote:
> On Wed, Jan 16, 2019 at 06:45:55PM +0100, Ahmad Fatoum wrote:
>> This commit imports DDRAMC initialization routines for use in PBL from
>> https://github.com/linux4sam/at91bootstrap/blob/v3.8.12/driver/ddramc.c
>>
>> Signed-off-by: Ahmad Fatoum
>> ---
>>
On Wed, Jan 16, 2019 at 06:16:43PM -0800, Andrey Smirnov wrote:
> Everyone:
>
> This seires is a build-up on previously submitted PCI sync set [1] and
> contains the patches I created while working on adding support for
> PCIe on i.MX7. The series consists of following:
>
> - Patches adding nece
On Wed, Jan 16, 2019 at 08:45:04PM -0800, Andrey Smirnov wrote:
> Strictly speaking, open() doesn't return a detailed error code as its
> return value and it can and should be obtained via 'errno'.
>
> Signed-off-by: Andrey Smirnov
> ---
> crypto/digest.c | 2 +-
> 1 file changed, 1 insertion(+)
On Wed, Jan 16, 2019 at 12:01:52PM +0100, Sam Ravnborg wrote:
> Hi Sascha.
>
> On Wed, Jan 16, 2019 at 10:17:27AM +0100, Sascha Hauer wrote:
> > Now that we compile the compressed binary into the decompressor we
> > no longer need fix_size but can use the linker to fill in the image
> > size into
On Wed, Jan 16, 2019 at 10:29:52AM +0100, Rouven Czerwinski wrote:
> From: Uwe Kleine-König
>
> Original patch from Uwe Kleine-König, I fixed the
> review comments and the imxcfg file to use the udoo neo values.
>
> I also tested the support on the udoo neo full board.
>
> Signed-off-by: Uwe Kl
On Wed, Jan 16, 2019 at 06:45:57PM +0100, Ahmad Fatoum wrote:
> From: Ahmad Fatoum
>
> We are limited to 64K in the first stage, but we still need MMC and FAT
> support, so to make place, make the device tree support optional by
> providing the sama5d3's board code for NAND/MMC as an alternative.
Hi Lucas,
I built ATF version that is used in the NXP-UBoot-Kernel image, and compiled
Barebox with that one. But still no further process. I think it is not related
to the Trusted Firmware.
Best,
Reyhaneh
On 1/16/19 10:34 AM, Lucas Stach wrote:
> Hi Reyhaneh,
>
> Am Mittwoch, den 16.01.2019, 08
On Wed, Jan 16, 2019 at 06:45:55PM +0100, Ahmad Fatoum wrote:
> This commit imports DDRAMC initialization routines for use in PBL from
> https://github.com/linux4sam/at91bootstrap/blob/v3.8.12/driver/ddramc.c
>
> Signed-off-by: Ahmad Fatoum
> ---
> +
> +void ddram_initialize(unsigned long base_ad
On Wed, Jan 16, 2019 at 06:59:46PM +0300, Серафим Долбилов wrote:
> Is there any another way to link DT to the image besides
> imx*_barebox_entry(void *boarddata) functions?
You can have any devicetree by adding it to arch/arm/dts/Makefile:
pbl-dtb-$(CONFIG_MACH_FREESCALE_MX51_PDK) += imx51-babb
53 matches
Mail list logo
