cjan
Posts: 861
Joined: Sun May 06, 2012 12:00 am

Re: Moving Linux Kernel to 5.4

Thu Jun 11, 2020 12:20 pm

does 'vc4-kms-v3d, noaudio=on' assign to headphone?

User avatar
DougieLawson
Posts: 39787
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Moving Linux Kernel to 5.4

Fri Jun 12, 2020 11:48 am

DougieLawson wrote:
Fri May 01, 2020 8:47 pm
PhilE wrote:
Fri May 01, 2020 8:19 pm
Dougie - is your display one of these?

https://m.banggood.com/MAX7219-Dot-Matr ... 72083.html

If so, I think the budget could stretch to buying one for testing.
It's one of these: https://www.ebay.co.uk/itm/MAX7219-SPI- ... 2580351911
I've got one purchased on Monday that the postie should be dropping in the box any day soon.

I'm going to try that on a RP1B to see if I can recreate the error on a second machine.
I found something interesting.

Code: Select all

Jun 12 10:17:29 falcon kernel: [   50.319679] enc28j60 spi0.0: Ethernet driver 1.02 loaded
Jun 12 10:17:29 falcon kernel: [   50.324714] enc28j60 spi0.0: chip not found
Jun 12 10:17:29 falcon kernel: [   50.324894] enc28j60: probe of spi0.0 failed with error -5
So I removed the pHAT that has the enc28j60 interface (it doesn't have an enc28j60 connected right now) and the SPI MAX7219 is working on 5.4.45+.

The pHAT has a device tree blob built from

Code: Select all

/*
Overlay for MisCap pHAT for the Microchip ENC28J60 Ethernet Controller
and 2-channel PWM Audio on GPIO 12,13
Enables SPI0 using spi-bcm2835 driver with additional CE3 on GPIO 5 and CE2 on GPIO 6
*/

/dts-v1/;
/plugin/;

/ {

compatible = "brcm,bcm2835", "brcm,bcm2836", "brcm,bcm2708", "brcm,bcm2709";

/* SPI0 */
fragment@0 {
      target = <&gpio>;
      __overlay__ {
          spi0_pins: spi0_pins {
              brcm,pins = <7 8 9 10 11>;
              brcm,function = <4>; /* alt0 */
          };
      };
   };

   fragment@1 {
      target = <&spi0>;
      __overlay__ {
         #address-cells = <1>;
         #size-cells = <0>;
         pinctrl-0 = <&spi0_pins &spi0_cs_pins>;
         status = "okay";
         cs-gpios = <0>, <0>, <&gpio 6 1>, <&gpio 5 1>;

         /*The first two <0>s request that native CS's 0 and 1 are used
         (even though the driver will convert them to GPIO CS's),
         and GPIO's 6 and 5 are used as active-low chip selects 2 and 3. */

         spidev@0{
              compatible = "spidev";
              reg = <0>;   /* CE0 */
              #address-cells = <1>;
              #size-cells = <0>;
              spi-max-frequency = <500000>;
          };

          spidev@1{
              compatible = "spidev";
              reg = <1>;   /* CE1 */
              #address-cells = <1>;
              #size-cells = <0>;
              spi-max-frequency = <500000>;
          };

         spidev@2{
            compatible = "spidev";
            reg = <2>;   /* CE2 */
            #address-cells = <1>;
            #size-cells = <0>;
            spi-max-frequency = <500000>;
         };

         spidev@3{
            compatible = "spidev";
            reg = <3>;   /* CE3 */
            #address-cells = <1>;
            #size-cells = <0>;
            spi-max-frequency = <500000>;
         };
      };
   };

/*reserve the extra GPIO 5 and 6 so no other drivers can claim them + mark them as outputs */

   fragment@2 {
      target = <&gpio>;
      __overlay__ {
         spi0_cs_pins: spi0_cs_pins {
            brcm,pins = <5 6>;
            brcm,function = <1>; /* out */
         };
      };
   };

/* enc28j60 enthernet */

   fragment@3 {
      target = <&spi0>;
      __overlay__ {
         /* needed to avoid dtc warning */
         #address-cells = <1>;
         #size-cells = <0>;

         status = "okay";

         spidev@0{
            status = "disabled";
         };

         eth1: enc28j60@0{
            compatible = "microchip,enc28j60";
            reg = <0>; /* CE0 */
            pinctrl-names = "default";
            pinctrl-0 = <&eth1_pins>;
            interrupt-parent = <&gpio>;
            interrupts = <25 0x2>; /* falling edge */
            spi-max-frequency = <12000000>;
            status = "okay";
         };
      };
   };

   fragment@4 {
      target = <&gpio>;
      __overlay__ {
         eth1_pins: eth1_pins {
            brcm,pins = <25>;
            brcm,function = <0>; /* in */
            brcm,pull = <0>; /* none */
         };
      };
   };


/* PWM */

  fragment@5 {
      target = <&gpio>;
      __overlay__ {
         pwm_pins: pwm_pins {
            brcm,pins = <12 13>;
            brcm,function = <4 4>; /* Alt0 */
         };
      };
   };

   fragment@6 {
      target = <&pwm>;
      __overlay__ {
         pinctrl-names = "default";
         pinctrl-0 = <&pwm_pins>;
         status = "okay";
      };
   };


};
sitting in an EEPROM on the pHAT. I've got everything I need to re-write that BLOB stashed away in a folder on my NAS.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All fake doctors are on my foes list.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3257
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.4

Fri Jun 12, 2020 1:42 pm

I'd try changing the cs-gpios property to say:

Code: Select all

         cs-gpios = <&gpio 8 1>, <&gpio 7 1>, <&gpio 6 1>, <&gpio 5 1>;
i.e. to revert to the way the driver prefers to work and let the SPI framework manage the CS lines.

User avatar
DougieLawson
Posts: 39787
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Moving Linux Kernel to 5.4

Fri Jun 12, 2020 3:21 pm

PhilE wrote:
Fri Jun 12, 2020 1:42 pm
I'd try changing the cs-gpios property to say:

Code: Select all

         cs-gpios = <&gpio 8 1>, <&gpio 7 1>, <&gpio 6 1>, <&gpio 5 1>;
i.e. to revert to the way the driver prefers to work and let the SPI framework manage the CS lines.
I'll give that a go. I'm hoping that it solves the SPI struggle completely as this has been niggling me. I don't like unsolved bugs.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All fake doctors are on my foes list.

User avatar
DougieLawson
Posts: 39787
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Moving Linux Kernel to 5.4

Sat Jun 13, 2020 5:28 pm

PhilE wrote:
Fri Jun 12, 2020 1:42 pm
I'd try changing the cs-gpios property to say:

Code: Select all

         cs-gpios = <&gpio 8 1>, <&gpio 7 1>, <&gpio 6 1>, <&gpio 5 1>;
i.e. to revert to the way the driver prefers to work and let the SPI framework manage the CS lines.
Thanks Phil, that's working with the 5.4.45+ kernel.

Edit: It's not working. So I'm going to blank out the EEPROM on the miscap pHAT.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All fake doctors are on my foes list.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3257
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.4

Tue Jun 16, 2020 11:12 am

Dougie,

I've reverted the downstream SPI patches related to chip selects - if you feel like giving it a test drive before I release it to the masses there is a test build for Pi 1/zero available here: https://drive.google.com/file/d/1sCN_Ei ... sp=sharing

It's a file called "pi1_5.4.45_spitest.tgz", and I would install it with:

Code: Select all

sudo tar --no-same-owner -zxf pi1_5.4.45_spitest.tgz -C /
Thanks.

User avatar
DougieLawson
Posts: 39787
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Moving Linux Kernel to 5.4

Tue Jun 16, 2020 4:16 pm

PhilE wrote:
Tue Jun 16, 2020 11:12 am
Dougie,

I've reverted the downstream SPI patches related to chip selects - if you feel like giving it a test drive before I release it to the masses there is a test build for Pi 1/zero available here: https://drive.google.com/file/d/1sCN_Ei ... sp=sharing

It's a file called "pi1_5.4.45_spitest.tgz", and I would install it with:

Code: Select all

sudo tar --no-same-owner -zxf pi1_5.4.45_spitest.tgz -C /
Thanks.
I'll re-write the (currently blank) EEPROM on the Miscap pHAT with your improved device tree stuff and start from there with your SPI stuff.
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All fake doctors are on my foes list.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3257
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.4

Tue Jun 16, 2020 4:20 pm

If I'm right it should work with either version - I'd like some confidence that the old hardware CS declarations "<0>" work again, but I have other means to test that.

User avatar
DougieLawson
Posts: 39787
Joined: Sun Jun 16, 2013 11:19 pm
Location: A small cave in deepest darkest Basingstoke, UK
Contact: Website Twitter

Re: Moving Linux Kernel to 5.4

Tue Jun 16, 2020 5:00 pm

PhilE wrote:
Tue Jun 16, 2020 4:20 pm
If I'm right it should work with either version - I'd like some confidence that the old hardware CS declarations "<0>" work again, but I have other means to test that.
If you can do smd soldering at home, I've got a spare Miscap pHAT that Karrika sent me.

I've tried with the rpi-update kernel and it's working.
I've tried with your kernel/bootcode and it's working.

I'll leave it alone with your test-case (as that raspberry does a useful job) until this week's rpi-update comes out.

I owe you a beer as this has been fun, it has even kept me sane on lockdown days when I've not been working at home. I've pencilled in a week on Thursday or Thursday 2nd July to venture back to an air-conditioned office in my new milk float new EV car. (The aircon is the thing I've missed most during the driest spring on record.)
Note: Any requirement to use a crystal ball or mind reading will result in me ignoring your question.

Criticising any questions is banned on this forum.

Any DMs sent on Twitter will be answered next month.
All fake doctors are on my foes list.

Bluestang
Posts: 35
Joined: Sat May 30, 2020 8:43 pm

Re: Moving Linux Kernel to 5.4

Wed Jun 17, 2020 5:59 am

Excuse my ignorance but are there any plans to evolve the KMS audio driver into a module (i.e. snd_bcm2835) and allow it to fully utilize the ALSA API?

So far my experiences with it are positive, but in its current state, it is unable to use some of the basic plugins that ALSA loads on default - i.e. dmix.

Using a 3rd party solution Jack or Audio Pulse is feasible but so is using the Broadcom audio.

Bluestang
Posts: 35
Joined: Sat May 30, 2020 8:43 pm

Re: Moving Linux Kernel to 5.4

Wed Jun 17, 2020 2:07 pm

Just curious about the following output with KMS audio driver enabled:

Code: Select all

cat /proc/asound/modules

Code: Select all

$ sudo cat /proc/asound/modules
 0 (efault)
 1 (efault)
 2 snd_usb_audio
I presume there is a typo there? Is that the correct output?

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9492
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Moving Linux Kernel to 5.4

Wed Jun 17, 2020 2:49 pm

Bluestang wrote:
Wed Jun 17, 2020 5:59 am
Excuse my ignorance but are there any plans to evolve the KMS audio driver into a module (i.e. snd_bcm2835) and allow it to fully utilize the ALSA API?

So far my experiences with it are positive, but in its current state, it is unable to use some of the basic plugins that ALSA loads on default - i.e. dmix.

Using a 3rd party solution Jack or Audio Pulse is feasible but so is using the Broadcom audio.
You mean the audio driver when vc4-kms-v3d is loaded? That's not snd_bcm2835, so your post is a little confusing.
The HDMI audio is part of the HDMI block driver, hence why it's part of the vc4 module. It requires various bits of information about the video setup to be able to insert the audio correctly.
HDMI audio is a little weird in that it uses part of the S/PDIF packing. Some hardware does this encapsulation in the hardware, others don't. The Broadcom block doesn't, so something in software has to. That's why it advertises the audio format as SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE.

Despite it only being a formatting thing, ALSA plugins tend not to support IEC958, but it has a module that can pack into iec958.
There was a discussion as to whether to bite the bullet and do the encapsulation in the kernel driver, but that's not the kernel way of doing things, and userspace can be more efficient as it can use NEON and other SIMD operations to do the encapsulation more efficiently.

Previous threads at https://github.com/raspberrypi/linux/is ... -497677954, with linked kernel mailing list discussions.
The latest LibreElec builds have an updated asound.rc that does improve matters by inserting the ALSA encapsulation module in a more useful place, but I don't fully understand the magic runes required.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

Bluestang
Posts: 35
Joined: Sat May 30, 2020 8:43 pm

Re: Moving Linux Kernel to 5.4

Wed Jun 17, 2020 4:03 pm

6by9 wrote:
Wed Jun 17, 2020 2:49 pm
Bluestang wrote:
Wed Jun 17, 2020 5:59 am
Excuse my ignorance but are there any plans to evolve the KMS audio driver into a module (i.e. snd_bcm2835) and allow it to fully utilize the ALSA API?

So far my experiences with it are positive, but in its current state, it is unable to use some of the basic plugins that ALSA loads on default - i.e. dmix.

Using a 3rd party solution Jack or Audio Pulse is feasible but so is using the Broadcom audio.
You mean the audio driver when vc4-kms-v3d is loaded? That's not snd_bcm2835, so your post is a little confusing.
The HDMI audio is part of the HDMI block driver, hence why it's part of the vc4 module. It requires various bits of information about the video setup to be able to insert the audio correctly.
HDMI audio is a little weird in that it uses part of the S/PDIF packing. Some hardware does this encapsulation in the hardware, others don't. The Broadcom block doesn't, so something in software has to. That's why it advertises the audio format as SNDRV_PCM_FMTBIT_IEC958_SUBFRAME_LE.

Despite it only being a formatting thing, ALSA plugins tend not to support IEC958, but it has a module that can pack into iec958.
There was a discussion as to whether to bite the bullet and do the encapsulation in the kernel driver, but that's not the kernel way of doing things, and userspace can be more efficient as it can use NEON and other SIMD operations to do the encapsulation more efficiently.

Previous threads at https://github.com/raspberrypi/linux/is ... -497677954, with linked kernel mailing list discussions.
The latest LibreElec builds have an updated asound.rc that does improve matters by inserting the ALSA encapsulation module in a more useful place, but I don't fully understand the magic runes required.
Yes, I was asking if the KMS audio driver would be implemented into a kernel driver. It seems that it is not the correct way forward.

However, vc4 shows up under snd_soc_core and snd_pcm so aren't those kernel modules?

I've read through the kernel mailing lists and the last bit says in theory it can be done but no one has proved that yet...

Where are these asound.rc's from the LibreElec builds?

HiassofT
Posts: 305
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: Moving Linux Kernel to 5.4

Wed Jun 17, 2020 4:51 pm

Here's the alsa card conf we use in LibreELEC https://github.com/HiassofT/LibreELEC.t ... -hdmi.conf - just copy it to /usr/share/alsa/cards and overwrite the existing vc4-hdmi.conf one (which isn't quite correct).

There's not too much black magic going on there, in fact it's quite simple:

The card.conf defines a hdmi pcm device which does the iec958 formatting. It can also accept AES/channel status bits (needed for audio pass through) and pass it on to the driver - but this is currently not implemented in the driver so you can simply the hook/mixer stuff in the conf file for now.

Then the card defines a default pcm device which runs audio through the plug alsa plugin (so it can accept arbitrary sample rates and numbers of channels which aren't supported by the driver) and through the softvol plugin so you get a volume control and then sends the data to the hdmi device.

So, you'll get a total of 3 PCMs: default, which will accept all sound formats/sample rates/channels, hdmi, which accepts only samplerates / formats / channels the driver can handle, and hw which only accepts IEC958 subframe format (no, you don't really want to use that unless your application can handle that).

TLDR: "aplay some.wav" will just work OOTB with that card conf.

BTW: my plan is to send that card conf upstream when AES/channel status bit support is implemented in the driver (we may need to adjust the card conf a bit for the final implementation).

so long,

Hias

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 3257
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.4

Wed Jun 17, 2020 5:05 pm

There's not too much black magic going on there, in fact it's quite simple:
I think that depends on the reader, Hias. ;)

