Linux kernel is now 4.0

[PhilE]

Delete the dt-blob.bin. It doesn't have the sections needed by the new firmware.

[predrag]

Hi,
Kernels from 3.18.16 up make the 8192cu driver, run in AP mode, unstable. All the hosts are disconnected after 24-36h and unable to reconnect. This doesn't happen with 3.18.14. The USB dongle is TL-WN822N version 3. (hostapd v2.4 for Realtek rtl871xdrv)

Please don't force these kernels to apt-get upgrade. the 9182cu USB chipsets are AFAIK the only one to support 48 hosts in the AP mode , and are sufficiently stable to replace of the shelf wifi routers.

Best,
Predrag Viceic

[StuartF]

Delete the dt-blob.bin. It doesn't have the sections needed by the new firmware.

That sorted it.
Thanks for the help.

[PhilE]

Cool. That dt-blob change could easily catch out other people - I'll try to handle it more gracefully.

[erotavlas]

Hi,
I'm looking for a support of a sound soc codec on Raspbian 8.0 Jessie. I tried to install the latest kernel 4.0 with rpi-update, but the module is not loadable even if modify the /etc/modules configuration file. In particular, I'm interested on sound soc codec adau1701 which is inside the kernel source https://github.com/raspberrypi/linux/bl ... adau1701.c.
How can I do to obtain a working module for the codec? Is to cross compile the kernel in another machine, the only way I have?
Thank you

[PhilE]

The easiest way for you is to request that SND_SOC_ADAU1701 is defined in standard Raspberry Pi kernel configurations, and then wait for a kernel update. If you are using rpi-update then that could be as early as tomorrow.

You can build for yourself on a Pi but it takes a long time, even on a Pi 2. There are instructions for rebuilding the kernel here.

Either way, once you have a module, modprobe isn't the answer. This is an i2c device, so we have to get the I2C subsystem to load the module for us. The old way is to write a string to a magic sysfs entry - probably something like this:

Code: Select all

echo adau1701 0x68 > /sys/bus/i2c/devices/i2c-1/new_device

More information about instantiating I2C devices can be found here.

But this is only half of the picture. You also need to configure the I2S interface in order to deliver the PCM data. Often this needs a simple module to be written to tie together the pieces (see sound/soc/bcm/hifiberry_dac.c and other files in the same folder), but you might be able to get away with using Device Tree and its simple_card device: https://github.com/raspberrypi/linux/bl ... e-card.txt

This isn't a simple subject, and I've struggled to find good documentation on writing and configuring ALSA components, but there are some useful examples already in the rpi-4.0.y tree. When you've got a bit further I can help you to write a DT overlay.

[erotavlas]

Thank you for all the information. I just opened and issue in order to add SND_SOC_ADAU1701 in standard Raspberry Pi kernel configurations as you suggested and a developer answered positively. In this way I can save time on compiling kernel.
Regarding the second part of your answer, when I will have time I will try your suggestions and I will keep you updated.

[PhilE]

Just FYI, that developer was me.

[domble]

Just tried a rpi-update on a system; updated to kernel 4.0, all fine except seems that I couldn't set /dev/ttyAMA0 rate to higher than 115200bps afterwards. Previously working at 1Mbit (using the excellent libmodbus - or excellent if your app needs modbus anyway!).

Using
sudo stty -F /dev/ttyAMA0 1000000
fails on 4.0 for any rate higher than 115200.
Hopefully it's me doing something daft, usually is.

