Thread (24 messages) 24 messages, 6 authors, 2014-09-01

Re: Booting bcm47xx (bcma & stuff), sharing code with bcm53xx

From: Rafał Miłecki <zajec5@gmail.com>
Date: 2014-09-01 07:48:55
Also in: linux-mips

On 31 August 2014 11:20, Rafał Miłecki [off-list ref] wrote:
On 29 August 2014 22:04, Arnd Bergmann [off-list ref] wrote:
quoted
You mentioned that the 'boot_device' variable in your code snippet
comes from a hardware register that can be accessed easily, right?
A possible way to handle it would then be to have two DT entries
like

        nvram@1c000000 {
                compatible = "bcm,bcm4710-nvram";
                reg = <0x1c000000 0x1000000>;
                bcm,boot-device = BCMA_BOOT_DEV_NAND;
        };

        nvram@1c000000 {
                compatible = "bcm,bcm4710-nvram";
                reg = <0x1e000000 0x1000000>;
                bcm,boot-device = BCMA_BOOT_DEV_SERIAL;
        };
This sounds like a nice consensus for me! Actually it seems to be
similar to what we already do for other hardware parts.

E.g. in bcm4708.dtsi Hauke put registers location of 4 Ethernet cores
(gmac@0, gmac@1, gmac@2, gmac@3). I believe this board is ready for 4
Ethernet cores so DT matches hardware capabilities. Then most vendors
use/activate only one (maybe up to 2?) Ethernet cores. It's up to the
driver to detect if core is activated/used.

AFAIU having two flash mappings (as suggested above) would follow this
logic. It would match hardware capabilities. And then it would be up
to driver to detect which one mapping is really in use for this
particular board.

Does it make sense?
I've just realized something. When Broadcom's code reads NVRAM content
it uses "hndnand_checkbadb" to skip bad blocks. It seems NVRAM doesn't
lay in 100% reliable flash sectors.

Above function comes from shared/ which (the directory) provides tons
of low level stuff without using any kernel API. OFC it won't be
acceptable for us to implement low level NAND stuff in the nvram
driver (this would mean duplicating NAND driver code). It seems we
won't be able to use NAND flash mapping to the memory (this magic
0x1c000000) at all...

So I think we'll need to change our vision of flash access in
bcm74xx_nvram driver. I guess we will have to:
1) Register NAND core early
2) Initialize NAND driver
3) Use mtd/nand API in bcm47xx_nvram

-- 
Rafał
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help