Bluestang
Posts: 35
Joined: Sat May 30, 2020 8:43 pm

Re: Moving Linux Kernel to 5.4

Wed Jun 17, 2020 5:28 pm

HiassofT wrote:
Wed Jun 17, 2020 4:51 pm
Here's the alsa card conf we use in LibreELEC https://github.com/HiassofT/LibreELEC.t ... -hdmi.conf - just copy it to /usr/share/alsa/cards and overwrite the existing vc4-hdmi.conf one (which isn't quite correct).

There's not too much black magic going on there, in fact it's quite simple:

The card.conf defines a hdmi pcm device which does the iec958 formatting. It can also accept AES/channel status bits (needed for audio pass through) and pass it on to the driver - but this is currently not implemented in the driver so you can simply the hook/mixer stuff in the conf file for now.

Then the card defines a default pcm device which runs audio through the plug alsa plugin (so it can accept arbitrary sample rates and numbers of channels which aren't supported by the driver) and through the softvol plugin so you get a volume control and then sends the data to the hdmi device.

So, you'll get a total of 3 PCMs: default, which will accept all sound formats/sample rates/channels, hdmi, which accepts only samplerates / formats / channels the driver can handle, and hw which only accepts IEC958 subframe format (no, you don't really want to use that unless your application can handle that).

