Re: [PATCH v6 00/25] spl: Use common function for loading/parsing images

2023-11-06 Thread Marek Behún
On Mon, 6 Nov 2023 08:49:05 +0100
Pali Rohár  wrote:

> What you are doing is the worst thing in the world. You have been
> ignoring all my changes which I have been sending for one year, then you
> wrote me that I'm not competent to do any kind of programming, later you
> wrote that you would ignore all my requests and stop responding to any
> questions, then you have removed all my code from u-boot and showed me
> as the worst person in the world.

I am sorry this happened the way it did. I personally do not think that
you're not a competent programmer. On the contrary, I think that you're
a very good programmer, and that what happened has more to do with
an escalation of misunderstandings and relevant people being too busy at
unfortunate times. This naturally led to frustrations and harsh
language, which led to this unfortunate situation.

Just wanted to let you know that I am sorry about how this whole thing
played out, and that I feel partially responsible for a little bit of
it, since I also made you some promises ages ago which still are not
fulfilled :-(

I have finally managed to recruit two newbie kernel hackers into our
team. I am currently tutoring them, and one of the projects I have
in the tutoring plan is getting the work you did out into the open. It
will take some time, but my hopes are that it will be done.

Again, I am sorry. I hope you are doing well.

Marek


Re: [PATCH v6 00/25] spl: Use common function for loading/parsing images

2023-11-06 Thread Heinrich Schuchardt

On 11/5/23 23:49, Pali Rohár wrote:

What you are doing is the worst thing in the world. You have been
ignoring all my changes which I have been sending for one year, then you
wrote me that I'm not competent to do any kind of programming, later you
wrote that you would ignore all my requests and stop responding to any
questions, then you have removed all my code from u-boot and showed me
as the worst person in the world.

But seems that this is not enough for you. You have to continue
attacking on me, and making everything even worse.

WHAT YOU WANT FROM ME NOW WHY YOU ARE CONTACTING ME??? IS NOT IT
ENOUGH WHAT YOU HAVE TO ME?? Or you do think that I forgot what you have
been doing with me last years? Speak up!


I have created a patch for .mailmap to avoid sending Pali any further
"unsolicited" mail.

[PATCH 1/1] .mailmap: map Pali Rohár
https://lists.denx.de/pipermail/u-boot/2023-November/536392.html

Best regards

Heinrich


Re: [PATCH v6 00/25] spl: Use common function for loading/parsing images

2023-11-05 Thread Pali Rohár
What you are doing is the worst thing in the world. You have been
ignoring all my changes which I have been sending for one year, then you
wrote me that I'm not competent to do any kind of programming, later you
wrote that you would ignore all my requests and stop responding to any
questions, then you have removed all my code from u-boot and showed me
as the worst person in the world.

But seems that this is not enough for you. You have to continue
attacking on me, and making everything even worse.

WHAT YOU WANT FROM ME NOW WHY YOU ARE CONTACTING ME??? IS NOT IT
ENOUGH WHAT YOU HAVE TO ME?? Or you do think that I forgot what you have
been doing with me last years? Speak up!

On Sunday 05 November 2023 21:25:38 Sean Anderson wrote:
> This series adds support for loading all image types (Legacy (with and without
> LZMA), FIT (with and without LOAD_FIT_FULL), and i.MX) to the MMC, SPI, NOR,
> NET, FAT, EXT, NVMe, and semihosting load methods. It does this by 
> introducing a
> helper function which handles the minutiae of invoking the proper parsing
> function, and reading the rest of the image.
> 
> Hopefully, this will make it easier for load methods to support all image 
> types
> that U-Boot supports, without having undocumented unsupported image types. I
> applied this to several loaders which were invoking spl_load_simple_fit and/or
> spl_parse_image_header, but I did not use it with others (e.g. DFU/RAM) which
> had complications in the mix.
> 
> This series is organized roughly into two parts. Patches up to "spl: Add 
> generic
> spl_load function" are all setup or size-reduction oriented. Later patches
> generally convert various load functions to spl_load.
> 
> bloat-o-meter results (for CONFIG_SPL only) at [1]. Size growth has been the
> bigegst challenge to preparing this series. I have used every trick I can 
> think
> of to reduce bloat. Some SAMA boards no longer fit, but I have a plan to fix
> them [2].
> 
> This is bar far the largest and most-difficult revision of this series 
> to-date.
> There are probably still things which can reduce the size, but I have been
> working on this series for the better part of two months and I think it is a
> good idea to get some feedback. Because of the SAMA bloat, this series will 
> not
> pass CI, so I expect to do a v7 before this is ready to apply. Feel free,
> however, to apply patches in the first half (especially the fixes).
> 
> This version of the series is better-tested than ever before, thanks to some 
> new
> unit tests. However, things like the i.MX ROMAPI are untested. NAND should 
> also
> be tested more-widely, for reasons listed in the commit message. I encourage 
> you
> try this series out on your favorite board.
> 
> This series depends on [3]. (Almost passing) CI at [4].
> 
> [1] https://gist.github.com/Forty-Bot/5bfe88676dd3c2aec6ebc23abb08e06f
> This includes some changes to am335x_evm_spiboot and am65x_evm_r5_usbdfu
> which have since been undone.
> [2] https://lore.kernel.org/u-boot/20231105022742.632175-1-sean...@gmail.com/
> [3] https://lore.kernel.org/u-boot/20231104203753.1579217-1-sean...@gmail.com/
> [4] https://source.denx.de/u-boot/custodians/u-boot-clk/-/pipelines/18447
> 
> Changes in v6:
> - Fix uninitialized return value when we can't get a blk_desc
> - Don't close fd before spl_load_simple_fit
> - Remove NULL assignments in spl_load_info
> - Remove dev from spl_load_info
> - Take advantage of bl_len's power-of-twoness
> - Refactor spl_load_info->read to use units of bytes
> - Remove filename from spl_load_info
> - Only support bl_len when we have to
> - Remove spl_nand_legacy_read
> - Split off LZMA decompression into its own function
> - Support testing LEGACY_LZMA filesystem images
> - Use pseudo-LTO for spl_load
> - Align reads to bl_len
> - Add SYS_MMCSD_RAW_MODE to help determine whether SPL_MMC loads
>   anything directly.
> - Convert nand to spl_load
> - Fix LZMA support
> - Fix load address
> - Fix invalid return from spl_blk_load_image
> - Fix soft reset after loading from SPI
> - Explicitly initialize load_info members to reduce text size
> - Rebase on u-boot/next
> - Add option to disable DMA alignment for FAT
> 
> Changes in v5:
> - Make SHOW_ERRORS depend on LIBCOMMON
> - Load the header in spl_load as well
> - Don't bother trying to DMA-align the buffer, since we can't really fix
>   it.
> - Convert NVMe to spl_load
> 
> Changes in v4:
> - Fix format specifiers in debug prints
> - Reword/fix some of the doc comments for spl_load
> - Rebase on u-boot/master
> 
> Changes in v3:
> - Fix using ffs instead of fls
> - Fix using not initializing bl_len when info->filename was NULL
> - Fix failing on success
> 
> Changes in v2:
> - Use reverse-xmas-tree style for locals in spl_simple_read. This is not
>   complete, since overhead depends on bl_mask.
> - Convert semihosting as well
> - Consolidate spi_load_image_os into spl_spi_load_image
> 
> Sean Anderson (25):
>   spl: blk_fs: Fix uninitialized