[fedora-arm] Re: F23 on Wandboard Quad -- kernel doesn't start?

[Nicolas Chauvet]

2016-03-03 21:51 GMT+01:00 Derek Atkins :

> Hi,
>
> I'm trying to run F23 on a Wandboard Quad, but it's not booting.  It
> hangs after the "Starting kernel" output.
>
> I followed the instructions at
>
> https://fedoraproject.org/wiki/Architectures/ARM/F23/Installation#For_the_Wandboard_.28Freescale_i.MX6.29
> starting from Fedora-Minimal-armhfp-23-10-sda.raw.xz I installed the
>

If you are on serial you might need to add console=ttymxc0,115200 to the
kernel bootlinux in extlinux.conf
I never tried to boot using hdmi output, so I usually need to add console
there.


-- 
-

Nicolas (kwizart)
___
arm mailing list
arm@lists.fedoraproject.org
http://lists.fedoraproject.org/admin/lists/arm@lists.fedoraproject.org

[fedora-arm] Pixie Case, - Was ARMv5 and atomic operations

[Nicolas Chauvet]

2012/4/25 Nicolas Chauvet :
> 2012/4/23 Dan Horák :
> ..
>> I'm usually skipping such packages as there is a lot of other work on
>> s390, but when I dealt with them I've used either the gcc or C++
>> primitives or the atomic_ops library. The Pixie package seems to be on
>> my list of blocked by atomic ops, there should be more, but I haven't
>> analysed all failures yet.

Hi Dan,

Been the Pixie maintainer and trying to fix the issue. I can test
anything on either my AC100 running F14 or 'soonish' a Pandaboard with
f17 armv7hl.

As Dan told me, there is a need to use a generic gcc intrinsinc code
for atomic_ops from this files:
http://pixie.svn.sourceforge.net/viewvc/pixie/trunk/src/ri/atomic.h?revision=1226&view=markup
The current generic function doesn't work and I wasn't able to sort
that out. (even if it look trivial, there is others problem than
adding a missing headers as the error sugguest)
http://arm.koji.fedoraproject.org/koji/getfile?taskID=753420&name=build.log

I wonder if It wouldn't worth to grab some equivalent ARM asm to
implement the same functions for __ARM_EABI__.

For the record, Pixie is an image renderer engine and requires massive
CPU load which worth to have optim enabled.
This is also a 'Final component' so it will not be triggered by
something that could run on a armv5 only CPU.
So my question is how can I opt-out armv5tel to force armv7l
compilation instead ?

Thx for your help.

Nicolas (kwizart)
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Fwd: DirectFB fixed but not for armv5tel

[Nicolas Chauvet]

Hi,

I've pushed a commit that I have tested (on ARM  F-14) to fix build of directfb.
The problem is that it won't work on armv5tel.