Not got time to play now, so gone back to a new noobs card with kernel 3.18.11 and all fine again.
(except that the apt-get version of libmodbus5 also didn't support 1MBit comms; uninstalled that and use libmodbus3.1.1 compiled from source with its make install... and 1Mbit is good).

Dominic.

[PhilE]

What is the nature of the failure - error message, data corruption, etc.?

Is 115200 a hard limit, i.e. does 115201 fail?

[ThatGuy39123]

Greetings,

It appears dm_mod is not being built.

Suggestions?

Thank you,
ThatGuy

[domble]

Ooh, of course I didn't try that. But

Code: Select all

pi ~ $ sudo stty -F /dev/ttyAMA0 1000000
stty: /dev/ttyAMA0: unable to perform all requested operations

whereas 115200 was ok. And 1000000 is fine on 3.18.11+.
And on 3.18.11 stty at least only seems to accept the 'standard' baud rates anyway.

Code: Select all

pi ~ $ sudo stty -F /dev/ttyAMA0 115201
stty: invalid argument `115201'
Try `stty --help' for more information.

Checked working or not on a scope; 115200bps setting did indeed transmit at 115200bps (with a cat * >> /dev/ttyAMA0).

I got no further in playing than to see that B1000000 used to be defined in /usr/include/arm-linux-gnueabihf/bits/termios.h, included by /usr/include/termios.h, and in the new version is defined in /usr/include/arm-linux-gnueabihf/asm/termbits.h which is included by /usr/include/arm-linux-gnueabihf/asm/termios.h which is included by /usr/include/termios.h - so moved, but still there, as far as my limited C knowledge could tell.

At that point I decided to give up and try the older version again - a deadline looms.

Oh - /boot/config.txt has

Code: Select all

# To allow faster UART rates
init_uart_clock=16000000

and "vcgencmd get_config init_uart_clock" reports the value ok.

Dominic.

[dom]

Greetings,

It appears dm_mod is not being built.

Suggestions?

Are you sure? It appears to be here and

Code: Select all

sudo modprobe dm-mod

Seems happy.

[PhilE]

@domble We switched to configuring UART0 from Device Tree last month, with a parameter to control the clock rate, but the firmware needs a small patch to set that automatically if init_uart_clock is set. I'll get that in the next release, but in the meantime you can add the following to your config.txt:

Code: Select all

dtparam=uart0_clkrate=16000000

[domble]

@PhilE

Thankyou very much for that; I need an idiots guide to device trees! That does indeed now set the UART clock correctly, so that I can use 1Mbit data again.

Much appreciated; and humble apologies for hijacking this thread.

Dominic.

[remkolodder]

Hi,

It seems that the videocore does not yet support 4.x?

[ 6.863205] Linux video capture interface: v2.00
[ 6.935121] bcm2835_v4l2: Failed to open VCHI service connection (status=-1)
[ 6.943773] : bcm2835-v4l2: error -19 while loading driver


$ uname -a
Linux pi3 4.0.8-v7+ #805 SMP PREEMPT Thu Jul 16 18:46:20 BST 2015 armv7l GNU/Linux

(Same goes for two RPI-b's)

Any suggestions on how I can help fix this?

Cheers
Remko

[PhilE]

@domble Yesterday's rpi-update firmware release includes the patch to automatically set the DT parameter uart0_clkrate from init_uart_clock, so if you choose to update then you can take out that dtparam= line.

[PhilE]

@remkolodder What command are you running to get that error?

[remkolodder]

Hi Phil,

I did a 'dmesg' to see that line. I am also missing /dev/video devicepointers so that motion for example does not detect a videodevice after updating to 4.x

[PhilE]

No - what command are you running to cause the error (not how to display it)?

[remkolodder]

Right, this is from the bootup of the Pi, so I expect that this is the modprobe/insmod situation.

Edit:
When I manually do the modprobe of the driver:

$ sudo modprobe bcm2835_v4l2
(dmesg output):
8164.440242] bcm2835_v4l2: Failed to open VCHI service connection (status=-1)
[ 8164.440302] : bcm2835-v4l2: error -19 while loading driver

[PhilE]

So you must be auto-loading bcm2835-v4l2.

What does "sudo vcdbg log msg" say?

And what is in your config.txt? I'm particularly interested in gpu_mem settings.

[remkolodder]

start_x=1
gpu_mem=16
disable_camera_led=1

edit: remove the incorrect output and replace it with the correct one:

and for the other command...
pi3 $ sudo vcdbg log msg
Unable to determine the value of __LOG_START
Unable to read logging_header from 0x00000000

[PhilE]

gpu_mem=16 and start_x=1 are contradictory, but your symptoms don't quite fit any of the standard failures.

What do you get from:

Code: Select all

vcgencmd get_mem gpu

and

Code: Select all

vcgencmd get_camera

?

And have you checked that the camera connectors are properly seated?

[dziadekfelek]

Unfortunately the new kernel omits lirc_igorplugusb driver, which makes my lirc installation non-functional.