Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Hello Rafał Attached is the brcmfmac patch as it is under review. One comment needs to be processed, but the general idea remains the same. All calls for this nvram reading are made under the define CONFIG_BCM47XX_NVRAM. Therefor it is mandatory that openwrt gets updated first. Only once the patch in openwrt is out the patch for brcmfmac will be posted. It can only break openwrt builds and nothing else as CONFIG_BCM47XX_NVRAM is openwrt specific. The reason why I choose not to copy the buffer in a freshly allocated buffer is that it was much more work. The problem is that allocating more than 64K or more will fail with kzalloc (or similar) so other alloc function need to be used. As a result also an API (and implementation) for releasing this memory needs to be added. This buffer is to be used read-only. So I choose the easy road, but if you prefer something else then I can do that. Regards, Hante -Original Message- From: Rafał Miłecki [mailto:zaj...@gmail.com] Sent: vrijdag 24 april 2015 14:08 To: Hante Meuleman Cc: Ian Kent; Arend Van Spriel; Jonas Gorski; mailinglist Subject: Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram. On 24 April 2015 at 12:03, Hante Meuleman wrote: > Attached are the two patch files. They were generated from > include/linux/bcm47xx_nvram.h and from > drivers/firmware/broadcom/bcm47xx_nvram.c. I think your idea is correct, I was just thinking about bcm47xx_nvram copying content to provided buffer, instead of sharing its own. I got an impression it's solution usually used when dealing with such situations & this would also protect bcm47xx internals. I'm not really sure how to submit this patch. It exports symbol and will be required by brcmfmac, so I guess we should ask Kalle to pick it. However I also planned moving nvram.c from mips to bcm47xx_nvram.c in firmware and I planned to submit this patch to Ralf (mips maintainer). Maybe it'll be better to work on moving NVRAM driver first? This would make more sense to Kalle accepting drivers/firmware/ patch rather than arch/mips/. We could keep this change in OpenWrt for now. I could submit patch to Ralf for 3.2 kernel. Then for 3.3 we could finally upstream your change to Kalle's tree. Can you also share your brcmfmac patch? firmware_nvram.patch Description: firmware_nvram.patch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Status report: spent lots of time trying to figure out how to use cpu port 8 and use vlan1ports "0 1 2 3 5 7 8t", and found that I got fooled by the way I tried to determine if it was working or not. To see if the switch configuration was working I used to type "ifconfig" and then see if there were and rx packets. Today I added logging in bgmac to see if there are any rx interrupts, and to my surprise there are. So it is possible to get it to work with cpu port 8 but the data is being dropped by the stack (nothing visible in the counters). This is sample data that gets received: [ 32.759614] bgmac: ETH, len=324, flags=0x01, protocol=0x0008 [ 32.766714] bgmac: 45 00 01 36 bc f2 40 00 ff 11 19 8a c0 a8 02 96 [ 32.774796] bgmac: e0 00 00 fb 14 e9 14 e9 01 22 b5 86 00 00 84 00 [ 32.782892] bgmac: ETH, len=344, flags=0x01, protocol=0xdd86 [ 32.789989] bgmac: 60 00 00 00 01 22 11 ff fd 1b 72 e5 79 5c 00 00 [ 32.798077] bgmac: 75 58 39 77 51 db f7 b2 ff 02 00 00 00 00 00 00 The ip addres of the ipv4 packet is of one of the connected PCs. These packets get dropped somehow and it is related to the config vlan1ports "0 1 2 3 5 7 8t". I can use cpu port 8 and config vlan1ports "0 1 2 3 5t" without a problem. So there might be an issue in the switch code, but there are more problems with this configuration in other areas. -Original Message----- On Thu, 2015-04-23 at 14:48 +, Hante Meuleman wrote: > Thank you for the information Ian, that was very helpful. Just found > part of the problem. My R8000 used to work quite well, till I upgraded > to new Netgear firmware. The old Netgear firmware is using this nvram > entry: > > vlan1ports=3 2 1 0 5 7 8* > > Newer firmware will update this nvram entry to > > vlan1ports=0 1 2 3 5 7 8* My device had this setting from the beginning. > > So depending on when you bought the AP you will have one of these > entries in the nvram. Both strings indicate that port 8 is the cpu port, > however, somehow the application (or script, not sure what is doing > this) that generates the file /etc/config/network at first boot will > generate different results for the entry: > > option ports > > vlan1ports=3 2 1 0 5 7 8* -> option ports '0 1 2 3 5t' > vlan1ports=0 1 2 3 5 7 8* -> option ports '0 1 2 3 5 7 8t' > > So when you have newer Netgear FW in your AP then you'll have a > different setting for vlan1ports in /etc/config/network then with older > firmware. This setting determines whether or not the switch is going to > work (as you already figured out). > > Still investigating to as of why this setting doesn't work with b53 driver. > > -Original Message- > On Wed, 2015-04-22 at 11:45 +, Hante Meuleman wrote: > > Today I wrote the original firmware back on the device > > (using the latest from netgear). This worked and the device > > was working fine. Then I flashed openwrt again, now the > > switch didn’t work anymore. So I checked the ports > > configuration and it had changed. So I reverted that > > using the nvram userspace program. This killed the > > nvram contents completely and after reboot I only had > > the bare minimum nvram contents and it was the same > > as before. However, now I cannot get the switch to work > > anymore. > > > > So doing an nvram set "xxx=yyy", followed by nvram commit > > appears to be killing my nvram contents. > > > > I've no idea why my switch is not working anymore. The > > problems with this switch is starting to get frustrating > > Yes, the switch is frustrating and all I can do is describe what I've > seen, maybe it will help. > > A fairly recent change to setting the switch configuration > in /etc/config/network at install sets the switch ports to "0 1 2 3 5 7 > 8t" and "4 8t" for the respective vlans. > > But the b53 driver still uses port 5 as the cpu and does the setup that > you've previously described as working (using port 5 as cpu). > > The switch configuration in network is done once at firmware install so > it needs to be changed by hand. > > What's more annoying is doing the heavy lifting in b53 to setup the > switch to use port 8 for the cpu, the way the Broadcom source does, > doesn't work so I'm missing something with that for sure. > > So we do need to stick to using port 5 for the cpu consistently > throughout for now. > > > > > Regards, > > Hante > > > > -Original Message- > > From: Hante Meuleman > > Sent: dinsdag 21 april 2015 17:22 > > To: 'Ian Kent'; Arend Van Spriel > > C
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Created some more logging, it is probably a configuration error in the switch when port 8 is part of the vlan configuration. It appears there is an offset in the data being received by bgmac, strangely enough, the log appears to show valid data, but that data is not accepted while the working configuration gives debug data like this: [ 23.955731] bgmac: ETH, len=64, flags=0x05, protocol=0x0081 [ 23.962731] bgmac: 00 01 08 00 46 c0 00 20 00 00 40 00 01 02 40 72 [ 23.970811] bgmac: c0 a8 02 02 e0 00 00 fb 94 04 00 00 16 00 09 04 Which appears to be incorrect (wrong protocol) and data has offset of 4. But this data does get accepted and is working. -Original Message- Status report: spent lots of time trying to figure out how to use cpu port 8 and use vlan1ports "0 1 2 3 5 7 8t", and found that I got fooled by the way I tried to determine if it was working or not. To see if the switch configuration was working I used to type "ifconfig" and then see if there were and rx packets. Today I added logging in bgmac to see if there are any rx interrupts, and to my surprise there are. So it is possible to get it to work with cpu port 8 but the data is being dropped by the stack (nothing visible in the counters). This is sample data that gets received: [ 32.759614] bgmac: ETH, len=324, flags=0x01, protocol=0x0008 [ 32.766714] bgmac: 45 00 01 36 bc f2 40 00 ff 11 19 8a c0 a8 02 96 [ 32.774796] bgmac: e0 00 00 fb 14 e9 14 e9 01 22 b5 86 00 00 84 00 [ 32.782892] bgmac: ETH, len=344, flags=0x01, protocol=0xdd86 [ 32.789989] bgmac: 60 00 00 00 01 22 11 ff fd 1b 72 e5 79 5c 00 00 [ 32.798077] bgmac: 75 58 39 77 51 db f7 b2 ff 02 00 00 00 00 00 00 The ip addres of the ipv4 packet is of one of the connected PCs. These packets get dropped somehow and it is related to the config vlan1ports "0 1 2 3 5 7 8t". I can use cpu port 8 and config vlan1ports "0 1 2 3 5t" without a problem. So there might be an issue in the switch code, but there are more problems with this configuration in other areas. -Original Message----- On Thu, 2015-04-23 at 14:48 +, Hante Meuleman wrote: > Thank you for the information Ian, that was very helpful. Just found > part of the problem. My R8000 used to work quite well, till I upgraded > to new Netgear firmware. The old Netgear firmware is using this nvram > entry: > > vlan1ports=3 2 1 0 5 7 8* > > Newer firmware will update this nvram entry to > > vlan1ports=0 1 2 3 5 7 8* My device had this setting from the beginning. > > So depending on when you bought the AP you will have one of these > entries in the nvram. Both strings indicate that port 8 is the cpu port, > however, somehow the application (or script, not sure what is doing > this) that generates the file /etc/config/network at first boot will > generate different results for the entry: > > option ports > > vlan1ports=3 2 1 0 5 7 8* -> option ports '0 1 2 3 5t' > vlan1ports=0 1 2 3 5 7 8* -> option ports '0 1 2 3 5 7 8t' > > So when you have newer Netgear FW in your AP then you'll have a > different setting for vlan1ports in /etc/config/network then with older > firmware. This setting determines whether or not the switch is going to > work (as you already figured out). > > Still investigating to as of why this setting doesn't work with b53 driver. > > -Original Message- > On Wed, 2015-04-22 at 11:45 +, Hante Meuleman wrote: > > Today I wrote the original firmware back on the device > > (using the latest from netgear). This worked and the device > > was working fine. Then I flashed openwrt again, now the > > switch didn’t work anymore. So I checked the ports > > configuration and it had changed. So I reverted that > > using the nvram userspace program. This killed the > > nvram contents completely and after reboot I only had > > the bare minimum nvram contents and it was the same > > as before. However, now I cannot get the switch to work > > anymore. > > > > So doing an nvram set "xxx=yyy", followed by nvram commit > > appears to be killing my nvram contents. > > > > I've no idea why my switch is not working anymore. The > > problems with this switch is starting to get frustrating > > Yes, the switch is frustrating and all I can do is describe what I've > seen, maybe it will help. > > A fairly recent change to setting the switch configuration > in /etc/config/network at install sets the switch ports to "0 1 2 3 5 7 > 8t" and "4 8t" for the respective vlans. > > But the b53 driver still uses port 5 as the cpu and does the setup that > you've previously described as working (using por
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Thanks, that explains. Also found some code in proprietary driver which appears to correct the header in certain situations, but it is rather complex. But what it appears to be is that there should be a vlan tag, but there isn’t always. And when there isn’t it should be inserted. But the current bgmac is incorrectly determining the ethertype as the function eth_type_trans won't take this vlan tag into account. Trying some trickery (based upon flags in header of rx frame) to make it work. -Original Message- On 29 April 2015 at 12:51, Hante Meuleman wrote: > Status report: spent lots of time trying to figure out how to use cpu > port 8 and use vlan1ports "0 1 2 3 5 7 8t", and found that I got fooled > by the way I tried to determine if it was working or not. To see if the > switch configuration was working I used to type "ifconfig" and then > see if there were and rx packets. Today I added logging in bgmac to > see if there are any rx interrupts, and to my surprise there are. So it > is possible to get it to work with cpu port 8 but the data is being > dropped by the stack (nothing visible in the counters). This is sample > data that gets received: > > [ 32.759614] bgmac: ETH, len=324, flags=0x01, protocol=0x0008 > [ 32.766714] bgmac: 45 00 01 36 bc f2 40 00 ff 11 19 8a c0 a8 02 96 > [ 32.774796] bgmac: e0 00 00 fb 14 e9 14 e9 01 22 b5 86 00 00 84 00 > [ 32.782892] bgmac: ETH, len=344, flags=0x01, protocol=0xdd86 > [ 32.789989] bgmac: 60 00 00 00 01 22 11 ff fd 1b 72 e5 79 5c 00 00 > [ 32.798077] bgmac: 75 58 39 77 51 db f7 b2 ff 02 00 00 00 00 00 00 Packets received by bgmac are supposed to be VLAN tagged. Are they in your case? I think you're dumping beginning on every packet. Compare dump (early bytes, look for 802.1Q header [0]) when using 5t vs. 8t. [0] http://en.wikipedia.org/wiki/IEEE_802.1Q ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Got some more information on the problems with the switch and the used vlan configuration. Basically it is possible to use port 8 as CPU port, however it is not possible to use the switch with vlan port configuration 0 1 2 3 5 7 8, without making some huge modifications. When this configuration is used the packets received will be without vlan tag (identified by status field in gmac). This mode is used for an optimization which is not easily to be used within the current OpenWRT driver framework. The usage of port 8 as CPU is possible, but not necessary, nor does it bring any improvements. The vlan port configuration is best limited to usable ports 0 1 2 3 and 4 for the lan/wan ports and port 5 as the cpu port. Doing this would mean that there are no further changes necessary to the existing drivers. Attached patch will modify the existing vlanport configuration so it will work on the r8000. -Original Message- On 29 April 2015 at 12:51, Hante Meuleman wrote: > Status report: spent lots of time trying to figure out how to use cpu > port 8 and use vlan1ports "0 1 2 3 5 7 8t", and found that I got fooled > by the way I tried to determine if it was working or not. To see if the > switch configuration was working I used to type "ifconfig" and then > see if there were and rx packets. Today I added logging in bgmac to > see if there are any rx interrupts, and to my surprise there are. So it > is possible to get it to work with cpu port 8 but the data is being > dropped by the stack (nothing visible in the counters). This is sample > data that gets received: > > [ 32.759614] bgmac: ETH, len=324, flags=0x01, protocol=0x0008 > [ 32.766714] bgmac: 45 00 01 36 bc f2 40 00 ff 11 19 8a c0 a8 02 96 > [ 32.774796] bgmac: e0 00 00 fb 14 e9 14 e9 01 22 b5 86 00 00 84 00 > [ 32.782892] bgmac: ETH, len=344, flags=0x01, protocol=0xdd86 > [ 32.789989] bgmac: 60 00 00 00 01 22 11 ff fd 1b 72 e5 79 5c 00 00 > [ 32.798077] bgmac: 75 58 39 77 51 db f7 b2 ff 02 00 00 00 00 00 00 Packets received by bgmac are supposed to be VLAN tagged. Are they in your case? I think you're dumping beginning on every packet. Compare dump (early bytes, look for 802.1Q header [0]) when using 5t vs. 8t. [0] http://en.wikipedia.org/wiki/IEEE_802.1Q vlan_number.patch Description: vlan_number.patch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Vlan configuration, limit the used ports
Do not mimic the vlan configuration in some devices like R8000 as the configuration is to be used with SW accelerators not available in OpenWRT. It is not possible to use the switch with vlan port configuration 0 1 2 3 5 7 8, without making some huge modifications. When this configuration is used the packets received will be without vlan tag (identified by status field in gmac). This mode is used for an optimization which is not easily to be used within the current OpenWRT driver framework. The patch below will modify the existing vlanport configuration so it will work on the r8000 with the existing opensource drivers. diff --git a/target/linux/bcm53xx/base-files/etc/board.d/02_network b/target/linux/bcm53xx/base-files/etc/board.d/02_network index 644d3d9..18958b8 100755 --- a/target/linux/bcm53xx/base-files/etc/board.d/02_network +++ b/target/linux/bcm53xx/base-files/etc/board.d/02_network @@ -23,10 +23,6 @@ if echo "$vlan1ports" | egrep -q "^1 2 3 4 5" && \ echo "$vlan2ports" | egrep -q "^0 5"; then ucidef_add_switch_vlan "switch0" "1" "1 2 3 4 5t" ucidef_add_switch_vlan "switch0" "2" "0 5t" -elif echo "$vlan1ports" | egrep -q "^0 1 2 3 5 7 8" && \ - echo "$vlan2ports" | egrep -q "^4 8"; then - ucidef_add_switch_vlan "switch0" "1" "0 1 2 3 5 7 8t" - ucidef_add_switch_vlan "switch0" "2" "4 8t" else ucidef_add_switch_vlan "switch0" "1" "0 1 2 3 5t" ucidef_add_switch_vlan "switch0" "2" "4 5t" ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] NVRAM > 32K
The R8000 AP has more than 32K nvram memory. This was an issue for the userspace app "nvram". This got fixed at some point, but then it was reverted: http://git.openwrt.org/?p=openwrt.git;a=commit;h=9258d82f1d4a79f86ea72aad349b3f3eeb772d87 Why was it reverted? Would be good to know what exact reason was, to be able to make a patch which will work on all platforms (assuming that it was reverted because some platform didn't work with the 64K setting). ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Give WiFi modules more time to settle
The boot script gives 1 second for wifi modules to settle. For newer routers
like R8000 which has three wifi devices which all need to be firmware
downloaded, nvram downloaded and initialized this delay is getting very
tight. On some bootups it was seen that not all wifi modules were
initialized by the time the "wifi detect" command was executed.
This patch increases the timeout from 1 to 2, leaving plenty of time for the
wifi modules to initialize:
diff --git a/package/base-files/files/etc/init.d/boot
b/package/base-files/files/etc/init.d/boot
index 6950130..534de53 100755
--- a/package/base-files/files/etc/init.d/boot
+++ b/package/base-files/files/etc/init.d/boot
@@ -40,7 +40,7 @@ boot() {
/sbin/kmodloader
# allow wifi modules time to settle
- sleep 1
+ sleep 2
/sbin/wifi detect > /tmp/wireless.tmp
[ -s /tmp/wireless.tmp ] && {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Give WiFi modules more time to settle
Understood, what is wifi detect using as input? Do the netdevs have to be up? Where is the information that wifi app is reading coming from? brcmfmac uses different method for firmware loading. It is not as easily patched as the ath10k driver. But I would like to know exactly what wifi detect uses as input. As in case of brcmfmac I expect that firmware loading will not be the only asynchronous "problem". What would be easy is adding a delay of 2 seconds to the function brcmfmac_module_init in core.c, but that won't guarantee it will work. -Original Message- From: Felix Fietkau [mailto:n...@openwrt.org] On 2015-05-12 10:35, Hante Meuleman wrote: > The boot script gives 1 second for wifi modules to settle. For newer > routers > > like R8000 which has three wifi devices which all need to be firmware > > downloaded, nvram downloaded and initialized this delay is getting very > > tight. On some bootups it was seen that not all wifi modules were > > initialized by the time the "wifi detect" command was executed. > > > > This patch increases the timeout from 1 to 2, leaving plenty of time for > the > > wifi modules to initialize: NACK from me. I think we should instead add an OpenWrt specifc patch to brcmfmac, similar to the one we have for ath10k, which makes device probing (and firmware loading) synchronous. The ath10k patch is 921-ath10k_init_devices_synchronously.patch - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Give WiFi modules more time to settle
Ok, thanks, that requires the wifi device to be completely up and initialized. There is way more involved in getting that synchronous. So what about the idea of adding a delay of two seconds to brcmfmac_module_init? Would that patch be accepted? -Original Message- From: Rafał Miłecki [mailto:zaj...@gmail.com] On 12 May 2015 at 11:33, Hante Meuleman wrote: > Understood, what is wifi detect using as input? Do the netdevs have to > be up? Where is the information that wifi app is reading coming from? What about just checking it by yourself? vim package/base-files/files/sbin/wifi vim package/kernel/mac80211/files/lib/wifi/mac80211.sh ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Give WiFi modules more time to settle
It is a bit more than just changing request_firmware_nowait into request_firmware. The worker in core.c needs to be removed. The function brcmf_pcie_setup needs to be updated as it cannot call device_release_driver during probe. As a result brcmf_fw_get_firmwares_pcie has to return the error, which means the api for brcmf_fw_get_firmwares_pcie will change, that will mean usb and sdio needs to patched as well. So it isn't going to be a small patch, but it can be done. I just wonder if it is worth the effort. The patch needs to be maintained as well. -Original Message- From: Felix Fietkau [mailto:n...@openwrt.org] On 2015-05-12 11:33, Hante Meuleman wrote: > Understood, what is wifi detect using as input? Do the netdevs have to > be up? Where is the information that wifi app is reading coming from? It looks for registered cfg80211 wiphys. It does not care about netdevs. > brcmfmac uses different method for firmware loading. It is not as > easily patched as the ath10k driver. But I would like to know exactly > what wifi detect uses as input. As in case of brcmfmac I expect that > firmware loading will not be the only asynchronous "problem". It should be enough to rework the request_firmware_nowait calls into request_firmware calls. > What would be easy is adding a delay of 2 seconds to the function > brcmfmac_module_init in core.c, but that won't guarantee it will work. Still seems more fragile and hackish. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] bcm53xx: Add functions to get/release copies of nvram contents.
Added two functions to the bcm47xx_nvram module to get and release copies
of the complete nvram contents. This can be used by for example brcmfmac
to get complete nvram contents which will after some parsing be sent to
device.
Signed-off-by: Hante Meuleman
---
diff --git
a/target/linux/bcm53xx/files/drivers/firmware/broadcom/bcm47xx_nvram.c
b/target/linux/bcm53xx/files/drivers/firmware/broadcom/bcm47xx_nvram.c
index d0055a4..96d2308 100644
--- a/target/linux/bcm53xx/files/drivers/firmware/broadcom/bcm47xx_nvram.c
+++ b/target/linux/bcm53xx/files/drivers/firmware/broadcom/bcm47xx_nvram.c
@@ -18,6 +18,7 @@
#include
#include
#include
+#include
#define NVRAM_MAGIC0x48534C46 /* 'FLSH' */
#define NVRAM_SPACE0x1
@@ -35,6 +36,7 @@ struct nvram_header {
};
static char nvram_buf[NVRAM_SPACE];
+static size_t nvram_len;
static const u32 nvram_sizes[] = {0x8000, 0xF000, 0x1};
static u32 find_nvram_size(void __iomem *end)
@@ -147,19 +149,19 @@ static int nvram_init(void)
err = mtd_read(mtd, 0, sizeof(header), &bytes_read, (uint8_t *)&header);
if (!err && header.magic == NVRAM_MAGIC) {
- u8 *dst = (uint8_t *)nvram_buf;
- size_t len = header.len;
-
- if (header.len > NVRAM_SPACE) {
+ nvram_len = header.len;
+ if (nvram_len > NVRAM_SPACE - 2) {
pr_err("nvram on flash (%i bytes) is bigger than the
reserved space in memory, will just copy the first %i bytes\n",
header.len, NVRAM_SPACE);
- len = NVRAM_SPACE;
+ nvram_len = NVRAM_SPACE - 2;
}
- err = mtd_read(mtd, 0, len, &bytes_read, dst);
+ err = mtd_read(mtd, 0, nvram_len, &bytes_read,
+ (u8 *)nvram_buf);
if (err)
return err;
-
+ nvram_buf[nvram_len] = 0;
+ nvram_buf[nvram_len + 1] = 0;
return 0;
}
#endif
@@ -183,9 +185,7 @@ int bcm47xx_nvram_getenv(const char *name, char *val,
size_t val_len)
/* Look for name=value and return value */
var = &nvram_buf[sizeof(struct nvram_header)];
- end = nvram_buf + sizeof(nvram_buf) - 2;
- end[0] = '\0';
- end[1] = '\0';
+ end = nvram_buf + nvram_len;
for (; *var; var = value + strlen(value) + 1) {
data_left = end - var;
@@ -222,4 +222,32 @@ int bcm47xx_nvram_gpio_pin(const char *name)
}
EXPORT_SYMBOL(bcm47xx_nvram_gpio_pin);
+char *bcm47xx_nvram_get_contents(size_t *nvram_size)
+{
+ int err;
+ char *nvram;
+
+ if (!nvram_buf[0]) {
+ err = nvram_init();
+ if (err)
+ return NULL;
+ }
+
+ *nvram_size = nvram_len - sizeof(struct nvram_header);
+ nvram = vmalloc(*nvram_size);
+ if (nvram == NULL)
+ return NULL;
+ memcpy(nvram, &nvram_buf[sizeof(struct nvram_header)], *nvram_size);
+
+ return nvram;
+}
+EXPORT_SYMBOL(bcm47xx_nvram_get_contents);
+
+void bcm47xx_nvram_release_contents(char *nvram)
+{
+ vfree(nvram);
+}
+EXPORT_SYMBOL(bcm47xx_nvram_release_contents);
+
+
MODULE_LICENSE("GPLv2");
diff --git a/target/linux/bcm53xx/files/include/linux/bcm47xx_nvram.h
b/target/linux/bcm53xx/files/include/linux/bcm47xx_nvram.h
index 0e52a92..2f3f48f 100644
--- a/target/linux/bcm53xx/files/include/linux/bcm47xx_nvram.h
+++ b/target/linux/bcm53xx/files/include/linux/bcm47xx_nvram.h
@@ -15,6 +15,8 @@
int bcm47xx_nvram_init_from_mem(u32 base, u32 lim);
int bcm47xx_nvram_getenv(const char *name, char *val, size_t val_len);
int bcm47xx_nvram_gpio_pin(const char *name);
+char *bcm47xx_nvram_get_contents(size_t *val_len);
+void bcm47xx_nvram_release_contents(char *nvram);
#else
static inline int bcm47xx_nvram_init_from_mem(u32 base, u32 lim)
{
@@ -29,6 +31,13 @@ static inline int bcm47xx_nvram_gpio_pin(const char *name)
{
return -ENOTSUPP;
};
+static inline char *bcm47xx_nvram_get_contents(size_t *val_len)
+{
+ return NULL;
+};
+static inline void bcm47xx_nvram_release_contents(char *nvram)
+{
+};
#endif
#endif /* __BCM47XX_NVRAM_H */
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bcm53xx: Add functions to get/release copies of nvram contents.
Initially I made the free an inline from header file, but it doesn't compile
out of the box as it needs the definition for kfree and not all c files which
include this header file had this, as I don't like the inclusion of header
files from header files I choose to make an implementation in the c file.
-Original Message-
From: Felix Fietkau [mailto:n...@openwrt.org]
Sent: dinsdag 12 mei 2015 22:03
To: Hante Meuleman; OpenWrt Development List
Subject: Re: [OpenWrt-Devel] [PATCH] bcm53xx: Add functions to get/release
copies of nvram contents.
On 2015-05-12 15:10, Hante Meuleman wrote:
> Added two functions to the bcm47xx_nvram module to get and release copies
> of the complete nvram contents. This can be used by for example brcmfmac
> to get complete nvram contents which will after some parsing be sent to
> device.
>
> Signed-off-by: Hante Meuleman
> ---
> diff --git
> a/target/linux/bcm53xx/files/drivers/firmware/broadcom/bcm47xx_nvram.c
> b/target/linux/bcm53xx/files/drivers/firmware/broadcom/bcm47xx_nvram.c
> index d0055a4..96d2308 100644
> --- a/target/linux/bcm53xx/files/drivers/firmware/broadcom/bcm47xx_nvram.c
> +++ b/target/linux/bcm53xx/files/drivers/firmware/broadcom/bcm47xx_nvram.c
> @@ -222,4 +222,32 @@ int bcm47xx_nvram_gpio_pin(const char *name)
> }
> EXPORT_SYMBOL(bcm47xx_nvram_gpio_pin);
>
> +char *bcm47xx_nvram_get_contents(size_t *nvram_size)
> +{
> + int err;
> + char *nvram;
> +
> + if (!nvram_buf[0]) {
> + err = nvram_init();
> + if (err)
> + return NULL;
> + }
> +
> + *nvram_size = nvram_len - sizeof(struct nvram_header);
> + nvram = vmalloc(*nvram_size);
> + if (nvram == NULL)
> + return NULL;
> + memcpy(nvram, &nvram_buf[sizeof(struct nvram_header)], *nvram_size);
> +
> + return nvram;
> +}
> +EXPORT_SYMBOL(bcm47xx_nvram_get_contents);
> +
> +void bcm47xx_nvram_release_contents(char *nvram)
> +{
> + vfree(nvram);
> +}
> +EXPORT_SYMBOL(bcm47xx_nvram_release_contents);
How about making this one inline instead of adding yet another export?
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Can you tell a bit more about: "switch to use port 8 for the cpu, the way the Broadcom source does, doesn't work so I'm missing something with that for sure." Is that something you tried with the by Rafał suggested changes to fix the cpu port to 8 in the struct, as described on the forum? On Wed, 2015-04-22 at 11:45 +, Hante Meuleman wrote: > Today I wrote the original firmware back on the device > (using the latest from netgear). This worked and the device > was working fine. Then I flashed openwrt again, now the > switch didn’t work anymore. So I checked the ports > configuration and it had changed. So I reverted that > using the nvram userspace program. This killed the > nvram contents completely and after reboot I only had > the bare minimum nvram contents and it was the same > as before. However, now I cannot get the switch to work > anymore. > > So doing an nvram set "xxx=yyy", followed by nvram commit > appears to be killing my nvram contents. > > I've no idea why my switch is not working anymore. The > problems with this switch is starting to get frustrating Yes, the switch is frustrating and all I can do is describe what I've seen, maybe it will help. A fairly recent change to setting the switch configuration in /etc/config/network at install sets the switch ports to "0 1 2 3 5 7 8t" and "4 8t" for the respective vlans. But the b53 driver still uses port 5 as the cpu and does the setup that you've previously described as working (using port 5 as cpu). The switch configuration in network is done once at firmware install so it needs to be changed by hand. What's more annoying is doing the heavy lifting in b53 to setup the switch to use port 8 for the cpu, the way the Broadcom source does, doesn't work so I'm missing something with that for sure. So we do need to stick to using port 5 for the cpu consistently throughout for now. > > Regards, > Hante > > -Original Message- > From: Hante Meuleman > Sent: dinsdag 21 april 2015 17:22 > To: 'Ian Kent'; Arend Van Spriel > Cc: 'Jonas Gorski'; 'mailinglist' > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > Today I managed to update brcmfmac to load the data > directly from bcm47xx_nvram but it will require an additional > api in this module. I will post my version of bcm47xx_nvram > later this week. Also the patch for brcmfmac will be posted > later this week. With proper NVRAM the device is now booting > fine and all wireless devices get detected properly and are > working fine. > > I still do not know why I lost the complete contents of the nvram. > I do know that the CFE holds a very small default set which get > programmed if nothing is available from the nvram mtd block > device. As I dumped the nvram initially I was able to restore the > nvram completely and after that I was not able to get in the > situation where the nvram would be cleared and only hold the > default set of keys. > > We do have another r8000, but that one needs to be "recoverable". > So I will spent some time to see if I can make sure that I can restore > the r8000 with the original firmware and the original nvram > contents and once I'm sure I can I will try to update the other > r8000 as well. Then I can see if nvram gets perhaps erased on > the initial flashing of the OpenWRT. It's just a guess, but I really > don’t know what cleared the nvram contents on my device and > as long as that isn’t clear I wouldn’t recommend anybody to flash > an openwrt image on it. > > Regards, > Hante > > -Original Message- > From: Hante Meuleman > Sent: dinsdag 21 april 2015 10:29 > To: 'Ian Kent'; Arend Van Spriel > Cc: 'Jonas Gorski'; 'mailinglist' > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > It is something else, the CFE appears to override the > nvram for some reason with some default data. Don’t > know yet what is reason for CFE to determine that nvram > is invalid but it appears to be within the CFE that NVRAM > gets erased and defaulted to something minimal. > > Regards, > Hante > > -Original Message- > From: Hante Meuleman > Sent: dinsdag 21 april 2015 9:36 > To: 'Ian Kent'; Arend Van Spriel > Cc: Jonas Gorski; mailinglist > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > Well, I found that the cause is within openwrt. > I thought that CFE would still show the original > cont
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Thank you for the information Ian, that was very helpful. Just found part of the problem. My R8000 used to work quite well, till I upgraded to new Netgear firmware. The old Netgear firmware is using this nvram entry: vlan1ports=3 2 1 0 5 7 8* Newer firmware will update this nvram entry to vlan1ports=0 1 2 3 5 7 8* So depending on when you bought the AP you will have one of these entries in the nvram. Both strings indicate that port 8 is the cpu port, however, somehow the application (or script, not sure what is doing this) that generates the file /etc/config/network at first boot will generate different results for the entry: option ports vlan1ports=3 2 1 0 5 7 8* -> option ports '0 1 2 3 5t' vlan1ports=0 1 2 3 5 7 8* -> option ports '0 1 2 3 5 7 8t' So when you have newer Netgear FW in your AP then you'll have a different setting for vlan1ports in /etc/config/network then with older firmware. This setting determines whether or not the switch is going to work (as you already figured out). Still investigating to as of why this setting doesn't work with b53 driver. -Original Message- On Wed, 2015-04-22 at 11:45 +, Hante Meuleman wrote: > Today I wrote the original firmware back on the device > (using the latest from netgear). This worked and the device > was working fine. Then I flashed openwrt again, now the > switch didn’t work anymore. So I checked the ports > configuration and it had changed. So I reverted that > using the nvram userspace program. This killed the > nvram contents completely and after reboot I only had > the bare minimum nvram contents and it was the same > as before. However, now I cannot get the switch to work > anymore. > > So doing an nvram set "xxx=yyy", followed by nvram commit > appears to be killing my nvram contents. > > I've no idea why my switch is not working anymore. The > problems with this switch is starting to get frustrating Yes, the switch is frustrating and all I can do is describe what I've seen, maybe it will help. A fairly recent change to setting the switch configuration in /etc/config/network at install sets the switch ports to "0 1 2 3 5 7 8t" and "4 8t" for the respective vlans. But the b53 driver still uses port 5 as the cpu and does the setup that you've previously described as working (using port 5 as cpu). The switch configuration in network is done once at firmware install so it needs to be changed by hand. What's more annoying is doing the heavy lifting in b53 to setup the switch to use port 8 for the cpu, the way the Broadcom source does, doesn't work so I'm missing something with that for sure. So we do need to stick to using port 5 for the cpu consistently throughout for now. > > Regards, > Hante > > -Original Message- > From: Hante Meuleman > Sent: dinsdag 21 april 2015 17:22 > To: 'Ian Kent'; Arend Van Spriel > Cc: 'Jonas Gorski'; 'mailinglist' > Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for > multiple PCIE devices in nvram. > > Today I managed to update brcmfmac to load the data > directly from bcm47xx_nvram but it will require an additional > api in this module. I will post my version of bcm47xx_nvram > later this week. Also the patch for brcmfmac will be posted > later this week. With proper NVRAM the device is now booting > fine and all wireless devices get detected properly and are > working fine. > > I still do not know why I lost the complete contents of the nvram. > I do know that the CFE holds a very small default set which get > programmed if nothing is available from the nvram mtd block > device. As I dumped the nvram initially I was able to restore the > nvram completely and after that I was not able to get in the > situation where the nvram would be cleared and only hold the > default set of keys. > > We do have another r8000, but that one needs to be "recoverable". > So I will spent some time to see if I can make sure that I can restore > the r8000 with the original firmware and the original nvram > contents and once I'm sure I can I will try to update the other > r8000 as well. Then I can see if nvram gets perhaps erased on > the initial flashing of the OpenWRT. It's just a guess, but I really > don’t know what cleared the nvram contents on my device and > as long as that isn’t clear I wouldn’t recommend anybody to flash > an openwrt image on it. > > Regards, > Hante > > -Original Message- > From: Hante Meuleman > Sent: dinsdag 21 april 2015 10:29 > To: 'Ian Kent'; Arend Van Spriel > Cc: 'Jonas Gorski'; 'mailinglist' > Subject: RE: [OpenWrt-Devel]
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Do you want the patch on top of target/linux/bcm53xx/patches-3.18/110-firmware-backport-NVRAM-driver.patch Or on top of the unpatched drivers/firmware/broadcom/bcm47xx_nvram.c Or on top of the kernel driver file where 110-firmwarepatch already has been applied? Or on top of the file target/linux/bcm53xx/files/drivers/firmware/Broadcom/bcm47xx_nvram.c The latter would be the easiest, but it probably breaks the 110 patch. In upstream kernels the bcm47xx_nvram is not part of the kernel, this made me believe that it was generated with a patch file. Didn’t realize that the OpenWRT also has a files directory from which the additional kernel drivers get "injected" in the kernel: target/linux/bcm53xx/files/drivers/firmware/broadcom Still this makes me believe they are openwrt specific kernel file, but I guess, that is just how one wants to read this sentence. -Original Message- On 23 April 2015 at 13:14, Hante Meuleman wrote: > Attached are > three files, one is from brcmfmac (firmware.c). This file is > added to demo how brcmfmac will use a new function of > bm47xx_nvram. The changes in this file are currently under > internal review and the patch may change, but it has been > tested and verified so it can be used to try it out. There exists a diff/patch format for a very good reason. Please send patches, so I can review your changes. > The other > two files bcm47xx_nvram.c and bcm47xx_nvram.h are > OpenWRT specific kernel files. Not really, they are part of the kernel. I was working for last few months moving them out of MIPS arch code. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Attached are the two patch files. They were generated from include/linux/bcm47xx_nvram.h and from drivers/firmware/broadcom/bcm47xx_nvram.c. Sorry about the confusion regarding the target/linux/bcm53xx/patches-3.18/110-firmware-backport-NVRAM-driver.patch I was looking at an older repo where this patch was different. -Original Message- > Do you want the patch on top of > > target/linux/bcm53xx/patches-3.18/110-firmware-backport-NVRAM-driver.patch > > Or on top of the unpatched > > drivers/firmware/broadcom/bcm47xx_nvram.c > > Or on top of the kernel driver file where 110-firmwarepatch > already has been applied? > > Or on top of the file > > target/linux/bcm53xx/files/drivers/firmware/Broadcom/bcm47xx_nvram.c > > The latter would be the easiest, but it probably breaks the 110 patch. > > In upstream kernels the bcm47xx_nvram is not part of the kernel, > this made me believe that it was generated with a patch file. > Didn’t realize that the OpenWRT also has a files directory from > which the additional kernel drivers get "injected" in the kernel: > > target/linux/bcm53xx/files/drivers/firmware/broadcom > > Still this makes me believe they are openwrt specific kernel file, > but I guess, that is just how one wants to read this sentence. NVRAM driver is part of upstream kernel, it's just living in arch/mips/ for now: http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/mips/bcm47xx/nvram.c bcm53xx's file is just a copy of above and that would be the best to keep it this way. I think you may prepare patch on top of drivers/firmware/broadcom/bcm47xx_nvram.c for now, then we can work on upstreaming it. Meanwhile I'll be happy to add your patch to /home/zajec/openwrt/openwrt.git/target/linux/bcm53xx/patches-3.18/ It doesn't matter if you work on top of 110-firmware-backport-NVRAM-driver.patch, it doesn't even touch (bcm47xx_)nvram.c. bcm47xx_nvram.c.patch Description: bcm47xx_nvram.c.patch bcm47xx_nvram.h.patch Description: bcm47xx_nvram.h.patch ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
