[PATCH] mx6cuboxi: Convert to watchdog driver model
Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused
the 'reset' command in U-Boot to not cause a board reset.
Fix it by switching to the watchdog driver model via sysreset, which
is the preferred method for implementing the watchdog reset.
Signed-off-by: Fabio Estevam
---
Christian,
Can you test this, please?
.../dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi | 10 ++
configs/mx6cuboxi_defconfig| 3 +++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
index 23a05773b579..e9b188ed6587 100644
--- a/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
+++ b/arch/arm/dts/imx6qdl-hummingboard2-emmc-som-v15-u-boot.dtsi
@@ -13,6 +13,12 @@
4 0
>;
};
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ bootph-pre-ram;
+ };
};
{
@@ -58,3 +64,7 @@
{
bootph-all;
};
+
+ {
+ bootph-pre-ram;
+};
diff --git a/configs/mx6cuboxi_defconfig b/configs/mx6cuboxi_defconfig
index 66d4aaeda2d9..27ceb22599a6 100644
--- a/configs/mx6cuboxi_defconfig
+++ b/configs/mx6cuboxi_defconfig
@@ -71,6 +71,8 @@ CONFIG_DM_REGULATOR=y
CONFIG_DM_REGULATOR_FIXED=y
CONFIG_DM_SERIAL=y
CONFIG_MXC_UART=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
CONFIG_DM_THERMAL=y
CONFIG_IMX_THERMAL=y
CONFIG_USB=y
@@ -89,3 +91,4 @@ CONFIG_IMX_HDMI=y
CONFIG_SPLASH_SCREEN=y
CONFIG_SPLASH_SCREEN_ALIGN=y
CONFIG_BMP_16BPP=y
+CONFIG_IMX_WATCHDOG=y
--
2.34.1
Re: [PATCH 5/6] Makefile: tune the include order
Peng, On Wed, Mar 27, 2024 at 11:07 AM Sumit Garg wrote: > That's the real reason why we should try to migrate to OF_UPSTREAM at > SoC level rather than at board level. If a particular board isn't > supported upstream then they can opt out for the time being. All the imx93 boards in U-Boot are supported by the upstream kernel, so, yes, please migrate all of them to OF_UPSTREAM.
[PATCH] warp7: Convert to watchdog driver model
Commit 68dcbdd594d4 ("ARM: imx: Add weak default reset_cpu()") caused
the 'reset' command in U-Boot to not cause a board reset.
Fix it by switching to the watchdog driver model via sysreset, which
is the preferred method for implementing the watchdog reset.
Signed-off-by: Fabio Estevam
---
arch/arm/dts/imx7s-warp-u-boot.dtsi | 10 ++
configs/warp7_defconfig | 3 +++
2 files changed, 13 insertions(+)
diff --git a/arch/arm/dts/imx7s-warp-u-boot.dtsi
b/arch/arm/dts/imx7s-warp-u-boot.dtsi
index 4f44598c9a27..98784fd7a2ef 100644
--- a/arch/arm/dts/imx7s-warp-u-boot.dtsi
+++ b/arch/arm/dts/imx7s-warp-u-boot.dtsi
@@ -7,6 +7,12 @@
chosen {
stdout-path =
};
+
+ wdt-reboot {
+ compatible = "wdt-reboot";
+ wdt = <>;
+ bootph-pre-ram;
+ };
};
{
@@ -24,3 +30,7 @@
{
bootph-all;
};
+
+ {
+ bootph-pre-ram;
+};
diff --git a/configs/warp7_defconfig b/configs/warp7_defconfig
index 9b518a121be6..48042b702c22 100644
--- a/configs/warp7_defconfig
+++ b/configs/warp7_defconfig
@@ -67,6 +67,8 @@ CONFIG_DM_REGULATOR_GPIO=y
CONFIG_SPECIFY_CONSOLE_INDEX=y
CONFIG_DM_SERIAL=y
CONFIG_MXC_UART=y
+CONFIG_SYSRESET=y
+CONFIG_SYSRESET_WATCHDOG=y
CONFIG_IMX_THERMAL=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
@@ -80,5 +82,6 @@ CONFIG_USB_GADGET_DOWNLOAD=y
CONFIG_USB_ETHER=y
CONFIG_USB_ETH_CDC=y
CONFIG_USBNET_HOST_ADDR="de:ad:be:af:00:00"
+CONFIG_IMX_WATCHDOG=y
CONFIG_OPTEE_TZDRAM_SIZE=0x300
CONFIG_BOOTM_OPTEE=y
--
2.34.1
Re: mx6cuboxi: failes to detect model
Hi Christian, On Wed, Mar 27, 2024 at 3:54 AM Christian Gmeiner wrote: > It does help \o/ Ok, great! > When you send out a proper patch feel free to add Tested-by: Christian > Gmeiner I have sent a more complete fix, so I have not included your Tested-by. Please test the formal version and reply with your Tested-by tag. > Time to look into the next broken thing on the device: network :) If you still have issues with Ethernet, please share the details on a new thread.
[PATCH] mx6cuboxi: Fix board revision detection
Currently, an i.MX6 Cuboxi board is incorrectly detected
as the HummingBoard model:
U-Boot 2024.04-rc5 (Mar 26 2024 - 15:59:22 +0100)
CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 26C
Reset cause: POR
Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc)
gpio@20a4000: set_dir_flags: error: gpio GPIO3_8 not reserved
gpio@20a4000: get_value: error: gpio GPIO3_8 not reserved
gpio@20a8000: set_dir_flags: error: gpio GPIO4_4 not reserved
gpio@20a8000: get_value: error: gpio GPIO4_4 not reserved
gpio@20b: set_dir_flags: error: gpio GPIO6_9 not reserved
gpio@20b: get_value: error: gpio GPIO6_9 not reserved
Board: MX6 HummingBoard
DRAM: 2 GiB
...
This error happens because request_detect_gpios() uses the GPIO DM
API, but board_type() still uses the legacy non-DM GPIO API.
Fix it by using the GPIO DM API in board_type() to read the
board revision pins in SPL.
Reported-by: Christian Gmeiner
Signed-off-by: Fabio Estevam
---
board/solidrun/mx6cuboxi/mx6cuboxi.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/board/solidrun/mx6cuboxi/mx6cuboxi.c
b/board/solidrun/mx6cuboxi/mx6cuboxi.c
index 8edabf4404c2..7fe515f928a0 100644
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -336,20 +336,17 @@ static enum board_type board_type(void)
* HB 1 1x
*/
- gpio_direction_input(IMX_GPIO_NR(2, 8));
- val3 = gpio_get_value(IMX_GPIO_NR(2, 8));
+ val3 = !!dm_gpio_get_value(_detect_desc[0]);
if (val3 == 0)
return HUMMINGBOARD2;
- gpio_direction_input(IMX_GPIO_NR(3, 4));
- val2 = gpio_get_value(IMX_GPIO_NR(3, 4));
+ val2 = !!dm_gpio_get_value(_detect_desc[1]);
if (val2 == 0)
return HUMMINGBOARD;
- gpio_direction_input(IMX_GPIO_NR(4, 9));
- val1 = gpio_get_value(IMX_GPIO_NR(4, 9));
+ val1 = !!dm_gpio_get_value(_detect_desc[2]);
if (val1 == 0) {
return CUBOXI;
@@ -363,8 +360,8 @@ static bool is_rev_15_som(void)
int val1, val2;
SETUP_IOMUX_PADS(som_rev_detect);
- val1 = gpio_get_value(IMX_GPIO_NR(6, 0));
- val2 = gpio_get_value(IMX_GPIO_NR(6, 4));
+ val1 = !!dm_gpio_get_value(_detect_desc[3]);
+ val2 = !!dm_gpio_get_value(_detect_desc[4]);
if (val1 == 1 && val2 == 0)
return true;
--
2.34.1
Bug#1057386: ITP: imsprog -- linux chip programmer for CH341a devices
On Tue, 26 Mar 2024 19:48:13 +0100 Carsten Schoenert wrote: > Hello Mikhail, > > Am 26.03.24 um 08:37 schrieb Kosolapov Ivan: > > Hello, Carsten! > > I have built a new version of IMSProg (v1.3.3). > > Can you please tell me how I can get this version to you? Do I have to > > upload the new version on mentors.debian or do you get it from GitHub? > > I pulled the git tree from GitHub and build the package from that source. > > I can build an updated version from the same tree again. > The current entries in debian/latest looking an bit odd and chaotic. > > > Can you rebase the last tree commits into one and keep at lest the > following lines in the changelog? (Once the package is within the > archive of course such rebasing should not happen anymore. Have a look > into existing changelog entries from other files for examples how to > write the entries.) > > * New upstream release 1.3.3 > * Initial release (Closes: #1057386) > > The last entry is needed with every new upstream version that is getting > uploaded for automatic closing the ITP bug report if the FTP master Hi, about rebase of latest tree commits into one I also think can be good, about d/changelog entries instead I'm not sure what you mean. I suggested it here: https://github.com/bigbigmdm/IMSProg/commit/21f8b17153bba0472c68f14d0382f3d3d50aa0a6#commitcomment-140195336 Because I saw all initial packages in NEW that have uploaded multiple versions have new entry like to be treated as if they were already uploaded into the repository, or are they wrong? (I supposed are correct as are all DDs to upload) Anyway I'm not completely sure about this since all the packages I added I always made further uploads only after they were accepted by ftp-master OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1057386: ITP: imsprog -- linux chip programmer for CH341a devices
On Tue, 26 Mar 2024 19:48:13 +0100 Carsten Schoenert wrote: > Hello Mikhail, > > Am 26.03.24 um 08:37 schrieb Kosolapov Ivan: > > Hello, Carsten! > > I have built a new version of IMSProg (v1.3.3). > > Can you please tell me how I can get this version to you? Do I have to > > upload the new version on mentors.debian or do you get it from GitHub? > > I pulled the git tree from GitHub and build the package from that source. > > I can build an updated version from the same tree again. > The current entries in debian/latest looking an bit odd and chaotic. > > > Can you rebase the last tree commits into one and keep at lest the > following lines in the changelog? (Once the package is within the > archive of course such rebasing should not happen anymore. Have a look > into existing changelog entries from other files for examples how to > write the entries.) > > * New upstream release 1.3.3 > * Initial release (Closes: #1057386) > > The last entry is needed with every new upstream version that is getting > uploaded for automatic closing the ITP bug report if the FTP master Hi, about rebase of latest tree commits into one I also think can be good, about d/changelog entries instead I'm not sure what you mean. I suggested it here: https://github.com/bigbigmdm/IMSProg/commit/21f8b17153bba0472c68f14d0382f3d3d50aa0a6#commitcomment-140195336 Because I saw all initial packages in NEW that have uploaded multiple versions have new entry like to be treated as if they were already uploaded into the repository, or are they wrong? (I supposed are correct as are all DDs to upload) Anyway I'm not completely sure about this since all the packages I added I always made further uploads only after they were accepted by ftp-master OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH] arm: imx: fix signature_block_hdr struct fields order
Hi Javier, On Tue, Mar 26, 2024 at 8:07 AM Javier Viguera wrote: > > According to the documentation (for example AN13994), for AHAB-enabled > devices the format of the signature block is: > > +--+--+--+-+ > | Tag | Length - msb | Length - lsb | Version | > +--+--+--+-+ > | SRK Table offset| Certificate offset | > +-++ > | Blob offset | Signature offset | > +-++ Could you elaborate more about this and share more details? Have you seen a run-time error or did you catch it by code inspection? Please clarify. Thanks
Re: [PATCH 5/7] arm64: imx: imx8mm-beacon: Migrate to OF_UPSTREAM
Hi Adam, On Tue, Mar 26, 2024 at 5:25 PM Adam Ford wrote: > > The imx8mm-beacon boards can migrate to OF_UPSTREAM which also > allows for the removal the device tree files. > > Signed-off-by: Adam Ford Please split the series by SoC family, thanks.
Re: [PATCH v3 2/3] imx: imx93_evk: add rtc pcf2131
On Tue, Mar 26, 2024 at 12:30 AM Joy Zou wrote:
> + {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + clock-frequency = <40>;
> + pinctrl-names = "default", "sleep";
> + pinctrl-0 = <_lpi2c3>;
> + pinctrl-1 = <_lpi2c3>;
> + status = "okay";
> +
> + pcf2131: rtc@53 {
> + compatible = "nxp,pcf2131";
> + reg = <0x53>;
> + interrupt-parent = <>;
> + interrupts = <1 IRQ_TYPE_LEVEL_LOW>;
> + status = "okay";
Please submit the RTC support to Linux first, then you can sync the
devicetree with Linux in U-Boot.
In the meantime, you can add the RTC support to the -u-boot.dtsi.
Please consider using OF_UPSTREAM available in the U-Boot next branch.
Re: [PATCH v3 3/3] configs: Enable RTC pcf2131 support
On Tue, Mar 26, 2024 at 12:30 AM Joy Zou wrote: > > Enable CONFIG_RTC_PCF2127 configs to support pcf2131. Subject should be imx93_11x11_evk specific: imx93_11x11_evk: Add PCF2131 RTC support
Re: [PATCH v3 1/3] drivers: rtc: add pcf2131 rtc driver
On Tue, Mar 26, 2024 at 12:30 AM Joy Zou wrote:
> +bool is_pcf2131_type(struct udevice *dev)
static bool
> static int pcf2127_rtc_read(struct udevice *dev, uint offset, u8 *buffer,
> uint len)
> {
> struct dm_i2c_chip *chip = dev_get_parent_plat(dev);
> @@ -43,10 +75,64 @@ static int pcf2127_rtc_read(struct udevice *dev, uint
> offset, u8 *buffer, uint l
> return dm_i2c_xfer(dev, , 1);
> }
>
> +static int pcf2131_rtc_lock(struct udevice *dev)
> +{
> + int ret = 0;
No need to initialize ret with 0.
> +static int pcf2131_rtc_unlock(struct udevice *dev)
> +{
> + int ret = 0;
Ditto.
> static int pcf2127_rtc_write(struct udevice *dev, uint offset,
> const u8 *buffer, uint len)
> {
> - return dm_i2c_write(dev, offset, buffer, len);
> + int ret = 0;
Ditto.
Re: mx6cuboxi: failes to detect model
On Tue, Mar 26, 2024 at 1:11 PM Christian Gmeiner
wrote:
> It got better but the model is (still) wrong:
>
> U-Boot 2024.04-rc5-dirty (Mar 26 2024 - 17:03:41 +0100)
>
> CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz)
> CPU: Extended Commercial temperature grade (-20C to 105C) at 20C
> Reset cause: POR
> Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc)
> Board: MX6 HummingBoard2
> DRAM: 2 GiB
> Core: 82 devices, 17 uclasses, devicetree: fit
> MMC: FSL_SDHC: 1, FSL_SDHC: 2
> Loading Environment from MMC... *** Warning - bad CRC, using default
> environment
It seems to me that there is a mix of DM GPIO and non-DM GPIO.
Does the change below help?
--- a/board/solidrun/mx6cuboxi/mx6cuboxi.c
+++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c
@@ -336,20 +336,16 @@ static enum board_type board_type(void)
* HB 1 1x
*/
- gpio_direction_input(IMX_GPIO_NR(2, 8));
- val3 = gpio_get_value(IMX_GPIO_NR(2, 8));
+ val3 = !!dm_gpio_get_value(&(board_detect_desc[0]));
if (val3 == 0)
return HUMMINGBOARD2;
- gpio_direction_input(IMX_GPIO_NR(3, 4));
- val2 = gpio_get_value(IMX_GPIO_NR(3, 4));
+ val2 = !!dm_gpio_get_value(&(board_detect_desc[1]));
if (val2 == 0)
return HUMMINGBOARD;
-
- gpio_direction_input(IMX_GPIO_NR(4, 9));
- val1 = gpio_get_value(IMX_GPIO_NR(4, 9));
+ val1 = !!dm_gpio_get_value(&(board_detect_desc[2]));
if (val1 == 0) {
return CUBOXI;
Re: mx6cuboxi: failes to detect model
Hi Christian, On Tue, Mar 26, 2024 at 12:17 PM Christian Gmeiner wrote: > > I am seeing model detection problems with the current git master. > > U-Boot 2024.04-rc5 (Mar 26 2024 - 15:59:22 +0100) > > CPU: Freescale i.MX6Q rev1.3 996 MHz (running at 792 MHz) > CPU: Extended Commercial temperature grade (-20C to 105C) at 26C > Reset cause: POR > Model: SolidRun HummingBoard2 Dual/Quad (1.5som+emmc) > gpio@20a4000: set_dir_flags: error: gpio GPIO3_8 not reserved > gpio@20a4000: get_value: error: gpio GPIO3_8 not reserved > gpio@20a8000: set_dir_flags: error: gpio GPIO4_4 not reserved > gpio@20a8000: get_value: error: gpio GPIO4_4 not reserved > gpio@20b: set_dir_flags: error: gpio GPIO6_9 not reserved > gpio@20b: get_value: error: gpio GPIO6_9 not reserved > Board: MX6 HummingBoard Unfortunately, my mx6cuboxi no longer works, so I can't test it myself. I am adding Baruch on Cc. Hopefully, Baruch or Josua can take a look. The 'not reserved' errors may be caused by the lack of gpio_request(). Do the changes below help? --- a/board/solidrun/mx6cuboxi/mx6cuboxi.c +++ b/board/solidrun/mx6cuboxi/mx6cuboxi.c @@ -336,18 +336,21 @@ static enum board_type board_type(void) * HB 1 1x */ + gpio_request(IMX_GPIO_NR(2, 8), "val3"); gpio_direction_input(IMX_GPIO_NR(2, 8)); val3 = gpio_get_value(IMX_GPIO_NR(2, 8)); if (val3 == 0) return HUMMINGBOARD2; + gpio_request(IMX_GPIO_NR(3, 4), "val2"); gpio_direction_input(IMX_GPIO_NR(3, 4)); val2 = gpio_get_value(IMX_GPIO_NR(3, 4)); if (val2 == 0) return HUMMINGBOARD; + gpio_request(IMX_GPIO_NR(4, 9), "val1"); gpio_direction_input(IMX_GPIO_NR(4, 9)); val1 = gpio_get_value(IMX_GPIO_NR(4, 9)); > DRAM: 2 GiB > Core: 82 devices, 17 uclasses, devicetree: fit > MMC: FSL_SDHC: 1, FSL_SDHC: 2 > Loading Environment from MMC... *** Warning - bad CRC, using default > environment > > In:serial > Out: serial > Err: serial > Net: eth0: ethernet@2188000 > > > I did a git bisect to find the commit that broke model detection: > > # good: [4459ed60cb1e0562bc5b40405e2b4b9bbf766d57] Prepare v2023.10 > git bisect good 4459ed60cb1e0562bc5b40405e2b4b9bbf766d57 > # bad: [873791433602281ed230486606e326983c97a285] Merge > https://source.denx.de/u-boot/custodians/u-boot-riscv > git bisect bad 873791433602281ed230486606e326983c97a285 > # bad: [6e0a75d3162a024cb0cdedd871d435e6ee782447] configs: Resync with > savedefconfig > git bisect bad 6e0a75d3162a024cb0cdedd871d435e6ee782447 > # good: [99b46477e3495f819f6826d11470d46f12a4f9f7] clk: Dont return > error when assigned-clocks is empty or missing > git bisect good 99b46477e3495f819f6826d11470d46f12a4f9f7 > # bad: [50fa67d091b6ffbc1d77d3100d7b31795bf64928] arm: mach-k3: > j721e_init: Move clk_k3 probe before loading TIFS > git bisect bad 50fa67d091b6ffbc1d77d3100d7b31795bf64928 > # bad: [827cece3aa550d41e9c08c640b3a73372c8fb14a] pinctrl: renesas: > Synchronize R8A77980 V3H PFC tables with Linux 6.5.3 > git bisect bad 827cece3aa550d41e9c08c640b3a73372c8fb14a > # good: [623b3e8f9718a1fbd612b3e42451859e9f98a947] x86: spl: Change > the condition for copying U-Boot to RAM > git bisect good 623b3e8f9718a1fbd612b3e42451859e9f98a947 > # good: [ad57b98e212bd15492398cea3a8d4df6297e16fd] x86: doc: Split out > manual booting into its own file > git bisect good ad57b98e212bd15492398cea3a8d4df6297e16fd > # bad: [6d53b50888315252cdd3251551add7a9108a1300] ARM: renesas: Enable > DM_ETH_PHY on 64-bit R-Car boards > git bisect bad 6d53b50888315252cdd3251551add7a9108a1300 > # bad: [283dcb63cb7d124fa427938f39aa9362872e02fc] buildman: Show > progress when regenerating the board.cfg file > git bisect bad 283dcb63cb7d124fa427938f39aa9362872e02fc > # bad: [9e644284ab812f2db23f6185af77c0e771b0be73] dm: core: Report > bootph-pre-ram/sram node as pre-reloc after relocation > git bisect bad 9e644284ab812f2db23f6185af77c0e771b0be73 > # good: [b05a184379631d13c4a49e423aa1324dc1ae6158] Merge tag > 'x86-pull-20230922' of > https://source.denx.de/u-boot/custodians/u-boot-x86 into next > git bisect good b05a184379631d13c4a49e423aa1324dc1ae6158 > # first bad commit: [9e644284ab812f2db23f6185af77c0e771b0be73] dm: > core: Report bootph-pre-ram/sram node as pre-reloc after relocation > > If I revert 9e644284ab812f2db23f6185af77c0e771b0be73 on top of git > master everything is fine again. As I am not an export in that area I > am seeking > some directions on how to fix this issue. > > -- > greets > -- > Christian Gmeiner, MSc > > https://christian-gmeiner.info/privacypolicy
Re: U-boot fails for khadas-edge -v
Hi Vivek, [Please don't top-post and do not post HTML] On Mon, Mar 25, 2024 at 1:37 PM Vivek Jaiswal wrote: > > Hello Fabio, > I tried using the this github repository. > https://github.com/u-boot/u-boot.git > > And the configuration used was following > > rockchip-rk3399-khadas-edge-v.conf > > UBOOT_MACHINE = "khadas-edge-v-rk3399_defconfig" > > I got some error during the build from the u-boot. > > Please check the attachment BuildError1.txt or BuildError2.txt > > make[2]: *** > [/home/vjaiswal/dev/Projects/SOLAR/khadas-dev/forTesting/yocto2_actual_meta_rockchip/build/tmp/work/rockchip_rk3399_khadas_edge_v-poky-linux/u-boot-rockchip/1_2017.09-r0/git/scripts/Makefile.build:280: > cmd/bootm.o] Error 1 > make[1]: *** > [/home/vjaiswal/dev/Projects/SOLAR/khadas-dev/forTesting/yocto2_actual_meta_rockchip/build/tmp/work/rockchip_rk3399_khadas_edge_v-poky-linux/u-boot-rockchip/1_2017.09-r0/git/Makefile:1317: > cmd] Error 2 > make: *** [Makefile:157: sub-make] Error 2 You are trying to build U-Boot 2017.09. U-Boot 2024.01 builds khadas-edge-v-rk3399_defconfig just fine.
[PATCH] imx8: Add a default reset_cpu() implementation
From: Fabio Estevam
Add a weak default reset_cpu() implementation just like
it is done on arch/arm/mach-imx/cpu.c.
This allows the removal of the empty reset_cpu() in several
board files.
Signed-off-by: Fabio Estevam
---
arch/arm/mach-imx/imx8/cpu.c | 4
board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c | 11 ---
board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c | 8
board/congatec/cgtqmx8/cgtqmx8.c | 7 ---
board/freescale/imx8qm_mek/imx8qm_mek.c | 8
board/freescale/imx8qxp_mek/imx8qxp_mek.c | 8
board/toradex/apalis-imx8/apalis-imx8.c | 8
board/toradex/colibri-imx8x/colibri-imx8x.c | 8
8 files changed, 4 insertions(+), 58 deletions(-)
diff --git a/arch/arm/mach-imx/imx8/cpu.c b/arch/arm/mach-imx/imx8/cpu.c
index 0b91e448a5d..6e643188f40 100644
--- a/arch/arm/mach-imx/imx8/cpu.c
+++ b/arch/arm/mach-imx/imx8/cpu.c
@@ -84,6 +84,10 @@ static char *get_reset_cause(void)
}
}
+__weak void reset_cpu(void)
+{
+}
+
int arch_cpu_init(void)
{
#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_RECOVER_DATA_SECTION)
diff --git a/board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c
b/board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c
index 8b4d73052eb..56b7bdb57c9 100644
--- a/board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c
+++ b/board/advantech/imx8qm_dmsse20_a1/imx8qm_dmsse20_a1.c
@@ -136,17 +136,6 @@ void detail_board_ddr_info(void)
puts("\nDDR");
}
-/*
- * Board specific reset that is system reset.
- */
-void reset_cpu(void)
-{
- puts("SCI reboot request");
-
- while (1)
- putc('.');
-}
-
#ifdef CONFIG_OF_BOARD_SETUP
int ft_board_setup(void *blob, struct bd_info *bd)
{
diff --git a/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
b/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
index 206ce7d5c13..7f766a688bb 100644
--- a/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
+++ b/board/advantech/imx8qm_rom7720_a1/imx8qm_rom7720_a1.c
@@ -112,14 +112,6 @@ int board_init(void)
return 0;
}
-/*
- * Board specific reset that is system reset.
- */
-void reset_cpu(void)
-{
- /* TODO */
-}
-
int board_mmc_get_env_dev(int devno)
{
return devno;
diff --git a/board/congatec/cgtqmx8/cgtqmx8.c b/board/congatec/cgtqmx8/cgtqmx8.c
index 26189ff66f5..3b01354bb6b 100644
--- a/board/congatec/cgtqmx8/cgtqmx8.c
+++ b/board/congatec/cgtqmx8/cgtqmx8.c
@@ -371,13 +371,6 @@ void detail_board_ddr_info(void)
puts("\nDDR");
}
-/*
- * Board specific reset that is system reset.
- */
-void reset_cpu(void)
-{
- /* TODO */
-}
#ifdef CONFIG_OF_BOARD_SETUP
int ft_board_setup(void *blob, struct bd_info *bd)
diff --git a/board/freescale/imx8qm_mek/imx8qm_mek.c
b/board/freescale/imx8qm_mek/imx8qm_mek.c
index d96d1d07bb1..2b209c8886f 100644
--- a/board/freescale/imx8qm_mek/imx8qm_mek.c
+++ b/board/freescale/imx8qm_mek/imx8qm_mek.c
@@ -102,14 +102,6 @@ int board_init(void)
return 0;
}
-/*
- * Board specific reset that is system reset.
- */
-void reset_cpu(void)
-{
- /* TODO */
-}
-
#ifdef CONFIG_OF_BOARD_SETUP
int ft_board_setup(void *blob, struct bd_info *bd)
{
diff --git a/board/freescale/imx8qxp_mek/imx8qxp_mek.c
b/board/freescale/imx8qxp_mek/imx8qxp_mek.c
index 516cefd2f24..833bee55462 100644
--- a/board/freescale/imx8qxp_mek/imx8qxp_mek.c
+++ b/board/freescale/imx8qxp_mek/imx8qxp_mek.c
@@ -126,14 +126,6 @@ int board_init(void)
return 0;
}
-/*
- * Board specific reset that is system reset.
- */
-void reset_cpu(void)
-{
- /* TODO */
-}
-
#ifdef CONFIG_OF_BOARD_SETUP
int ft_board_setup(void *blob, struct bd_info *bd)
{
diff --git a/board/toradex/apalis-imx8/apalis-imx8.c
b/board/toradex/apalis-imx8/apalis-imx8.c
index 49719f2f553..0f993e644d7 100644
--- a/board/toradex/apalis-imx8/apalis-imx8.c
+++ b/board/toradex/apalis-imx8/apalis-imx8.c
@@ -291,14 +291,6 @@ int board_init(void)
return 0;
}
-/*
- * Board specific reset that is system reset.
- */
-void reset_cpu(void)
-{
- /* TODO */
-}
-
#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
int ft_board_setup(void *blob, struct bd_info *bd)
{
diff --git a/board/toradex/colibri-imx8x/colibri-imx8x.c
b/board/toradex/colibri-imx8x/colibri-imx8x.c
index 6fc8076163c..a507d666c07 100644
--- a/board/toradex/colibri-imx8x/colibri-imx8x.c
+++ b/board/toradex/colibri-imx8x/colibri-imx8x.c
@@ -140,14 +140,6 @@ int board_init(void)
return 0;
}
-/*
- * Board specific reset that is system reset.
- */
-void reset_cpu(void)
-{
- /* TODO */
-}
-
#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
int ft_board_setup(void *blob, struct bd_info *bd)
{
--
2.34.1
Re: [PATCH 00/12] arm: xea: Provide support for different XEA board HW versions
Hi Lukasz,
On Mon, Mar 25, 2024 at 5:48 AM Lukasz Majewski wrote:
> The case here is that I'm modifying the *-u-boot.dts{i} files only. In
The diff below shows that you are creating imx28-xea-1.dts and imx28-xea-2.dts
for U-Boot consumption and renaming the upstream imx28-xea.dts to imx28-xea.dts.
create mode 100644 arch/arm/dts/imx28-xea-1.dts
create mode 100644 arch/arm/dts/imx28-xea-2-u-boot.dtsi
create mode 100644 arch/arm/dts/imx28-xea-2.dts
rename arch/arm/dts/{imx28-xea.dts => imx28-xea.dtsi} (100%)
> other words, u-boot will not support features described in Linux DTS.
That's OK and this happens frequently.
For example, upstream devicetree may describes audio codec,
but U-Boot does not support audio playback.
Devicetree should be OS agnostic.
In U-Boot, we want to re-use the upstream Linux devicetree files 'as-is'.
Adding -u-boot.dtsi files is OK though.
Can you convert the imx28-xea board to OF_UPSTREAM available in the
U-Boot next branch?
> Hence, the rename of files (which would be in sync with Linux at some
> point) looks like not related to Linux DTS (as even after re-sync with
> upstream Linux those changes will not be in Linux DTS).
I did not understand this part, do you mean that Linux will also do the
imx28-xea.dts => imx28-xea.dtsi rename and will also have the new
imx28-xea-1.dts and imx28-xea-2.dts?
Regards,
Fabio Estevam
Bug#1067733: iptables: regression in 1.8.9 with -n breaks portblock in resource-agents
> Version 1.8.10 fixed this bug (see "udp" and "tcp" in "prot") in > https://git.netfilter.org/iptables/commit/?id=34f085b1607364f4eaded1140060dcaf965a2649 iptables 1.8.10 was released on 2023-10-10, but this commit was merged in 2024-02-07, so it is not fixed in 1.8.10, but it will be in the release after that.
Bug#1066711: marked as pending in freeipmi
Control: tag -1 pending Hello, Bug #1066711 in freeipmi reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/debian/freeipmi/-/commit/ce43a274e237f9ef690d25c4fbd58fbc2724c867 update changelog Closes: #1066711 (this message was generated automatically) -- Greetings https://bugs.debian.org/1066711
Re: 'static-networking' fails to start
On Mon, 2024-03-25 at 20:12 +0200, Roman Riabenko via wrote: > I attest that I succeeded this weekend by following the instructions > in the latest (development) version of the guix manual without > commenting anything out. Hi Roman, thanks for confirming this. > Second, I was unsure where to get the IPv6 default gateway. I tried > the "ip -6 route" command. Yes, that's what I did, i.e. I tried with the link-local address and that failed. Unsure whether this is the expected behaviour? Perhaps someone might confirm. As reported earlier on this thread, I was able to make it work by dropping the IPv6 gateway altogether, as suggested by Felix. Thanks for sharing your settings/experience with this. Cheers, Fabio. -- Fabio Natali https://fabionatali.com
Bug#1065131: electron: GPU process crash with AMDGPU, ac: Unknown GPU, using 0 for raster_config
Version: 24.0.3-1+b1 Great, they belong to the same source package and should be both upgraded. Closing. > With mesa-va-drivers:amd64 24.0.3-1+b1 and libgl1-mesa-dri:amd64 > 23.3.3-3, the result is the same. > > But with also updating libgl1-mesa-dri:amd64 to 24.0.3-1+b1, the issue > is fixed.
Bug#1065131: electron: GPU process crash with AMDGPU, ac: Unknown GPU, using 0 for raster_config
Version: 24.0.3-1+b1 Great, they belong to the same source package and should be both upgraded. Closing. > With mesa-va-drivers:amd64 24.0.3-1+b1 and libgl1-mesa-dri:amd64 > 23.3.3-3, the result is the same. > > But with also updating libgl1-mesa-dri:amd64 to 24.0.3-1+b1, the issue > is fixed.
bug#64653: 'static-networking' fails to start
On 2024-03-25, 11:52 +, Fabio Natali wrote:
> Once the reconfiguration has taken place and when restarting the
> networking service, I get this error:
>
> ,
> | herd: error: exception caught while executing 'start' on service
> 'networking':
> | Throw to key `%exception' with args `("#< errno:
> 17>")'.
> `
Ok, good news, thanks to Felix's advice[0] I was able to get this
sorted!
Apparently, specifying a default IPv6 gateway (as a link local address)
is what was causing the issue for me. Once the following bit was
commented out, everything started working again.
,
| (static-networking
| (addresses (list (network-address
|(device "eth0")
|(value "10.0.0.2/24"))
| (network-address
|(device "eth0")
|(value "2001:db8::1/64"
| (routes (list (network-route
| (destination "default")
| (gateway "10.0.0.1"
| ;;(network-route
| ;; (destination "default")
| ;; (gateway "fe80::"
| (name-servers '("10.0.0.1" "2001:db8::")))
`
("fe80::" and "2001:db8::" are just placeholders.)
I assume the router address gets retrieved automatically via Router
Advertisment (RA), so no need for that in my case.
Still, I'd expect to be possible to indicate the router's link-local
address... Do you see a possible bug here or is there anything else that
I might be missing?
Thanks, cheers, Fabio.
[0] https://lists.gnu.org/archive/html/help-guix/2024-03/msg00132.html
--
Fabio Natali
https://fabionatali.com
Re: 'static-networking' fails to start
Hi Felix, Thanks for getting back to me. On 2024-03-25, 08:49 -0700, Felix Lechner wrote: > Debbugs was down. I unarchived Bug#64653 for you. Great - I'll be following up on that bug report from now on then. > I also had issues with static networking two years ago. Here is what > worked for me at the time. [1] I think I tried that (commenting out the default gateway part, which might be picked up automatically by means of Router Advertisement RA?). I'll definitely try again once in front of the machine and update the bug report with my findings. Thanks for now! Cheers, Fabio.
bug#64653: 'static-networking' fails to start
Hi,
I've been trying to reconfigure a machine from static IPv4 to static
dual-stack or IPv6-only. I followed one⁰ of the examples in the manual,
so I'd think I got the syntax right.
Once the reconfiguration has taken place and when restarting the
networking service, I get this error:
,
| herd: error: exception caught while executing 'start' on service 'networking':
| Throw to key `%exception' with args `("#< errno:
17>")'.
`
This would seem to be relevant to this bug report 64653?
Do you know what this might be related to and what I can do to solve it?
This happens on an up-to-date Guix system.
Thanks, best wishes, Fabio.
⁰
https://guix.gnu.org/manual/devel/en/html_node/Networking-Setup.html#index-static_002dnetworking
--
Fabio Natali
https://fabionatali.com
[PATCH] phycore_pcl063: Drop leading zero from USB vendor number
CONFIG_USB_GADGET_VENDOR_NUM is a 16-bit number, so remove the leading zero. Reported-by: Marek Vasut Signed-off-by: Fabio Estevam --- configs/phycore_pcl063_defconfig | 2 +- configs/phycore_pcl063_ull_defconfig | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configs/phycore_pcl063_defconfig b/configs/phycore_pcl063_defconfig index 6b00df1cffb3..017054a8e12b 100644 --- a/configs/phycore_pcl063_defconfig +++ b/configs/phycore_pcl063_defconfig @@ -63,7 +63,7 @@ CONFIG_USB=y CONFIG_SPL_USB_HOST=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Phytec" -CONFIG_USB_GADGET_VENDOR_NUM=0x01b67 +CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y diff --git a/configs/phycore_pcl063_ull_defconfig b/configs/phycore_pcl063_ull_defconfig index 6195fcfb73df..b3da43a5bf1e 100644 --- a/configs/phycore_pcl063_ull_defconfig +++ b/configs/phycore_pcl063_ull_defconfig @@ -54,7 +54,7 @@ CONFIG_USB=y CONFIG_SPL_USB_HOST=y CONFIG_USB_GADGET=y CONFIG_USB_GADGET_MANUFACTURER="Phytec" -CONFIG_USB_GADGET_VENDOR_NUM=0x01b67 +CONFIG_USB_GADGET_VENDOR_NUM=0x1b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff CONFIG_CI_UDC=y CONFIG_USB_GADGET_DOWNLOAD=y -- 2.34.1
'static-networking' fails to start
(I've been trying to post this as a follow-up to 64...@debbugs.gnu.org
but my email gets rejected as the issue is archived. I wasn't able to
un-archive the issue, apparently, so I'm now sending this
here. Apologies if you receive it twice.)
Hi,
I've been trying to reconfigure a machine from static IPv4 to static
dual-stack or IPv6-only. I followed one⁰ of the examples in the manual,
so I'd think I got the syntax right.
Once the reconfiguration has taken place and when restarting the
networking service, I get this error:
,
| herd: error: exception caught while executing 'start' on service 'networking':
| Throw to key `%exception' with args `("#< errno:
17>")'.
`
It'd seem to be relevant to bug report 64653¹?
Do you know what this might be related to and what I can do to solve it?
This happens on an up-to-date Guix system.
Thanks, best wishes, Fabio.
⁰
https://guix.gnu.org/manual/devel/en/html_node/Networking-Setup.html#index-static_002dnetworking
¹ https://issues.guix.gnu.org/64653
--
Fabio Natali
https://fabionatali.com
Re: [PATCH v1 1/3] crypto/fsl: allow accessing Job Ring from non-TrustZone
Hi Emanuele, On Mon, Mar 25, 2024 at 8:47 AM Emanuele Ghidoli wrote: > +config FSL_CAAM_JR_NTZ_ACCESS > + bool "Give caam Job Ring access to non-secure world" Please spell CAAM instead. > + default n 'default n' is already the default, please drop this line.
Re: [PATCH] board: phytec: phycore_imx8mp.env fix netboot issues
On Fri, Mar 22, 2024 at 9:55 AM Yannic Moog wrote:
>
> The "run netargs" command should come later in the "netboot" command
> order when using dhcp since it sets the server and client ip addresses.
> The previous order led to misconfigured kernel boot params and thus
> kernel panic when serverip was not manually set.
> Further, following Linux FHS 3.0, change the nfsroot default directory
> to /srv/nfs.
>
> Fixes: 60f64bec414e ("board: phytec: phycore_imx8mp: Add fec support")
> Signed-off-by: Yannic Moog
Applied to u-boot-imx/next, thanks.
Re: [PATCH v3 2/3] configs: imx93-phyboard-segin: Add USB support
On Thu, Mar 21, 2024 at 4:17 PM Marek Vasut wrote: > $ git grep -i usb.*phytec configs > configs/phycore_pcl063_defconfig:CONFIG_USB_GADGET_MANUFACTURER="Phytec" > configs/phycore_pcl063_ull_defconfig:CONFIG_USB_GADGET_MANUFACTURER="Phytec" > > It would be good to be consistent. > > Also, what is the vendor/product number those two boards use ? They both use: CONFIG_USB_GADGET_VENDOR_NUM=0x01b67 CONFIG_USB_GADGET_PRODUCT_NUM=0x4fff configs/phycore-imx8mp_defconfig has: CONFIG_USB_GADGET_MANUFACTURER="FSL" CONFIG_USB_GADGET_VENDOR_NUM=0x0525 CONFIG_USB_GADGET_PRODUCT_NUM=0xa4a5 I agree we should make this consistent. To not block this series, I applied it, but it would be great if Phytec could submit a separate series making it consistent across their boards. Thanks
Re: [PATCH v3 1/3] arm: dts: imx93-phyboard-segin: Add USB support
On Thu, Mar 21, 2024 at 4:17 PM Marek Vasut wrote: > > On 3/21/24 3:45 PM, Mathieu Othacehe wrote: > > Enable both usbotg1 and usbotg2 ports. Disable over-current as OC pins are > > not connected to the SoC. > > > > This > > "This addition to ...-u-boot.dtsi is temporary, ..." would be clearer. I fixed as Marek's suggestion and applied it to u-boot-imx/next, thanks.
Re: [PATCH] imx: ele_ahab: Add ahab_commit command support
On Thu, Mar 21, 2024 at 4:20 AM Mathieu Othacehe wrote: > > This message is used to commit into the fuses any new SRK revocation and > FW version information that have been found into the NXP (ELE FW) and > OEM containers. > > Signed-off-by: Mathieu Othacehe Applied to u-boot-imx/next, thanks.
Re: [PATCH v4 00/11] imx8mp: Enable PCIe/NVMe support
On Fri, Mar 22, 2024 at 10:51 AM Fabio Estevam wrote: > > Hi Sumit, > > On Thu, Mar 21, 2024 at 11:55 AM Sumit Garg wrote: > > > Changes in v4: > > - Incorporated misc comments from Marek and added his review tag. > > - Dropped patch #4 (imx8mp: power-domain: Don't power off pd_bus) > > since power domain off path is never excercised for DT based devices. > > - Added patch#8 as suggested by Peter to describe older pcie_imx.c > > driver as legacy one. > > v4 looks good, thanks. > > I'll wait a few days and will queue it to next. Applied to u-boot-imx/next, thanks.
[GIT PULL] Please pull u-boot-imx-next-20240324
Hi Tom,
Please pull this material for next from u-boot-imx, thanks.
The following changes since commit fb49d6c289d942ff7de309a5c5eaa37a7f4235db:
remoteproc: uclass: Add methods to load firmware to rproc and boot rproc
(2024-03-22 15:50:28 -0400)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git
tags/u-boot-imx-next-20240324
for you to fetch changes up to 9d27e441bb14dd526c60c13d5ff16353ca322eb3:
board: phytec: phycore_imx8mp.env fix netboot issues (2024-03-24 13:42:10
-0300)
u-boot-imx-next-20240324
--
CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/20056
- Add ahab_commit command support.
- Add USB support for the imx93-phyboard-segin board.
- Add i.MX8MP PCIe support.
- Fix netboot environment on phycore_imx8mp.
Mathieu Othacehe (4):
imx: ele_ahab: Add ahab_commit command support
arm: dts: imx93-phyboard-segin: Add USB support
configs: imx93-phyboard-segin: Add USB support
configs: imx93-phyboard-segin: Add fastboot support
Sumit Garg (10):
clk: imx8mp: Add support for PCIe clocks
reset: imx: Refactor driver to simplify function names
reset: imx: Add support for i.MX8MP reset controller
imx8mp: power-domain: Add PCIe support
imx8mp: power-domain: Expose high performance PLL clock
phy: phy-imx8m-pcie: Add support for i.MX8M{M/P} PCIe PHY
pci: Add DW PCIe controller support for iMX8MP SoC
pcie_imx: Update header to describe it as a legacy driver
verdin-imx8mp_defconfig: Enable PCIe/NVMe support
MAINTAINERS: Add entry for PCIe DWC IMX driver
Tim Harvey (1):
imx8mp_venice_defconfig: Enable PCIe/NVMe support
Yannic Moog (1):
board: phytec: phycore_imx8mp.env fix netboot issues
MAINTAINERS| 6 +
arch/arm/dts/imx93-phyboard-segin-u-boot.dtsi | 15 ++
arch/arm/include/asm/mach-imx/ele_api.h| 2 +
arch/arm/mach-imx/ele_ahab.c | 29 +++
board/phytec/phycore_imx8mp/phycore_imx8mp.env | 4 +-
configs/imx8mp_venice_defconfig| 8 +
configs/imx93-phyboard-segin_defconfig | 14 +
configs/verdin-imx8mp_defconfig| 6 +
drivers/clk/imx/clk-imx8mp.c | 6 +
drivers/misc/imx_ele/ele_api.c | 32 +++
drivers/pci/Kconfig| 11 +
drivers/pci/Makefile | 1 +
drivers/pci/pcie_dw_imx.c | 338 +
drivers/pci/pcie_imx.c | 8 +
drivers/phy/Kconfig| 11 +
drivers/phy/Makefile | 1 +
drivers/phy/phy-imx8m-pcie.c | 283 +
drivers/power/domain/imx8mp-hsiomix.c | 190 +++---
drivers/reset/reset-imx7.c | 143 +--
19 files changed, 1049 insertions(+), 59 deletions(-)
create mode 100644 drivers/pci/pcie_dw_imx.c
create mode 100644 drivers/phy/phy-imx8m-pcie.c
Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks
On Fri, Mar 22, 2024 at 4:31 PM Fabio Estevam wrote: > As Pierre's explanation addresses Marc's concern, > do you think this can go to 2024.01 to fix the boot regression on imx8qxp/8qm? I meant 2024.04, sorry.
Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks
Hi Tom, On Tue, Mar 19, 2024 at 9:39 AM Pierre-Clément Tosi wrote: > For most AArch64 U-Boot ports (including the i.MX family), the answer is > trivial > because they use the arch code i.e. setup_all_pgtables(). However, as > fsl-layerscape re-implements mmu_setup(), it had to be looked at separately, > hence my question, which you answered above. As Pierre's explanation addresses Marc's concern, do you think this can go to 2024.01 to fix the boot regression on imx8qxp/8qm? Thanks
Re: inconsistent wget behavior
Hi Paul, On Sun, Feb 11, 2024 at 4:42 PM Paul Liu wrote: > > Hi Fabio, > > I'm on vacation now (Chinese new year). I hope I'll find some time to revive > my imx8 board. > I've tried sandbox and qemu. Both of them are not reproducible. I'm wondering > if it could be some packet loss that causes the issue. Because sandbox and > qemu there won't be any missing packets because of loopback devices. Have you had a chance to reproduce the issue on your imx8mm board?
Re: Look for help: how to package Rust project
On Fri, Mar 22, 2024 at 3:26 PM Ming Lei wrote: > > I love this easy way. > > But when I try to build in this way, I got the following failure: > > Problem 1: nothing provides requested (crate(ilog/default) >= 1.0.1 > with crate(ilog/default) < 2.0.0~) > Problem 2: nothing provides requested (crate(libublk/default) >= > 0.3.0 with crate(libublk/default) < 0.4.0~) > Problem 3: nothing provides requested (crate(qcow2-rs/default) >= > 0.1.2 with crate(qcow2-rs/default) < 0.2.0~) > Problem 4: nothing provides requested (crate(shared_memory/default) > >= 0.12.4 with crate(shared_memory/default) < 0.13.0~) > Problem 5: nothing provides requested (crate(smol/default) >= 1.3.0 > with crate(smol/default) < 2.0.0~) > > I guess it is because that all above crate aren't packaged in Fedora, > can you share how to > deal with this issue? Yes, these error messages represent all the crate dependencies that cannot be resolved from Fedora repositories. They will need to be packaged separately if you want to submit this as an official package for Fedora. Or if you want a "quick and dirty" solution for unofficial packages, you can use "rust2rpm --vendor". Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: A sundial in Seville
it is also here: www.sundialatlas.eu/atlas.php?sun=ES877 Fabio Savian Il 22/03/2024 15:40, Douglas Bateman via sundial ha scritto: Diese Nachricht wurde eingewickelt um DMARC-kompatibel zu sein. Die eigentliche Nachricht steht dadurch in einem Anhang. This message was wrapped to be DMARC compliant. The actual message text is therefore in an attachment. --- https://lists.uni-koeln.de/mailman/listinfo/sundial -- Fabio Savian fabio.sav...@nonvedolora.it UTC +1, DST +2, 45° 34' 9'' N, 9° 9' 53'' E Paderno Dugnano, Milano, Italy --- https://lists.uni-koeln.de/mailman/listinfo/sundial
Re: [PATCH v4 00/11] imx8mp: Enable PCIe/NVMe support
Hi Sumit, On Thu, Mar 21, 2024 at 11:55 AM Sumit Garg wrote: > Changes in v4: > - Incorporated misc comments from Marek and added his review tag. > - Dropped patch #4 (imx8mp: power-domain: Don't power off pd_bus) > since power domain off path is never excercised for DT based devices. > - Added patch#8 as suggested by Peter to describe older pcie_imx.c > driver as legacy one. v4 looks good, thanks. I'll wait a few days and will queue it to next.
Re: [PATCH 00/12] arm: xea: Provide support for different XEA board HW versions
Hi Lukasz,
On Fri, Mar 22, 2024 at 8:43 AM Lukasz Majewski wrote:
> arch/arm/dts/Makefile | 3 +-
> arch/arm/dts/imx28-xea-1-u-boot.dtsi | 11
> arch/arm/dts/imx28-xea-1.dts | 8 +++
> arch/arm/dts/imx28-xea-2-u-boot.dtsi | 11
> arch/arm/dts/imx28-xea-2.dts | 8 +++
> arch/arm/dts/imx28-xea-u-boot.dtsi| 1 -
> .../arm/dts/{imx28-xea.dts => imx28-xea.dtsi} | 0
This rename deviates from the upstream devicetree name.
Ideally, we should convert to OF_UPSTREAM available in U-Boot next.
> board/liebherr/xea/spl_xea.c | 21 +++---
> board/liebherr/xea/xea.c | 65 +++
> board/liebherr/xea/xea.env| 4 +-
> configs/imx28_xea_defconfig | 5 +-
> configs/imx28_xea_sb_defconfig| 5 +-
> 12 files changed, 128 insertions(+), 14 deletions(-)
> create mode 100644 arch/arm/dts/imx28-xea-1-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx28-xea-1.dts
> create mode 100644 arch/arm/dts/imx28-xea-2-u-boot.dtsi
> create mode 100644 arch/arm/dts/imx28-xea-2.dts
> rename arch/arm/dts/{imx28-xea.dts => imx28-xea.dtsi} (100%)
You should upstream imx28-xea-1.dts and imx28-xea-2.dts first.
Bug#1062963: patch is incomplete
Il 22/03/2024 03:31, Matthias Klose ha scritto: Control: reopen -1 Control: tags -1 + ftbfs patch some library names in the symbols file were omitted. patch attached. http://launchpadlibrarian.net/720580389/muffin_6.0.1-1build1_6.0.1-1ubuntu1.diff.gz thanks, I didn't notice that, I just noticed another bad breaks/replaces issue in libmuffin-dev on nmu to unstable was fixed, I'll fix in experimental too OpenPGP_signature.asc Description: OpenPGP digital signature
Re: [PATCH v3 1/3] arm: dts: imx93-phyboard-segin: Add USB support
Hi Mathieu, On Thu, Mar 21, 2024 at 11:46 AM Mathieu Othacehe wrote: > > Enable both usbotg1 and usbotg2 ports. Disable over-current as OC pins are > not connected to the SoC. > > This is temporary, until USB support is added to imx93-phyboard-segin.dts > in Linux. > > Signed-off-by: Mathieu Othacehe Thanks, this looks better: Reviewed-by: Fabio Estevam
Re: [PATCH v2 0/3] imx93-phyboard-segin: Add USB support.
Hi Mathieu, On Thu, Mar 21, 2024 at 3:57 AM Mathieu Othacehe wrote: > Mathieu Othacehe (3): > arm: dts: imx93-phyboard-segin: Add USB support > configs: imx93-phyboard-segin: Add USB support > configs: imx93-phyboard-segin: Add fastboot support > > arch/arm/dts/imx93-phyboard-segin.dts | 13 + The addition of the i.MX93 USB support in the kernel devicetree is taking longer than expected: https://lore.kernel.org/linux-arm-kernel/20240321081439.541799-8-xu.yan...@nxp.com/T/#u To avoid getting out of sync with the upstream dts, please add the USB nodes inside imx93-phyboard-segin-u-boot.dtsi for now. Thanks
Re: Look for help: how to package Rust project
On Thu, Mar 21, 2024 at 9:25 AM Richard W.M. Jones wrote: > > On Thu, Mar 21, 2024 at 11:04:13AM +0800, Ming Lei wrote: > > Hello Richard and Guys, > > > > I plan to package rublk to Fedora, and it is one Rust project. > > Hi, I'm on holiday at the moment, but please do look at how we > packaged libblkio in Fedora: > > https://bugzilla.redhat.com/show_bug.cgi?id=2124697 > > > Can you provide a little guide about how to do that? such as, > > where can I find the guide doc? And is it github or crates which > > should be used as source for Fedora packaging? > > Everything has to start with a source tarball, so normally github > would be the best source. > > > [1] https://github.com/ublk-org/rublk > > [2] https://crates.io/crates/rublk If the project is a single "crate" (i.e. one compilation unit) and will continue to be published on crates.io, I would recommend using the sources published there instead of GitHub sources. Using files distributed via crates.io makes packaging a bit easier and avoids some work that is necessary for non-crate Rust packages. I would recommend reading the Rust packaging guidelines for this case: https://docs.fedoraproject.org/en-US/packaging-guidelines/Rust/#_rust_crates You should get a working spec file by just running "rust2rpm -s rublk". Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: SPDX Statistics - Book Smugglers edition
On Wed, Mar 20, 2024 at 2:53 PM Tomasz Kłoczko wrote: > > On Sat, 16 Mar 2024 at 10:03, Miroslav Suchý wrote: >> >> Hot news: >> >> The last phase has been announce >> https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_4 and we will >> proceed when approved with FESCO. > > > I think that generally you are wasting your man/hours posting such statistics. > The same time could be used better by going with a few grep. sort, sed > oneliers to co update and align all packages License: fields and commit all > those changes across all per packages repos in a few minutes. > Some of the proven packagers with RW access to all packages repos can apply > necessary changes in a few tenths of minutes. > Subject of SPDX migrations are already IIRC active since July 2022 (soon it > will be two years anniversary). > All those changes should not be applied relying on each package maintainers > because that change is from Trival™️ class. While I agree with some of what you're saying here, the problem is that it is, in fact, *not trivial* in many cases. Migrating the License tag from Callaway to SPDX identifiers is only the "easy" part of the transition. Re-reviewing package contents and re-classifying licenses is the non-trivial part, and that definitely can't be scripted. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F41 Change Proposal: Disable openSSL Engine Support (system-wide)
On Wed, Mar 20, 2024 at 3:06 PM Daniel P. Berrangé wrote: > > On Wed, Mar 20, 2024 at 02:35:21PM +0100, Dmitry Belyavskiy wrote: (...) > > As I understand, upstream is going to remove engines but it wouldn't happen > > before OpenSSL 4.0 > > That makes sense, as it solves the ELF ABI / SONAME change > issue with removing the APIs. > > > I don't think Fedora should wait for that. We definitely want to land > > no-engine in RHEL10 so Fedora should be ready for that. > > Fedora shouldn't neccessarily be rushed into something just because > RHEL wants to do it prematurely due to RHEL's long lifecycle. I fully agree here. Just because something is desirable for RHEL x+1 doesn't mean that it's desirable for Fedora y+1. Also, hasn't CentOS Stream 10 already been branched off of ELN-is-Fedora-40, meaning it would be too late if done in Fedora 41 anyway? Or is this just about OpenSSL maintainers not wanting to have to keep maintaining Engine support in Fedora while it will be phased out in RHEL sooner? Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Bug#1067207: mesa: switch statement too large, might need -mlong-jump-table-offsets
Maybe it's better to file an issue or send a MR upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests It looks like m68k was considered in the past: https://cgit.freedesktop.org/mesa/mesa/log/?qt=grep=m68k
Bug#1067207: mesa: switch statement too large, might need -mlong-jump-table-offsets
Maybe it's better to file an issue or send a MR upstream: https://gitlab.freedesktop.org/mesa/mesa/-/issues https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests It looks like m68k was considered in the past: https://cgit.freedesktop.org/mesa/mesa/log/?qt=grep=m68k
Re: ld: error: triggering the generation of an executable stack
On Wed, Mar 20, 2024, 01:28 Orion Poplawski wrote: > With a recent update, plplot is failing to build with: > > cd > /builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/examples/fortran > && /usr/bin/cmake -E cmake_link_script CMakeFiles/x16af.dir/link.txt > --verbose=1 > /usr/bin/gfortran -Wl,-z,relro -Wl,--as-needed > -Wl,-z,pack-relative-relocs -Wl,-z,now > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld-errors > -specs=/usr/lib/rpm/redhat/redhat-hardened-ld > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -Wl,--build-id=sha1 -O2 > -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe > -Wall -Wno-complain-wrong-lang -Werror=format-security > -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS > -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong > -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -march=x86-64 > -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection > -fcf-protection -mtls-dialect=gnu2 -fno-omit-frame-pointer > -mno-omit-leaf-frame-pointer -frecursive > CMakeFiles/x16af.dir/x16af.f90.o -o x16af > -Wl,-rpath,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/bindings/fortran:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime > > ../libplfortrandemolib.a > ../../bindings/fortran/libplplotfortran.so.0.2.0 > > -Wl,-rpath-link,/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/src:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/csa:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/nn:/builddir/build/BUILD/plplot-5.15.0/redhat-linux-build/lib/qsastime > /usr/bin/ld: error: /tmp/cchkMGCX.ltrans0.ltrans.o: is triggering the > generation of an executable stack (because it has an executable > .note.GNU-stack section) > /usr/bin/ld: failed to set dynamic section sizes: No such file or directory > > I have no idea what is up here. > Isn't this what this change was about? https://fedoraproject.org/wiki/Changes/Linker_Error_On_Security_Issues Fabio > Seems to have started with: > > gcc 14.0.1-0.7.fc41 > glibc 2.39.9000-3.fc41 > util-linux 2.40-0.9.rc1.fc41 > binutils 2.42.50-4.fc41 > > and lots of others, but that seems the most likely. > > -- > Orion Poplawski > he/him/his - surely the least important thing about me > IT Systems Manager 720-772-5637 > NWRA, Boulder/CoRA Office FAX: 303-415-9702 > 3380 Mitchell Lane or...@nwra.com > Boulder, CO 80301 https://www.nwra.com/ > -- > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam, report it: > https://pagure.io/fedora-infrastructure/new_issue > -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Bug#1067199: RFS: bleachbit/4.6.0-3 [ITA] [RC] -- delete unnecessary files from the system
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "bleachbit": * Package name : bleachbit Version : 4.6.0-3 Upstream contact : Andrew Ziem * URL : https://www.bleachbit.org/ * License : CC0-1.0, GPL-3+ * Vcs : https://salsa.debian.org/python-team/packages/bleachbit Section : admin The source builds the following binary packages: bleachbit - delete unnecessary files from the system To access further information about this package, please visit the following URL: https://mentors.debian.net/package/bleachbit/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/b/bleachbit/bleachbit_4.6.0-3.dsc Changes since the last upload: bleachbit (4.6.0-3) unstable; urgency=medium . * Return to Debian Python Team and add myself to uploaders (Closes: #1065808) * Remove libgtk-3-0 from depends (Closes: #1067171) Regards, -- Fabio Fantoni
Bug#1067199: RFS: bleachbit/4.6.0-3 [ITA] [RC] -- delete unnecessary files from the system
Package: sponsorship-requests Severity: important Dear mentors, I am looking for a sponsor for my package "bleachbit": * Package name : bleachbit Version : 4.6.0-3 Upstream contact : Andrew Ziem * URL : https://www.bleachbit.org/ * License : CC0-1.0, GPL-3+ * Vcs : https://salsa.debian.org/python-team/packages/bleachbit Section : admin The source builds the following binary packages: bleachbit - delete unnecessary files from the system To access further information about this package, please visit the following URL: https://mentors.debian.net/package/bleachbit/ Alternatively, you can download the package with 'dget' using this command: dget -x https://mentors.debian.net/debian/pool/main/b/bleachbit/bleachbit_4.6.0-3.dsc Changes since the last upload: bleachbit (4.6.0-3) unstable; urgency=medium . * Return to Debian Python Team and add myself to uploaders (Closes: #1065808) * Remove libgtk-3-0 from depends (Closes: #1067171) Regards, -- Fabio Fantoni
Bug#1067171: marked as pending in bleachbit
Control: tag -1 pending Hello, Bug #1067171 in bleachbit reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/python-team/packages/bleachbit/-/commit/70ff0b682a0d402ce1e972cb7f45311066527477 Remove libgtk-3-0 from depends Remove the explicit dependency on libgtk-3-0. For Python code that uses GTK via GObject-Introspection, it is sufficient to depend on gir1.2-gtk-3.0. This solves a blocking issue for 64-bit time_t transition. Closes: #1067171 (this message was generated automatically) -- Greetings https://bugs.debian.org/1067171
Backport request for xtables-addons
Hi, I'd like to request the backports of xtables-addons as follow. bullseye-backports: backport 3.23-1 from bookworm. Note that linux 6.1 is already available in bullseye-backports and it's not compatible with the default bullseye xtables-addons (3.13-1). Backporting xtables-addons 3.23-1 from bookworm will make it compatible with linux 6.1. bookworm-backports: 3.25-2 from trixie. Eventually: bullseye-backports-sloppy: 3.25-2 from trixie. Thanks!
[grpc-io] Re: who else is looking for an active (discord) community?
indeed El lunes, 18 de marzo de 2024 a la(s) 9:53:11 p.m. UTC-5, ji-podhead escribió: > theres no channel on discord. gitter and git-discussion are dead. > i dont have any slack invites. > k8s groups have no grpc sub. > maybe we should start a server on our own? > love from germany: > ji > -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/ed664701-afc4-4660-b3dc-54593489116cn%40googlegroups.com.
Re: [grpc-io] who else is looking for an active (discord) community?
INDEED! Sent from Mailspring (https://link.getmailspring.com/link/9bb5a3ec-703b-421a-b623-f557c0992...@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F=Z3JwYy1pb0Bnb29nbGVncm91cHMuY29t), the best free email app for work On Mar 15 2024, at 1:22 pm, ji-podhead wrote: > theres no channel on discord. gitter and git-discussion are dead. > i dont have any slack invites. > k8s groups have no grpc sub. > maybe we should start a server on our own? > love from germany: > ji > > -- > You received this message because you are subscribed to the Google Groups > "grpc.io" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to grpc-io+unsubscr...@googlegroups.com > (https://link.getmailspring.com/link/9bb5a3ec-703b-421a-b623-f557c0992...@getmailspring.com/1?redirect=mailto%3Agrpc-io%2Bunsubscribe%40googlegroups.com=Z3JwYy1pb0Bnb29nbGVncm91cHMuY29t). > To view this discussion on the web visit > https://groups.google.com/d/msgid/grpc-io/1c4be26b-9c37-40b8-b965-01eeaffccf8dn%40googlegroups.com > > (https://link.getmailspring.com/link/9bb5a3ec-703b-421a-b623-f557c0992...@getmailspring.com/2?redirect=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fgrpc-io%2F1c4be26b-9c37-40b8-b965-01eeaffccf8dn%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter=Z3JwYy1pb0Bnb29nbGVncm91cHMuY29t). -- You received this message because you are subscribed to the Google Groups "grpc.io" group. To unsubscribe from this group and stop receiving emails from it, send an email to grpc-io+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/grpc-io/9BB5A3EC-703B-421A-B623-F557C099262A%40getmailspring.com.
Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks
Hi Pierre, On Tue, Mar 19, 2024 at 8:39 AM Pierre-Clément Tosi wrote: > This means gd->arch.tlb_addr pointing to the live PTs during setup_pgtables(). > > In arch/arm/cpu/armv8, setup_all_pgtables() runs with SCTLR_ELx.M unset. > > In arch/arm/cpu/armv8/fsl-layerscape, setup_pgtables() is called twice: > > - early_mmu_setup() calls it with SCTLR_ELx.M unset; > - final_mmu_setup() overwrites gd->arch.tlb_addr before calling it iff >CFG_SYS_MEM_RESERVE_SECURE is defined i.e. if > CONFIG_SYS_SOC="fsl-layerscape" >so that gets auto-included through >. > > So can CONFIG_FSL_LAYERSCAPE be set while CONFIG_SYS_SOC != "fsl-layerscape"? No, this cannot happen. Only the following Layerscape SoCs select CONFIG_FSL_LAYERSCAPE in arch/arm/cpu/armv8/fsl-layerscape/Kconfig: LS1012A, LS1028A, LS1043A, LS1046A, LS1088A, LS2080A, LX2162A and LX2160A I saw the original boot problem with the i.MX8QX. The i.MX8QX is part of the i.MX family, not the Layerscape family. > I suppose Fabio and Stefano can answer this and/or help with ensuring that > setup_pgtables() is never called on live PTs. Let me know if you need any clarification. Thanks, Fabio Estevam
Re: [nexa] Affidabilità delle traduzioni automatiche
Il giorno mar 19 mar 2024 alle ore 11:48 Diego Giorio ha scritto: > > Questa è decisamente carina. > > E non ditemi che sono out of topic, perché riguarda l'affidabilità dei > sistemi di traduzione automatica. > > Il paese in questione è naturalmente la cittadina di BRA, opportunamente > tradotta in italiano... Immagino dipenda da quanto si è disposti a pagare. ___ nexa mailing list nexa@server-nexa.polito.it https://server-nexa.polito.it/cgi-bin/mailman/listinfo/nexa
Re: [PATCH 1/2] clk: clk-imx8qxp: Add LPUART IPG entries
Hi Tom and Sean,
On Fri, Mar 8, 2024 at 5:13 PM Fabio Estevam wrote:
>
> Since commit cc7df0b9e8bc ("serial: lpuart: Enable IPG clock")
> the colibri-imx8qxp board no longer boots.
>
> The reason is that the imx8qxp clock driver does not handle the
> LPUART IPG clocks inside get_rate(), set_rate() and enable() functions.
>
> Fix the boot regression by adding the LPUART IPG entries.
>
> Fixes: cc7df0b9e8bc ("serial: lpuart: Enable IPG clock")
> Reported-by: Marcel Ziswiler
> Signed-off-by: Fabio Estevam
Please consider applying this series to 2024.04.
It fixes a boot regression on imx8qxp and imx8qm.
Thanks!
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
Hi Pierre, On Mon, Mar 18, 2024 at 4:59 PM Pierre-Clément Tosi wrote: > I notice that the mem_map in these logs have overlapping ranges, which results > in unnecessary work when creating the PTs. For this reason, it would make > sense > to prune it in arch/arm/mach-imx/imx8/cpu.c before calling dcache_enable(), > IMO. > On this point, you also have contiguous ranges with identical attributes > (mem_map[0] and mem_map[6]), which could be merged into a single entry. This > could result in more efficient MMU mappings if the mem_map entries can share a > block mapping. Also note that mem_map[4].size=0 so could be dropped. > > In any case, if we assume that overlapping mem_map entries are a valid input > to > the arch code (maybe not as it leads to potentially ambiguous behavior?), then > 41e2787f5ec4 had removed support for splitting existing block mappings. > > In your case, my assumption is that the function was then treating block > mappings in the range 0x1c00-0x8000 (which get mapped, at least > partially, by mem_map[0], mem_map[1], then mem_map[2]) as table mappings and > was > issuing read/write instructions in that range (accessing them as PTEs). As > those > seem to be device memory (I see they get mapped as MT_DEVICE_NGNRNE), these > accesses might explain the SError you were experiencing. > > Would you mind testing [1] and giving it "Tested-by:" if it addresses the > issue? Your patch fixed the boot regression. Thanks for your fix, appreciated it! I have replied with my Tested-by tag. Cheers, Fabio Estevam
Re: [PATCH] arm64: Fix map_range() not splitting mapped blocks
Hi Pierre,
On Mon, Mar 18, 2024 at 4:35 PM Pierre-Clément Tosi wrote:
>
> The implementation of map_range() creates the requested mapping by
> walking the page tables, iterating over multiple PTEs and/or descending
> into existing table mappings as needed. When doing so, it assumes any
> pre-existing valid PTE to be a table mapping. This assumption is wrong
> if the platform code attempts to successively map two overlapping ranges
> where the latter intersects a block mapping created for the former.
>
> As a result, map_range() treats the existing block mapping as a table
> mapping and descends into it i.e. starts interpreting the
> previously-mapped range as an array of PTEs, writing to them and
> potentially even descending further (extra fun with MMIO ranges!).
>
> Instead, pass any valid non-table mapping to split_block(), which
> ensures that it actually was a block mapping (calls panic() otherwise)
> before splitting it.
>
> Fixes: 41e2787f5ec4 ("arm64: Reduce add_map() complexity")
> Signed-off-by: Pierre-Clément Tosi
This fixes the boot regression on colibri-imx8x.
Thanks a lot for your fix!
Tested-by: Fabio Estevam
Re: Follow up for bash-completion pkgconfig file packaging change
On Mon, Mar 18, 2024 at 5:22 PM Dan Horák wrote:
>
> On Mon, 18 Mar 2024 17:07:08 +0100
> Fabio Valentini wrote:
> > I wonder why these packages rely in pkg-config and don't just install
> > to `%{bash_completions_dir}`?
>
> because it hasn't always exist? Or it's mentioned in some guidelines?
Likely, yes. They've been around for ~2 years.
They are available on all current branches of Fedora and on EPEL 9.
The effort to document them in the packaging guidelines seems to have stalled:
https://pagure.io/packaging-committee/issue/1202
Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: Follow up for bash-completion pkgconfig file packaging change
On Mon, Mar 18, 2024 at 4:33 PM Mamoru TASAKA wrote:
>
> Hello, all:
>
> After investigating the recent Fedora-Security-Live livespin compose failure
> on F-41, it is found that this is caused because:
>
> - Recently on F-41, bash-completion packaging changed so that pkgconfig file
>is moved into -devel subpackage: (bash-completion-2.11-15.fc41)
>
> https://src.fedoraproject.org/rpms/bash-completion/c/d1f5dc48c0440cc68efdd519b78fccca416cad94?branch=rawhide
>
> - A package (lynis) installing bash-completion file into the directory
>$(pkg-config --variable=completionsdir bash-completion), had
> "BuildRequires: bash-completion",
>but did not have "BuildRequires: pkgconfig(bash-completion)".
>
> - So after the above bash-completion side packaging change, the above command
> line was
>expanded to the empty string, so the completion file was installed into
> the wrong directory,
>which caused conflict with filesystem rpm.
>
>
> So on F-41(rawhide), the packages
>
> * trying to install bash-completion file using $(pkg-config
> --variable=completionsdir bash-completion)
> * which have "BuildRequires: bash-completion", but do NOT have
> "BuildRequires: pkgconfig(bash-completion)"
>
> may be installing completion file into wrong directories after rebuild.
> (At least, I tried rebuilding cowsay and actually it installs completion file
> into the wrong
> directory).
I wonder why these packages rely in pkg-config and don't just install
to `%{bash_completions_dir}`?
This macro is defined in the default buildroot, regardless of
BuildRequires, and always expands to the correct location for
installing bash completions.
Fabio
--
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
On Mon, Mar 18, 2024 at 10:31 AM Fabio Estevam wrote: > I tried dumping the page table entries, but could not notice anything > that looked suspicious. This looks suspicious: With 41e2787f5ec4 reverted: Checking if pte fits for virt=1c00 size=6400 blocksize=4000 Checking if pte fits for virt=1c00 size=6400 blocksize=20 Checking if pte fits for virt=1c20 size=63e0 blocksize=4000 Checking if pte fits for virt=1c20 size=63e0 blocksize=20 Checking if pte fits for virt=1c40 size=63c0 blocksize=4000 In U-Boot master: Checking if pte fits for virt=1c00 size=6400 blocksize=4000 Checking if pte fits for virt=1c00 size=2400 blocksize=20 Checking if pte fits for virt=1c20 size=23e0 blocksize=20 Checking if pte fits for virt=1c40 size=23c0 blocksize=20 The second entry has size=2400 instead of size=6400.
Re: [PATCH 1/2] arm64: Reduce add_map() complexity
Hi Pierre, On Fri, Mar 15, 2024 at 12:13 PM Pierre-Clément Tosi wrote: > I had a quick look through your logs and notice that U-Boot master attempts to > map addresses in the high VA range e.g. > > Checking if pte fits for virt=e400 [...] > > while the logs that boot successfully only use the low VA range e.g. > > Checking if pte fits for virt=80193000 [...] > > Unless that has recently changed (since I last worked with U-Boot), U-Boot on > AArch64 only supports identity mappings and therefore was only taught how to > program TTBR0_ELx (i.e. is only able to map low virtual addresses). This means > that the code - with or without 41e2787f5ec4 - would be unable to map > addresses > such as 0xe400. Yes, I found it strange too. I may have done something wrong the last time I instrumented the code. I tried it again and no longer see these unexpected high virtual addresses. Please find the new logs here: https://pastebin.com/raw/qF3GbJry > Now, given that 41e2787f5ec4 only affects implementation details of add_map(), > I am surprised that reverting that commit changes the arguments received by > the > function such as virt. As a reminder, add_map() is exclusively used on > mem_map: > > for (i = 0; mem_map[i].size || mem_map[i].attrs; i++) > add_map(_map[i]); > > > > > That's the only issue preventing colibri-imx8x from booting mainline U-Boot. > > If I read the U-Boot configs right i.e. > > - configs/colibri-imx8x_defconfig: CONFIG_ARCH_IMX8=y > - arch/arm/mach-imx/imx8/Makefile: obj-y += cpu.o > - arch/arm/mach-imx/imx8/cpu.c: struct mm_region *mem_map = imx8_mem_map; Correct, these are the relevant files for the i.MXQ8XP. > There is a possibility that your mem_map is getting modified by MACH-specific > code. In particular, enable_caches() seems to dynamically get the MMU mappings > from some RPC mechanism (see get_owned_memreg() and sc_rm_get_memreg_info()). > > Could it be that whatever services those requests might be returning > unexpected > values? Instrumenting arch/arm/mach-imx/imx8/cpu.c and dumping mem_map (and > the RPC messages) with/without the patch would help clear this up. I tried dumping the page table entries, but could not notice anything that looked suspicious. Please let me know if you have any suggestions. Thanks
Re: Why can't I add karlowich as co-maintainer of this package?
On Mon, Mar 18, 2024 at 1:51 PM Richard W.M. Jones wrote: > > On Mon, Mar 18, 2024 at 10:14:38AM +, Richard W.M. Jones wrote: > > On Mon, Mar 18, 2024 at 10:05:42AM +, Daniel P. Berrangé wrote: > > > On Mon, Mar 18, 2024 at 09:57:58AM +, Richard W.M. Jones wrote: > > > > > > > > https://src.fedoraproject.org/rpms/xnvme/adduser > > > > > > > > I try to add karlowich > > > > (https://accounts.fedoraproject.org/user/karlowich/) > > > > but his name doesn't appear in the username field even though he's > > > > in the packager group. Why? > > > > > > If they were only recently granted packager status, they might need login > > > to 'src.fedoraproject.org' to (re)sync group membership perhaps ? > > > > Thanks everyone, I'll have him try this. > > No luck. He's apparently tried logging out / in a few times and > doesn't appear in the list. Is there something else he needs to try? It appears that src.fp.o does not know about him *at all*: https://src.fedoraproject.org/user/karlowich Note that the logging out / back in needs to happen on src.fedoraproject.org, not with any other Fedora service. For me, sometimes opening "src.fedoraproject.org" in an incognito browser window and logging in there has helped. Fabio -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Bug#405859: GLUT_ALPHA does not work with DRI
Version: 8.0-1 mga driver was removed from mesa since 8.0 in 2012: https://docs.mesa3d.org/relnotes/8.0.html
Bug#405859: GLUT_ALPHA does not work with DRI
Version: 8.0-1 mga driver was removed from mesa since 8.0 in 2012: https://docs.mesa3d.org/relnotes/8.0.html
Bug#646929: libgl1-mesa-glx: message "failed to create drawable" when starting Firefox
Version: 8.0-1 It looks like this was addressed in mesa years ago with this commit: https://cgit.freedesktop.org/mesa/mesa/commit/?id=4833104718677caad0027d5e7539ca9bba389392
Bug#646929: libgl1-mesa-glx: message "failed to create drawable" when starting Firefox
Version: 8.0-1 It looks like this was addressed in mesa years ago with this commit: https://cgit.freedesktop.org/mesa/mesa/commit/?id=4833104718677caad0027d5e7539ca9bba389392
Bug#775235: use llvm's getCPUTargetFeatures() over getHostCPUName()
It looks like the src/gallium/auxiliary/gallivm/lp_bld_misc.cpp file in mesa was heavily updated for managing newer llvm versions, even if mesa is still using getHostCPUName and still not getCPUTargetFeatures. Michael, do you think there is still something to do in mesa? Steve and Bernhard, are you still able to reproduce the original issue?
Bug#775235: use llvm's getCPUTargetFeatures() over getHostCPUName()
It looks like the src/gallium/auxiliary/gallivm/lp_bld_misc.cpp file in mesa was heavily updated for managing newer llvm versions, even if mesa is still using getHostCPUName and still not getCPUTargetFeatures. Michael, do you think there is still something to do in mesa? Steve and Bernhard, are you still able to reproduce the original issue?
Re: [PATCH v1] arm: imx: imx8m: soc: Fix NPU/VPU fdt disable fixup
On Fri, Mar 15, 2024 at 11:45 AM Vitor Soares wrote: > > From: Vitor Soares > > On imx8m[m|p|q].dtsi, upstream Linux uses different names for NPU/VPU > IP block nodes. It leads variants without such HW block having it > enabled by default. > > This patch adds the upstream Linux node's paths to the disable list while > keep the compatibility with downstream Linux. > > Signed-off-by: Vitor Soares Applied for u-boot-imx/master, thanks.
Re: [PATCH] apalis-imx8: Fix sc_misc_otp_fuse_read() error check
On Tue, Mar 12, 2024 at 9:59 PM Fabio Estevam wrote:
>
> Commit bfb3409d676f ("imx: toradex/apalis-imx8: correct SCU API usage")
> made an incorrect logic change in the error code check of
> sc_misc_otp_fuse_read():
>
> - if (scierr == SC_ERR_NONE) {
> + if (scierr) {
> /* QP has one A72 core disabled */
> is_quadplus = ((val >> 4) & 0x3) != 0x0;
> }
>
> The other changes in this commit are correct.
>
> sc_misc_otp_fuse_read() returns 0 on a successful fuse read.
>
> This inversion causes board_mem_get_layout() to report incorrect RAM size.
>
> Go back the original error check logic to fix the problem.
>
> Fixes: bfb3409d676f ("imx: toradex/apalis-imx8: correct SCU API usage")
> Signed-off-by: Fabio Estevam
Applied for u-boot-imx/master, thanks.
Re: [PATCH] colibri-imx8x: Fix sc_misc_otp_fuse_read() error check
On Tue, Mar 12, 2024 at 9:36 PM Fabio Estevam wrote:
>
> Commit aa6e698a7acd ("imx: toradex/colibri-imx8x: correct SCU API usage")
> made an incorrect logic change in the error code check of
> sc_misc_otp_fuse_read():
>
> - if (sc_err == SC_ERR_NONE) {
> + if (sc_err) {
> /* DX has two A35 cores disabled */
> return (val & 0xf) != 0x0;
> }
>
> The other changes in this commit are correct.
>
> sc_misc_otp_fuse_read() returns 0 on a successful fuse read.
>
> This inversion causes board_mem_get_layout() to report incorrect RAM size.
>
> Go back the original error check logic to fix the problem.
>
> Fixes: aa6e698a7acd ("imx: toradex/colibri-imx8x: correct SCU API usage")
> Reported-by: Hiago De Franco
> Signed-off-by: Fabio Estevam
Applied for u-boot-imx/master, thanks.
Re: [PATCH] imx8m*_venice: move venice to OF_UPSTREAM
On Tue, Mar 12, 2024 at 10:16 PM Fabio Estevam wrote:
>
> Hi Tim,
>
> On Tue, Mar 12, 2024 at 4:05 PM Tim Harvey wrote:
> >
> > Move to imx8m{m,n,p}-venice to OF_UPSTREAM:
> > - replace the non-upstream generic imx8m{m,n,p}-venice dt with one of the
> >dt's from the OF_LIST
> > - handle the fact that dtbs now have a 'freescale/' prefix
> > - imply OF_UPSTREAM
> > - remove rudundant files from arch/arm/dts leaving only the
> >*-u-boot.dtsi files
> >
> > Signed-off-by: Tim Harvey
> ...
> > 33 files changed, 13 insertions(+), 10658 deletions(-)
>
> This diff looks great :-)
>
> Reviewed-by: Fabio Estevam
Applied for u-boot-imx/next, thanks.
Re: [PATCH v2 0/5] Add RAUC boot logic for phycore_imx8mp
On Tue, Mar 12, 2024 at 6:00 AM Leonard Anderweit wrote: > > This series adds RAUC boot logic for the phycore_imx8mp. > The first patch converts the environment from a CFG_EXTRA_ENV_SETTINGS #define > to a text environment for better readability and maintainability. > The second patch moves the default bootcmd from the defconfig to the board > environment. > The third patch enables the redundant environment on phycore_imx8mp. > Patch 4 adds RAUC boot logic common to all phytec boards. > Patch 5 adds the RAUC boot logic to phycore_imx8mp. > > v2: > - rebase on next Applied series for u-boot-imx/next, thanks.
Re: [PATCH] board: phytec: define get_som_type also when SoM detection is disabled
On Tue, Mar 12, 2024 at 6:39 AM Benjamin Hahn wrote:
>
> define the phytec_get_som_type function also when the SoM detection is
> disabled.
>
> Fixes:
> commit 110d321a56c3 ("board: phytec: common: phytec_som_detection: Add
> phytec_get_som_type")
>
> Signed-off-by: Benjamin Hahn
Applied for u-boot-imx/master, thanks.
Re: [PATCH v1] configs: colibri-imx7: enable watchdog
On Thu, Mar 7, 2024 at 12:23 PM Parth Pancholi wrote: > > From: Parth Pancholi > > Enable watchdog functionality for Toradex's Colibri iMX7 (NAND/EMMC) > modules. > > Signed-off-by: Parth Pancholi Applied for u-boot-imx/next, thanks.
Re: [PATCH] drivers: imx_tmu: Select polling-rate from cpu-thermal devicetree node
On Mon, Mar 4, 2024 at 8:49 AM Benjamin Hahn wrote: > > The polling rate is already specified in some devicetrees, like > imx8mp.dtsi for example, but was not selected so far. For the > trippoints, the cpu-thermal node is used. Also get the polling rate from > this node. Use the default of 5000ms if the polling rate should not be > specified in the devicetree. > > NOTE: The polling rate from the devicetree will be used after this > patch. In imx8*.dtsi devicetrees the polling delay is set to 2000ms for > example. > > Signed-off-by: Benjamin Hahn Applied for u-boot-imx/next, thanks.
[GIT PULL] Please pull u-boot-imx-next-20240317
Hi Tom, Please pull this material for next from u-boot-imx, thank The following changes since commit 099c94b7613bb10d97936447f5136f3a36694325: Merge tag 'u-boot-rockchip-20240315' of https://source.denx.de/u-boot/custodians/u-boot-rockchip into next (2024-03-15 09:15:31 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-next-20240317 for you to fetch changes up to 86b79cf131b64eadae023a127921893d30503093: imx8m*_venice: move venice to OF_UPSTREAM (2024-03-17 18:39:54 -0300) u-boot-imx-next-20240317 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/19975 - Select polling-rate from cpu-thermal devicetree node on imx_tmu. - Re-organize the U-Boot environment and add RAUC logic for phycore_imx8mp. - Enable watchdog on colibri-imx7. - Move imx8mm-venice to use OF_UPSTREAM. Benjamin Hahn (1): drivers: imx_tmu: Select polling-rate from cpu-thermal devicetree node Leonard Anderweit (5): phycore_imx8mp: Move environment from include/config to board phycore_imx8mp: Move default bootcmd to board env configs: phycore-imx8mp_defconfig: Use redundant environment include: env: Add phytec RAUC boot logic board: phytec: phycore_imx8mp: Add RAUC boot logic to environment Parth Pancholi (1): configs: colibri-imx7: enable watchdog Tim Harvey (1): imx8m*_venice: move venice to OF_UPSTREAM arch/arm/dts/Makefile | 17 - arch/arm/dts/imx7d-colibri-eval-v3-u-boot.dtsi |4 + arch/arm/dts/imx8mm-venice-gw700x.dtsi | 525 --- arch/arm/dts/imx8mm-venice-gw71xx-0x.dts | 19 - arch/arm/dts/imx8mm-venice-gw71xx.dtsi | 239 - arch/arm/dts/imx8mm-venice-gw72xx-0x.dts | 19 - arch/arm/dts/imx8mm-venice-gw72xx.dtsi | 400 - arch/arm/dts/imx8mm-venice-gw73xx-0x.dts | 19 - arch/arm/dts/imx8mm-venice-gw73xx.dtsi | 452 -- arch/arm/dts/imx8mm-venice-gw7901.dts | 1137 arch/arm/dts/imx8mm-venice-gw7902.dts | 1052 -- arch/arm/dts/imx8mm-venice-gw7903.dts | 869 -- arch/arm/dts/imx8mm-venice-gw7904.dts | 928 --- arch/arm/dts/imx8mm-venice-gw7905-0x.dts | 28 - arch/arm/dts/imx8mm-venice-gw7905.dtsi | 303 --- arch/arm/dts/imx8mm-venice.dts | 169 arch/arm/dts/imx8mn-venice-gw7902.dts | 980 arch/arm/dts/imx8mn-venice.dts | 169 arch/arm/dts/imx8mp-venice-gw702x.dtsi | 587 arch/arm/dts/imx8mp-venice-gw71xx-2x.dts | 19 - arch/arm/dts/imx8mp-venice-gw71xx.dtsi | 236 - arch/arm/dts/imx8mp-venice-gw72xx-2x.dts | 19 - arch/arm/dts/imx8mp-venice-gw72xx.dtsi | 378 arch/arm/dts/imx8mp-venice-gw73xx-2x.dts | 19 - arch/arm/dts/imx8mp-venice-gw73xx.dtsi | 421 - arch/arm/dts/imx8mp-venice-gw74xx.dts | 1125 --- arch/arm/dts/imx8mp-venice-gw7905-2x.dts | 28 - arch/arm/dts/imx8mp-venice-gw7905.dtsi | 309 --- arch/arm/dts/imx8mp-venice.dts | 183 arch/arm/mach-imx/imx8m/Kconfig|3 + board/gateworks/venice/venice.c|7 +- board/phytec/phycore_imx8mp/phycore_imx8mp.env | 62 ++ configs/colibri_imx7_defconfig |2 + configs/colibri_imx7_emmc_defconfig|2 + configs/imx8mm_venice_defconfig|4 +- configs/imx8mn_venice_defconfig|4 +- configs/imx8mp_venice_defconfig|4 +- configs/phycore-imx8mp_defconfig |4 +- drivers/thermal/imx_tmu.c |6 +- include/configs/phycore_imx8mp.h | 43 - include/env/phytec/rauc.env| 52 ++ 41 files changed, 141 insertions(+), 10705 deletions(-) delete mode 100644 arch/arm/dts/imx8mm-venice-gw700x.dtsi delete mode 100644 arch/arm/dts/imx8mm-venice-gw71xx-0x.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw71xx.dtsi delete mode 100644 arch/arm/dts/imx8mm-venice-gw72xx-0x.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw72xx.dtsi delete mode 100644 arch/arm/dts/imx8mm-venice-gw73xx-0x.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw73xx.dtsi delete mode 100644 arch/arm/dts/imx8mm-venice-gw7901.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw7902.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw7903.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw7904.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw7905-0x.dts delete mode 100644 arch/arm/dts/imx8mm-venice-gw7905.dtsi delete mode 100644 arch/arm/dts/imx8mm-venice.dts delete mode 100644
[GIT PULL] Please pull u-boot-imx-master-20240317
Hi Tom, Please pull these fixes from u-boot-imx, thanks. The following changes since commit 86fd291a7990af84e96808f48eff2219dd4ef496: Merge tag 'efi-2024-04-rc5' of https://source.denx.de/u-boot/custodians/u-boot-efi (2024-03-13 20:39:46 -0400) are available in the Git repository at: https://gitlab.denx.de/u-boot/custodians/u-boot-imx.git tags/u-boot-imx-master-20240317 for you to fetch changes up to e648c4a3455a4d1880efe121602ed90a0bc9b53f: arm: imx: imx8m: soc: Fix NPU/VPU fdt disable fixup (2024-03-17 18:00:04 -0300) u-boot-imx-master-20240317 -- CI: https://source.denx.de/u-boot/custodians/u-boot-imx/-/pipelines/19974 - Fix build error when SoM detection on Phytec board. - Fix sc_misc_otp_fuse_read() error check on colibri-imx8x/apalis-imx8. - Fix NPU/VPU fdt disable fixup on i.MX8M. Benjamin Hahn (1): board: phytec: define get_som_type also when SoM detection is disabled Fabio Estevam (2): colibri-imx8x: Fix sc_misc_otp_fuse_read() error check apalis-imx8: Fix sc_misc_otp_fuse_read() error check Vitor Soares (1): arm: imx: imx8m: soc: Fix NPU/VPU fdt disable fixup arch/arm/mach-imx/imx8m/soc.c | 18 ++ board/phytec/common/phytec_som_detection.c | 5 + board/toradex/apalis-imx8/apalis-imx8.c | 2 +- board/toradex/colibri-imx8x/colibri-imx8x.c | 2 +- 4 files changed, 21 insertions(+), 6 deletions(-)
Bug#901533: mesa: please build intel_sanitize_gpu tool
There is a MR here, but needs to be updated: https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/26
Bug#901533: mesa: please build intel_sanitize_gpu tool
There is a MR here, but needs to be updated: https://salsa.debian.org/xorg-team/lib/mesa/-/merge_requests/26
[KClock] [Bug 483824] New: Timer does not play sound when finished
https://bugs.kde.org/show_bug.cgi?id=483824 Bug ID: 483824 Summary: Timer does not play sound when finished Classification: Applications Product: KClock Version: 24.02.0 Platform: Mint (Ubuntu based) OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: espi...@gmail.com Reporter: fabio.for...@gmail.com CC: hanyo...@protonmail.com Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. set a timer 2. wait for the timer to end OBSERVED RESULT system message, dialog window EXPECTED RESULT system message, dialog window + sound SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: Kernel: 6.5.0-25-generic x86_64 bits: 64 compiler: N/A Desktop: MATE 1.26.0 info: mate-panel wm: marco 1.26.0 dm: LightDM 1.30.0 Distro: Linux Mint 21.3 Virginia base: Ubuntu 22.04 jammy ADDITIONAL INFORMATION In the last version it worked! -- You are receiving this mail because: You are watching all bug changes.
Bug#1018207: mesa: missing svga gallium driver for arm64
Version: 22.2.0-1 "svga" gallium driver was added in 22.2.0-1.
Bug#1018207: mesa: missing svga gallium driver for arm64
Version: 22.2.0-1 "svga" gallium driver was added in 22.2.0-1.
Bug#1025213: gnome-shell: Flickering and mangled screens on wayland if dri driver not available
This was fixed in mutter 43.8 and 44.4 as per mutter report https://gitlab.gnome.org/GNOME/mutter/-/issues/2602
Bug#1025213: gnome-shell: Flickering and mangled screens on wayland if dri driver not available
This was fixed in mutter 43.8 and 44.4 as per mutter report https://gitlab.gnome.org/GNOME/mutter/-/issues/2602
Bug#1041647: radeonsi: no VAAPI support (regression)
Closing as per previous comment.
Bug#1041647: radeonsi: no VAAPI support (regression)
Closing as per previous comment.
Bug#1065131: electron: GPU process crash with AMDGPU, ac: Unknown GPU, using 0 for raster_config
Can you try again with 24.0.3-1 ? Thanks. Il giorno ven 1 mar 2024 alle ore 00:12 Alexis Murzeau ha scritto: > > Package: mesa-va-drivers > Version: 24.0.1-1 > Severity: important > > * What led up to the situation? > Upgrading mesa-va-drivers to version 24.0.1-1 cause GPU process craches > in electron based applications.
Bug#1065131: electron: GPU process crash with AMDGPU, ac: Unknown GPU, using 0 for raster_config
Can you try again with 24.0.3-1 ? Thanks. Il giorno ven 1 mar 2024 alle ore 00:12 Alexis Murzeau ha scritto: > > Package: mesa-va-drivers > Version: 24.0.1-1 > Severity: important > > * What led up to the situation? > Upgrading mesa-va-drivers to version 24.0.1-1 cause GPU process craches > in electron based applications.
Bug#1017819: libgl1-mesa-dri: Memory leak in iris_dri.so causes Xorg to eat all memory and crash every few days
Current Debian stable (12, bookworm) has the fix.
Bug#1017819: libgl1-mesa-dri: Memory leak in iris_dri.so causes Xorg to eat all memory and crash every few days
Current Debian stable (12, bookworm) has the fix.
Bug#1001836: libgl1-mesa-dri: Incorrect texture blitting/mapping seen on Intel (Mesa issue #4412)
Version: 21.0.3-1 Fixed since 21.0.3-1, as per upstream bug report.
Bug#1001836: libgl1-mesa-dri: Incorrect texture blitting/mapping seen on Intel (Mesa issue #4412)
Version: 21.0.3-1 Fixed since 21.0.3-1, as per upstream bug report.
Re: [PRQ#57904] Merge Request for eclipse-cpp-bin
altermetax [1] filed a request to merge eclipse-cpp-bin [2] into eclipse-cpp [3]: - The eclipse-cpp-bin package seems unmaintained - Both eclipse-cpp and eclipse-cpp-bin create the package from pre- built artifacts, however as per the AUR submission guidelines Java software shouldn't have the -bin prefix, so eclipse-cpp should be the correct name. [1] https://aur.archlinux.org/account/altermetax/ [2] https://aur.archlinux.org/pkgbase/eclipse-cpp-bin/ [3] https://aur.archlinux.org/pkgbase/eclipse-cpp/ Please don't merge this, but do it the other way around. This is not an arch=any Java package but a desktop application, therefore the Java exception to '-bin' naming shouldn't apply. AUR/eclipse-cpp should be built from source, or removed and merged to eclipse-cpp-bin. Yes, eclipse isn't a .jar $ file eclipse eclipse: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, forGNU/Linux 3.2.0, BuildID[sha1]=563ac05a1196682d0ea8e7fde3c3389e1917597a, stripped eclipse-cpp-bin is already orphan
Re: [PRQ#57846] Deletion Request for libpamac-aur
paulgureghian [1] filed a deletion request for libpamac-aur [2]: Are you going to update this soon? [1] https://aur.archlinux.org/account/paulgureghian/ [2] https://aur.archlinux.org/pkgbase/libpamac-aur/ Deletion requests are not made for prompting updates You already commented today with: "Needs to be updated so I can update my EOS installation." This is already at the last version 11.6.4 https://gitlab.manjaro.org/applications/libpamac/-/tags The pkgbuild is not flagged OOD Likely you need to rebuild against the the libalpm.so
Re: [PATCH v1] doc: board: colibri-imx8x: Update and improve documentation
Hi Hiago, On Fri, Mar 15, 2024 at 11:39 AM Hiago De Franco wrote: > > From: Hiago De Franco > > Update and improve the building documentation of Colibri iMX8X. > The following changes were made: > - imx-atf repository changed to nxp-imx GitHub. > - imx-atf branch updated to 'lf_v2.6'. > - imx-seco updated to version 5.8.7. > - nxp-imx mfgtools link updated to GitHub releases. > - General writing improvements. Thanks for improving the documentation. One minor suggestion. I have recently followed this document and noticed that the instruction to copy the mx8qm-apalis-scfw-tcm.bin to the U-Boot source is missing. Please add it. Also, since you are updating several components, shouldn't mx8qm-apalis-scfw-tcm.bin be updated? Currently, the version is from toradex-sumo-4.14.78-1.0.0_ga-bringup which looks quite ancient.
