On Wed, Dec 11, 2019 at 10:10:10AM +0100, Maik Otto wrote:
> Hi Sascha,
>
> so do you think we should always start from-dcdofs instead of full?
> at the moment i use this configuration with from-dcdofs and i think you
> have right, there is
> not really a good case to sign the area between 0x00 an
On Wed, Dec 11, 2019 at 10:53:32AM +0100, Hubert Feurstein wrote:
> Signed-off-by: Hubert Feurstein
> ---
> commands/miitool.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
Applied, thanks
Sascha
--
Pengutronix e.K. | |
Ste
On Thu, Dec 12, 2019 at 08:34:17PM +0100, Ahmad Fatoum wrote:
> If led_set fails, the error code is the return value, not errno.
> Fix this. While at replace the magic value in the command return code.
>
> Signed-off-by: Ahmad Fatoum
> ---
> commands/led.c | 4 ++--
> 1 file changed, 2 insertion
On Thu, Dec 12, 2019 at 08:24:57PM +0100, Ahmad Fatoum wrote:
> the .num member of struct led is a 'private' member populated by
> led_register. Populating it has no effect because it's always
> overwritten. Remove the assignment.
>
> Signed-off-by: Ahmad Fatoum
> ---
> drivers/led/led-pca955x.c
On Wed, Dec 11, 2019 at 09:02:43PM +0100, Roland Hieber wrote:
> Based on the downstream patch series in the WAGO PFC firmware SDK [1].
> Downstream has support for other boards too, which we leave out for now
> because no devices are available for testing. The upstream device trees
> have been use
Hello Roland,
On 12/11/19 9:02 PM, Roland Hieber wrote:
> diff --git a/arch/arm/boards/wago-pfc-am335x/ram-timings.h
> b/arch/arm/boards/wago-pfc-am335x/ram-timings.h
> new file mode 100644
> index ..cc3d518f0c27
> --- /dev/null
> +++ b/arch/arm/boards/wago-pfc-am335x/ram-timings.h
>
On Tue, Dec 10, 2019 at 03:44:52PM +0100, Hubert Feurstein wrote:
> Hi,
>
> I've updated barebox for our custom platform from v2015.06.0 to
> v2019.12.0. With the new version I have noticed a much worse write
> performance onto the onboard eMMC.
>
> With v2015.06.0 the indicated progress of the c
This implements an idea Lucas came up with: Our block layer is quite
stupid. It works on chunks from which one is currently 16KiB in size.
Whenever such a chunk is written to we must write the whole chunk which
also means we have to read it from the device first in order to keep
unaffected data. Th
discard_range() is a way to tell the lower layers that we are no longer
interested in a data range of a file, so that the lower layers can
discard the underlying data if desired.
This is mainly designed to bypass the deficiencies of our block layer.
We cache the block data in chunks of multiple Ki
This implements the discard_range hook. When a range of data is
discarded then we do not have to read it from the device and can
pass a zeroed buffer instead.
Signed-off-by: Sascha Hauer
---
common/block.c | 21 +
include/block.h | 3 +++
2 files changed, 24 insertions(+)
discard the range in the output file we are going to overwrite anyway.
Signed-off-by: Sascha Hauer
---
lib/libfile.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/lib/libfile.c b/lib/libfile.c
index 5a1817e32a..dbeed12ccd 100644
--- a/lib/libfile.c
+++ b/lib/libfile.c
@@ -367,6 +367,8 @@
To pass though discard_range() to the underlying drivers add a
discard_range hook to struct cdev_operations.
Signed-off-by: Sascha Hauer
---
fs/devfs.c | 21 +
include/driver.h | 1 +
2 files changed, 22 insertions(+)
diff --git a/fs/devfs.c b/fs/devfs.c
index d088c1a
Thanks Sascha,
I could finally program Barebox on eMMC from u-boot :)
Best,
Reyhaneh
On 12/13/19 8:55 AM, Sascha Hauer wrote:
> On Fri, Dec 13, 2019 at 07:20:15AM +, Yazdani, Reyhaneh wrote:
>> Thanks Lucas.
>>
>> So, if I have a board which has only eMMC (no SD card). What would be your
>>
13 matches
Mail list logo