Here is the error:
CE  -std=gnu99 -Werror-implicit-function-declaration -c -o util.lo util.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../../../../..
-I../../../../../include -I../../../../../lib -I../../../../../include
-I../../../../../lib -DDATADIR=\"/usr/share/directfb-1.5.3\"
-DMODULEDIR=\"/usr/lib/directfb-1.5-0\" -D_REENTRANT -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wno-strict-aliasing
-Werror-implicit-function-declaration -O2 -g2 -ffast-math -pipe -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -march=armv5te -mfloat-abi=soft
-D_GNU_SOURCE -std=gnu99 -Werror-implicit-function-declaration -c
util.c  -fPIC -DPIC -o .libs/util.o
{standard input}: Assembler messages:
{standard input}:494: Error: selected processor does not support `ldrex r2,[r3]'
{standard input}:496: Error: selected processor does not support
`strex r0,r2,[r3]'
{standard input}:535: Error: selected processor does not support `ldrex r2,[r3]'
{standard input}:537: Error: selected processor does not support
`strex r0,r2,[r3]'
make[5]: *** [system.lo] Error 1
make[5]: *** Waiting for unfinished jobs
make[5]: Leaving directory
`/srv/ac100-builder/rpmbuild/BUILD/DirectFB-1.5.3/lib/direct/os/linux/glibc'


This is related to the atomic code (this is the same version up2date).
http://git.directfb.org/?p=core/DirectFB.git;a=blob;f=lib/direct/atomic.h;h=fe7664f71444c9f005984a9c4db61b0122491bff;hb=d62f35b4278e0b25eb924b90e51467427c7fec9f

Now I have tested that the same package is fixed if built for armv6l or armv7l.
Should I exclude armv5tel and explicitely build for armv6l and armv7l
? (along with armv7hl).

Nicolas (kwizart)
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Status of vanilla u-boot on tegra based paz00 aka Toshiba ac100

[Nicolas Chauvet]

Hi

I would like to share a recent experiment I made with u-boot v2013.04

As reported upstream, I needed to revert some patches, and add a trivial
one:
http://lists.denx.de/pipermail/u-boot/2013-April/152397.html
http://lists.denx.de/pipermail/u-boot/2013-April/152398.html
It would be interesting to know if others (pandaboard) also have issue
related to theses patches for sdcard boot.

The tegra screen support is now available,but keyboard support is still
missing.
In order to work with keyboard, I used this special tree:
git://gitorious.org/u-boot-ac100-exp/u-boot-ac100-exp.git

Also worth to notice with tegra board, is the recent addition of cbootimage
in our package collection.
http://bugzilla.redhat.com/954117
tegrarcm will be made available elsewhere in the nonfree section (rfbz#2768)

Then I tried to consider using the f18 trimslice image to avoid creating a
new image( with the paz00 dtb added to the uImage). But upstream u-boot
does only support GPT partition, so I would like to know if it can be
considered to force usage of GPT on trimslice images for f19 ?

The next step for me is to build a special kernel that would allow the
framebuffer device to work.
Did others already worked on a kernel config suitable for f18 for the paz00
?

Thx

Nicolas (kwizart)
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] u-boot update testing

[Nicolas Chauvet]

2013/10/21 Dennis Gilmore 

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi All,
>
> I have proposed
> https://admin.fedoraproject.org/updates/uboot-tools-2013.10-2.fc20 as a
> blocker for beta I would appreciate as many people testing it as
> possible and providing karma in bodhi, thanks.
>

Do you have a minimal image to test on Wandboard quad with this updated
u-boot?
So something closer to Beta than TC2 since TC5 isn't booting for me.
Just to share a reference
http://fedoraproject.org/wiki/User:Mrunge/Wandboard_quad

I've tested the previous build on my AC100 and it worked (despite it's
still missing keyboard support in uboot upstream).

Thx
Nicolas (kwizart)
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] sata / ahci support for wandboard quad

[Nicolas Chauvet]

2013/11/23 Ronald 

> Peter,
>
> thanks for the quick reply. I am now running with the kernel you
> recommended, but I still do not see the sata drive (see below).
> Do I need to do anything else?
> thanks, Ronald
>
>
> [root@wandquad ~]# uname -a
> Linux wandquad 3.12.1-2.fc21.armv7hl #1 SMP Thu Nov 21 05:58:27 UTC 2013
> armv7l armv7l armv7l GNU/Linux
> [root@wandquad ~]# fdisk -l
>
> Disk /dev/mmcblk0: 7.2 GiB, 7742685184 bytes, 15122432 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disk label type: dos
> Disk identifier: 0x0009891a
>
> Device Boot Start   End  Blocks  Id System
> /dev/mmcblk0p1   1953   1001953  50+ 83 Linux
> /dev/mmcblk0p21001954   4083711 1540879  83 Linux
> /dev/mmcblk0p34083712  15122431 5519360  83 Linux
>

I've hit the same issue and just modprobe ahci_platform to have sata
support (tested)
That been said, I don't understand what the problem was here: ahci_imx was
loaded but not in the initamfs, and ahci_platform was in the initramfs but
was not loaded. Instead I've

[8.070829] systemd-udevd[211]: starting version 208
[8.437543] [ cut here ]
[8.437605] WARNING: CPU: 1 PID: 234 at fs/sysfs/dir.c:526
sysfs_add_one+0x84/0xa4()
[8.437618] sysfs: cannot create duplicate filename
'/bus/platform/devices/ahci'
[8.437627] Modules linked in: snd_timer(+) ahci_imx(+) snd soundcore
nfsd mmc_block sdhci_esdhc_imx sdhci_pltfm sdhci
[8.437675] CPU: 1 PID: 234 Comm: systemd-udevd Not tainted
3.12.1-2.fc21.armv7hl #1
[8.437741] [] (unwind_backtrace+0x0/0x124) from []
(show_stack+0x18/0x1c)
[8.437782] [] (show_stack+0x18/0x1c) from []
(dump_stack+0x74/0x90)
[8.437823] [] (dump_stack+0x74/0x90) from []
(warn_slowpath_common+0x6c/0x90)
[8.437859] [] (warn_slowpath_common+0x6c/0x90) from
[] (warn_slowpath_fmt+0x34/0x44)
[8.437897] [] (warn_slowpath_fmt+0x34/0x44) from []
(sysfs_add_one+0x84/0xa4)
[8.437927] [] (sysfs_add_one+0x84/0xa4) from []
(sysfs_do_create_link_sd+0x118/0x1e8)
[8.437969] [] (sysfs_do_create_link_sd+0x118/0x1e8) from
[] (bus_add_device+0xec/0x184)
[8.437994] [] (bus_add_device+0xec/0x184) from []
(device_add+0x4ec/0x624)
[8.438022] [] (device_add+0x4ec/0x624) from []
(platform_device_add+0x168/0x204)
[8.438054] [] (platform_device_add+0x168/0x204) from
[] (imx_ahci_probe+0x1a4/0x1f4 [ahci_imx])
[8.438081] [] (imx_ahci_probe+0x1a4/0x1f4 [ahci_imx]) from
[] (platform_drv_probe+0x1c/0x20)
[8.438103] [] (platform_drv_probe+0x1c/0x20) from
[] (driver_probe_device+0x130/0x32c)
[8.438122] [] (driver_probe_device+0x130/0x32c) from
[] (bus_for_each_drv+0x7c/0x90)
[8.438141] [] (bus_for_each_drv+0x7c/0x90) from []
(device_attach+0x6c/0x90)
[8.438160] [] (device_attach+0x6c/0x90) from []
(bus_probe_device+0x30/0xa0)
[8.438180] [] (bus_probe_device+0x30/0xa0) from []
(device_add+0x540/0x624)
[8.438197] [] (device_add+0x540/0x624) from []
(platform_device_add+0x168/0x204)
[8.438217] [] (platform_device_add+0x168/0x204) from
[] (imx_ahci_probe+0x1a4/0x1f4 [ahci_imx])
[8.438240] [] (imx_ahci_probe+0x1a4/0x1f4 [ahci_imx]) from
[] (platform_drv_probe+0x1c/0x20)
[8.438260] [] (platform_drv_probe+0x1c/0x20) from
[] (driver_probe_device+0x130/0x32c)
[8.438280] [] (driver_probe_device+0x130/0x32c) from
[] (__driver_attach+0x70/0x94)
[8.438361] [] (__driver_attach+0x70/0x94) from []
(bus_for_each_dev+0x78/0x8c)
[8.438387] [] (bus_for_each_dev+0x78/0x8c) from []
(bus_add_driver+0x108/0x274)
[8.438415] [] (bus_add_driver+0x108/0x274) from []
(driver_register+0xa4/0xe8)
[8.438434] [] (driver_register+0xa4/0xe8) from []
(do_one_initcall+0xcc/0x188)
[8.438472] [] (do_one_initcall+0xcc/0x188) from []
(load_module+0x1854/0x1e24)
[8.438493] [] (load_module+0x1854/0x1e24) from []
(SyS_finit_module+0x90/0xa8)
[8.438519] [] (SyS_finit_module+0x90/0xa8) from []
(ret_fast_syscall+0x0/0x30)
[8.438530] ---[ end trace 7e0a411d1d766543 ]---
[8.438665] ahci-imx: probe of ahci failed with error -17
[8.438851] platform ahci: failed to claim resource 0
[8.443998] ahci-imx: probe of ahci failed with error -16

I tried to add ahci_imx to the initamfs, but I didn't solved anything, so I
might have a module dependency issue there, or something related to the
sysfs warning...

There is also no rtc support, device tree describe one, but I guess the
driver isn't here yet...

Nicolas (kwizart)
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] ARM Tegra Toshiba AC100 Fedora 19 Remix

[Nicolas Chauvet]

Hello,

Here is a simplified process to install the Fedora 19 armhfp remix for the
Toshiba AC100
You need to have:
- The BCT retrieved from your specific AC100 device (as ac100.bct)
- A mini-usb/usb cable
- A sdcard at least 4GB class 10
- The Toshiba AC100 device itself.

# yum install tegrarcm cbootimage
# curl -O
http://dl.kwizart.net/pub/ac100/Fedora-LXDE-AC100-Remix-19-1-sda.raw.xz
# curl -O 
http://dl.kwizart.net/pub/ac100/Fedora-LXDE-AC100-Remix-19-1-sda.raw.xz.CHECKSUM
#sha256sum -c Fedora-LXDE-AC100-Remix-19-1-sda.raw.xz.CHECKSUM
 Fedora-LXDE-AC100-Remix-19-1-sda.raw.xz: OK
# xzcat Fedora-LXDE-AC100-Remix-19-1-sda.raw.xz > /dev/sd? (the
# partprobe /dev/sd?
# cp -p /run/media/*/__/usr/share/uboot-paz00/u-boot-dtb-tegra.bin .
Plug your AC100 to the host via the USB cable and power-on the device
holding  + . That will enter the device into the recovery mode
of the tegra device.
Plug the sdcard into the device
# tegrarcm --bct ac100.bct --bootloader u-boot-dtb-tegra.bin
--loadaddr=0x00108000

You should see the uboot text booting the 3.10 kernel,
..., then it should start the initial-setup of Fedora 19 LXDE


Known issues. (please read carefully)
- The right rtc isn't selected by default, the wired rtc is available as
/dev/rtc1
Better is to set time during initial-setup, rely on network time, or do
this on cold boot:
/sbin/hwclock --hctosys -f /dev/rtc1 && /sbin/hwclock --systohc -f /dev/rtc0
-  Sometime the screen poweron/off  sequence fails, you need to hold power
button
-  No sound yet

Updating u-boot, choices:
- Keeping the original proprietary bootloader
You will need to keep booting with the usb cable and tegrarcm from another
host:
- Updating to the provided uboot form the remix.
This version adds non-upstream patches over the fedora uboot package to
support the tegra keyboard. So it's a quite decent choice
- Using the android cyanogen remix from zombah (Recommended).
You need to install the cm-paz00 remix first, then plugin the sdcard after
xzcat step and just poweron. The device will boot using the sdcard.


Installing Fedora into the internal mmc:
 Not tested yet.

Next steps is to backport what is needed from 3.14 to 3.13, so I can build
a f20 Remix.
We can envision to support the device by Fedora 21.(exept for the uboot kb).
What will remains is about how to select the right Xorg ddx and probably
few dracuts adjustments.

Resources:
https://dl.kwizart.net/pub/ac100/
http://repos.fedorapeople.org/repos/kwizart/ac100/
http://fedorapeople.org/cgit/kwizart/public_git/kernel.git/log/?h=f19-3.10-ac100
http://ac100.grandou.net/start
https://code.google.com/p/cm-paz00/
http://http.download.nvidia.com/tegra-public-appnotes/

Nicolas (kwizart)
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Fedora ARM Status Meeting Minutes 2014-03-05

[Nicolas Chauvet]

2014-03-06 0:09 GMT+01:00 Paul Whalen :

>
>
> Thanks to those that were able to join us for the status meeting today,
> for those unable the minutes are posted below:
>
>
>
>
> 
> #fedora-meeting-1: Fedora ARM status meeting
> 
>
>
> Meeting summary
> ---
> * 1) Kernel Update  (pwhalen, 21:02:58)
>   * 3.13 appears solid for supported targets  (bconoboy, 21:07:03)
>   * 3.14 is being worked on now, utilite is being investigated, other
> imx6 device support is likely to work as well.  (bconoboy, 21:07:31)
>   * 3.14 looking good on aarch64 foundation model  (bconoboy, 21:07:46)
>   * Some known issues in 3.13/3.14 with displays on trimslice/bbb, need
> investigation  (bconoboy, 21:09:38)
>   * ACTION: pwhalen to file BZs on display issues  (bconoboy, 21:10:17)
>
> * 2) Creating Fedora ARM Remixes  (pwhalen, 21:11:37)
>   * LINK:
> https://fedoraproject.org/wiki/Architectures/ARM/Creating_Remixes
> (pwhalen, 21:14:14)
>   * The number of supported devices has decreased over time due to
> semiconductor decisions (EOL omap3/4 etc)  (bconoboy, 21:17:53)
>   * We want to start ramping up the number of supported devices through
> the use of remixes until F21 comes out  (bconoboy, 21:18:34)
>   * LINK: Today's how to make a remix documentation is at
> https://fedoraproject.org/wiki/Architectures/ARM/Creating_Remixes
> (bconoboy, 21:20:20)
>
> * 3) ARM representation in Fedora Working Groups  (pwhalen, 21:26:08)
>   * Per dgilmore, server wg is considering arm, cloud is keeping it on
> the radar, workstation is only thinking of x86_64  (bconoboy,
> 21:29:56)
>   * LINK: https://fedoraproject.org/wiki/Cloud_Changelist   (dgilmore,
> 21:30:36)
>   * LINK:
> https://fedoraproject.org/wiki/Workstation/Technical_Specification
> (dgilmore, 21:31:01)
>   * LINK: https://fedoraproject.org/wiki/Server/Technical_Specification
> (dgilmore, 21:31:23)
>   * LINK: Cloud WG info https://fedoraproject.org/wiki/Cloud_Changelist
> (bconoboy, 21:31:41)
>   * LINK: Workstation technical spec:
> https://fedoraproject.org/wiki/Workstation/Technical_Specification
> (bconoboy, 21:31:52)
>   * LINK: Server technical spec:
> https://fedoraproject.org/wiki/Server/Technical_Specification
> (bconoboy, 21:31:59)
>   * Server WG is considering xfs for /boot, but uboot doesn't support
> xfs meaning arm cannot follow this spec.  (bconoboy, 21:32:52)
>   * Workstation spec is 64 bit only and requires 3d drivers: Could be
> extended to arm32 if 3d drivers become available  (bconoboy,
> 21:36:27)
>   * ACTION: masta to keep an eye on server WG for armv7hl: follow up on
> HW virt hardware remix and ext2fs issue  (bconoboy, 21:49:56)
>   * ACTION: dgilmore to keep an eye on workstation WG for armv7hl:
> follow up on 3d graphics driver  (bconoboy, 21:50:13)
>
> * 4) Open Floor  (pwhalen, 21:53:59)
>   * dgilmore is working on swtiching all uboots to use extlinux.conf
> (bconoboy, 21:56:37)
>   * LINK: http://fedoraproject.org/wiki/Changes/u-boot_syslinux
> (dgilmore, 21:57:09)
>   * http://fedoraproject.org/wiki/Changes/u-boot_syslinux  (pbrobinson,
> 21:57:25)
>   * ACTION: kwizart will file BZes for his rtc and fbdev issues
> (bconoboy, 22:13:02)
>
> Meeting ended at 22:13:19 UTC.
>
>
>
>
> Action Items
> 
> * pwhalen to file BZs on display issues
> * masta to keep an eye on server WG for armv7hl: follow up on HW virt
>   hardware remix and ext2fs issue
> * dgilmore to keep an eye on workstation WG for armv7hl: follow up on 3d
>   graphics driver
> * kwizart will file BZes for his rtc and fbdev issues
>
>
>
>
> Action Items, by person
> ---
> * dgilmore
>   * dgilmore to keep an eye on workstation WG for armv7hl: follow up on
> 3d graphics driver
> * kwizart
>   * kwizart will file BZes for his rtc and fbdev issues
>  


FYI
This is the tegra fbdev issue
https://bugzilla.redhat.com/show_bug.cgi?id=1073960

This is the rtc issue on ARM
https://bugzilla.redhat.com/show_bug.cgi?id=1074002


Nicolas (kwizart)
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] Mythtv on fedora arm

[Nicolas Chauvet]

2014-04-23 20:28 GMT+02:00 Timothy Krantz :

> Hi,
> This is a copy of a message I sent to the mythtv mailing list the other
> day.
> I thought there might be some interest about it here as well.
>
> Subsequent to this post I was also able to get mythtv to work on an MK802
> device. Audio has stabilized.  The only current problem is that is tries to
> play at a higher than normal FPS.
>
> Tim
>
> I ran across some notes that said there was now VDPAU for the sunxi/mali400
> chip devices.  It seems to sit on top of the "binary blob" drivers.
>
> So, I fired up my trusty hackberry board and installed Fedora 20, got it
> completely up to date with the latest kernel off of the sunxi site.
> 3.4.79ish.  Followed all the instructions on installing "binary blob"
> drivers and fbturbo and finally VDPAU.
>
> Then, being a masochist I downloaded the latest fixes .027 and went about
> compiling mythtv.  Yes on the hackberry itself, I have not yet fiddled with
> cross compiling.  I only compiled libs programs and yes it took forever.
> There was a syntax error in the ffmpeg portion.  I found a patch for it in
> the ffmpeg forums and then it compiled ok.  In fact everything compiled ok.
>
> So, I fired up mythfrontend.  Damned if it did not come up.  I set video
> play back to vdpau slim, audio to the hdmi device and went to play back a
> recording.  I chose a very low file for my first test.  A recording of "It
> takes a thief".  After some crackling, it played.  Yep it played.  Not
> perfectly.  Not usably, but it played.  Oddly it played too fast as if I
> had
> chosen to play it back at maybe 1.5 times normal.  There was some video
> tearing but the VDPAU stuff is still very new, perhaps that will change.  I
> can't get the OSD to appear, not sure why.  Choosing OpenGL for the painter
> gives a black screen (I fell back to qt).  Oh and playback continued with
> 30-50 percent idle processor.  Audio seems to be sketchy, I will try it
> with
> the non-hdmi connector to see if that makes a difference.
> Playing back higher quality digital programs produced similar results.
> Attempts to playback recordings from my HDPVR resulted in a ball of
> scrambled pixels in the center of the screen




FYI mythtv could be redistributed on this well known third party project,
but the bug you were talking about still prevent it:
https://bugzilla.rpmfusion.org/show_bug.cgi?id=2891
Any chances that you can submit a working patch against the current
mythtv.spec file ?

Also I wonder if your setup can work better with OpenGLES over OpenGL on
arm, in which case you might need to evaluate if recompiling qt with
OpenGLES will work better in your case ?...
https://bugzilla.redhat.com/show_bug.cgi?id=967365


Thx for your feedbacks.

Nicolas (kwizart)
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] [PATCH] Bump CMA to 64M by default as found in 3.15 multi_v7_defconfig

[Nicolas Chauvet]

The commit d1c912c1001f was made into tegra_defconfig and later
forwared to multi_v7_deconfig as 0c86f089e66a93

Quoting original commit into the kernel tree:
- Allocate 64 MiB for CMA by default; the default 16MiB is not enough
  for the majority of use-cases. This can still be overridden by the cma
  command-line option.

If this patch is not applied, KMS drivers using CMA would
rapidly exhaust the allocated memory. This was seen on tegra_drm
(from tagr libdrm/opentegra with exa support on freedesktop.org)
...
kernel: host1x drm: failed to allocate buffer with size 2457600
...

On the other side, CMA allocated memory can easily be freed
http://lwn.net/Articles/486301/
"Freeing memory is much simpler process..."
Whereas they can only be allocated at boot time
https://lkml.org/lkml/2014/5/7/810
"CMA is introduced to provide physically contiguous pages at runtime.
For this purpose, it reserves memory at boot time."

This patch is about to have a convenient generic default
and to match upstream kernel default value.
Everything can be setup back into fedora tools such as arm-boot-config

At some point, tegra revisions that can support IOMMU  will not
rely on CMA. This is not the case for tegra20

Tested on Toshiba AC100 (with 512M RAM with cma=128M zram=1x128M)
with opentegra DDX driver
---
 config-arm-generic |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/config-arm-generic b/config-arm-generic
index 0c5242c..158ea5c 100644
--- a/config-arm-generic
+++ b/config-arm-generic
@@ -162,7 +162,7 @@ CONFIG_THERMAL_GOV_USER_SPACE=y
 CONFIG_CMA=y
 CONFIG_DMA_CMA=y
 # CONFIG_CMA_DEBUG is not set
-CONFIG_CMA_SIZE_MBYTES=16
+CONFIG_CMA_SIZE_MBYTES=64
 CONFIG_CMA_SIZE_SEL_MBYTES=y
 # CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
 # CONFIG_CMA_SIZE_SEL_MIN is not set
-- 
1.7.2.1

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Testing CMA=64M on low memory devices (BeagleBones)

[Nicolas Chauvet]

Hi,

I would request beaglebones users (either Black or white) to do some tests
about a possible
cma=64M to be set on kernel cmdline:

# sed -i 's/^ABC_BASEARGS="\(.*\)"/ABC_BASEARGS="\1 cma=64M\"/'
/etc/sysconfig/arm-boot-config
# a-b-c
# reboot

By default cma is set to 16 and is not enought for some cases: (see
rhbz#1127000)
The goal is to see how it behaves on bb

Journalctl -b currently shows:
  cma: CMA: reserved 16 MiB at 3e80
At should show 64 MiB on the next boot.

What would be nice to test is for possible regression on memory usage or
else.
I let the cma conservative camp to provide any appropriate tests to support
theirs arguments:
https://bugzilla.redhat.com/show_bug.cgi?id=1127000#c15


Nicolas (kwizart)

stress -m 512Mstress -m 512M
stress -m 512M

-- 
-

Nicolas (kwizart)
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] [PATCH] [ARM] Enable kernel-lpae for tegra devices

[Nicolas Chauvet]

From: Stephen Warren 

Move config options from config-armv7 cpu config options to
config-armv7-generic so that they can be shared with kernel-lpae
rhbz#1110963
---
 config-armv7 |   60 ++---
 config-armv7-generic |   46 ++
 config-armv7-lpae|   23 +++---
 3 files changed, 68 insertions(+), 61 deletions(-)

diff --git a/config-armv7 b/config-armv7
index 21f56c6..a2afb2b 100644
--- a/config-armv7
+++ b/config-armv7
@@ -10,7 +10,7 @@ CONFIG_ARCH_OMAP4=y
 CONFIG_ARCH_PICOXCELL=y
 CONFIG_ARCH_QCOM=y
 CONFIG_ARCH_ROCKCHIP=y
-CONFIG_ARCH_TEGRA=y
+# CONFIG_ARCH_SOCFPGA is not set
 CONFIG_ARCH_U8500=y
 # CONFIG_ARCH_VIRT is not set
 CONFIG_ARCH_ZYNQ=y
@@ -562,47 +562,16 @@ CONFIG_IIO_ST_SENSORS_I2C=m
 CONFIG_IIO_ST_SENSORS_SPI=m
 CONFIG_IIO_ST_SENSORS_CORE=m
 
-# tegra
+# Tegra
+# (Options only needed by platforms that don't have LPAE):
 CONFIG_ARCH_TEGRA_2x_SOC=y
 CONFIG_ARCH_TEGRA_3x_SOC=y
-CONFIG_ARCH_TEGRA_114_SOC=y
-CONFIG_ARCH_TEGRA_124_SOC=y
-CONFIG_ARM_TEGRA_CPUFREQ=y
 CONFIG_TEGRA20_MC=y
-CONFIG_TEGRA30_MC=y
-CONFIG_TRUSTED_FOUNDATIONS=y
-
-CONFIG_SERIAL_TEGRA=y
-
-CONFIG_AHCI_TEGRA=m
-
-CONFIG_PCI_TEGRA=y
 CONFIG_TEGRA_IOMMU_GART=y
-CONFIG_TEGRA_IOMMU_SMMU=y
-CONFIG_MMC_SDHCI_TEGRA=m
-CONFIG_TEGRA_WATCHDOG=m
-CONFIG_I2C_TEGRA=m
-CONFIG_TEGRA_SYSTEM_DMA=y
-CONFIG_TEGRA_EMC_SCALING_ENABLE=y
-CONFIG_TEGRA_AHB=y
-CONFIG_TEGRA20_APB_DMA=y
-CONFIG_SPI_TEGRA114=m
 CONFIG_SPI_TEGRA20_SFLASH=m
 CONFIG_SPI_TEGRA20_SLINK=m
-CONFIG_PWM_TEGRA=m
 CONFIG_MFD_MAX8907=m
-CONFIG_KEYBOARD_TEGRA=m
-CONFIG_PINCTRL_TEGRA=y
-CONFIG_PINCTRL_TEGRA20=y
-CONFIG_PINCTRL_TEGRA30=y
-CONFIG_USB_EHCI_TEGRA=m
-CONFIG_RTC_DRV_TEGRA=m
-CONFIG_CRYPTO_DEV_TEGRA_AES=m
-
-CONFIG_SND_SOC_TEGRA=m
 CONFIG_SND_SOC_TEGRA_ALC5632=m
-CONFIG_SND_SOC_TEGRA_MAX98090=m
-CONFIG_SND_SOC_TEGRA_RT5640=m
 CONFIG_SND_SOC_TEGRA_TRIMSLICE=m
 CONFIG_SND_SOC_TEGRA_WM8753=m
 CONFIG_SND_SOC_TEGRA_WM8903=m
@@ -610,10 +579,6 @@ CONFIG_SND_SOC_TEGRA_WM9712=m
 CONFIG_SND_SOC_TEGRA20_AC97=m
 CONFIG_SND_SOC_TEGRA20_DAS=m
 CONFIG_SND_SOC_TEGRA20_SPDIF=m
-CONFIG_SND_SOC_TEGRA30_AHUB=m
-CONFIG_SND_SOC_TEGRA30_I2S=m
-CONFIG_SND_HDA_TEGRA=m
-
 # AC100 (PAZ00)
 CONFIG_MFD_NVEC=y
 CONFIG_MFD_TPS80031=y
@@ -626,25 +591,6 @@ CONFIG_MFD_TPS6586X=y
 CONFIG_GPIO_TPS6586X=y
 CONFIG_RTC_DRV_TPS6586X=m
 
-# Jetson TK1
-CONFIG_PINCTRL_AS3722=y
-CONFIG_POWER_RESET_AS3722=y
-CONFIG_MFD_AS3722=y
-CONFIG_REGULATOR_AS3722=m
-CONFIG_RTC_DRV_AS3722=y
-
-CONFIG_TEGRA_HOST1X=m
-CONFIG_TEGRA_HOST1X_FIREWALL=y
-CONFIG_DRM_TEGRA=m
-CONFIG_DRM_TEGRA_FBDEV=y
-# CONFIG_DRM_TEGRA_DEBUG is not set
-CONFIG_DRM_TEGRA_STAGING=y
-CONFIG_DRM_PANEL=y
-CONFIG_DRM_PANEL_SIMPLE=m
-CONFIG_DRM_PANEL_LD9040=m
-CONFIG_DRM_PANEL_S6E8AA0=m
-CONFIG_NOUVEAU_PLATFORM_DRIVER=m
-
 # OLPC XO
 CONFIG_SERIO_OLPC_APSP=m
 
diff --git a/config-armv7-generic b/config-armv7-generic
index 10ab6b6..07d53fd 100644
--- a/config-armv7-generic
+++ b/config-armv7-generic
@@ -54,6 +54,7 @@ CONFIG_IRQ_CROSSBAR=y
 CONFIG_ARCH_EXYNOS=y
 CONFIG_ARCH_HIGHBANK=y
 CONFIG_ARCH_SUNXI=y
+CONFIG_ARCH_TEGRA=y
 CONFIG_ARCH_VEXPRESS_CA9X4=y
 CONFIG_ARCH_VEXPRESS_CORTEX_A5_A9_ERRATA=y
 # CONFIG_ARCH_BCM is not set
@@ -291,6 +292,51 @@ CONFIG_RTC_DRV_MAX8997=m
 CONFIG_RTC_DRV_MAX77686=m
 CONFIG_EXTCON_MAX8997=m
 
+# Tegra
+CONFIG_ARCH_TEGRA_114_SOC=y
+CONFIG_ARCH_TEGRA_124_SOC=y
+CONFIG_ARM_TEGRA_CPUFREQ=y
+CONFIG_TEGRA30_MC=y
+CONFIG_TRUSTED_FOUNDATIONS=y
+CONFIG_SERIAL_TEGRA=y
+CONFIG_AHCI_TEGRA=m
+CONFIG_PCI_TEGRA=y
+CONFIG_TEGRA_IOMMU_SMMU=y
+CONFIG_MMC_SDHCI_TEGRA=m
+CONFIG_TEGRA_WATCHDOG=m
+CONFIG_I2C_TEGRA=m
+CONFIG_TEGRA_SYSTEM_DMA=y
+CONFIG_TEGRA_EMC_SCALING_ENABLE=y
+CONFIG_TEGRA_AHB=y
+CONFIG_TEGRA20_APB_DMA=y
+CONFIG_SPI_TEGRA114=m
+CONFIG_PWM_TEGRA=m
+CONFIG_KEYBOARD_TEGRA=m
+CONFIG_USB_EHCI_TEGRA=m
+CONFIG_RTC_DRV_TEGRA=m
+CONFIG_SND_SOC_TEGRA=m
+CONFIG_SND_SOC_TEGRA_MAX98090=m
+CONFIG_SND_SOC_TEGRA_RT5640=m
+CONFIG_SND_SOC_TEGRA30_AHUB=m
+CONFIG_SND_SOC_TEGRA30_I2S=m
+CONFIG_SND_HDA_TEGRA=m
+CONFIG_TEGRA_HOST1X=m
+CONFIG_TEGRA_HOST1X_FIREWALL=y
+CONFIG_DRM_TEGRA=m
+CONFIG_DRM_TEGRA_FBDEV=y
+# CONFIG_DRM_TEGRA_DEBUG is not set
+CONFIG_DRM_TEGRA_STAGING=y
+CONFIG_DRM_PANEL=y
+CONFIG_DRM_PANEL_SIMPLE=m
+CONFIG_DRM_PANEL_LD9040=m
+CONFIG_DRM_PANEL_S6E8AA0=m
+# Jetson TK1
+CONFIG_PINCTRL_AS3722=y
+CONFIG_POWER_RESET_AS3722=y
+CONFIG_MFD_AS3722=y
+CONFIG_REGULATOR_AS3722=m
+CONFIG_RTC_DRV_AS3722=y
+
 # regmap
 CONFIG_REGMAP=y
 CONFIG_REGMAP_I2C=m
diff --git a/config-armv7-lpae b/config-armv7-lpae
index 7ad1fce..2536087 100644
--- a/config-armv7-lpae
+++ b/config-armv7-lpae
@@ -13,6 +13,7 @@ CONFIG_ARCH_VIRT=y
 # CONFIG_SOC_DRA7XX is not set
 # CONFIG_ARCH_ROCKCHIP is not set
 # CONFIG_ARCH_TEGRA is not set
+# CONFIG_ARCH_SOCFPGA is not set
 # CONFIG_ARCH_ZYNQ is not set
 # CONFIG_ARCH_AXXIA is not set
 
@@ -65,7 +66,21 @@ CONFIG_TI_DAVINCI_MDIO=m
 # CONFIG_SND_DAVINCI_SOC is not set
 # CONFIG_TI_SOC_THERMAL is not set
 
-# CONFIG_TEGRA_HOST1X 

[fedora-arm] [PATCH] Switch CMA to 10% RAM on armv7l and 128M on lpae/arm64

[Nicolas Chauvet]

This should offer an ever better conveniant default
than the default to 64M found in multi_v7_defconfig.
That, before a per-board solution to be found.
See rhbz#1127000

RAM  CMA
armv7   128M??? ~13M
256M~26M
512M~51M
1G ~102M
2G  205M
lpae2G min? 128M
arm64   2G min? 128M

As already determined, CMA allocated memory can only be
set at boot time, whereas they can be used for others
purpose at runtime.

Quoting drivers/base/dma-contiguous.c:
--
/*
 * Default global CMA area size can be defined in kernel's .config.
 * This is useful mainly for distro maintainers to create a kernel
 * that works correctly for most supported systems.
 * The size can be set in bytes or as a percentage of the total memory
 * in the system.
 *
 * Users, who want to set the size of global CMA area for their system
 * should use cma= kernel parameter.
 */
--
---
 config-arm-generic |4 ++--
 config-arm64   |5 +
 config-armv7   |5 +
 config-armv7-lpae  |5 +
 4 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/config-arm-generic b/config-arm-generic
index ac89eb2..68e84e8 100644
--- a/config-arm-generic
+++ b/config-arm-generic
@@ -167,8 +167,8 @@ CONFIG_THERMAL_GOV_USER_SPACE=y
 CONFIG_CMA=y
 CONFIG_DMA_CMA=y
 # CONFIG_CMA_DEBUG is not set
-CONFIG_CMA_SIZE_MBYTES=16
-CONFIG_CMA_SIZE_SEL_MBYTES=y
+# CONFIG_CMA_SIZE_MBYTES is not set
+# CONFIG_CMA_SIZE_SEL_MBYTES is not set
 # CONFIG_CMA_SIZE_SEL_PERCENTAGE is not set
 # CONFIG_CMA_SIZE_SEL_MIN is not set
 # CONFIG_CMA_SIZE_SEL_MAX is not set
diff --git a/config-arm64 b/config-arm64
index f6c244e..4c2a78d 100644
--- a/config-arm64
+++ b/config-arm64
@@ -42,6 +42,11 @@ CONFIG_HAVE_NET_DSA=y
 CONFIG_HVC_DRIVER=y
 CONFIG_HZ=100
 
+# Set arm64 kernel cma size
+# see rhbz#1127000
+CONFIG_CMA_SIZE_MBYTES=128
+CONFIG_CMA_SIZE_SEL_MBYTES=y
+
 CONFIG_KVM=y
 CONFIG_KVM_ARM_MAX_VCPUS=8
 CONFIG_LOG_BUF_SHIFT=14
diff --git a/config-armv7 b/config-armv7
index a2afb2b..7200ae7 100644
--- a/config-armv7
+++ b/config-armv7
@@ -21,6 +21,11 @@ CONFIG_ARCH_ZYNQ=y
 # CONFIG_ARM_VIRT_EXT is not set
 # CONFIG_VIRTUALIZATION is not set
 
+# Set non-lpae kernel cma size
+# see rhbz#1127000
+CONFIG_CMA_SIZE_PERCENTAGE=10
+CONFIG_CMA_SIZE_SEL_PERCENTAGE=y
+
 # mvebu
 CONFIG_MACH_ARMADA_370_XP=y
 CONFIG_MACH_ARMADA_370=y
diff --git a/config-armv7-lpae b/config-armv7-lpae
index 2536087..0dbf811 100644
--- a/config-armv7-lpae
+++ b/config-armv7-lpae
@@ -28,6 +28,11 @@ CONFIG_ARM_DMA_IOMMU_ALIGNMENT=8
 CONFIG_ARM_ERRATA_798181=y
 CONFIG_ARM_ERRATA_773022=y
 
+# Set lpae kernel cma size
+# see rhbz#1127000
+CONFIG_CMA_SIZE_MBYTES=128
+CONFIG_CMA_SIZE_SEL_MBYTES=y
+
 CONFIG_KVM=y
 CONFIG_KVM_ARM_HOST=y
 CONFIG_KVM_ARM_MAX_VCPUS=8
-- 
1.7.2.1

___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

Re: [fedora-arm] [PATCH] [ARM] Enable kernel-lpae for tegra devices

[Nicolas Chauvet]

2014-08-21 21:40 GMT+02:00 Peter Robinson :
>
> Why are you sending this to the list when there's already a BZ?

Hi Peter,

This was just a trivial rebase on top of 3.17.
But after my tests the nouveau pull request was merged, so there is a need
of an additional
CONFIG_NOUVEAU_PLATFORM_DRIVER=m in armv7-generic
So both patches need to be applied together. I tought I was sending the
squashed version.

Scratch build with all the 3 patches applied:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7437142

Nicolas (kwizart)
___
arm mailing list
arm@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/arm

[fedora-arm] Feedback needed on wandboard single/dual

[Nicolas Chauvet]

Hello,

I've send a patch to u-boot upstream that enable sata on wandboard quad.
This patch operates as appropriate on the device, but it also need to
be tested on wandboard single/dual which don't have the sata port.
(because the u-boot binary is the same for all board variants).

https://lists.denx.de/pipermail/u-boot/2017-February/281505.html

You need to apply the patch to the current u-boot upstream tree (or to
the u-boot fedora spec) and report the serial output

Thx for sending the feedback to the u-boot ml directly. (eventually
with Sefano Babic cc'ed).



-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: U-Boot not working with imx6

[Nicolas Chauvet]

2017-05-23 1:06 GMT+02:00 Andrew Gillis :
> I am using an imx6 SoM from SolidRun. We have purchased a large number of
> these and mostly they work fine.
>
> I tried to update to Fedora 25 and now a few of them won't boot. (most work
> fine)
>
> All my SoMs are all supposed to be the same but some must be different. Both
> worked fine with an older version of Fedora
>
> Is there any way to just force a boot from MMC1 with no checks?
>
> I tried to update to the u-boot from Fedora 26 just to see if that would
> help. It does not.
>
>
> This is what I get with the "bad" ones
>
>
> U-Boot SPL 2016.09.01 (Oct 19 2016 - 14:40:29)
> Trying to boot from unknown boot device
> SPL: Unsupported Boot Device!
> SPL: failed to boot from all boot devices
> ### ERROR ### Please RESET the board ###
>
>
> The ones that boot correctly do this
>
>
> U-Boot SPL 2016.09.01 (Oct 19 2016 - 14:40:29)
> Trying to boot from MMC1
>
>
> U-Boot 2016.09.01 (Oct 19 2016 - 14:40:29 +)
>
> CPU:   Freescale i.MX6DL rev1.3 996 MHz (running at 792 MHz)
> CPU:   Commercial temperature grade (0C to 95C) at 28C
> Reset cause: POR
> Board: MX6 Hummingboard
> DRAM:  1 GiB
> MMC:   FSL_SDHC: 0
> *** Warning - bad CRC, using default environment
It means that it's using the default environment because no custom env
was ever saved.
try (on the devices that do not boot)
resetenv
savenv




-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: U-Boot not working with imx6

[Nicolas Chauvet]

So it means that you probably need to report the problem to u-boot
upstream as a normal u-boot binary should discover the right boot
device without additional tweak.
Or do you have a link to the report ?


2017-05-23 21:26 GMT+02:00 Andrew Gillis :
> Thanks that didn't work but it turns out the new version of u-boot doesn't
> work correctly if the SRC_SBMR1 value is not set. The old version figured it
> out somehow.
>
> I modified u-boot to always boot from the MMC and now it works fine. Thanks
> for your help.
>
> -Andrew
>
> On Tue, May 23, 2017 at 3:06 AM, Nicolas Chauvet  wrote:
>>
>> 2017-05-23 1:06 GMT+02:00 Andrew Gillis :
>> > I am using an imx6 SoM from SolidRun. We have purchased a large number
>> > of
>> > these and mostly they work fine.
>> >
>> > I tried to update to Fedora 25 and now a few of them won't boot. (most
>> > work
>> > fine)
>> >
>> > All my SoMs are all supposed to be the same but some must be different.
>> > Both
>> > worked fine with an older version of Fedora
>> >
>> > Is there any way to just force a boot from MMC1 with no checks?
>> >
>> > I tried to update to the u-boot from Fedora 26 just to see if that would
>> > help. It does not.
>> >
>> >
>> > This is what I get with the "bad" ones
>> >
>> >
>> > U-Boot SPL 2016.09.01 (Oct 19 2016 - 14:40:29)
>> > Trying to boot from unknown boot device
>> > SPL: Unsupported Boot Device!
>> > SPL: failed to boot from all boot devices
>> > ### ERROR ### Please RESET the board ###
>> >
>> >
>> > The ones that boot correctly do this
>> >
>> >
>> > U-Boot SPL 2016.09.01 (Oct 19 2016 - 14:40:29)
>> > Trying to boot from MMC1
>> >
>> >
>> > U-Boot 2016.09.01 (Oct 19 2016 - 14:40:29 +)
>> >
>> > CPU:   Freescale i.MX6DL rev1.3 996 MHz (running at 792 MHz)
>> > CPU:   Commercial temperature grade (0C to 95C) at 28C
>> > Reset cause: POR
>> > Board: MX6 Hummingboard
>> > DRAM:  1 GiB
>> > MMC:   FSL_SDHC: 0
>> > *** Warning - bad CRC, using default environment
>> It means that it's using the default environment because no custom env
>> was ever saved.
>> try (on the devices that do not boot)
>> resetenv
>> savenv
>>
>>
>>
>>
>> --
>> -
>>
>> Nicolas (kwizart)
>
>
>
>
> --
> Andrew Gillis
> Small Green Computer
> 603-488-0617



-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: The 4.15 kernel rebase on stable releases

[Nicolas Chauvet]

2018-02-12 18:56 GMT+01:00 Peter Robinson :
> Hi All,
>
> Just a heads up that the 4.15 kernel is headed to stable releases.
>
> I did a bunch of testing over the weekend and fixed up a bunch of
> issues, added some minor enhancements across a number of platforms.
> There is a kernel-4.15.2-301.fc27 build [1] which had all those fixes
> for people to test, I expect a 4.15.3 kernel going to updates-testing
> later today or tomorrow.
>
> A few notes for the fixes I added:
> * fixed cpufreq/thermal on i.MX6 (thanks kwizart for upstream fix)
Thx for the mention!

There is also a patch that has landed in 4.16-rc1 to fix the load of
the sdma firmware (included in our linux-firmware package).
https://git.kernel.org/pub/scm/linux/kernel/git/vkoul/slave-dma.git/commit/?h=topic/imx&id=c0879342efc41bc79a0836cc06ce2af22ec496c9
If you care to backport to 4.15 at some point ;)

Thx
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Nouveau acceleration on armv7/aarch64

[Nicolas Chauvet]

Hi there,


FYI I've backported the tegra/nouveau support that has landed in mesa
master recently on top of mesa-18.0
Here is a koji scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=26171305

I'm testing it only on a jetson-tk1 (armv7hl) for now, using a 4.16.0 kernel.
But in this case, I have the following message (that freeze the system).
[ 1140.014947] nouveau 5700.gpu: fifo: SCHED_ERROR 20 []

Because of that, I need to boot with rd.driver.blacklist=nouveau
modprobe.blacklist=nouveau from cmdline.
I'm trying to have it reported upstream.

Even with nouveau disabled, and using the mesa with tegra backport,
I'm able to run a wayland session on tegra. (very slowly). this was
not the case before the mesa tegra backport as it fallback on Xorg.

I don't think there is any improvement on SOC older than tegra k1. I
haven't tried yet.
I hope you can enjoy.

PS: I think this is a little too much for backport the whole tegra
support to the normal fedora package. But if it's something to
consider, I can submit a PR on mesa...


-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org

[fedora-arm] Re: fake hwclock

[Nicolas Chauvet]

Le mer. 8 août 2018 à 16:15, Robert Moskowitz  a
écrit :

> This is from the Centos-arm list.
>
> I have this running on a number of Centos7-armfhp Cubieboards.
>

There is a quicker workaround here:
https://bugzilla.redhat.com/show_bug.cgi?id=1074002#c7
But it's only for battery-backed RTC.

Best would be to have merge this feature into systemd or dracut I would say.


-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/message/WVGTZSSJO2TE7AZFAKQGEC4L52NDWHGA/

[fedora-arm] Help testing suspend on arm

[Nicolas Chauvet]

Hi there,

While testing upstream kernel on some devices, I've recently
discovered that suspend was broken for "distro kernel" (not only
related to fedora kernel, but also ubuntu).

I order to debug this, I was advised to use a serial console and boot
with theses options:
no_console_suspend=1 initcall_debug

Then using systemctl suspend outputs this report for me:
https://bugzilla.redhat.com/show_bug.cgi?id=1619699
Basically, I'm running a tegra device, but a pxa driver (unrelated to
the device) lead to a crash preventing suspend.

I would like others on this list to try to report such use case, I
don't expect pxa_gpio to be the only driver to have issue in the
fedora config. Specially as it does not have problem at boot time or
shutdown so this problem might remains silent.

Please don't forget to block ARMTracker on bugzilla.redhat.com, and
mention it there if you uses upstream bug tracker.

Thx for any report.

-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/message/RNZGCO4PVYOKTBI4SLZ2SZCAMHMESGWN/

[fedora-arm] Re: Help testing suspend on arm

[Nicolas Chauvet]

2018-08-29 14:24 GMT+02:00 Peter Robinson :
> Hi Nicolas,
Hi Peter,

>> I order to debug this, I was advised to use a serial console and boot
>> with theses options:
>> no_console_suspend=1 initcall_debug
>
> This good information, would you be able to assist in documenting this
> in a wiki page. I've created an initial template [1] so feel free to
> add/adjust.
>
> [1] https://fedoraproject.org/wiki/Architectures/ARM/Debugging
Sure, I will report in the appropriate section when possible.

>> Then using systemctl suspend outputs this report for me:
>> https://bugzilla.redhat.com/show_bug.cgi?id=1619699
>> Basically, I'm running a tegra device, but a pxa driver (unrelated to
>> the device) lead to a crash preventing suspend.
>
> Has this been reported to the pxa_gpio driver maintainer upstream?
This issue has been reported on linux-gpio along with:
https://bugzilla.kernel.org/show_bug.cgi?id=200905

The pxa_gpio maintainer is answering , but unfortunately the first
patch he suggested doesn't seem to work.

About the ti-cpufreq patch reported at:
https://bugzilla.kernel.org/show_bug.cgi?id=200875
There is a patch on the omap mailing list:
https://marc.info/?l=linux-arm-kernel&m=153505207226577&w=2
This seems to work at this step.

Thx

-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Re: Help testing suspend on arm

[Nicolas Chauvet]

2018-09-04 20:05 GMT+02:00 Robert Moskowitz :
> Nicolas,
>
> I finally have an Xfce desktop.  So I decided to try suspend to ram.
>
> It did something, but then stopped.  Monitor is still on, in character mode.
> And I realized, WHAT do I do to get the system to resume?  What do I have on
> this SOC that will trigger the resume.  I am stumped!
>
> So I will power cycle...
>
> [ 1422.375877] PM: Syncing filesystems ... done.
> [ 1427.191217] Freezing user space processes ... (elapsed 0.004 seconds)
> done.
> [ 1427.203321] OOM killer disabled.
> [ 1427.206678] Freezing remaining freezable tasks ... (elapsed 0.001
> seconds) done.
> [ 1427.216019] Suspending console(s) (use no_console_suspend to debug)

It depends on the device, I expect not all keys can leave suspend. On
the Trimslice, I can use the power button, on AC100 any key on the
keyboard.
If you have an usb keyboard plugin and it didn't leave suspend, then I
guess there is something missing to be hooked there.

But I would have expected crash to happen when entering suspend.
Having no crash on your device is an interesting information anway.
(I was also able to "not" reproduce any crash with wandboard).

Thx for your tests.

-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Fedora 28 with the "grate-driver" for (older) Tegra

[Nicolas Chauvet]

Hi,


FYI I've recently compiled a set of packages (1) from the grate-driver
project (2).

In short, this FLOSS driver allows to enable video acceleration with
vdpau on older tegra soc.
There is also a very basic mesa driver, but it only advertise opengl
1.4 and gles 2.0 (probably not really conformant even). At least it
doesn't crash with glxgears.
There is support up to Tegra114, Tegra K1 may comes later using the
same framework.

Please reminds that for later SOC (Tegra K1+), f29 will have a better
support. There mesa has tegra/nouveau mesa drivers that will operate.
(not tested recently).


Mini FAQ:
- Why not upstream ?
There is an ABI destaging process in progress for tegra in the Linux
kernel. Once done, it will be probably possible to have more changes
upstream. Unfortunately, this is a long process and the review queue
in Tegra is growing.
- How to enable video hw acceleration ?
Look at the grate-driver page for libvdpau-tegra for the doc
You will need the mesa libdrm libvdpau-tegra xorg-x11-drv-opentegra
packages from the (2) repos. These replace fedora ones. You can keep
the fedora kernel. Please verify to have about cma=128M.


(1) - https://repos.fedorapeople.org/kwizart/ac100/
(2) - https://github.com/grate-driver/

-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Re: Fedora 28 with the "grate-driver" for (older) Tegra

[Nicolas Chauvet]

2018-09-12 17:13 GMT+02:00 Peter Robinson :
>> In short, this FLOSS driver allows to enable video acceleration with
>> vdpau on older tegra soc.
>
> How does this relate to the tegr-vde driver for video acceleration
> that's already in the upstream kernel[1] , albeit in staging, that
> supports tegra20-114 now.
The tegra-vde driver is used unmodified by the tegra vdpau backend
But the libvdpau-tegra backend requires few missing patches from the
grate-driver modified libdrm.
That's the patches I hope to see merged once the kernel ABI for tegra
drm is unstaged.

Then there is a need for a video output. Without a good opengl driver,
the best choice is currently to use the legacy Xv video output.
This can be granted by using the opentegra DDX which also requires the
modified libdrm.
Using the modified libdrm, libvdpau-tegra and modified
xorg-x11-drv-opentegra is enough to get video acceleration.
Using the modified mesa will allow to use the DRI2 framework to
autodetect the appropriate vdpau backend.

>> There is also a very basic mesa driver, but it only advertise opengl
>> 1.4 and gles 2.0 (probably not really conformant even). At least it
>> doesn't crash with glxgears.
>> There is support up to Tegra114, Tegra K1 may comes later using the
>> same framework.
>
> There's also a patch series to add 124 AKA TK1 support [2] and once
> they add support for the v4l requests API [3] this should all work
> OOTB with standard mesa AFAICT. So my question is how does grate fit
> into / relate to the upstream work?
I've only tested this patch WRT older hardware and it breaks video acceleration.

v4l requests API is the way forward indeed, I haven't seen any code for Tegra,
There are plans. I don't know yet about the userspace, but at least
there is a bridge for vaapi enabled applications.

About grate and upstream, it's still un-clear if there will be two
drivers or only one within mesa


-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Re: Moving root fs to sata

[Nicolas Chauvet]

Le ven. 7 juin 2019 à 17:24, Steven A. Falco  a écrit :
>
> I have a wandboard quad, and I'd like to move the root filesystem to a sata 
> drive.  I have the drive connected and formatted, and I copied all of "/" to 
> a partition on the sata drive.
>
> Now the question is "where do I need to change the UUID to match that of the 
> new partition".
>
> I know I need to change /etc/fstab, /boot/extlinux/extlinux.conf and perhaps 
> /boot/grub/grub.conf, but do I also have to regenerate the initramfs images, 
> and if so, what command would I use so they contain the correct UUID and 
> drivers?
Hello,

You do not need to regen the initramfs for the UUID, but more to have
the appropriate sata driver (unless you already have a generic
initramfs, which is not the default IIRC).

Unless you really want to re-use an existing installation, I would
recommend to xzcat the image you want on sata from another host.
You only need to have the bootloader on the mmc for the wanboard,
(modern) u-boot can boot to sata directly even for /boot.

-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org

[fedora-arm] Jetson-tk1 regulator and initramfs

[Nicolas Chauvet]

HI,

FYI, I've found an issue with the current kernel 5.6.x (maybe earlier)
the as3722_regulator module isn't added by dracut in hostonly mode (it
is added as all others regulators)

I need to add this:
cat >/etc/dracut.conf.d/jetson-tk1.conf

[fedora-arm] Re: Qt with GLES

[Nicolas Chauvet]

Le mar. 22 sept. 2020 à 13:23, rinigus  a écrit :
>
> As far as I have seen, having pkgconfig(gl) in Qt devel dependencies
> brings in glvnd libs in all kinds of variants clashing with libhybris.
> Specific issue I will have to recheck tonight and get back to you.
>
> Maybe such a combination Mesa GL software rendering + hw accelerated
> EGL/GLESv2 would work. As far as I know, I can specify it during
> runtime. On Sailfish we don't have libGL at all, hence my questions

You might have a better chance using gl4es than switching to GLES
where the fedora default is to use GL everywhere.
But it's probably not something that can be supported on the fedora
side for the same reason libhybris can't be supported. (you will need
to link libhybris/gl4es to a proprietary gles implementation instead
of the generic/mesa version)

https://bugzilla.redhat.com/show_bug.cgi?id=1788327
https://github.com/ptitSeb/gl4es
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-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/arm@lists.fedoraproject.org

[fedora-arm] Re: plexmediaserver app for fedora-arm on raspberry pi 4B 8 gig

[Nicolas Chauvet]

Le lun. 2 août 2021 à 19:56, Donatom M  a écrit :
>
> I have fedora-arm 34 with openbox. Where/how can I get plexmediaserver for 
> this system?

plex-media-player (not server) is available via rpmfusion for armhfp
and aarch64 (along x86_64).

I'm not sure which video acceleration method is available on this
player and if it's suitable for fedora on pi...
(the way forward is probably to use v4l2-m2m api for pi).

Thx
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-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/arm@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[fedora-arm] Rawhide nodebug kernel for armhfp

[Nicolas Chauvet]

Hi,

With the removal of the armhfp koji target in rawhide, the
kernel-rawhide-nodebug kernel repository is missing an armhfp build.

As building an armhfp kernel on copr natively is inefficient (it would
use an x86_64 builder with qemu-system-arm emulation), I've setup a
copr repository that will cross-compile an armhfp kernel on a x86_64
host.

Currently available is a (normal) kernel package (and kernel-lpae)
tracking once a week the fedora kernel distgit repository unmodified
(aka 6.2-rc1).
(tested on trimslice)

I also plan to switch a kernel-longterm package from 5.15 to 6.1 in
the next few weeks.

Please see https://copr.fedorainfracloud.org/coprs/kwizart/cross-armhfp/

Hopefully the fc36 EOL kernel will be in a good shape to shutdown the
armhfp architecture in Fedora.
Hope this helps.

-- 
-

Nicolas (kwizart)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-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/arm@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[fedora-arm] Re: Le Potato?

[Nicolas Chauvet]

Le ven. 31 mars 2023 à 13:55, Peter Robinson  a écrit :
>
> On Wed, Mar 29, 2023 at 7:03 PM Richard Shaw  wrote:
> >
> > Google has failed me. Can I run Fedora on a Le Potato? If so, what target 
> > do I use?
> >
> > Anything I need to do before writing the image?
> >
> > I plan to use eMMC if I can get it cheap enough due to the failure rate of 
> > SD cards.
>
> So it doesn't look like the DT is upstream, but LibreComputer used to
> do a very good firmware that likely provides an appropriate firmware.
> I'm not sure of the recent state of their firmwares. We don't
> currently build firmware for amlogic devices because "It's
> complicated".
>
> But if the LibreComputer have a quality firmware for the Le Potato it
> likely should just work as we have the vast majority of the kernel
> side enabled, if there's something missing from the kernel that will
> be easy enough to fix.

I confirm I'm running Fedora on another device ("la frite", still
amlogic, but older soc).

After manually updating the firmware, I was able to run Fedora, as is,
on the device.
I don't know for sure with "le potato"

Hope this helps
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-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/arm@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[fedora-arm] Re: hardlink segfaults on armv7 in F-36

[Nicolas Chauvet]

Le mar. 4 avr. 2023 à 16:48, Dan Horák  a écrit :
>
> Hi all,
>
> is anyone here still running an armv7 hw with F-36? Could you check if
> /usr/bin/hardlink -n -c -vvv .
> in some directory with some files segfaults for you?
>
> I know F-36 is getting EOLed soon, but there might be a toolchain issue
> that might be worth looking at. Please see
> https://bugzilla.redhat.com/show_bug.cgi?id=2181826
> for more details.

It segfaults also with me on trimslice. (Tegra20 SoC).
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-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/arm@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[fedora-arm] Re: hardlink segfaults on armv7 in F-36

[Nicolas Chauvet]

Le ven. 7 avr. 2023 à 18:44, Nicolas Chauvet  a écrit :
>
> Le mar. 4 avr. 2023 à 16:48, Dan Horák  a écrit :
> >
> > Hi all,
> >
> > is anyone here still running an armv7 hw with F-36? Could you check if
> > /usr/bin/hardlink -n -c -vvv .
> > in some directory with some files segfaults for you?
> >
> > I know F-36 is getting EOLed soon, but there might be a toolchain issue
> > that might be worth looking at. Please see
> > https://bugzilla.redhat.com/show_bug.cgi?id=2181826
> > for more details.
>
> It segfaults also with me on trimslice. (Tegra20 SoC).

When run under valgrind, it shows:

# LANG=C valgrind /usr/bin/hardlink -n -c -vvv .
==669== Memcheck, a memory error detector
==669== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==669== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==669== Command: /usr/bin/hardlink -n -c -vvv .
==669==
Scanning [device/inode/links]:
==669== Invalid read of size 1
==669==at 0x486C0B8: strlen (vg_replace_strmem.c:495)
==669==by 0x491C947: __vfprintf_internal (vfprintf-internal.c:1517)
==669==by 0x10A71B: UnknownInlinedFun (stdio2.h:135)
==669==by 0x10A71B: jlog (hardlink.c:230)
==669==by 0x10D4E3: UnknownInlinedFun (hardlink.c:814)
==669==by 0x10D4E3: inserter (hardlink.c:783)
==669==by 0x49A72AB: process_entry.constprop.0 (ftw.c:472)
==669==by 0x49A777B: ftw_dir (ftw.c:551)
==669==by 0x49A80D3: ftw_startup (ftw.c:771)
==669==by 0x49A820B: nftw64@@GLIBC_2.4 (ftw.c:844)
==669==by 0x109BF7: main (hardlink.c:1374)
==669==  Address 0x936 is not stack'd, malloc'd or (recently) free'd
==669==
==669==
==669== Process terminating with default action of signal 11
(SIGSEGV): dumping core
==669==  Access not within mapped region at address 0x936
==669==at 0x486C0B8: strlen (vg_replace_strmem.c:495)
==669==by 0x491C947: __vfprintf_internal (vfprintf-internal.c:1517)
==669==by 0x10A71B: UnknownInlinedFun (stdio2.h:135)
==669==by 0x10A71B: jlog (hardlink.c:230)
==669==by 0x10D4E3: UnknownInlinedFun (hardlink.c:814)
==669==by 0x10D4E3: inserter (hardlink.c:783)
==669==by 0x49A72AB: process_entry.constprop.0 (ftw.c:472)
==669==by 0x49A777B: ftw_dir (ftw.c:551)
==669==by 0x49A80D3: ftw_startup (ftw.c:771)
==669==by 0x49A820B: nftw64@@GLIBC_2.4 (ftw.c:844)
==669==by 0x109BF7: main (hardlink.c:1374)
==669==  If you believe this happened as a result of a stack
==669==  overflow in your program's main thread (unlikely but
==669==  possible), you can try to increase the size of the
==669==  main thread stack using the --main-stacksize= flag.
==669==  The main thread stack size used in this run was 8388608.
==669==
==669== HEAP SUMMARY:
==669== in use at exit: 38,040 bytes in 6 blocks
==669==   total heap usage: 6 allocs, 0 frees, 38,040 bytes allocated
==669==
==669== LEAK SUMMARY:
==669==definitely lost: 0 bytes in 0 blocks
==669==indirectly lost: 0 bytes in 0 blocks
==669==  possibly lost: 0 bytes in 0 blocks
==669==still reachable: 38,040 bytes in 6 blocks
==669== suppressed: 0 bytes in 0 blocks
==669== Rerun with --leak-check=full to see details of leaked memory
==669==
==669== For lists of detected and suppressed errors, rerun with: -s
==669== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Erreur de segmentation (core dumped)
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-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/arm@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[fedora-arm] Re: Fedora for Tegra / jetson nano : how good is it ?

[Nicolas Chauvet]

Le mar. 9 mai 2023 à 00:12, Mario Marietto  a écrit :
>
> Hello.
>
> I dont hide my interest in the installation of fedora on the Jetson nano. I 
> would like to understand what works and what not. Can I have a more modern OS 
> than Ubuntu 18.04 ? help me to understand. Very thanks.

I have a Jetson TX1 that shares the same SOC (tegra210). In a headless
server configuration it works pretty well. But in graphical, using
accelerated graphics (with nouveau) is unpractical. Probably because
of the lack of EMC (External Memory Controller) frequency scaling. So
in the Jetson TX1 case, the EMC is locked at the bootloader frequency
(800Mhz instead of 1600Mhz, for Nano it might be even lower). And that
seems to produce some graphical failure with nouveau has seen in the
mesa bug tracker (search for tegra tags). With nouveau being
blacklisted, the device can use llvm just fine, but then it's not
efficient, Also there is no video hw support. and CI/CSI (for camera)
support (yet, but that might land at some point)...

Hope this helps.
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-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/arm@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[fedora-arm] Re: Fedora for Tegra / jetson nano : how good is it ?

[Nicolas Chauvet]

Le ven. 12 mai 2023 à 14:31, Mario Marietto  a écrit :
>
> The Nvidia Jetson Nano. was announced as a development system in mid-March 
> 2019. Only 4 years have passed. Not 8. I'm an end user,that's how I count. I 
> may agree that,generally .

I've even requested that nvidia to better support upstream on tegra210
(nano) on this thread
https://forums.developer.nvidia.com/t/efi-support-for-jetson-tx1-and-running-upstream-kernel/187945

Maybe if more interested nano end-users would come with this concern
on their forum, it would make them change this behavior.
I'm more into thinking that nvidia uses this lack of upstream support
to force EOL on these devices... So that's a kind of vendor locking.
But upstream concern on jetson forum isn't that common for some reason...
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-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/arm@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[fedora-arm] Re: U-Boot testing request - 2023.10 series

[Nicolas Chauvet]

Le sam. 19 août 2023 à 19:53, Peter Robinson  a écrit :
>
> Hi Folks,
>
> The 2023.10 RC series are now landing in F-39 and rawhide. There's
> been the beginnings of a few enhancements.
...
> least be no different than the usual process but I'd like to hear any
> feedback.

I have an issue on jetson-tx1 (L4T 32.7.4) with this f39 u-boot build:
Everything operates correctly under u-boot, but then after entering
initramfs the CPU hard lockup.


Using a previous 2023.07 or self compiled u-boot 2023.10-rc3 (cross
compiled under fc37) works as appropriate.
I will try to reproduce a local build with fedora patches applied...


Here is the following output

Welcome to Fedora Linux 38 (Workstation Edition) dracut-059-3.fc38 (Initramfs)!

[  135.415665] rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
[  135.421756] rcu: 1-...!: (4 GPs behind) idle=2e28/0/0x0
softirq=270/270 fqs=0 (false positive?)
[  135.430532] rcu: 2-...!: (0 ticks this GP) idle=0a28/0/0x0
softirq=129/129 fqs=0 (false positive?)
[  135.439567] rcu: 3-...!: (3 GPs behind) idle=1c70/0/0x0
softirq=360/360 fqs=0 (false positive?)
[  135.448341] rcu: (detected by 0, t=60002 jiffies, g=549, q=7 ncpus=4)
[  135.454857] Task dump for CPU 1:
[  135.458077] task:swapper/1   state:R  running task stack:0
   pid:0 ppid:1  flags:0x0008
[  135.467985] Call trace:
[  135.470425]  __switch_to+0xc8/0xf8
[  135.473830]  cpuidle_enter+0x40/0x60
[  135.477404]  cpuidle_idle_call+0x124/0x1a8
[  135.481500]  do_idle+0xa8/0xf8
[  135.484552]  cpu_startup_entry+0x30/0x40
[  135.488470]  secondary_start_kernel+0xe0/0x108
[  135.492913]  __secondary_switched+0xb8/0xc0
[  135.497090] Task dump for CPU 2:
[  135.500309] task:swapper/2   state:R  running task stack:0
   pid:0 ppid:1  flags:0x0008
[  135.510213] Call trace:
[  135.512652]  __switch_to+0xc8/0xf8
[  135.516049]  cpuidle_enter+0x40/0x60
[  135.519618]  cpuidle_idle_call+0x124/0x1a8
[  135.523709]  do_idle+0xa8/0xf8
[  135.526759]  cpu_startup_entry+0x30/0x40
[  135.530677]  secondary_start_kernel+0xe0/0x108
[  135.535117]  __secondary_switched+0xb8/0xc0
[  135.539292] Task dump for CPU 3:
[  135.542510] task:swapper/3   state:R  running task stack:0
   pid:0 ppid:1  flags:0x0008
[  135.552413] Call trace:
[  135.554851]  __switch_to+0xc8/0xf8
[  135.558247]  cpuidle_enter+0x40/0x60
[  135.561816]  cpuidle_idle_call+0x124/0x1a8
[  135.565907]  do_idle+0xa8/0xf8
[  135.568956]  cpu_startup_entry+0x2c/0x40
[  135.572873]  secondary_start_kernel+0xe0/0x108
[  135.577312]  __secondary_switched+0xb8/0xc0
[  135.581489] rcu: rcu_preempt kthread timer wakeup didn't happen for
5 jiffies! g549 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
[  135.592774] rcu: Possible timer handling issue on cpu=2 timer-softirq=24
[  135.599549] rcu: rcu_preempt kthread starved for 60002 jiffies!
g549 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=2
[  135.609880] rcu: Unless rcu_preempt kthread gets sufficient CPU
time, OOM is now expected behavior.
[  135.618992] rcu: RCU grace-period kthread stack dump:
[  135.624031] task:rcu_preempt state:I stack:0 pid:17
ppid:2  flags:0x0008
[  135.632370] Call trace:
[  135.634809]  __switch_to+0xc8/0xf8
[  135.638205]  __schedule+0x284/0x730
[  135.641688]  schedule+0x64/0x108
[  135.644910]  schedule_timeout+0xa4/0x1b8
[  135.648828]  rcu_gp_fqs_loop+0x120/0x4c0
[  135.652748]  rcu_gp_kthread+0x180/0x1e8
[  135.656576]  kthread+0xf4/0x108
[  135.659714]  ret_from_fork+0x10/0x20
[  135.663286] rcu: Stack dump where RCU GP kthread last ran:
[  135.668758] Task dump for CPU 2:
[  135.671977] task:swapper/2   state:R  running task stack:0
   pid:0 ppid:1  flags:0x0008
[  135.681879] Call trace:
[  135.684316]  __switch_to+0xc8/0xf8
[  135.687712]  cpuidle_enter+0x40/0x60
[  135.691282]  cpuidle_idle_call+0x124/0x1a8
[  135.695373]  do_idle+0xa8/0xf8
[  135.698422]  cpu_startup_entry+0x30/0x40
[  135.702339]  secondary_start_kernel+0xe0/0x108
[  135.706778]  __secondary_switched+0xb8/0xc0
[  135.712124] systemd[1]: No hostname configured, using default hostname.
[  135.719358] systemd[1]: Hostname set to .
[  135.724708] systemd[1]: Initializing machine ID from random generator.
[  156.038664] watchdog: Watchdog detected hard LOCKUP on cpu 3
[  156.044324] Modules linked in:
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-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/arm@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[fedora-arm] Re: U-Boot testing request - 2023.10 series

[Nicolas Chauvet]

Le mer. 23 août 2023 à 14:01, Nicolas Chauvet  a écrit :
>
> Le sam. 19 août 2023 à 19:53, Peter Robinson  a écrit :
> >
> > Hi Folks,
> >
> > The 2023.10 RC series are now landing in F-39 and rawhide. There's
> > been the beginnings of a few enhancements.
> ...
> > least be no different than the usual process but I'd like to hear any
> > feedback.
>
> I have an issue on jetson-tx1 (L4T 32.7.4) with this f39 u-boot build:
> Everything operates correctly under u-boot, but then after entering
> initramfs the CPU hard lockup.

Just some follow-up about this issue. I've tested again recently (with
2023.10 GA rebased from f39 packages).
And the issue still arises with me. But it could be because of some
mess with /boot/dtb symlink and device-tree location expectation. (my
/boot/dtb wasn't updated

When I tried to report to #u-boot upstream, it's the first question
that was raised (is device-tree rightly found ?).
Of course our distro patch might help

The problem is that in-between I've broken my micro-usb port, so I
cannot update u-boot anymore on the jetson-tx1 (and I'm stuck with
fedora based u-boot 2023.07 there).

Anyway, I don't think it's a blocker for F39 GA, so if anyone is able
to reproduce (or not) it is worth mentioning in the wiki.
___
arm mailing list -- arm@lists.fedoraproject.org
To unsubscribe send an email to arm-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/arm@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue