[Linux-exynos] general comments

bruce m beach brucembeach at gmail.com
Tue Feb 24 18:02:36 CET 2015

Hi Merlijn

>> Sound and wi-fi are not currently working for me
> Sound is still in the works (but looks like it is getting some progress
> in the last few days), and it looks like wifi was broken by something
> trivial, so that should also work again in a bit.

Both of these I'm not particularly anxious for, and can wait
indefinitely, Wifi I am interested in because I roll my own
system and this time around I am not using udev and as far
as I can tell it is being phased out. I could go on about
this but what I really want to say is to point out the
following particularly interesting kernel parameter:

>device Drivers > Generic Driver Options

[*] Support for uevent helper

and the help message for it


The uevent helper program is forked by the kernel for every
uevent. Before the switch to the netlink-based uevent
source, this was used to hook hotplug scripts into kernel
device events. It usually pointed to a shell script at

 ==> This should not be used today, <== because usual systems create
many events at bootup or device discovery in a very short
time frame. One forked process per event can create so many
processes that it creates a high system load, or on smaller
systems it is known to create out-of-memory situations
during bootup.

I disabled it but exynos_defconfig enables it. Also I built
/sd8797_uapsta.bin right into the kernel itself with the
following from dmesg

[    7.321724] bus: 'sdio': add driver mwifiex_sdio
[    9.818780] bus: 'sdio': driver_probe_device: matched
               device mmc2:0001:1 with driver mwifiex_sdio
[    9.818785] bus: 'sdio': really_probe: probing driver
               mwifiex_sdio with device mmc2:0001:1
[    9.818802] mwifiex_sdio mmc2:0001:1: no default pinctrl
[    9.819318] mwifiex: rx work enabled, cpus 2
[    9.819605] driver: 'mwifiex_sdio': driver_bound: bound
               to device 'mmc2:0001:1'
[    9.819616] bus: 'sdio': really_probe: bound device
               mmc2:0001:1 to driver mwifiex_sdio
[    9.820001] __allocate_fw_buf: fw-mrvl/sd8797_uapsta.bin
[    9.820107] mwifiex_sdio mmc2:0001:1: Direct firmware
               load for mrvl/sd8797_uapsta.bin failed with error -2
[    9.820114] __fw_free_buf: fw-mrvl/sd8797_uapsta.bin
               buf=ed943a00 data=  (null) size=0
[    9.820120] mwifiex_sdio mmc2:0001:1: Failed to get
               firmware mrvl/sd8797_uapsta.bin

anyway I read on the irc logs that someone got it working
as a module. By now I imagine my kernel is outdated
( 3.19.0-next-20150216 ) Maybe I should upgrade or maybe I
should just wait until 19.1. I need the kernel headers.

Of interest is as I mentioned on irc was with shutdown -h
now the led on the power button does not turn off. Also the
screen doesn't turn off. It just dims. This you can find out
by makeing your background white with some black objects in
it for contrast. Also when it is in this state the current
draw is about 500mA. Normal operation when the system is not
particularly busy is at around 670mA, so it hardly shuts
down at all. Holding down the power button in this state
shuts it down.

> There may be some people in IRC who have knowledge on how to flash the
> chip -- but I don't know that too well personally. Perhaps coreboot is
> also an option? (Or it that loaded by u-boot?)

Other way around with infinite variations. I believe
coreboot launches u-boot as a payload on one particular
samsung system.

 I know mostly what to do. U-boot (the original, not forked)
has recently added "snow" to one of its configurations (a
little bit like "make exysnosdefonfig" ) and it compiles out
of the box, and somebody on irc mentioned that they had
installed it and it works like a dream. I launched it in
memory and it froze the computer. Thats what I call job
satisfaction. There are reasons for the freeze but it would
be nice to have something that would act both as a chained
bootloader and a bootloader. Coreboot might actually be
better but the problem is "snow". Everything later is okay.
My only requirement is like everything on this system it has
to be compiled on this system. No 3 year old binaries.
The big problem is that if you make a mistake you no longer
have a computer and have to go to hell and back and spend
more money than the worth of your computer for additional
equipment and have to have an addition computer to get it
working again so I want to sit and think for a long
time until I venture to try it.


More information about the Linux-exynos mailing list