TLDR: "aplay some.wav" will just work OOTB with that card conf.

BTW: my plan is to send that card conf upstream when AES/channel status bit support is implemented in the driver (we may need to adjust the card conf a bit for the final implementation).

so long,

Hias
Thanks for the response. My issue is not the fact that I can't get any sound. My issue, a trivial one all things considered, is that the ALSA plugins don't all work - i.e. dmix.

This current config, only one sound application is allowed at a time. Multiple applications are not possible which only leads to third-party solutions like Pulse Audio or Jack - although I wasn't able to get Jack running either, only Pulse Audio.

HiassofT
Posts: 305
Joined: Fri Jun 30, 2017 10:07 pm
Location: Salzburg, Austria
Contact: Website

Re: Moving Linux Kernel to 5.4

Wed Jun 17, 2020 6:43 pm

Bluestang wrote:
Wed Jun 17, 2020 5:28 pm
Thanks for the response. My issue is not the fact that I can't get any sound. My issue, a trivial one all things considered, is that the ALSA plugins don't all work - i.e. dmix.
dmix is problematic, as it doesn't support IEC958 subframes - see this post on the alsa mailinglist for details: https://mailman.alsa-project.org/piperm ... 19659.html

Other ALSA plugins should work, either use hdmi:0 (instead of hw:0) as slave device or manually add iec958 to the end of the chain (before hw:0).
This current config, only one sound application is allowed at a time. Multiple applications are not possible which only leads to third-party solutions like Pulse Audio or Jack - although I wasn't able to get Jack running either, only Pulse Audio.
Yes, using an external sound server is currently the only way to allow concurrent output from multiple applications.

