Bug#1063380: ITP: libuio -- Linux Kernel UserspaceIO helper library

[Traut Manuel LCPF-CH]

> On Thu, Mar 07, 2024 at 05:02:29PM +0200, Peter Pentchev wrote:
>> On Thu, Mar 07, 2024 at 03:25:01PM +0100, Manuel Traut wrote:
>>> On 7 Feb 2024, at 18:27, Dima Kogan  wrote:
>>>
>>> Hi. Thanks for your contribution. I looked at the upstream code a tiny
>>> bit, and it looks like it might have portability bug, at least on
>>> big-endian architectures. For instance:
>>>
>>> https://github.com/missinglinkelectronics/libuio/blob/6ef3d8d096a641686bfdd112035aa04aa16fe81a/irq.c#L78
>>>
>>> This assumes that sizeof(long)==4. Maybe this is benign, but it would be
>>> nice to fix. Are you upstream or do you know upstream? Can yall fix
>>> these?
>>>
>> The kernel expects a 4 byte write here, since unsigned long is defined as at 
>> least 32 bit this shall work on all architectures.
>>
>> If your concern is about endianess this is not in the current scope of 
>> libuio and needs to be addressed by a higher layer.
>>
>> I am very familiar with library and in close contact with upstream.
>>
> In the case of uio_disable_irq() the bug is nicely hidden by the fact
> that tmp is guaranteed to be all-zeroes. However, consider the previous
> function in the file, uio_enable_irq(). If sizeof(unsigned long) == 8,
> then the "tmp" variable's value of 1 will be encoded in memory as
> 8 bytes containing the values 0, 0, 0, 0, 0, 0, 0, and 1 respectively.
> When uio_enable_irq() calls write(..., , 4), it will only send
> the first four bytes to the kernel - and they are 0, 0, 0, and... 0.
> So it turns out that uio_disable_irq() and uio_enable_irq() do
> exactly the same - send a 32-bit zero value to the kernel.
>
> ...of course, this will only happen on a big-endian system, as
> Dima Kogan was concerned about. On a little-endian system, this
> will work by chance.
>
> Is this the expected behavior indeed?

No it is not :) Thanks for the detailed explanation.

Looks this fix sane to you?
https://github.com/manut/libuio/commit/1edcf262fbfaf0b7f8519875ed5b357964dd1e55

I am not sure if users also expect an automatic conversion for the read/write 
functions:
https://github.com/manut/libuio/commit/d0319169359bffc73374f1011e942702e9bafb1e

It will be somehow inconsistent since a user could also access the device 
memory by pointer:
https://github.com/manut/libuio/blob/add-ci/mem.c#L93
and than needs to take care on the endianess by its own anyway.

Bug#801822: Proposal for a fix

[Traut Manuel LCPF-CH]

Hi,

I am not sure if I understood everything properly.

I tried to fix this bug with this MR:
Support template units (!23) * Merge requests * Debian / init-system-helpers * 
GitLab

Would be nice if someone with a better understanding of deb-systemd-helper 
could have a look.

Thanks
Manuel

Bug#1035055: AW: EXTERNAL - Bug#1035055: ITP: firmware-imx -- Firmware binary blobs needed on NXP i.MX platforms

[Traut Manuel LCPF-CH]

Hi Josch,

>>Quoting Manuel Traut (2023-04-28 14:59:50)
>> * Package name: firmware-imx
>>   Version : 8.19
>>   Upstream Contact: NXP
>> * URL : https://www.nxp.com/
>> * License : LA_OPT_NXP_Software_License_v42
>>   Description : Firmware binary blobs needed on NXP i.MX platforms
>> 
>> i.MX Firmware including firmware for VPU, DDR, EPDC, HDMI, DP (Display 
>> Port), and SDMA
>> 
>> To build a working u-boot for i.MX8* at least the DDR train binaries 
>> from NXP are needed.
>> 
>> More details are available in this document:
>> https://www.nxp.com/docs/en/release-note/IMX_LINUX_RELEASE_NOTES.pdf
>> 
>> The package shall provide the files from firmware-imx-8.19.bin:
>
>thank you for intending to package this!
>
>Do you also have some packaging done that we could test? We need these blobs 
>to build working u-boot binaries.

The current version can be found here:
https://salsa.debian.org/manut/firmware-imx/

I also need it for adding imx8mm support to u-boot. On which target are you 
working?

>Do you plan to upload this to non-free-firmware?

Yes, but did not so far.
Currently the .bin is part of the debian git. Did not find a way to write a 
valid watch file for a webpage that denies indexing.

Any help on the package is welcome - even uploading it, since I am no DD.

Thanks
Manu

Bug#1016019:

[Traut Manuel LCPF-CH]

Started to work on creating a Debian package:
https://salsa.debian.org/manut/libusbgx/