OpenWrt Forum Archive

Topic: Netgear R8000 support?

The content of this topic has been archived between 23 Mar 2018 and 5 May 2018. Unfortunately there are posts – most likely complete pages – missing.

Oh, it seems you have your partitions there. That's nice!

I can see 3 problems there:

1) PCIe host controller
You're right, there is something wrong. I won't be able to fix it in the next days and on Monday I'm leaving for a week.

2) Ethernet MAC
For some reason NVRAM doesn't seem to provide valid MAC addr:

bgmac bcma0:3: Invalid MAC addr: 00:00:00:00:00:00
bgmac bcma0:3: Using random MAC: 16:4a:0e:2d:fa:56

Can you provide me output of "nvram show"?

3) LEDs and buttons
It would be nice to support them. Can you take a look at our howto:
http://wiki.openwrt.org/doc/devel/add.new.device#gpios
and try to find GPIOs controlling LEDs & buttons?

(Last edited by Zajec on 30 Jan 2015, 11:46)

Zajec wrote:

Oh, it seems you have your partitions there. That's nice!

I can see 3 problems there:

1) PCIe host controller
You're right, there is something wrong. I won't be able to fix it in the next days and on Monday I'm leaving for a week.

Yep.

Zajec wrote:

2) Ethernet MAC
For some reason NVRAM doesn't seem to provide valid MAC addr:

bgmac bcma0:3: Invalid MAC addr: 00:00:00:00:00:00
bgmac bcma0:3: Using random MAC: 16:4a:0e:2d:fa:56

Can you provide me output of "nvram show"?

Will the "nvram show" from the Netgear firmware be OK?


Zajec wrote:

3) LEDs and buttons
It would be nice to support them. Can you take a look at our howto:
http://wiki.openwrt.org/doc/devel/add.new.device#gpios
and try to find GPIOs controlling LEDs & buttons?

Sure, will try and have something for you on your return.
I also need to tear myself away from this to catch up on work.

Ian

Ahh, I can see the problem with MAC address. This unit uses pretty new SPROM revision, see:

sromrev=11

However there should be "Unsupported SPROM revision" in OpenWrt boot log, no idea why it didn't appear neutral

Any thoughts on why the PCI bus discovery isn't working?

No. You have to look for some problems in target/linux/bcm53xx/patches-3.14/170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch

Zajec wrote:

No. You have to look for some problems in target/linux/bcm53xx/patches-3.14/170-pcie2-bcma-add-new-PCIe2-driver-for-bcma.patch

Will do, not familiar with this though.

Here's an interesting bit of information.

AFAICS these devices don't have an SPROM!

Now, someone probably already knows that because under the bcm53xx target there's this file files/drivers/misc/bcm47xx-sprom.c.
OK, so this driver provides nvram -> sprom mapping, supposedly, to be used when there's no SPROM available.
OK, again, but it loads afrter the bcma module which calls the SPROM load.
So we can play with module load order to fix that.

Obviously the nvram -> sprom driver needs an nvram module.
OK, again even.
But the nvram module looks like requires an MTD module and we even see a driver for this at files/drivers/mtd/spi-nor/bcm53xxspiflash.c.
But that driver looks like it needs the base MTD and probably the SPI driver.

Not OK, since it looks like the pci bus scan must be completed for these modules to load.
OOPS!

Someone tell me I'm wrong, please!
Ian

(Last edited by raven-au on 3 Feb 2015, 10:10)

raven-au wrote:

AFAICS these devices don't have an SPROM!

Now, someone probably already knows that because under the bcm53xx target there's this file files/drivers/misc/bcm47xx-sprom.c.
OK, so this driver provides nvram -> sprom mapping, supposedly, to be used when there's no SPROM available.
OK, again, but it loads afrter the bcma module which calls the SPROM load.
So we can play with module load order to fix that.

Obviously the nvram -> sprom driver needs an nvram module.
OK, again even.
But the nvram module looks like requires an MTD module and we even see a driver for this at files/drivers/mtd/spi-nor/bcm53xxspiflash.c.
But that driver looks like it needs the base MTD and probably the SPI driver.

Not OK, since it looks like the pci bus scan must be completed for these modules to load.
OOPS!

Someone tell me I'm wrong, please!
Ian

In answer to my own question, no the MTD subsystem shouldn't be needed.

Provided that the sprom driver that implements the fallback SPROM provider is loaded early enough.
And a special call is made to the nvram -> sprom driver to prime the lookup cache which has been written to scan the NAND device for the nvram variables and read them in before calling the  fallback SPROM provider.

Now, if I can get that to work, all that needs to be done is add support for the differences in the revision 11 sprom variables.

You are overthinking that. Everything you need is already in place.
1) NVRAM is built-in exporting simple symbols
2) bcma registers SPI & NAND cores before any NVRAM entry is needed
3) SPI core driver loads, registers SPI master
4) mtd SPI driver loads, registers MTD and "nvram" partition
5) NVRAM starts working (entries can be read)
6) bcma triggers reading SPROM from NVRAM
7) bcma registers rest of cores

Zajec wrote:

You are overthinking that. Everything you need is already in place.
1) NVRAM is built-in exporting simple symbols
2) bcma registers SPI & NAND cores before any NVRAM entry is needed
3) SPI core driver loads, registers SPI master
4) mtd SPI driver loads, registers MTD and "nvram" partition
5) NVRAM starts working (entries can be read)
6) bcma triggers reading SPROM from NVRAM
7) bcma registers rest of cores

The messages

bcma: bus0: Using fallback SPROM failed (err -2)
bcma: bus0: No SPROM available
bma: bus0: Bus registered

definitely come before those other modules load.

There's an entry point in  files/drivers/firmware/broadcom/bcm47xx_nvram.c,  bcm47xx_nvram_init_from_mem(), specifically for the early access but I can't work out what should be used for the parameters to the function.

The above messages result from a call to bcma_sprom_get() in bcma_bus_register() which is done before any of the steps above occur.

However, as you say, the values aren't actually needed by anything until much later so maybe it isn't important.
It's worth another look and there's still the question of whether these devices actually have an SPROM.

TBH I'm more concerned with the pci scan failures and it's not worth doing anything else until that can be sorted out since pretty much nothing works. In particular no switch and no gpios.

It may be related to the device having a BCM53012 rather than a BCM53011 which the code seems to be aware of and, I guess, knows how to handle.

The only thing I know for sure is that at a certain point an attempt is made by the pci subsystem to read standard pci header values which fails.
But the device should be returning something different for a device that isn't present so the pci subsystem knows it or the read is not using the correct hardware access method, perhaps because it hasn't actually seen a BCM53012 before or perhaps the dts definition isn't quite right, not sure.

Have a look at this log:
https://www.dropbox.com/s/g51782t4p23ri … t.log?dl=0

You can see where this goes pear shaped.
Any suggestions.

Ian

(Last edited by raven-au on 9 Feb 2015, 03:30)

Oops, shit. I see the problem now, it appears on other Broadcom ARM devices as well.
At least it's clear now why there isn't "Unsupported SPROM revision" in the log.

To make it more interesting, building SPROM was working earlier, it's a regression since dropping some hacky code:
https://dev.openwrt.org/changeset/43981/

Zajec wrote:

Oops, shit. I see the problem now, it appears on other Broadcom ARM devices as well.
At least it's clear now why there isn't "Unsupported SPROM revision" in the log.

To make it more interesting, building SPROM was working earlier, it's a regression since dropping some hacky code:
https://dev.openwrt.org/changeset/43981/

LOL, so my reading of the code wasn't completely wrong.
We can return to this later although I wonder what effect that might have on the bus scan  .....

I'll add that patch back and see what happens just so I know.

raven-au wrote:

I'll add that patch back and see what happens just so I know.

I've added a bit more sane patch, see
https://dev.openwrt.org/changeset/44367/

Let me know if you get a message about SPROM revision now and maybe try to find GPIOs in some free time smile

(Last edited by Zajec on 9 Feb 2015, 19:45)

Zajec wrote:
raven-au wrote:

I'll add that patch back and see what happens just so I know.

I've added a bit more sane patch, see
https://dev.openwrt.org/changeset/44367/

Let me know if you get a message about SPROM revision now and maybe try to find GPIOs in some free time smile

I'll give it a try but the bus scan still fails with the old patch so, no switch, no gpios etc.
I'm not sure this will make a difference to that.

I was looking at bgmac.c and noticed something odd.

There are a number of checks for, for example BCMA_CHIP_ID_BCM4707, and in most cases they use struct bcma_chipinfo from the struct bcma_device. But a couple use the id from struct bcma_device_id.

On my device the bcma_chipinfo id corresponds to, for example BCMA_CHIP_ID_BCM4707, whereas the bcma_device_id corresponds to the switch id so in the (I think two) cases where bcma_device_id is used the check will never succeed.

That looks wrong to me because, for example, in bgmac_chip_reset() it refers to doing the reset in bgmac_probe() but in bgmac_probe() the reset won't be done due to this.

Thoughts?

raven-au wrote:
Zajec wrote:
raven-au wrote:

I'll add that patch back and see what happens just so I know.

I've added a bit more sane patch, see
https://dev.openwrt.org/changeset/44367/

Let me know if you get a message about SPROM revision now and maybe try to find GPIOs in some free time smile

I'll give it a try but the bus scan still fails with the old patch so, no switch, no gpios etc.
I'm not sure this will make a difference to that.

And it didn't, *sigh*.

raven-au wrote:
Zajec wrote:
raven-au wrote:

I'll add that patch back and see what happens just so I know.

I've added a bit more sane patch, see
https://dev.openwrt.org/changeset/44367/

Let me know if you get a message about SPROM revision now and maybe try to find GPIOs in some free time smile

I'll give it a try but the bus scan still fails with the old patch so, no switch, no gpios etc.
I'm not sure this will make a difference to that.

I should have also mentioned I did get the expected message about the SPROM revision.
I guess it's worth updating that to deal with rev 11 regardless of how this progresses.
Is this page sufficiently up to date?
http://bcm-v4.sipsolutions.net/SPROM

It does specify rev 11 differences.
Ian

raven-au wrote:
raven-au wrote:

I'll give it a try but the bus scan still fails with the old patch so, no switch, no gpios etc.
I'm not sure this will make a difference to that.

And it didn't, *sigh*.

Please provide a log, otherwise we know nothing neutral

Zajec wrote:
raven-au wrote:
raven-au wrote:

I'll give it a try but the bus scan still fails with the old patch so, no switch, no gpios etc.
I'm not sure this will make a difference to that.

And it didn't, *sigh*.

Please provide a log, otherwise we know nothing neutral

These logs are older (I'll add printks again later if needed) but the recent log messages I see indicate the problem is occurring in the same way at the same place.

A boot log:
https://www.dropbox.com/s/g51782t4p23ri … t.log?dl=0

and the dmesg output after the boot has slightly more info:
https://www.dropbox.com/s/9c2pyj57jve7h … g.log?dl=0

It  looks like a device is hung somehow and is returning rubbish.
Not quite which device it is...

raven-au wrote:
Zajec wrote:
raven-au wrote:

And it didn't, *sigh*.

Please provide a log, otherwise we know nothing neutral

These logs are older (I'll add printks again later if needed) but the recent log messages I see indicate the problem is occurring in the same way at the same place.

A boot log:
https://www.dropbox.com/s/g51782t4p23ri … t.log?dl=0

and the dmesg output after the boot has slightly more info:
https://www.dropbox.com/s/9c2pyj57jve7h … g.log?dl=0

It  looks like a device is hung somehow and is returning rubbish.
Not quite which device it is...

@Zajec, no thoughts on this?

Perhaps it's the PEX8603 that's causing confusion, I can't see any driver for this?

OK, I finally resolved other issues and got time to look at this R8000.


raven-au wrote:
Zajec wrote:

I've added a bit more sane patch, see
https://dev.openwrt.org/changeset/44367/

Let me know if you get a message about SPROM revision now and maybe try to find GPIOs in some free time smile

I'll give it a try but the bus scan still fails with the old patch so, no switch, no gpios etc.
I'm not sure this will make a difference to that.

I took a look at log you provided (openwrt-pci-prob-boot.log) and:

  1. It uses r44186 so it doesn't contain my fix for bus loading. It was added in r44367.

  2. I see "bcma: bus0: Found chip with id 53010, rev 0x00 and package 0x00" and many devices below, so bus scanning seems to work.

  3. Switch won't work because of using old revision. You need r44367 to get SPROM working. You need SPROM to get bgmac working. You need bgmac to get switch working.

  4. I don't see any GPIO error, is /sys/class/gpio empty for you or something?


raven-au wrote:

I was looking at bgmac.c and noticed something odd.

There are a number of checks for, for example BCMA_CHIP_ID_BCM4707, and in most cases they use struct bcma_chipinfo from the struct bcma_device. But a couple use the id from struct bcma_device_id.

A very nice catch, thank you! Fixed in:
https://git.kernel.org/cgit/linux/kerne … b1e7f06cc0
https://dev.openwrt.org/changeset/44411/


raven-au wrote:

I should have also mentioned I did get the expected message about the SPROM revision.
I guess it's worth updating that to deal with rev 11 regardless of how this progresses.
Is this page sufficiently up to date?
http://bcm-v4.sipsolutions.net/SPROM

It does specify rev 11 differences.

I think we can use bcmsrom_tbl.h, it's open source and can be Googled easily.

raven-au wrote:

These logs are older (I'll add printks again later if needed) but the recent log messages I see indicate the problem is occurring in the same way at the same place.

A boot log:
https://www.dropbox.com/s/g51782t4p23ri … t.log?dl=0

and the dmesg output after the boot has slightly more info:
https://www.dropbox.com/s/9c2pyj57jve7h … g.log?dl=0

It  looks like a device is hung somehow and is returning rubbish.
Not quite which device it is...

I finally took a look at this PCI problem. I was looking at above logs and another one you shared on IRC: https://www.dropbox.com/s/1uv912m0cj3ik … s.txt?dl=0

First of all, I'm a bit surprised how PCI host/devices are connected. This router contains 3 PCIe devices and has 3 PCIe hosts, so I expected there will be one device per PCIe host. In other words I expected 3 separated PCI domains. This is not really the case:

[    0.602917] pci_host_bcm5301x bcma0:7: initializing PCIe controller
[    0.880319] pci_host_bcm5301x bcma0:7: link: UP
[    0.886400] pci_host_bcm5301x bcma0:7: PCI host bridge to bus 0000:00
[    1.018950] pci_host_bcm5301x bcma0:8: initializing PCIe controller
[    1.300309] pci_host_bcm5301x bcma0:8: link: UP
[    1.306346] pci_host_bcm5301x bcma0:8: PCI host bridge to bus 0001:00
[    2.377650] pci_host_bcm5301x bcma0:9: initializing PCIe controller
[    2.770308] pci_host_bcm5301x bcma0:9: link: DOWN

Worth noting when looking at this issue.

So the first domain (0001: for Broadcom firmware, 0000: for OpenWrt) contains 2 buses:

  1. One with just a 14e4:8012.

  2. Another with just a 14e4:aa52. It seems brcmfmac may be missing 14e4:aa52 entry.

The 2nd domain (0002: for Broadcom firmware, 0001: for OpenWrt) contains 5 buses:

  1. 1 device with ID 14e4:8012

  2. 1 device with ID 10b5:8603

  3. 2 devices, both 10b5:8603

  4. 1 device with ID 14e4:aa52

  5. 1 device with ID 14e4:aa52

The first PCI domain (with a 1st BCM43602) seems to be working fine with OpenWrt.

In case on 2nd domain (with two BCM43602 as last buses) there are following errors that could worry us:

[    1.456450] pci 0001:03:00.0: BAR 2: can't assign mem (size 0x400000)
[    1.464640] pci 0001:03:00.0: BAR 0: can't assign mem (size 0x8000)
[    1.478950] pci 0001:04:00.0: BAR 2: can't assign mem (size 0x400000)
[    1.487142] pci 0001:04:00.0: BAR 0: can't assign mem (size 0x8000)

It may be worth to check if we try assigning memory correcty in our PCI host driver.

Zajec wrote:

OK, I finally resolved other issues and got time to look at this R8000.

Right, thanks for looking at this.


Zajec wrote:

I don't see any GPIO error, is /sys/class/gpio empty for you or something?

Yeah, either it didn't work last time I tried or I didn't perform the procedure correctly.
I tried the gpios again yesterday and I was able to make the power light go off and then on.

I'll work through the gpio process and get back with the info.

Umm, what should I do about leds that have three states, off, white (on) and and Amber (error or pending)?

Sorry, posts 51 to 50 are missing from our archive.