I can't help much with Jack (only ever used it once or maybe twice many years ago), could be that you need to configure it to use the hdmi device (with iec958 formatting) instead of hw as well.

so long,

Hias

joyrider3774
Posts: 48
Joined: Sun Mar 13, 2016 12:21 pm

Re: Moving Linux Kernel to 5.4

Thu Jun 18, 2020 1:38 pm

does h264 mmal decoding still work in 5.4? i'm using an application that does h264 mmal decoding it works fine on 4.19 but when trying out 5.4 kernel i keep getting errors ([h264_mmal @ 0xa784df70] Did not get output frame from MMAL.f=0/0) when it decodes h264 using mmal.

Output from ffplay:

Code: Select all

 ffplay -codec:v h264_mmal ./.attract/menu-art/snap/All\ Displays.mp4
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from './.attract/menu-art/snap/All Displays.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    date            : 2018-01-28T18:10:03.00012
    encoder         : Lavf58.20.100
  Duration: 00:00:31.08, start: 0.000000, bitrate: 1705 kb/s
    Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 854x480 [SAR 1280:1281 DAR 16:9], 1568 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 129 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
[h264_mmal @ 0xa784df70] Did not get output frame from MMAL.f=0/0
[h264_mmal @ 0xa784df70] Did not get output frame from MMAL.f=0/0
[h264_mmal @ 0xa784df70] Did not get output frame from MMAL.f=0/0
..
..
[h264_mmal @ 0xa784df70] Too many errors when draining, this is a bug. Stop draining and force EOF.
pi@retropieTV:~ $
do we need to recompile ffmpeg / libavcodec on 5.4 for h264 mmal decoding to work ?

dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5590
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Moving Linux Kernel to 5.4

Thu Jun 18, 2020 2:31 pm

joyrider3774 wrote:
Thu Jun 18, 2020 1:38 pm
does h264 mmal decoding still work in 5.4? i'm using an application that does h264 mmal decoding it works fine on 4.19 but when trying out 5.4 kernel i keep getting errors ([h264_mmal @ 0xa784df70] Did not get output frame from MMAL.f=0/0) when it decodes h264 using mmal.
There should be no problem running mmal apps with 5.4 kernel.
Did you enable 64-bit kernel? That would have problems.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9492
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Moving Linux Kernel to 5.4

Thu Jun 18, 2020 2:45 pm

dom wrote:
Thu Jun 18, 2020 2:31 pm
joyrider3774 wrote:
Thu Jun 18, 2020 1:38 pm
does h264 mmal decoding still work in 5.4? i'm using an application that does h264 mmal decoding it works fine on 4.19 but when trying out 5.4 kernel i keep getting errors ([h264_mmal @ 0xa784df70] Did not get output frame from MMAL.f=0/0) when it decodes h264 using mmal.
There should be no problem running mmal apps with 5.4 kernel.
Did you enable 64-bit kernel? That would have problems.
64 bit kernel should be fine. 64 bit userspace will have issues.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

