Re: [OpenWrt-Devel] NAND flashes in Broadcom routers: bad blocks, ECC
On 19 August 2014 20:45, Rafał Miłecki zaj...@gmail.com wrote: I wanted to finally switch from NAND_ECC_NONE to NAND_ECC_SOFT (there is no hw ECC) but it appears it won't be that straightforward. The problem is NAND implementation in Broadcom's CFE bootloader. It appears that all the bootloader cares about is if block is good or bad. I think it doesn't even use BBT. It simply checks for oob[0x0] (or oob[0x5] for small flashes) being 0xff. Then it writes to the block or skips it. The bootloader doesn't seem to even calculate ECC when writing! So after installing firmware using bootloader all OOB content is 0xFF. Of course enableing NAND_ECC_SOFT results in uncorrectable errors: bcm47xxnflash: NAND_CMD_RNDOUT len:0x0F bcm47xxnflash: NAND_CMD_RNDOUT data FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF __nand_correct_data: uncorrectable ECC error __nand_correct_data: uncorrectable ECC error __nand_correct_data: uncorrectable ECC error mtd_read error while reading (offset: 0x6)! So I wonder how we could deal with that. Should I somehow detect if this is first boot after installation and calculate ECCs on my own? Hoping nothing wrong will happen of the first read? Any ideas? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] lantiq: BTHOMEHUBV2B use bigger mtd partition for kernel
The bb-rc3 image for the BTHOMEHUBV2B is too big for its
mtd partition. This patch corrects the partition sizes in
the device tree. This patch should really go in before
bb-final, otherwise the BTHOMEHUBV2B images won't be useable.
I do apologise for not spotting this straight away.
Many thanks,
Ben
Signed-off-by: Ben Mulvihill ben.mulvih...@gmail.com
---
--- a/target/linux/lantiq/dts/BTHOMEHUBV2B.dts 2014-08-27 08:28:48.372326110
+0200
+++ b/target/linux/lantiq/dts/BTHOMEHUBV2B.dts 2014-08-27 01:04:46.230278970
+0200
@@ -81,12 +81,12 @@
partition@4000 {
label = kernel;
- reg = 0x4000 0x16;
+ reg = 0x4000 0x20;
};
partition@164000 {
label = ubi;
- reg = 0x164000 0x1E9C000;
+ reg = 0x204000 0x1DFC000;
};
};
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AsiaRF MT7620a mounting sdhci drive readonly
Hi,
i saw that the latest RTSDK driver has support for CD polling. i will
have a look at the datasheet to figure out if we can work around this in
software. i need to port the newest sdk driver anyhow to get the mt7628
support
John
On 27/08/2014 07:10, Luis Soltero wrote:
hello John,
the following patch fixes the write protect issue on the AsiaRF FXS
board (AWV002-001 REV .1)
so the broken-wp patch is not required to mount the drive rw once
the pin is grounded.
Not sure if you want to include the broken-wp patch or not in the CC
distribution. It might be useful to others...
Here is hoping you didn't waste too much time on this.
--luis
On 8/24/14, 2:46 AM, Luis Soltero wrote:
hello john,
thanks for looking into this... just so that you know I forced is_readonly = 0
in sdhci.c as in ...
static int sdhci_check_ro(struct sdhci_host *host)
{
unsigned long flags;
int is_readonly;
spin_lock_irqsave(host-lock, flags);
if (host-flags SDHCI_DEVICE_DEAD)
is_readonly = 0;
else if (host-quirks2 SDHCI_QUIRK2_BROKEN_WRITE_PROTECT)
is_readonly = 0;
else if (host-ops-get_ro)
is_readonly = host-ops-get_ro(host);
else
is_readonly = !(sdhci_readl(host, SDHCI_PRESENT_STATE)
SDHCI_WRITE_PROTECT);
is_readonly = 0;
spin_unlock_irqrestore(host-lock, flags);
return 0;
and yet...
root@Optimizer:~# e2fsck /dev/mmcblk0p2
e2fsck 1.42.4 (12-June-2012)
e2fsck: Read-only file system while trying to open /dev/mmcblk0p2
Disk write-protected; use the -n option to do a read-only
check of the device.
so unsure at this time why the driver thinks that this is a read only file
system.
look forward to your findings.
--luis
On 8/24/14, 2:07 AM, John Crispin wrote:
Hi Luis,
i have a awm0003 on my desk and will have a look during the week.
John
On 23/08/2014 23:26, Luis Soltero wrote:
Hello All,
Been trying to get an AsiaRF based MT7620a board running using CC
r42230 and having issue getting the MMC SD card reader to mount
rw.
I have been in communication with the manufacturer to discover the
GPIO (if any) used for the WP line for the SDHCI card reader on the
board. They have not gotten back to me. In the mean time I have
attempted to use some of the mmc driver properties such as
wp-inverted to no avail. In desperation I implemented a patch
based on http://permalink.gmane.org/gmane.linux.kernel.mmc/25615
which tells the driver to ignore the write protect line and assume
r/w always... yet the card still mounts read only. note that when
mounting the same SD card using a USB based reader the file system
mounts rw as expected.
here is the mount table showing the ro mount
root@OpenWRT:~# mount rootfs on / type rootfs (rw) snip...
/dev/mmcblk0p2 on /wxa type ext4 (ro,relatime,data=ordered)
here is the DTS definition for the board
sdhci@1013 { status = okay; broken-wp; };
following is the patch (some of you might find it useful). Any
thoughts would greatly be appreciated.
$ cat
target/linux/ramips/patches-3.10/0402-mmc-add-broken-wp.patch ---
a/Documentation/devicetree/bindings/mmc/mmc.txt2014-08-23
12:39:54.816004290 -0700 +++
b/Documentation/devicetree/bindings/mmc/mmc.txt2014-08-23
12:40:56.574123135 -0700 @@ -21,6 +21,8 @@ below for the case, when
a GPIO is used for the CD line - wp-inverted: when present,
polarity on the WP line is inverted. See the note below for the
case, when a GPIO is used for the WP line +- broken-wp: when
present, no indication of write protection is available, + and
write protection is assumed always off. - max-frequency: maximum
operating clock frequency - no-1-8-v: when present, denotes that
1.8v card voltage is not supported on this system, even if the
controller claims it is. --- a/drivers/mmc/host/sdhci-pltfm.c
2014-08-23 12:44:02.648454500 -0700 +++
b/drivers/mmc/host/sdhci-pltfm.c2014-08-23 12:45:52.009124011
-0700 @@ -80,7 +80,9 @@ bus_width == 1)) host-quirks |=
SDHCI_QUIRK_FORCE_1_BIT_DATA;
-if (sdhci_of_wp_inverted(np)) +if
(of_get_property(np, sdhci,broken-wp, NULL) ||
of_get_property(np, broken-wp, NULL)) +host-quirks2
|= SDHCI_QUIRK2_BROKEN_WRITE_PROTECT; +else if
(sdhci_of_wp_inverted(np)) host-quirks |=
SDHCI_QUIRK_INVERTED_WRITE_PROTECT;
if (of_get_property(np, broken-cd, NULL)) ---
a/drivers/mmc/host/sdhci.c2014-08-23 12:46:10.028575138 -0700
+++ b/drivers/mmc/host/sdhci.c2014-08-23 12:48:23.588506665
-0700 @@ -1621,6 +1621,8 @@
if (host-flags SDHCI_DEVICE_DEAD) is_readonly = 0; +else if
(host-quirks2 SDHCI_QUIRK2_BROKEN_WRITE_PROTECT) +
is_readonly = 0; else if (host-ops-get_ro) is_readonly =
host-ops-get_ro(host); else --- a/include/linux/mmc/sdhci.h
2014-08-23 12:56:38.005445877 -0700 +++ b/include/linux/mmc/sdhci.h
[OpenWrt-Devel] platform name 'ramips' VS 'ramips_24kec'
i stumbled in a custom script over this problem: root@fonera2n:~ opkg status kernel Package: kernel Version: 3.10.34-1-9ab8a27dee25ed0e5197bf83aebd96c3 Depends: libc Status: install hold installed Architecture: ramips_24kec Installed-Time: 1396519878 # so the platform/architacture name is 'ramips_24kec' # but here the name is just: 'ramips' root@fonera2n:~ grep packages /etc/opkg.conf src/gz barrier_breaker http://downloads.openwrt.org/snapshots/trunk/ramips/packages our auto-update-script is confused (me too!). can somebody explain this? bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] platform name 'ramips' VS 'ramips_24kec'
* Weimarnetz e.V., Vorstand/Vereinsvorsitzender: Bastian Bittorf bitt...@bluebottle.com [27.08.2014 09:42]: can somebody explain this? bye, bastian digging through 'target/linux/ramips' i can see, that all boards are CPU_TYPE:=24kec but only 1 board 'rt288x' is CPU_TYPE:=mips32r2 (so '24kec' is a special subtype of mips32r2?) so why there is at http://downloads.openwrt.org/snapshots/trunk/ a folder 'ramips.rt3883' and 'ramips' (but 24kec) but not 'rampis.rt288x' (which is special: mips32r2) bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] gemini: switch to kernel 3.10
This switches to kernel 3.10 that was prepared by Hauke in: gemini: add support for kernel 3.10 This is compile tested only, please run test and report back. I've simply checked if it still compiles, unfortunately we didn't get any feedback for this target. Signed-off-by: Rafał Miłecki zaj...@gmail.com --- target/linux/gemini/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/gemini/Makefile b/target/linux/gemini/Makefile index b64c9c8..6a6c0a7 100644 --- a/target/linux/gemini/Makefile +++ b/target/linux/gemini/Makefile @@ -13,7 +13,7 @@ FEATURES:=squashfs pci CPU_TYPE:=fa526 MAINTAINER:=Imre Kaloz ka...@openwrt.org -LINUX_VERSION:=3.9.11 +LINUX_VERSION:=3.10.49 KERNELNAME:=zImage -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] omap: add kernel 3.14 support
It has been compile-tested only so far. Please give it a try.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
.../0334-video-da8xx-fb-adding-dt-support.patch| 203 +
...-fb-Add-API-to-register-wait-for-vsync-ca.patch | 91 +
...-fb-fix-defect-with-vsync-callback-invoca.patch | 38
...0-wlcore-Add-support-for-DT-platform-data.patch | 155
...ts-am335x-evmsk-add-support-for-lcd-panel.patch | 70 +++
.../patches-3.14/950-am335x-evmsk-wilink-dts.patch | 79
6 files changed, 636 insertions(+)
create mode 100644
target/linux/omap/patches-3.14/0334-video-da8xx-fb-adding-dt-support.patch
create mode 100644
target/linux/omap/patches-3.14/0343-video-da8xx-fb-Add-API-to-register-wait-for-vsync-ca.patch
create mode 100644
target/linux/omap/patches-3.14/0752-video-da8xx-fb-fix-defect-with-vsync-callback-invoca.patch
create mode 100644
target/linux/omap/patches-3.14/900-wlcore-Add-support-for-DT-platform-data.patch
create mode 100644
target/linux/omap/patches-3.14/920-arm-dts-am335x-evmsk-add-support-for-lcd-panel.patch
create mode 100644
target/linux/omap/patches-3.14/950-am335x-evmsk-wilink-dts.patch
diff --git
a/target/linux/omap/patches-3.14/0334-video-da8xx-fb-adding-dt-support.patch
b/target/linux/omap/patches-3.14/0334-video-da8xx-fb-adding-dt-support.patch
new file mode 100644
index 000..63ec77f
--- /dev/null
+++ b/target/linux/omap/patches-3.14/0334-video-da8xx-fb-adding-dt-support.patch
@@ -0,0 +1,203 @@
+From 884d3962ef4787c8cf0b8a7a673531c623d1dff8 Mon Sep 17 00:00:00 2001
+From: Darren Etheridge detheri...@ti.com
+Date: Fri, 2 Aug 2013 15:35:36 -0500
+Subject: [PATCH 334/752] video: da8xx-fb: adding dt support
+
+Enhancing driver to enable probe triggered by a corresponding dt entry.
+
+Add da8xx-fb.txt documentation to devicetree section.
+
+Obtain fb_videomode details for the connected lcd panel using the
+display timing details present in DT.
+
+Ensure that platform data is present before checking whether platform
+callback is present (the one used to control backlight). So far this
+was not an issue as driver was purely non-DT triggered, but now DT
+support has been added this check must be performed.
+
+v2: squashing multiple commits from Afzal Mohammed (af...@ti.com)
+v3: remove superfluous cast
+v4: expose both ti,am3352-lcdc and ti,da830-lcdc for .compatible
+ as driver can use enhanced features of all version of the
+ silicon block.
+v5: addressed review comments from Prabhakar Lad
+v6: Changed the .compatible naming to match the existing drm bindings
+ for am33xx devices
+v7: clarify which compatible to use in the documentation for DA850
+
+Acked-by: Lad, Prabhakar prabhakar.cse...@gmail.com
+Signed-off-by: Darren Etheridge detheri...@ti.com
+---
+ .../devicetree/bindings/video/da8xx-fb.txt | 42 +
+ drivers/video/da8xx-fb.c | 66 +++-
+ 2 files changed, 105 insertions(+), 3 deletions(-)
+ create mode 100644 Documentation/devicetree/bindings/video/da8xx-fb.txt
+
+--- /dev/null
b/Documentation/devicetree/bindings/video/da8xx-fb.txt
+@@ -0,0 +1,42 @@
++TI LCD Controller on DA830/DA850/AM335x SoC's
++
++Required properties:
++- compatible:
++ DA830, DA850 - ti,da8xx-tilcdc
++ AM335x SoC's - ti,am33xx-tilcdc
++- reg: Address range of lcdc register set
++- interrupts: lcdc interrupt
++- display-timings: typical videomode of lcd panel, represented as child.
++ Refer Documentation/devicetree/bindings/video/display-timing.txt for
++ display timing binding details. If multiple videomodes are mentioned
++ in display timings node, typical videomode has to be mentioned as the
++ native mode or it has to be first child (driver cares only for native
++ videomode).
++
++Recommended properties:
++- ti,hwmods: Name of the hwmod associated to the LCDC
++
++Example for am335x SoC's:
++
++lcdc@4830e000 {
++ compatible = ti,am33xx-tilcdc;
++ reg = 0x4830e000 0x1000;
++ interrupts = 36;
++ ti,hwmods = lcdc;
++ status = okay;
++ display-timings {
++ 800x480p62 {
++ clock-frequency = 3000;
++ hactive = 800;
++ vactive = 480;
++ hfront-porch = 39;
++ hback-porch = 39;
++ hsync-len = 47;
++ vback-porch = 29;
++ vfront-porch = 13;
++ vsync-len = 2;
++ hsync-active = 1;
++ vsync-active = 1;
++ };
++ };
++};
+--- a/drivers/video/da8xx-fb.c
b/drivers/video/da8xx-fb.c
+@@ -36,6 +36,7 @@
+ #include linux/slab.h
+ #include linux/delay.h
+ #include linux/lcm.h
++#include video/of_display_timing.h
+ #include video/da8xx-fb.h
+ #include asm/div64.h
+
+@@ -1311,12 +1312,54 @@ static struct fb_ops da8xx_fb_ops = {
+ .fb_blank = cfb_blank,
[OpenWrt-Devel] Using - in section names
Hi, I am currently writing an init script using the callback method [1], on BB-rc3. However, it does not seem possible to use - in a section name, for instance: config interface 'tun-test' option 'rxcost' '42' The config_cb function never gets called for this section (but option_cb gets called for its options). I am aware that shell variables can't have - in their name, but it should not matter here, as the section name is not used as a variable name, only as a variable value. Is there a reason for disallowing - in the section names, or is it a bug? Also note that very strange things happen in this case. Some options from *other* sections are not parsed when using such a section name. The full example is this one: config interface tinc option rtt_max 500 option 'max_rtt_penalty' '25' option split_horizon false config interface 'gre-mejis' option 'wired' 'true' option 'max_rtt_penalty' '60' option 'enable_timestamps' 'true' option 'rxcost' '45' The sequence of calls to config_cb() and option_cb() is the following: config_cb interface tinc option_cb rtt_max 500 option_cb split_horizon false option_cb wired true option_cb max_rtt_penalty 60 option_cb enable_timestamps true option_cb rxcost 45 config_cb config interface gre-mejis is not parsed, but option max_rtt_penalty 25 is not either, while it is in the middle of another section... This option is correctly parsed when no - is used in the section name. Thanks, Baptiste [1] http://wiki.openwrt.org/doc/devel/config-scripting#callbacks pgpdOn_ww4aea.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Parsing list of options with the callback method
Hi, According to [1], it should be possible to parse list of options in a UCI file using an option_cb() callback. It does not seem to work as expected, for instance this block: config example list 'import_table' '42' list 'import_table' '53' leads to the following calls: config_cb example cfg02f223 option_cb import_table_ITEM1 42 option_cb import_table_LENGTH 1 option_cb import_table_ITEM2 53 option_cb import_table_LENGTH 2 I would have simply expected multiple calls to option_cb() with import_table as the first argument and the various value as the second argument. Is this intended? Thanks, Baptiste [1] http://wiki.openwrt.org/doc/devel/config-scripting#callbacks pgp2JYXtyiLvG.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Using - in section names
Hi, yes there is a reason, the initial uci implementation was shell based and section names are part of generated variable names which must not contain dashes. Simply replacing dashes with underscores is not possible either as this would lead to ambiguous results. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Using - in section names
On Wed, Aug 27, 2014 at 07:49:21PM +0200, Jo-Philipp Wich wrote: Hi, yes there is a reason, the initial uci implementation was shell based and section names are part of generated variable names which must not contain dashes. So, it shouldn't be necessary with the C implementation? Simply replacing dashes with underscores is not possible either as this would lead to ambiguous results. Yes, I've got exactly this problem: the name of a section is supposed to be a physical interface name. But both - and _ are valid characters in the name of an interface on Linux, so it would be ambiguous to convert one to the other. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel pgpHvFt8mkUGg.pgp Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Using - in section names
So, it shouldn't be necessary with the C implementation? Correct, but that cannot be changed without breaking support for legacy APIs. Simply replacing dashes with underscores is not possible either as this would lead to ambiguous results. Yes, I've got exactly this problem: the name of a section is supposed to be a physical interface name. But both - and _ are valid characters in the name of an interface on Linux, so it would be ambiguous to convert one to the other. Even if - would be allowed you'd still need to deal with @, ., #, : and other funny characters that are legal in ifnames. The only suitable way using the existing syntax constraints is to use an option value, similar to how /etc/config/network is structured e.g. config interface; option name eth0.1 ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Including git revision commit hash and svn revision id on release announcement.
Hello developers. Probably you are annoyed by people asking which revision is Barrier Breaker RC3 or similar, because they want to be able to compile the specific release theirselves. To address this issue, I think it would be better to add git revision commit hash for each Openwrt release announcement. So that, if someone already has a trunk repository, no need to hassle with cloning repository again just for applying that relase. Users will be able to go to specific release just by issuing git revert git commit hash or git reset git commit hash in their local git repository. I hope next release announcement will include git commit hash and svn revision number for more convenience. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Including git revision commit hash and svn revision id on release announcement.
On 28 August 2014 11:11, Alive4Ever alive4e...@live.com wrote: Hello developers. Probably you are annoyed by people asking which revision is Barrier Breaker RC3 or similar, because they want to be able to compile the specific release theirselves. To address this issue, I think it would be better to add git revision commit hash for each Openwrt release announcement. So that, if someone already has a trunk repository, no need to hassle with cloning repository again just for applying that relase. Users will be able to go to specific release just by issuing git revert git commit hash or git reset git commit hash in their local git repository. Trunk and release are in different repositories and there exists commits that are in one repo but not in the other so that operations on trunk with commit id from release repo should not work. I use the following setup git remote add bb git://git.openwrt.org/14.07/openwrt.git git fetch bb git checkout -b bb --track bb/master Then local branch bb will track remote Barrier Breaker repo's master branch. yousong ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] GPIO Keys and LED definitions for AsiaRF mt7620a AWV002-001 Rev .1
Hello All,
I am having issues implementing GPIO definitions in the DTS file for
the AsiaRF board that we are trying to bring up. This is seemingly
an easy task but for the life of me I can't figure out why this is
not working. First some info.
From the manufacturer...
GPIO#24 - Reset switch on board
GPIO#25 - Status (or system LED)
GPIO#72 - WLED
Now on to the DTS... i used this as a template
http://wiki.openwrt.org/toh/asus/rt-n14u
since the GPIOs are defined on the wiki and the DTS file is sitting
right next to mine.
first we enable the appropriate GPIO register banks.
/dts-v1/;
;
bsp;
bsp;
;
/include/
"mt7620a.dtsi"
bsp;
;
/
{&
nbsp;
p;
compatible = "ralink,mt7620a-eval-board",
"ralink,mt7620a-soc";
model = "Ralink MT7620a
GEMINI";
bsp;
;
palmbus@1000
{
gpio0: gpio@600
{
status =
"okay";
};
sp;
bsp;
;
gpio1: gpio@638
{
status =
"okay";
};
sp;
bsp;
;
gpio3: gpio@688
{
status =
"okay";
};
sp;
bsp;
;
spi@b00
{
status = "okay";
snip...
Then we configure pinctl to multiplex the pins
snip
pinctrl
{&
nbsp;
p;
state_default: pinctrl0
{
default
{
ralink,group = "i2c", "uartf",
"ephy",
"wled";
ralink,function =
"gpio";
};
};
sp;
};
snip...
then we define the buttons and leds
gpio-leds
{&
nbsp;
compatible =
"gpio-leds";
sys
{
label =
"gemini:sys";
gpios = gpio1 1 1; # GPIO 25
is the send slot in the second bank
};
sp;
wifi
{
label =
"gemini:wifi";
gpios = gpio3 0 1; # GPIO 72
is the one and only slot in the 4th bank
};
sp;
};
sp;
bsp;
;
gpio-keys-polled
{
compatible =
"gpio-keys-polled";
#address-cells =
1;
#size-cells =
0;
poll-interval =
20;
reset
{
label =
"reset";
gpios = gpio1 0 1; # GPIO 24
is the first slot of the second bank
linux,code =
0x198;
};
sp;
};
sp;
we add the following to ../ramips/base-files/etc/board.d/01_leds
gemini7620a)
ucidef_set_led_default "power" "power" "gemini:sys"
"1"
set_wifi_led "gemini:wifi"
;;
we compile and install...
here is what i get from the system log at boot...
[ 0.52] rt2880_gpio 1600.gpio: registering 24 gpios
[ 0.53] rt2880_gpio 1600.gpio: registering 24 irq
handlers
[ 0.54] rt2880_gpio 1638.gpio: registering 16 gpios
[ 0.55] rt2880_gpio 1638.gpio: registering 16 irq
handlers
[ 0.56] rt2880_gpio 1688.gpio: registering 1 gpios
[ 0.57] rt2880_gpio 1688.gpio: registering 1 irq handlers
[ 6.31] rt2880-pinmux pinctrl.1: pin 24 is not set to gpio
mux
[ 6.34] gpio-keys-polled gpio-keys-polled.5: unable to claim
gpio 24, err=-22
[ 6.36] gpio-keys-polled: probe of gpio-keys-polled.5 failed
with error -22
[ 6.87] leds-gpio gpio-leds.4: pins are not configured from
the driver
[ 6.89] rt2880-pinmux pinctrl.1: pin 25 is not set to gpio
mux
[ 6.89] rt2880-pinmux pinctrl.1: request pin 25 (io25) for
pio:25
[ 6.89] rt2880-pinmux pinctrl.1: pin 25 is not set to gpio
mux
[ 6.90] rt2880-pinmux pinctrl.1: request() failed for pin
25
[ 6.91] rt2880-pinmux pinctrl.1: pin-25 (pio:25) status
-22
OK... i can live with keys-polled errors since this board does not
actually have a switch (my new board (in route) will have one).
However... I can't understand why
leds-gpio gpio-leds.4: pins are not configured from the driver
[ 6.89] rt2880-pinmux pinctrl.1: pin 25 is not set to gpio
mux
what does this error mean?
leds-gpio.c
tells me this...
234 static int gpio_led_probe(struct platform_device *pdev)
235 {
236 struct gpio_led_platform_data *pdata = pdev-dev.platform_data;
237 struct gpio_leds_priv *priv;
238 struct pinctrl *pinctrl;
239 int i, ret = 0;
240
241 pinctrl = devm_pinctrl_get_select_default(pdev-dev);
242 if (IS_ERR(pinctrl))
243 dev_warn(pdev-dev,
244 "pins are not configured from the driver\n");
245
so the error seems to indicate that pinctl has not