joyrider3774
Posts: 48
Joined: Sun Mar 13, 2016 12:21 pm

Re: Moving Linux Kernel to 5.4

Thu Jun 18, 2020 3:37 pm

dom wrote:
Thu Jun 18, 2020 2:31 pm
joyrider3774 wrote:
Thu Jun 18, 2020 1:38 pm
does h264 mmal decoding still work in 5.4? i'm using an application that does h264 mmal decoding it works fine on 4.19 but when trying out 5.4 kernel i keep getting errors ([h264_mmal @ 0xa784df70] Did not get output frame from MMAL.f=0/0) when it decodes h264 using mmal.
There should be no problem running mmal apps with 5.4 kernel.
Did you enable 64-bit kernel? That would have problems.
no did not enable 64bit kernel as far as i'm aware just did a `sudo rpi-update` and a reboot and it stops working not sure if that would enable the 64 bit kernel or not (Linux retropieTV 5.4.47-v7l+ #1322 SMP Wed Jun 17 17:58:52 BST 2020 armv7l GNU/Linux
) if i do a `sudo apt-get install --reinstall raspberrypi-bootloader raspberrypi-kernel` and reboot to get back to 4.19 it works again

when i use Linux retropieTV 4.19.118-v7l+ #1311 SMP Mon Apr 27 14:26:42 BST 2020 armv7l GNU/Linux the video plays fine using ffmpeg from repo (not self build) as in the app

was currently trying to install ffmpeg from sources but thats a complete failure. so reinstalled ffmpeg & related libs from the repo again and reverted back to 4.19 and it plays fine both in the app as in ffplay

I seems it did not matter which h264 video i supplied i kept getting that error on 5.4. I can go back to 5.4 if i need to test something or so

edit: just updated to 5.4 again (edited to firmwarerevision file so it would rpiupdate again) and will try some other h264 video's but they seemed to all fail with same error in ffplay when i tested

edit2: don't think i'm running 64 bit ..

Code: Select all

pi@retropieTV:~ $ getconf LONG_BIT
32
edit3: all h264 video's i have tested all produce same error, also not sure if it matters but i run outside x using drm backend of ffplay (as does the app i had initially seen the problem with)

hectorkvs
Posts: 47
Joined: Tue Jan 21, 2020 1:23 pm

Re: Moving Linux Kernel to 5.4

Fri Jun 19, 2020 10:50 am

Just updated Rpi4 4Gb model to the latest kernel 5.4.47 via sudo rpi-update and i found out Bluetooth is missing...icon is gone and i can't access any BT device..latest version of RP OS fully updated and upgraded, also latest version of bootloader from June 15th..any help?

User avatar
dickon
Posts: 1695
Joined: Sun Dec 09, 2012 3:54 pm
Location: Home, just outside Reading

Re: Moving Linux Kernel to 5.4

Fri Jun 19, 2020 11:07 am

Mine did the same. I needed to run

Code: Select all

hciattach /dev/ttyAMA0 bcm43xx 921600 noflow -
to make it work again. I have had that in /etc/rc.local for some time, but it seems to not be working for some reason.

tvjon
Posts: 800
Joined: Mon Jan 07, 2013 9:11 am

Re: Moving Linux Kernel to 5.4

Fri Jun 19, 2020 11:53 am

Same problem as both of you.

dickon, your one liner just returns after a while with:

bcm43xx_init
Initialization timed out

It's a tad inconvenient as currently, any usb1 devices plugged in cause any usb disc drives to randomly dismount then remount. Using bluetooth mouse & keyboard alleviates that problem.

PiUser10
Posts: 42
Joined: Mon Dec 30, 2013 9:20 am

Re: Moving Linux Kernel to 5.4

Fri Jun 19, 2020 12:04 pm

I assume that everyone reporting this issue with Bluetooth has done a recent sudo rpi-update command ?
if so you have installed the latest 5.4 kernel and also a new firmware with faulty builtin hardware Bluetooth support.
Over on the git hub this is documented see issue at https://github.com/Hexxeh/rpi-firmware/issues/227
Running the following command (as detailed in the git hub responses) will keep new kernel and revert to previous firmware

sudo SKIP_KERNEL=1 rpi-update a50c7d5

I have run this and it has fixed the Bluetooth issue on my Pi 4 8GB model.

However RUN THIS AT YOUR OWN RISK.

Return to “Advanced users”