Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes

[Florian Fainelli]

On 4/2/24 13:32, Laurent Pinchart wrote:

Hi Florian,

On Tue, Apr 02, 2024 at 01:18:35PM -0700, Florian Fainelli wrote:

On 4/2/24 13:08, Laurent Pinchart wrote:

On Tue, Apr 02, 2024 at 09:52:06PM +0200, Stefan Wahren wrote:

Am 02.04.24 um 10:58 schrieb Ivan T. Ivanov:

On 2024-03-28 01:37, Laurent Pinchart wrote:

On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote:

Hi,

[add Peter and Ivan]

Am 26.03.24 um 20:58 schrieb Laurent Pinchart:

Hello,

This small series includes a few drive-by fixes for DT validation
errors.

The first patch has been posted previously in v1 ([1], and now addresses
a small review comment. I think it's good to go.

The next two patches address the same issue as "[PATCH 1/2] dt-bindings:
arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]),
but this time with a (hopefully) correct approach. Patch 2/3 starts by
fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT
properties that are specified in bcm2835-rpi.dtsi but not documented in
the corresponding bindings. Patch 3/3 can then drop those properties,
getting rid of the warnings.


since this series drops properties from the device tree, does anyone
have the chance to test it with a recent U-Boot?


I don't have U-Boot running with my RPi, so I would appreciate if
someone could help :-)


Sorry for taking me so long to verify this.

I think on RPi U-Boot side we are fine. API used when accessing Mbox
device do not follow DM model and do not use DMA, but just access
device directly using this nice macros phys_to_bus/bus_to_phys.

I build new DTB files with this patch included and U-Boot build
from the latest sources. No obvious issues on RPi3 and RPi4.
Devices boot fine.


Thank you for testing Ivan.


Thanks you, Laurent and Ivan

Reviewed-by: Stefan Wahren 


Stefan, I'm quite unfamiliar with the Raspberry Pi upstreaming process
(despite having sent patches for ages :-)), do I understand correctly
that this patch will go through your tree, or do I need to work with
someone else to get it merged upstream ?


I will be taking those via the Broadcom SoC tree.


Thank you.

If there's a chance to include patches 05/10, 07/10, 08/10 and 09/10
from [1] at the same time, that would be great :-)

[1] 
https://lore.kernel.org/linux-media/20240402000424.4650-1-laurent.pinch...@ideasonboard.com



Yes, now done, thanks!
--
Florian



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes

[Florian Fainelli]

On 4/2/24 01:58, Ivan T. Ivanov wrote:


Hi,

On 2024-03-28 01:37, Laurent Pinchart wrote:

On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote:

Hi,

[add Peter and Ivan]

Am 26.03.24 um 20:58 schrieb Laurent Pinchart:
> Hello,
>
> This small series includes a few drive-by fixes for DT validation
> errors.
>
> The first patch has been posted previously in v1 ([1], and now 
addresses

> a small review comment. I think it's good to go.
>
> The next two patches address the same issue as "[PATCH 1/2] 
dt-bindings:

> arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]),
> but this time with a (hopefully) correct approach. Patch 2/3 starts by
> fixing the raspberrypi-bcm2835-firmware driver, removing the need 
for DT
> properties that are specified in bcm2835-rpi.dtsi but not 
documented in

> the corresponding bindings. Patch 3/3 can then drop those properties,
> getting rid of the warnings.

since this series drops properties from the device tree, does anyone
have the chance to test it with a recent U-Boot?


I don't have U-Boot running with my RPi, so I would appreciate if
someone could help :-)


Sorry for taking me so long to verify this.

I think on RPi U-Boot side we are fine. API used when accessing Mbox
device do not follow DM model and do not use DMA, but just access
device directly using this nice macros phys_to_bus/bus_to_phys.

I build new DTB files with this patch included and U-Boot build
from the latest sources. No obvious issues on RPi3 and RPi4.
Devices boot fine.


Can I add this as a Tested-by tag from you while applying then?
--
Florian

Re: [PATCH v2 0/3] dt-bindings: arm: bcm: raspberrypi,bcm2835-firmware: Drive-by fixes

[Florian Fainelli]

On 4/2/24 13:08, Laurent Pinchart wrote:

Hello,

On Tue, Apr 02, 2024 at 09:52:06PM +0200, Stefan Wahren wrote:

Am 02.04.24 um 10:58 schrieb Ivan T. Ivanov:

On 2024-03-28 01:37, Laurent Pinchart wrote:

On Wed, Mar 27, 2024 at 07:49:38AM +0100, Stefan Wahren wrote:

Hi,

[add Peter and Ivan]

Am 26.03.24 um 20:58 schrieb Laurent Pinchart:

Hello,

This small series includes a few drive-by fixes for DT validation
errors.

The first patch has been posted previously in v1 ([1], and now addresses
a small review comment. I think it's good to go.

The next two patches address the same issue as "[PATCH 1/2] dt-bindings:
arm: bcm: raspberrypi,bcm2835-firmware: Add missing properties" ([2]),
but this time with a (hopefully) correct approach. Patch 2/3 starts by
fixing the raspberrypi-bcm2835-firmware driver, removing the need for DT
properties that are specified in bcm2835-rpi.dtsi but not documented in
the corresponding bindings. Patch 3/3 can then drop those properties,
getting rid of the warnings.


since this series drops properties from the device tree, does anyone
have the chance to test it with a recent U-Boot?


I don't have U-Boot running with my RPi, so I would appreciate if
someone could help :-)


Sorry for taking me so long to verify this.

I think on RPi U-Boot side we are fine. API used when accessing Mbox
device do not follow DM model and do not use DMA, but just access
device directly using this nice macros phys_to_bus/bus_to_phys.

I build new DTB files with this patch included and U-Boot build
from the latest sources. No obvious issues on RPi3 and RPi4.
Devices boot fine.


Thank you for testing Ivan.


Thanks you, Laurent and Ivan

Reviewed-by: Stefan Wahren 


Stefan, I'm quite unfamiliar with the Raspberry Pi upstreaming process
(despite having sent patches for ages :-)), do I understand correctly
that this patch will go through your tree, or do I need to work with
someone else to get it merged upstream ?


I will be taking those via the Broadcom SoC tree.
--
Florian

Re: [PATCH v4 2/6] rpi5: Use devicetree as alternative way to read IO base addresses

[Florian Fainelli]

On 1/10/24 04:29, Ivan T. Ivanov wrote:

From: Dmitry Malkin 

MBOX and Watchdog on RPi5/bcm2712 has a different base IO offsets.


s/has a/have a /


Find them via devicetree blob passed by bootloader.

Signed-off-by: Dmitry Malkin 
Reviewed-by: Matthias Brugger 
Signed-off-by: Ivan T. Ivanov 
---
  arch/arm/mach-bcm283x/include/mach/base.h  |  5 ++-
  arch/arm/mach-bcm283x/include/mach/mbox.h  |  3 +-
  arch/arm/mach-bcm283x/include/mach/sdhci.h |  3 +-
  arch/arm/mach-bcm283x/include/mach/timer.h |  3 +-
  arch/arm/mach-bcm283x/include/mach/wdog.h  |  3 +-
  arch/arm/mach-bcm283x/init.c   | 43 ++
  6 files changed, 43 insertions(+), 17 deletions(-)

diff --git a/arch/arm/mach-bcm283x/include/mach/base.h 
b/arch/arm/mach-bcm283x/include/mach/base.h
index 4ccaf69693..6de99e7ea1 100644
--- a/arch/arm/mach-bcm283x/include/mach/base.h
+++ b/arch/arm/mach-bcm283x/include/mach/base.h
@@ -6,7 +6,10 @@
  #ifndef _BCM283x_BASE_H_
  #define _BCM283x_BASE_H_
  
-extern unsigned long rpi_bcm283x_base;

+extern unsigned long rpi_mbox_base;
+extern unsigned long rpi_timer_base;
+extern unsigned long rpi_sdhci_base;
+extern unsigned long rpi_wdog_base;


Maybe suffix those variables with _phys_base to denote they are physical 
addresses, even if you seem to use a 1:1 mapping between virtual and 
physical, knowing which type of address we are dealing with right away 
is clearer.

--
Florian



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH v4 1/6] rpi5: add initial memory map for bcm2712

[Florian Fainelli]

On 1/10/24 04:29, Ivan T. Ivanov wrote:

From: Dmitry Malkin 

This includes:
* 1GB of RAM (from 4GB or 8GB total)
* AXI ranges (main peripherals)

When HDMI cable is plugged in at boot time firmware will
insert "simple-framebuffer" device into devicetree and will
shrink first memory region to 0x3f80UL. Board setup then
will properly reserve frameboofer region.


s/frameboofer/framebuffer/



When no HDMI cable is plugged in size of the region will be
0x3fc0UL.


s/in size/in the size/
--
Florian



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH v3 5/7] mmc: bcmstb: Add support for bcm2712 SD controller

[Florian Fainelli]

On 12/18/2023 10:03 PM, Ivan T. Ivanov wrote:

Borrow SD quirks from vendor Linux driver.

"BCM2712 unfortunately carries with it a perennial bug with the SD
controller register interface present on previous chips (2711/2709/2708).
Accesses must be dword-sized and a read-modify-write cycle to the 32-bit
registers containing the COMMAND, TRANSFER_MODE, BLOCK_SIZE and
BLOCK_COUNT registers tramples the upper/lower 16 bits of data written.
BCM2712 does not seem to need the extreme delay between each write as on
previous chips, just the serialisation of writes to these registers in a
single 32-bit operation."

Signed-off-by: Ivan T. Ivanov 


This is diverging from the Linux sdhci-brcmstb.c driver where no such 
quirk needs to be carried out, rather the logic for such quirks has been 
present in sdhci-iproc.c...

--
Florian


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [PATCH 0/4] arm: bcmbca: add basic support for more Broadcom BCA SoCs

[Florian Fainelli]

On 8/5/2022 6:33 PM, William Zhang wrote:

Broadcom BCA (Broadband Carrier Access origin) chipset family includes
DSL, PON and WLAN access point and gateway SoC. Now that the ARCH_BCMBCA
architecture and its first SoC BCM47622 are supported in u-boot 2022.07,
this patch series add the basic support for following BCA chips under
ARCH_BCMBCA: BCM4908, BCM4912, BCM63146 and BCM6813.

This patch series applies on top of the my previous patch [1].

[1] https://lists.denx.de/pipermail/u-boot/2022-August/491060.html


Looks good to me, thanks William! On the mmu_table.c implementation 
maybe just a few nits:


- should not we do an early parsing of the memory node for the given 
board(s) to ensure that we map no more than the amount of available DRAM?


- the exact same file is currently being re-used, so it would make sense 
to make it a common object


- you could create a memory mapping for the AXI bus region right away to 
avoid forgetting about it later if you start bringing up drivers that 
make use of that peripheral region


Thanks!
--
Florian

Re: [PATCH 4/4] arm: bcmbca: add bcm4908 SoC support

[Florian Fainelli]

On 8/5/2022 6:34 PM, William Zhang wrote:

BCM4908 is a Broadcom B53 based WLAN AP router SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added
under ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and Broadcom uart.

This SoC is supported in the linux git repository so the dts and dtsi
files are stripped down version of linux copies with mininum blocks
needed by u-boot.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang 


Reviewed-by: Florian Fainelli 
--
Florian

Re: [PATCH 3/4] arm: bcmbca: add bcm6813 SoC support

[Florian Fainelli]

On 8/5/2022 6:34 PM, William Zhang wrote:

BCM6813 is a Broadcom B53 based PON and WLAN AP router SoC. It is part
of the BCA (Broadband Carrier Access origin) chipset family so it's
added under ARCH_BCMBCA platform. This initial support includes a
bare-bone implementation and dts with CPU subsystem, memory and ARM
PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang 
---

  MAINTAINERS  |   1 +
  arch/arm/dts/Makefile|   2 +
  arch/arm/dts/bcm6813.dtsi| 128 +++
  arch/arm/dts/bcm96813.dts|  30 ++
  arch/arm/mach-bcmbca/Kconfig |   8 ++
  arch/arm/mach-bcmbca/Makefile|   1 +
  arch/arm/mach-bcmbca/bcm6813/Kconfig |  17 +++
  arch/arm/mach-bcmbca/bcm6813/Makefile|   5 +
  arch/arm/mach-bcmbca/bcm6813/mmu_table.c |  32 ++


OK, so after seeing the same mmu_table.c 4 times, maybe we could share a 
common implementation that is configurable enough, even if there may not 
be any need for configuration other than the DRAM size.


Reviewed-by: Florian Fainelli 
--
Florian

Re: [PATCH 2/4] arm: bcmbca: add bcm4912 SoC support

[Florian Fainelli]

On 8/5/2022 6:34 PM, William Zhang wrote:

BCM4912 is a Broadcom B53 based WLAN AP router SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts
and dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there to the console.

Signed-off-by: William Zhang 


Same question as in patch #1, but otherwise:

Reviewed-by: Florian Fainelli 
--
Florian

Re: [PATCH 1/4] arm: bcmbca: add bcm63146 SoC support

[Florian Fainelli]

On 8/5/2022 6:34 PM, William Zhang wrote:

BCM63146 is a Broadcom B53 based DSL Broadband SoC. It is part of the
BCA (Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory and ARM PL011 uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are copied from linux.

The u-boot image can be loaded from flash or network to the entry point
address in the memory and boot from there to the console.

Signed-off-by: William Zhang 
---


[snip]


+#include 
+#include 
+#include 
+
+static struct mm_region bcm963146_mem_map[] = {
+   {
+   .virt = 0xUL,
+   .phys = 0xUL,
+   .size = 1UL * SZ_1G,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+   PTE_BLOCK_INNER_SHARE
+   },
+   {


Should you create a mapping for the AXI bus portion at PA 0x8100 
just so it is already in place for when you might need it?


Reviewed-by: Florian Fainelli 
--
Florian

Re: ethernet dt aliases implications in U-Boot and Linux

[Florian Fainelli]

On 8/8/22 14:28, Tim Harvey wrote:

On Mon, Aug 8, 2022 at 2:19 PM Florian Fainelli  wrote:


On 8/8/22 12:57, Sean Anderson wrote:

Hi Tim,

On 8/8/22 3:18 PM, Tim Harvey wrote:

Greetings,

I'm trying to understand if there is any implication of 'ethernet'
aliases in Linux such as:
  aliases {
  ethernet0 = 
  ethernet1 = 
  ethernet2 = 
  ethernet3 = 
  ethernet4 = 
  ethernet5 = 
  ethernet6 = 
  };

I know U-Boot boards that use device-tree will use these aliases to
name the devices in U-Boot such that the device with alias 'ethernet0'
becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
appears that the naming of network devices that are embedded (ie SoC)
vs enumerated (ie pci/usb) are always based on device registration
order which for static drivers depends on Makefile linking order and
has nothing to do with device-tree.

Is there currently any way to control network device naming in Linux
other than udev?


You can also use systemd-networkd et al. (but that is the same kind of 
mechanism)


Does Linux use the ethernet aliases for anything at all?


No :l


It is actually used, but by individual drivers, not by the networking
stack AFAICT:

git grep -E "of_alias_get_id\((.*), \"(eth|ethernet)\"\)" *
drivers/net/ethernet/broadcom/genet/bcmmii.c:   id =
of_alias_get_id(dn, "eth");
drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:plat->bus_id =
of_alias_get_id(np, "ethernet");
drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:   plat->bus_id =
of_alias_get_id(np, "ethernet");
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:  plat->bus_id =
of_alias_get_id(np, "ethernet");

There were discussions about using that alias to name ethernet network
devices in the past (cannot quite point to the thread), the current
consensus appears to be that if you use the "label" property (which was
primed by DSA) then your network device will follow that name, still not
something the networking stack does for you within the guts of
register_netdev().


Right, I recall several discussions and debates about this.

I did find a few references:
- failed attempt at using dt for naming:
https://patchwork.kernel.org/project/linux-arm-kernel/patch/1399390594-1409-1-git-send-email-boris.brezil...@free-electrons.com/
- systemd predicatable interface names:
https://systemd.io/PREDICTABLE_INTERFACE_NAMES/

I do find it odd that for DSA devices the port names are defined in dt
yet the cpu uplink port can not be.


There is no network interface created for the CPU port on the switch 
side, and the other network device (named the DSA conduit) is just a 
conduit, so its name does not matter so much except for making sure that 
it is brought up before the DSA ports that are dependent upon it and 
that can be resolved via "ip link show (the interface after the '@'). It 
matter even less nowadays that it gets brought up automatically by any 
of the user facing ports of the DSA switch:


https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9d5ef190e5615a7b63af89f88c4106a5bc127974



The issue I was trying to work through is an IMX8MP board which has
IMX8MP FEC as the cpu uplink port to a GbE switch and IMX8MP EQOS as
an additional GbE. In this case the FEC enumerates first becoming eth0
and the EQOS second becoming eth1. I wanted to make the EQOS eth0 as
it is the first RJ45 on the board physically followed by
lan1/lan2/lan3/lan4/lan5. While I can do this in U-Boot by controlling
the aliases for fec/eqos the same doesn't work for Linux so it's not
worth doing as that would add user confusion.


None of that should matter in Linux anymore however, the names of the 
Ethernet controller(s) connected to your switch have no significance, 
see above.




I have never liked the idea of using systemd to deal with network
interface re-naming as that's just another dependency where embedded
Linux users typically want to strip things down to the bare minimum.


Fair enough.
--
Florian

Re: ethernet dt aliases implications in U-Boot and Linux

[Florian Fainelli]

On 8/8/22 12:57, Sean Anderson wrote:

Hi Tim,

On 8/8/22 3:18 PM, Tim Harvey wrote:

Greetings,

I'm trying to understand if there is any implication of 'ethernet'
aliases in Linux such as:
 aliases {
 ethernet0 = 
 ethernet1 = 
 ethernet2 = 
 ethernet3 = 
 ethernet4 = 
 ethernet5 = 
 ethernet6 = 
 };

I know U-Boot boards that use device-tree will use these aliases to
name the devices in U-Boot such that the device with alias 'ethernet0'
becomes eth0 and alias 'ethernet1' becomes eth1 but for Linux it
appears that the naming of network devices that are embedded (ie SoC)
vs enumerated (ie pci/usb) are always based on device registration
order which for static drivers depends on Makefile linking order and
has nothing to do with device-tree.

Is there currently any way to control network device naming in Linux
other than udev?


You can also use systemd-networkd et al. (but that is the same kind of 
mechanism)


Does Linux use the ethernet aliases for anything at all?


No :l


It is actually used, but by individual drivers, not by the networking 
stack AFAICT:


git grep -E "of_alias_get_id\((.*), \"(eth|ethernet)\"\)" *
drivers/net/ethernet/broadcom/genet/bcmmii.c:   id = 
of_alias_get_id(dn, "eth");
drivers/net/ethernet/samsung/sxgbe/sxgbe_platform.c:plat->bus_id = 
of_alias_get_id(np, "ethernet");
drivers/net/ethernet/stmicro/stmmac/dwmac-loongson.c:   plat->bus_id = 
of_alias_get_id(np, "ethernet");
drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c:  plat->bus_id = 
of_alias_get_id(np, "ethernet");


There were discussions about using that alias to name ethernet network 
devices in the past (cannot quite point to the thread), the current 
consensus appears to be that if you use the "label" property (which was 
primed by DSA) then your network device will follow that name, still not 
something the networking stack does for you within the guts of 
register_netdev().

--
Florian

Re: [PATCH] arm: bcmbca: add bcm63138 SoC support

[Florian Fainelli]

On 8/1/2022 3:18 PM, William Zhang wrote:

BCM63138 is an ARM A9 based DSL Broadband SoC. It is part of the BCA
(Broadband Carrier Access origin) chipset family so it's added under
ARCH_BCMBCA platform. This initial support includes a bare-bone
implementation and dts with CPU subsystem, memory, peripheral timer and
Broadcom uart.

This SoC is supported in the linux-next git repository so the dts and
dtsi files are stripped down version of linux copies with mininum blocks
needed by u-boot.

The u-boot image can be loaded from flash or network to the entry
point address in the memory and boot from there.

This patch applies on top of the my previous patch [1] and depends
on the timer support from patch [2].

[1] https://lists.denx.de/pipermail/u-boot/2022-August/490597.html
[2] https://lists.denx.de/pipermail/u-boot/2022-August/490570.html

Signed-off-by: William Zhang 


FWIW:

Reviewed-by: Florian Fainelli 
--
Florian

Re: [PATCH] timer: bcmbca: Add Broadcom BCMBCA timer support

[Florian Fainelli]

On 8/2/2022 5:07 PM, William Zhang wrote:

Hi Rafal,

On 08/01/2022 10:26 PM, Rafał Miłecki wrote:

On 2.08.2022 00:03, William Zhang wrote:

This driver supports the peripheral block timer found on the Broadcom
BCA SoCs. It is 30-bit up-count timer running at 50MHz and can be used
as the system clock source such as on BCM63138.
Signed-off-by: William Zhang 

(...)

+static const struct udevice_id bcmbca_timer_ids[] = {
+    { .compatible = "brcm,bcm-timers" },
+    { }
+};
+
+U_BOOT_DRIVER(bcmbca_timer) = {
+    .name = "bcmbca_timer",
+    .id = UCLASS_TIMER,
+    .of_match = bcmbca_timer_ids,
+    .priv_auto = sizeof(struct bcmbca_timer_priv),
+    .probe = bcmbca_timer_probe,
+    .ops = _timer_ops,
+    .flags = DM_FLAG_PRE_RELOC,
+};


That "brcm,bcm-timers" seems like a really wide bidding. Is that exact
timer block guaranteed to be present on all Broadcom devices? Does it
exist e.g. on Northstar SoCs? Or old MIPS SoCs like BCM4706?


Agree I will make change to use brcm,bcmbca-timers.


Why not change to use a compatible string that uses the first chip in 
which this timer block was introduced, was that 6345 or later?





It seems that even across BCMBCA devices this block may differ and may
need different bindings. Most SoCs have 4 CTL and 4 CNT registers but
some have only 3 + 3 (BCM6838 BCM60333 BCM63268).
This timer driver is intended for the clock source for u-boot only so 
only need the first channel. Although it could work for the old mips 
based dsl chip, BCMBCA chip family support is only for the new ARM based 
  chips which is stated in the BCMBA introduction patch.




Finally could we have that binding actually documented?
I don't see u-boot has binding document.  I believe it generally use 
linux binding document.  I have no plan to upstream this driver to 
linux. But I can put the binding info in the driver if that is the right 
way to do in u-boot.


Out of curiosity, why does u-boot require this timer as opposed to using 
the Cortex-A9 architected timers? Is it necessary to boot strap the A9 
timers?

--
Florian

Re: [PATCH] net: bcmgenet: Don't set ID_MODE_DIS when not using RGMII

[Florian Fainelli]

On 2/20/20 8:36 AM, Nicolas Saenz Julienne wrote:
> As per Linux's driver, ID_MODE_DIS is only set when the PHY interface is
> RGMII. Don't enable it for the rest of setups.
> 
> This has been seen to misconfigure RPi4's PHY when booting Linux.
> 
> Signed-off-by: Nicolas Saenz Julienne 

Does the failure look like the following: you have a driver for the
Broadcom PHY used on the Pi4 in u-boot, and the phy_dev->interface value
is being used to configure the Ethernet PHY chip in a certain way.

Later when you boot Linux, you do not have CONFIG_BROADCOM_PHY enabled
so the Generic PHY driver gets used instead, and there is a disagreement
between the AMAC and PHY as to whom should be adding the delays?

At any rate:

Reviewed-by: Florian Fainelli 

> ---
>  drivers/net/bcmgenet.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/net/bcmgenet.c b/drivers/net/bcmgenet.c
> index 8f4848aec6..e971b556ac 100644
> --- a/drivers/net/bcmgenet.c
> +++ b/drivers/net/bcmgenet.c
> @@ -448,7 +448,10 @@ static int bcmgenet_adjust_link(struct bcmgenet_eth_priv 
> *priv)
>   }
>  
>   clrsetbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, OOB_DISABLE,
> - RGMII_LINK | RGMII_MODE_EN | ID_MODE_DIS);
> + RGMII_LINK | RGMII_MODE_EN);
> +
> + if (phy_dev->interface == PHY_INTERFACE_MODE_RGMII)
> + setbits_32(priv->mac_reg + EXT_RGMII_OOB_CTRL, ID_MODE_DIS);
>  
>   writel(speed << CMD_SPEED_SHIFT, (priv->mac_reg + UMAC_CMD));
>  
> 


-- 
Florian

Re: [PATCH 1/3] net: Add support for Broadcom GENETv5 Ethernet controller

[Florian Fainelli]

On 12/19/2019 4:58 AM, Daniel Schwierzeck wrote:
> Hi Andre,
> 
> Am 19.12.19 um 12:42 schrieb Andre Przywara:
>> On Thu, 19 Dec 2019 12:32:06 +0100
>> Daniel Schwierzeck  wrote:
>>
>> Hi Daniel,
>>
>> many thanks for your valuable comments! Do you have access to a MIPS board 
>> using a GENETv5 MAC? I would be very curious to see if the driver works 
>> there, and am happy to make adjustments.
> 
> No, I have not. I was only triggered by your commit message that this
> MAC is also used on some MIPS based Broadcom SoC's ;)

GENET v1, v2 and v3 are used exclusively used on MIPS-based Broadcom STB
chips. GENET v4 is used exclusively used on ARM (32-bit) Broadcom STB
chips and finally GENET v5 is used exclusively used on ARM 64-bit based
chips, including 2711. Unlike other peripherals (SPI, NAND, I2C,
Ethernet switches and PHYs) this Ethernet MAC is only used on STB chips
and no other business unit within Broadcom has used it AFAICT so the
chances of finding GENET in a non STB chips are close to zero at this point.

The GENET data path goes through a proprietary bus called SCB which for
MIPS and ARM 32-bit was configurable to be little, big or automatically
follow the CPU's endian which is the default. With the latest 64-bit ARM
chips it was decided to drop the endian configuration and hard code the
bus to be little endian. The register interface goes through a
proprietary bus called GISB which always follows the CPU's endian and is
not configurable AFAICT (there are other properties, like no
re-ordering, no posting, which is why "raw" accessors are correct, too).
Therefore using native endian accessors is the right thing to do here to
guarantee maximum portability between all SoCs where this controller can
be used.

Only MIPS-based STB chips support a boot strap to select the CPU's
endian and when that happens the SCB and GISB buses remain native endian
as indicated earlier. We did some work to ensure that an ARM BE kernel
would work:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=69d2ea9c798983c4a7157278ec84ff969d1cd8e8

but that was just for making sure there were no obvious problem and is
not a configuration we support or want to support and only the kernel
and userland were made BE for testing, it was booted from the LE boot
loader.

> 
>> Does your board use a PHY connected via RGMII? Because this is something we 
>> are relying on at the moment. But without any ways of testing this I'd 
>> rather not support other transports at this time.
>>
>> I think your points below are all valid, so thanks for bringing this up. 
>> Will test this later on and post a v2 in due time then.
>>
> 
> We had a similar scenario a few months ago, where a newly supported ARM
> based Broadcom SoC could simply reuse various drivers initially added
> for MIPS based Broadcom SoC's. So if someone wants to use your driver
> with a MIPS based Broadcom SoC in the future, likely some tweaking of
> the driver is required. But at least the basic cross-arch compatibility
> should be given.

Agreed. I am not sure if such a situation will ever arise in the future
because those MIPS-based chips are reasonably old now, and few if any
people have shown interest in using something different than CFE
(Broadcom's own boot loader) or their own third stage, but hey, someone
might see the light at some point :).
-- 
Florian

Re: [RFC PATCH 2/2] net: Add Support for GENET Ethernet controller

[Florian Fainelli]

On 12/13/2019 8:50 AM, Andre Przywara wrote:
>> +/* total number of Buffer Descriptors, same for Rx/Tx */
>> +#define TOTAL_DESC   256
>> +
>> +#define DEFAULT_Q0x10
> 
> I think that deserves a comment.
> Maybe Florian can comment on what this odd "queue 16" is really about? It 
> seems weird to support *17* queues and make the last one the default.

In the mode we operate (descriptor mode) this is the background/default
queue, I have no other explanation to provide than that, sorry if this
is a bit "compact". You could bring up the other priority queues, but
that seems pointless in u-boot.

> 
>> +
>> +/* Body(1500) + EH_SIZE(14) + VLANTAG(4) + BRCMTAG(6) + FCS(4) = 1528.
>> + * 1536 is multiple of 256 bytes
>> + */
>> +#define ENET_BRCM_TAG_LEN6
>> +#define ENET_PAD 8
>> +#define ENET_MAX_MTU_SIZE(ETH_DATA_LEN + ETH_HLEN + VLAN_HLEN + 
>> \
>> +  ENET_BRCM_TAG_LEN + ETH_FCS_LEN + 
>> ENET_PAD)
>> +
>> +/* Tx/Rx Dma Descriptor common bits*/
>> +#define DMA_EN   BIT(0)
>> +#define DMA_RING_BUF_EN_SHIFT0x01
>> +#define DMA_RING_BUF_EN_MASK 0x
>> +#define DMA_BUFLENGTH_MASK   0x0fff
>> +#define DMA_BUFLENGTH_SHIFT  16
>> +#define DMA_RING_SIZE_SHIFT  16
>> +#define DMA_OWN  0x8000
>> +#define DMA_EOP  0x4000
>> +#define DMA_SOP  0x2000
>> +#define DMA_WRAP 0x1000
>> +#define DMA_MAX_BURST_LENGTH 0x8
> 
> I think it deserves mentioning that this is the RPi4 specific value, all the 
> other GENET hardware can use 0x10 here. It looks to me like 0x8 is probably 
> safe for all to use, it would just be less efficient. But I guess we don't 
> care in U-Boot.

Correct.

> 
>> +/* Tx specific Dma descriptor bits */
>> +#define DMA_TX_UNDERRUN  0x0200
>> +#define DMA_TX_APPEND_CRC0x0040
>> +#define DMA_TX_OW_CRC0x0020
>> +#define DMA_TX_DO_CSUM   0x0010
>> +#define DMA_TX_QTAG_SHIFT7
>> +#define GENET_TDMA_REG_OFF   (0x4000 + \
>> +  TOTAL_DESC * DMA_DESC_SIZE)
>> +#define GENET_RDMA_REG_OFF   (0x2000 + \
>> +  TOTAL_DESC * DMA_DESC_SIZE)
>> +
>> +/* DMA rings size */
>> +#define DMA_RING_SIZE(0x40)
>> +#define DMA_RINGS_SIZE   (DMA_RING_SIZE * (DEFAULT_Q + 
>> 1))
>> +
>> +/* DMA Descriptor */
>> +#define DMA_DESC_LENGTH_STATUS   0x00
>> +#define DMA_DESC_ADDRESS_LO  0x04
>> +#define DMA_DESC_ADDRESS_HI  0x08
>> +#define DMA_DESC_SIZE0xc
>> +
>> +#define DMA_FC_THRESH_HI (TOTAL_DESC >> 4)
>> +#define DMA_FC_THRESH_LO 5
>> +#define DMA_XOFF_THRESHOLD_SHIFT 16
>> +
>> +#define TDMA_RING_REG_BASE(QUEUE_NUMBER) (GENET_TDMA_REG_OFF \
>> +   + (DMA_RING_SIZE * (QUEUE_NUMBER)))
> 
> So it seems like we are *always* using the default queue number. For improved 
> readability we could drop this parameter and hardcode this here, so that 
> users just need to use TDMA_RING_REG_BASE.

Agreed. If you were to use the other TX or RX queues, you would have to
incur additional configuration that is not worth the trouble here.

[snip]

>> +static void reset_umac(struct bcmgenet_eth_priv *priv)
> 
> What is the difference to the function above? The name is confusingly similar.

And so is the version in the kernel arguably. Note that Doug recently
made a fair amount of changes to how GENET is reset, you have some of
those changes with the loopback enabling, but please check you have the
latest programming sequence since this is a source of hard to debug
problems with the UniMAC receiver stuck/replicating packets incorrectly
if not properly reset.

[snip]

>> +static int _bcmgenet_gmac_eth_send(struct bcmgenet_eth_priv *priv, void 
>> *packet,
>> +   int len)
>> +{
>> +u32 size, len_stat, prod_index, cons;
>> +u32 tries = 100;
>> +
>> +void *desc_base = (priv->tx_desc_base + (priv->tx_index * 
>> DMA_DESC_SIZE));
>> +
>> +len_stat = (len << DMA_BUFLENGTH_SHIFT) | (0x3F << DMA_TX_QTAG_SHIFT);
>> +len_stat |= (DMA_TX_APPEND_CRC | DMA_SOP | DMA_EOP);
>> +
>> +prod_index = readl(priv->mac_reg + TDMA_RING_REG_BASE(DEFAULT_Q) + 
>> TDMA_PROD_INDEX);
>> +
>> +size = roundup(len, ARCH_DMA_MINALIGN);
> 
> I think more important than aligning the size is aligning the base.
> Not that it really matters architecturally ...

Agreed, and if your flush_dcache_range() is not able to figure out
whether it needs to span adjacent cachelines, it is mildy broken at that
point.

> 
>> +flush_dcache_range((ulong)packet, (ulong)packet + size);
>> +
>> +/* Set-up packet for 

Re: [U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Florian Fainelli]

On 12/12/19 10:38 AM, Andre Przywara wrote:
> On Thu, 12 Dec 2019 10:13:27 -0800
> Florian Fainelli  wrote:
> 
> Hi Florian,
> 
> thanks for chiming in!
> 
>> On 12/12/19 3:59 AM, Matthias Brugger wrote:
>>>
>>>
>>> On 12/12/2019 11:41, Andre Przywara wrote:  
>>>> On Wed, 11 Dec 2019 10:23:16 +0100
>>>> Matthias Brugger  wrote:
>>>>
>>>> Hi,
>>>>  
>>>>> On 09/12/2019 14:33, Sascha Dewald wrote:  
>>>>>> Hello Amit,
>>>>>>
>>>>>> no problem.
>>>>>>
>>>>>> Is there some git feature branch, to have a look ?
>>>>>
>>>>> Yes I'd love to have a look as well :)  
>>>>
>>>> We will send an RFC later this week, Amit is doing some cleanup now. At 
>>>> the moment transfers work up to 256 packets (375KB when using TFTP), at 
>>>> this point it breaks, because recycling DMA descriptors is not working for 
>>>> some reason. I haven't found any documentation for the MAC, so I am 
>>>> reverse engineering the Linux driver and doing printf and tcpdump 
>>>> debugging right now. Looking forward to people joining us in this effort 
>>>> ;-)
>>>>  
>>>
>>> Thanks for the update. I CC'ed Florian who I think is the SW expert on that
>>> chip. Maybe he can help you.  
>>
>> Transfers work for up to 256 packets in which direction? Are you
>> properly consuming descriptors that were produced by the RDMA (on
>> receive), 
> 
> Yes, not sure we do it properly, but we do.
> 
> The problem I see is that the TDMA_CONS_INDEX does not increase after it 
> reaches 256, although RDMA_PROD_INDEX does. Is there any cleanup in the 
> actual descriptors needed?

There is no explicit mention or description that the CPU should be
polling the TDMA_CONS_INDEX and that this is being used by the HW as an
indication to release the buffers, they should continue to increase
linearly and wrap around. There must be something else that prevents the
TDMA from making further progress.

How did you configure the TDMA start address/read/write pointers/size
and do you use the same mode as the Linux driver which is on-chip
descriptor ring (1 << 16 in TDMA_RING_CFG).

Can you start with as many as 2 buffers, copy whatever you get from the
u-boot network stack (if you can't do zero copy TX) and see if wrapping
around/recycling works properly?

Another possibility would be if you don't properly set the EOF/SOF on
every packet you send, and it is waiting for that "last packet with the
EOF flag set" could hold up TX for a while.

> Did I get this right that those indices are just linear "progress counters", 
> and not actual descriptor indices? I see the Linux code masks them with 
> 0x, not with the number of descriptors.

They are linear progress counters of how many buffers the CPU produced,
and how many buffers the GENET hardware consumed (and vice versa for RDMA).

> 
> Will try to dig a bit deeper on this.
> 
>> conversely, polling the TDMA consumer index on transmit?
> 
> Yes, I switched over to that (from polling for the DMA_OWN bit).

Yes that is not going to work, there may have been older versions of
GENET that did write back the descriptor flags back into memory, but the
version in the Pi4 certainly does not do that to the best of my knowledge.

The hardware would not also tell you whether there were errors during
transmit on per-packet basis but you may be able to extract the transmit
vector bits out of the GENET_TBUF register space. That would give you
access to the raw transmit status vector between the TDMA and UniMAC
(the part that does the framing) but it would be just for the last
packet basically.

Hope this helps...
-- 
Florian

Re: [U-Boot-Board-Maintainers] Raspberry pi 4 - u-boot - genet / scb

[Florian Fainelli]

On 12/12/19 3:59 AM, Matthias Brugger wrote:
> 
> 
> On 12/12/2019 11:41, Andre Przywara wrote:
>> On Wed, 11 Dec 2019 10:23:16 +0100
>> Matthias Brugger  wrote:
>>
>> Hi,
>>
>>> On 09/12/2019 14:33, Sascha Dewald wrote:
 Hello Amit,

 no problem.

 Is there some git feature branch, to have a look ?  
>>>
>>> Yes I'd love to have a look as well :)
>>
>> We will send an RFC later this week, Amit is doing some cleanup now. At the 
>> moment transfers work up to 256 packets (375KB when using TFTP), at this 
>> point it breaks, because recycling DMA descriptors is not working for some 
>> reason. I haven't found any documentation for the MAC, so I am reverse 
>> engineering the Linux driver and doing printf and tcpdump debugging right 
>> now. Looking forward to people joining us in this effort ;-)
>>
> 
> Thanks for the update. I CC'ed Florian who I think is the SW expert on that
> chip. Maybe he can help you.

Transfers work for up to 256 packets in which direction? Are you
properly consuming descriptors that were produced by the RDMA (on
receive), conversely, polling the TDMA consumer index on transmit? Can
you share your code somewhere so I could see if there are obvious problems?
-- 
Florian

Re: [U-Boot] [PATCH] arm: bcm7445: Move config defines to bcm7445.h

[Florian Fainelli]

On 07/26/2018 08:02 PM, Thomas Fitzsimmons wrote:
> Move some configuration #defines that do not apply to other bcmstb
> boards from bcmstb.h to bcm7445.h.
> 
> Signed-off-by: Thomas Fitzsimmons 

Acked-by: Florian Fainelli 

Thanks for addressing this.
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] board: arm: Add support for Broadcom BCM7260

[Florian Fainelli]

On 08/16/2018 06:44 PM, Thomas Fitzsimmons wrote:
> Add support for loading U-Boot on the Broadcom 7260 SoC.  This port
> assumes Broadcom's BOLT bootloader is acting as the second stage
> bootloader, and U-Boot is acting as the third stage bootloader, loaded
> as an ELF program by BOLT.
> 
> Signed-off-by: Thomas Fitzsimmons 

Reviewed-by: Florian Fainelli 

Looks good to me given the structured you added earlier for 7445
support, just one nit below:

[snip]

> +
> +#ifndef __CONFIG_H
> +#define __CONFIG_H
> +
> +#define CONFIG_SYS_NS16550_COM3  0xf040c000

This is the physical address of UARTA, there are typically 3 UARTs on
those SoCs, is there a reason to name this COM3 and not COM1? If this is
an established u-boot convention, pardon my ignore here.
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715

[Florian Fainelli]

On 06/13/2018 06:37 AM, Nishanth Menon wrote:
> On 00:30-20180613, Florian Fainelli wrote:
>> On June 12, 2018 1:24:09 PM PDT, Nishanth Menon  wrote:
>>> As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
>>> needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
>>> be done unconditionally for Cortex-A15 processors. Provide a config
>>> option for platforms to enable this option based on impact analysis
>>> for products.
>>>
>>> NOTE: This patch in itself is NOT the final solution, this requires:
>>> a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
>>>   provide direct access to ACR register.
>>> b) Operating Systems such as Linux to provide adequate workaround in
>>> the
>>>   right locations.
>>
>> This is the case as of 4.18 so you could probably reference 
>> CONFIG_CPU_SPECTRE and CONFIG_HARDEN_BRANCH_PREDICTOR in a v2.
> 
> Did'nt want to tie the description too deep to Linux specifics.. Linux
> documents itself and users are encouraged to read that documentation,
> correct?

That's fair enough I guess, we also don't know how the other OSes do
provide that mitigation and whether they have run-time/build-time
configuration options gating those.

> 
>>
>>> c) This workaround applies to only the boot processor. It is important
>>>   to apply workaround as necessary (context-save-restore) around low
>>>   power context loss OR additional processors as necessary in either
>>>   firmware support OR elsewhere in OS.
>>
>> About that, I don't know enough of uboot but are there existing PSCI or
>> other seemingly standard secondary core support in uboot that would make
>> us go through the same initialization as the boot CPU? If not, is
>> everything going to be largely implementation specific and
>> scattered between uboot and the hypervisors or kernel?
> 
> in ARMV7 SoCs, unfortunately, we lived in a world of no-exact-standard.
> even within TI, Few of the SoCs use PSCI, others did implement custom
> SMC calls (since they existed in an architecture prior to PSCI).
> 
>>
>> FWIW, this is what prompted me to submit this:
>>
>> https://patchwork.kernel.org/patch/10453643/
> 
> That wont work in a generic manner for precisely the same reason I had to do
> it with weak function in u-boot (some SoCs will only permit 'mcr
> p15, 0, r0, c1, c0, 1' in secure world and you need to make a custom smc
> call to make it happen). Unfortunately, IMHO, at least at this
> point, there'd be custom implementations per SoC and layers depending on
> where to implement it.

It won't work in a generic manner but it will work for some platforms
where updating the firmware is impractical, and since the bits are write
ignore if your PL does not allow it, this still seems like a net win for
platforms where this is effective, and it does take care of Linux doing
the SMP bring-up of secondary cores as well. That's what we have in our
downstream tree at least, and I was hoping this could land upstream too.
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 2/4] ARM: Introduce ability to enable invalidate of BTB with ICIALLU on Cortex-A15 for CVE-2017-5715

[Florian Fainelli]

On June 12, 2018 1:24:09 PM PDT, Nishanth Menon  wrote:
>As recommended by Arm in [1], ACTLR[0] (Enable invalidates of BTB)
>needs to be set[2] for BTB to be invalidated on ICIALLU. This needs to
>be done unconditionally for Cortex-A15 processors. Provide a config
>option for platforms to enable this option based on impact analysis
>for products.
>
>NOTE: This patch in itself is NOT the final solution, this requires:
>a) Implementation of v7_arch_cp15_set_acr on SoCs which may not
>   provide direct access to ACR register.
>b) Operating Systems such as Linux to provide adequate workaround in
>the
>   right locations.

This is the case as of 4.18 so you could probably reference CONFIG_CPU_SPECTRE 
and CONFIG_HARDEN_BRANCH_PREDICTOR in a v2.

>c) This workaround applies to only the boot processor. It is important
>   to apply workaround as necessary (context-save-restore) around low
>   power context loss OR additional processors as necessary in either
>   firmware support OR elsewhere in OS.

About that, I don't know enough of uboot but are there existing PSCI or other 
seemingly standard secondary core support in uboot that would make us go 
through the same initialization as the boot CPU? If not, is everything going to 
be largely implementation specific and scattered between uboot and the 
hypervisors or kernel?

FWIW, this is what prompted me to submit this:

https://patchwork.kernel.org/patch/10453643/


>
>[1] https://developer.arm.com/support/security-update
>[2]
>http://infocenter.arm.com/help/topic/com.arm.doc.ddi0438c/BABGHIBG.html
>
>Cc: Marc Zyngier 
>Cc: Russell King 
>Cc: Tony Lindgren 
>Cc: Robin Murphy 
>Cc: Florian Fainelli 
>Cc: Catalin Marinas 
>Cc: Will Deacon 
>Cc: Christoffer Dall 
>Cc: Andre Przywara 
>Cc: Ard Biesheuvel 
>Cc: Tom Rini 
>Cc: Michael Nazzareno Trimarchi 
>
>Signed-off-by: Nishanth Menon 
>---
> arch/arm/Kconfig   | 4 
> arch/arm/cpu/armv7/start.S | 8 
> 2 files changed, 12 insertions(+)
>
>diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>index 9e32d5b43cb0..98f58fd27696 100644
>--- a/arch/arm/Kconfig
>+++ b/arch/arm/Kconfig
>@@ -109,6 +109,7 @@ config SYS_ARM_MPU
> # CONFIG_ARM_ERRATA_798870
> # CONFIG_ARM_ERRATA_801819
> # CONFIG_ARM_CORTEX_A8_CVE_2017_5715
>+# CONFIG_ARM_CORTEX_A15_CVE_2017_5715
> 
> config ARM_ERRATA_430973
>   bool
>@@ -182,6 +183,9 @@ config ARM_ERRATA_855873
> config ARM_CORTEX_A8_CVE_2017_5715
>   bool
> 
>+config ARM_CORTEX_A15_CVE_2017_5715
>+  bool
>+
> config CPU_ARM720T
>   bool
>   select SYS_CACHE_SHIFT_5
>diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
>index 3beaf5a93d81..81edec01bf32 100644
>--- a/arch/arm/cpu/armv7/start.S
>+++ b/arch/arm/cpu/armv7/start.S
>@@ -241,6 +241,14 @@ skip_errata_798870:
> skip_errata_801819:
> #endif
> 
>+#ifdef CONFIG_ARM_CORTEX_A15_CVE_2017_5715
>+  mrc p15, 0, r0, c1, c0, 1   @ read auxilary control register
>+  orr r0, r0, #1 << 0 @ Enable invalidates of BTB
>+  push{r1-r5} @ Save the cpu info registers
>+  bl  v7_arch_cp15_set_acr
>+  pop {r1-r5} @ Restore the cpu info - fall through
>+#endif
>+
> #ifdef CONFIG_ARM_ERRATA_454179
>   mrc p15, 0, r0, c1, c0, 1   @ Read ACR
> 


-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 1/1] board: arm: Add support for Broadcom BCM7445

[Florian Fainelli]

On 06/06/2018 11:35 AM, Thomas Fitzsimmons wrote:
> Add support for loading U-Boot on the Broadcom 7445 SoC.  This port
> assumes Broadcom's BOLT bootloader is acting as the second stage
> bootloader, and U-Boot is acting as the third stage bootloader, loaded
> as an ELF program by BOLT.
> 
> Signed-off-by: Thomas Fitzsimmons 
> Cc: Stefan Roese 
> Cc: Tom Rini 
> Cc: Florian Fainelli 
> ---

Looks good, still some minor comments about the choice of representation
for physical addresses of peripherals, see below.

> +config BCMSTB_TIMER_LOW
> + hex "Address of BCMSTB timer low register"
> + default 0xf0412008

This looks very simplistic here since the CPU system control timer is a
64-bit timer.

I am really not a big fan of all of those configurable addresses which
are a) fixed given a specific SoC family (7445, 7439 etc.) and b) are
error prone because we let an user change those without necessarily
knowing what is the implication. I really think sticking those constants
into a header file would be much more appropriate.

> +void enable_caches(void)
> +{
> + /*
> +  * Nothing required here, since the prior stage bootloader has
> +  * enabled I-cache and D-cache already.  Implementing this
> +  * function silences the warning in the default function.
> +  */

This heavily depends on how you load your binary from BOLT, so you must
be careful about this statement here.
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] board: arm: Add support for Broadcom BCM7445D0

[Florian Fainelli]

On 06/06/2018 01:39 PM, Thomas Fitzsimmons wrote:
> Florian Fainelli  writes:
> 
>> On 05/10/2018 06:04 AM, Thomas Fitzsimmons wrote:
>>> Florian Fainelli  writes:
>>>
>>>> On 05/06/2018 04:09 AM, Thomas Fitzsimmons wrote:
> 
> [...]
> 
>>>>> +
>>>>> +config BCMSTB_ACCOMMODATE_STBLINUX
>>>>> + bool ""
>>>>> + default y
>>>>> + help
>>>>> +   This prevents U-Boot from adding memory reservations for the
>>>>> +  lengths of initramfs and DTB.  Without skipping these,
>>>>> +  stblinux's "contiguous memory allocator" (CMA) Linux driver
>>>>> +  (cma_driver) will allocate memory ranges smaller than what
>>>>> +  are actually available, because it only checks reservation
>>>>> +  sizes.  It doesn't check if the reserved range overlaps the
>>>>> +  range it allocates.  stblinux also tries to move the DTB to
>>>>> +  a lower memory location early in the Linux boot.  If the FIT
>>>>> +  image specifies a load address for the initramfs then
>>>>> +  sometimes the DTB is moved into the range where the
>>>>> +  initramfs image is loaded.  Defining this will mean that
>>>>> +  FIT-provided initramfs load addresses are ignored.
>>>>
>>>> What STB Linux kernel did you observe this with? I am afraid this is
>>>> still true about the ranges vs. allocation even in newer kernels, but
>>>> that is kind of intented to keep the logic KISS (because it's already
>>>> too complicated IMHO).
>>>
>>> I investigated the allocation discrepancy and wrote the workaround while
>>> we were still using stblinux-3.14.  Since then we've updated to
>>> stblinux-4.1 and I've left the workaround enabled, but I haven't
>>> investigated its interactions with the newer bmem mechanism.  I should
>>> probably revisit this though, with stblinux-4.1 and stblinux-4.9, just
>>> to make sure this macro is still useful.
>>
>> Sounds good, let me know if there is something that does not seem quite
>> right, we could fix it.
> 
> [...]
> 
> In the v3 patch, I keep the FIT's RFS and DTB in-place.  This approach
> eliminates the bmem/cma allocation discrepancies.  I compared bmem/cma
> dmesg output for stblinux 3.14, 4.1 and 4.9, zImage and ITB builds, on
> my eval board, and they're all the same for the same kernel version.
> The only thing I noticed is that in 3.14 and 4.1 (zImage and ITB), the
> first bmem region is:
> 
>768 MiB at 0x1000
> 
> whereas in 4.9 (zImage and ITB), it is:
> 
>760 MiB at 0x1080
> 
> This is booting with no kernel command line arguments, so I guess some
> default may have changed between stblinux 4.1 and 4.9?

This upstream commit is responsible for what you see:
6ff0966052c46efb53980b8a1add2e7b49c9f560 ("ARM: 8432/1: move VMALLOC_END
from 0xff00 to 0xff80") we've backported that change to our 3.14
and 4.1 kernels since then.
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] board: arm: Add support for Broadcom BCM7445D0

[Florian Fainelli]

On 05/10/2018 06:04 AM, Thomas Fitzsimmons wrote:
> Florian Fainelli <f.faine...@gmail.com> writes:
> 
>> On 05/06/2018 04:09 AM, Thomas Fitzsimmons wrote:
>>> Add support for loading U-Boot on the Broadcom 7445D0 SoC.  This port
>>> assumes Broadcom's BOLT bootloader is acting as the second stage
>>> bootloader, and U-Boot is acting as the third stage bootloader, loaded
>>> as an ELF program by BOLT.
>>>
>>> Signed-off-by: Thomas Fitzsimmons <fitz...@fitzsim.org>
>>> Cc: Stefan Roese <s...@denx.de>
>>
>>>
>>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
>>> index 9bd70f4..b2df30a 100644
>>> --- a/arch/arm/Kconfig
>>> +++ b/arch/arm/Kconfig
>>> @@ -498,6 +498,17 @@ config TARGET_VEXPRESS_CA15_TC2
>>> select CPU_V7_HAS_VIRT
>>> select PL011_SERIAL
>>>  
>>> +config TARGET_BCM7445D0
>>> +   bool "Broadcom 7445D0 TSBL"
>>> +   select CPU_V7
>>> +   select SUPPORT_SPL
>>> +   help
>>> + Support for the Broadcom 7445D0 SoC.  This port assumes Bolt
>>
>> BOLT
>>
>>> + is acting as the second stage bootloader, and U-Boot is
>>> + acting as the third stage bootloader (TSBL), loaded by Bolt.
>>
>> again BOLT
> 
> Oops, will fix in a v2 patch.
> 
>>> + This port may work on other BCM7xxx boards with
>>> + configuration changes.
>>
>> There are other revisions than D0, so I would just name this
>> TARGET_BCM7445. You would likely want to create a TARGET_BRCMSTB general
>> menu which would encompass all ARMv7-A based SoCs from the Broadcom
>> STB/CM division, and then have per-chip Kconfig options (similar to what
>> the older <= 3.14 STB Linux kernels did).
> 
> OK, will try this in v2.
> 
>>> +
>>> +config BCMSTB_ACCOMMODATE_STBLINUX
>>> +   bool ""
>>> +   default y
>>> +   help
>>> + This prevents U-Boot from adding memory reservations for the
>>> +  lengths of initramfs and DTB.  Without skipping these,
>>> +  stblinux's "contiguous memory allocator" (CMA) Linux driver
>>> +  (cma_driver) will allocate memory ranges smaller than what
>>> +  are actually available, because it only checks reservation
>>> +  sizes.  It doesn't check if the reserved range overlaps the
>>> +  range it allocates.  stblinux also tries to move the DTB to
>>> +  a lower memory location early in the Linux boot.  If the FIT
>>> +  image specifies a load address for the initramfs then
>>> +  sometimes the DTB is moved into the range where the
>>> +  initramfs image is loaded.  Defining this will mean that
>>> +  FIT-provided initramfs load addresses are ignored.
>>
>> What STB Linux kernel did you observe this with? I am afraid this is
>> still true about the ranges vs. allocation even in newer kernels, but
>> that is kind of intented to keep the logic KISS (because it's already
>> too complicated IMHO).
> 
> I investigated the allocation discrepancy and wrote the workaround while
> we were still using stblinux-3.14.  Since then we've updated to
> stblinux-4.1 and I've left the workaround enabled, but I haven't
> investigated its interactions with the newer bmem mechanism.  I should
> probably revisit this though, with stblinux-4.1 and stblinux-4.9, just
> to make sure this macro is still useful.

Sounds good, let me know if there is something that does not seem quite
right, we could fix it.

> 
>>> +
>>> +config BCMSTB_SDHCI
>>> +   bool ""
>>> +   default y
>>> +
>>> +config BCMSTB_SDHCI_BASE
>>> +   hex ""
>>> +   default 0xf03e0200
>>> +
>>> +config BCMSTB_SPI_BASE
>>> +   hex ""
>>> +   default 0xf03e3400
>>
>> Why don't you get those from the Device Tree blob that BOLT passes?
> 
> During development I did implement that for SDHCI_BASE, so it is
> possible.  But I ended up #ifdef'ing it out and hard-coding the address
> in production, to keep the runtime logic simpler.  Doing DTB traversal
> in code adds complexity but it may achieve portability to different
> BCM7xxx SoCs without further code changes, which would be nice.

Given what I see with Broadcom STB customers, I don't think there is a
strong push for anything other than BOLT, or another proprietary TSBL,
so with that, I am not sure about whether there would be an use case for
e.g; a s

Re: [U-Boot] [PATCH 1/1] board: arm: Add support for Broadcom BCM7445D0

[Florian Fainelli]

On 05/06/2018 04:09 AM, Thomas Fitzsimmons wrote:
> Add support for loading U-Boot on the Broadcom 7445D0 SoC.  This port
> assumes Broadcom's BOLT bootloader is acting as the second stage
> bootloader, and U-Boot is acting as the third stage bootloader, loaded
> as an ELF program by BOLT.
> 
> Signed-off-by: Thomas Fitzsimmons 
> Cc: Stefan Roese 

> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 9bd70f4..b2df30a 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -498,6 +498,17 @@ config TARGET_VEXPRESS_CA15_TC2
>   select CPU_V7_HAS_VIRT
>   select PL011_SERIAL
>  
> +config TARGET_BCM7445D0
> + bool "Broadcom 7445D0 TSBL"
> + select CPU_V7
> + select SUPPORT_SPL
> + help
> +   Support for the Broadcom 7445D0 SoC.  This port assumes Bolt

BOLT

> +   is acting as the second stage bootloader, and U-Boot is
> +   acting as the third stage bootloader (TSBL), loaded by Bolt.

again BOLT

> +   This port may work on other BCM7xxx boards with
> +   configuration changes.

There are other revisions than D0, so I would just name this
TARGET_BCM7445. You would likely want to create a TARGET_BRCMSTB general
menu which would encompass all ARMv7-A based SoCs from the Broadcom
STB/CM division, and then have per-chip Kconfig options (similar to what
the older <= 3.14 STB Linux kernels did).

> +
> +config BCMSTB_ACCOMMODATE_STBLINUX
> + bool ""
> + default y
> + help
> +   This prevents U-Boot from adding memory reservations for the
> +  lengths of initramfs and DTB.  Without skipping these,
> +  stblinux's "contiguous memory allocator" (CMA) Linux driver
> +  (cma_driver) will allocate memory ranges smaller than what
> +  are actually available, because it only checks reservation
> +  sizes.  It doesn't check if the reserved range overlaps the
> +  range it allocates.  stblinux also tries to move the DTB to
> +  a lower memory location early in the Linux boot.  If the FIT
> +  image specifies a load address for the initramfs then
> +  sometimes the DTB is moved into the range where the
> +  initramfs image is loaded.  Defining this will mean that
> +  FIT-provided initramfs load addresses are ignored.

What STB Linux kernel did you observe this with? I am afraid this is
still true about the ranges vs. allocation even in newer kernels, but
that is kind of intented to keep the logic KISS (because it's already
too complicated IMHO).

> +
> +config BCMSTB_SDHCI
> + bool ""
> + default y
> +
> +config BCMSTB_SDHCI_BASE
> + hex ""
> + default 0xf03e0200
> +
> +config BCMSTB_SPI_BASE
> + hex ""
> + default 0xf03e3400

Why don't you get those from the Device Tree blob that BOLT passes?

> +
> +config CMD_FDT_MAX_DUMP
> + int ""
> + default 256
> +
> +config GENERIC_MMC
> + bool ""
> + default y
> +
> +config MMC_SDMA
> + bool ""
> + default y
> +
> +config SDHCI
> + bool ""
> + default y
> +
> +config SYS_BCMSTB_SPI_WAIT
> + int ""
> + default 10
> +
> +config SYS_FDT_SAVE_ADDRESS
> + hex ""
> + default 0x1f0
> +
> +config SYS_NO_FLASH
> + bool ""
> + default y
> +
> +config TIMER_FREQUENCY_REGISTER_ADDRESS
> + hex ""
> + default 0xf0412020
> +
> +config TIMER_LOW_REGISTER_ADDRESS
> + hex ""
> + default 0xf0412008

All of these physical address ares not going to change given a
7445-based design, so why not hard code them in a header file unless you
are keen on taking them from the passed Device Tree blob from BOLT?

> +int dram_init_banksize(void)
> +{
> + bd_t *bd = gd->bd;
> +
> + bd->bi_dram[0].start = 0x;
> + bd->bi_dram[0].size  = 0x4000;
> + bd->bi_dram[1].start = 0x4000;
> + bd->bi_dram[1].size  = 0x4000;
> + bd->bi_dram[2].start = 0x8000;
> + bd->bi_dram[2].size  = 0x4000;

This may be true for your system if you have 3x1GB populated, but 7445
supports additional extension regions, so this must be configurable if
you want to make this flexible enough for other people to use it.


> +/* Copied from stblinux, include/linux/brcmstb/brcmstb.h. */
> +#define DEV_RD(x) (readl((x)))
> +#define DEV_WR(x, y) do { writel((y), (x)); } while (0)
> +#define DEV_UNSET(x, y) do { DEV_WR((x), DEV_RD(x) & ~(y)); } while (0)
> +#define DEV_SET(x, y) do { DEV_WR((x), DEV_RD(x) | (y)); } while (0)
> +
> +#define DEV_WR_RB(x, y) do { DEV_WR((x), (y)); DEV_RD(x); } while (0)
> +#define DEV_SET_RB(x, y) do { DEV_SET((x), (y)); DEV_RD(x); } while (0)
> +#define DEV_UNSET_RB(x, y) do { DEV_UNSET((x), (y)); DEV_RD(x); } while (0)

I would just flat out drop those macros and instead use standard
accessors. Those happen to work just fine given Broadcom STB's GISB bus,
but if you want portable drivers in u-boot, and you likely would want
those, you should use more standard I/O accessors.

Re: [U-Boot] [PATCH v4 0/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

On 12/09/2017 03:02 PM, Joe Hershberger wrote:
> On Sat, Dec 9, 2017 at 4:59 PM, Florian Fainelli <f.faine...@gmail.com> wrote:
>> Hi all,
>>
>> This patch series adds support for the Broadcom BCM53xx switches, in 
>> particular
>> BCM53125 which is found no the Lamobo R1 board.
>>
>> The driver is largely based on the DSA/b53 driver Linux driver and only
>> incorporates what is necessary to succesfully bring-up all ports (including 
>> the
>> management port) for boot over the network:
>>
>> => dhcp
>> dw_adjust_link: Speed: 1000, full duplex
>> BOOTP broadcast 1
>> DHCP client bound to address 192.168.0.11 (3 ms)
>> Using ethernet@01c5 device
>> TFTP from server 192.168.0.1; our IP address is 192.168.0.11
>> Filename 'sun7i-a20-lamobo-r1-kernel.bin'.
>> Load address: 0x4200
>> Loading: #
>>  #
>>  
>>  11.6 MiB/s
>> done
>> Bytes transferred = 2371552 (242fe0 hex)
>> =>
>>
>> Joe there is one warning left which does not look legit to me since we now 
>> have
>> a help paragraph describing the config symbol:
>>
>> WARNING: please write a paragraph that describes the config symbol fully
>> #34: FILE: drivers/net/phy/Kconfig:15:
>> +config B53_SWITCH
>>
>> and one CHECK left which I intentionally did not fix because it makes the
>> definitions of the bits less clear:
>> CHECK: Prefer using the BIT macro
>> #134: FILE: drivers/net/phy/b53.c:63:
>> +#define   PORT_OVERRIDE_SPEED_100M (1 << PORT_OVERRIDE_SPEED_S)
> 
> Works for me.o

Should I expect you to queue up these patches in a git tree/branch, or
is someone else picking up networking/PHY patches?
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH] efi_loader: helloworld.c: Explicitly use .rodata for loaded_image_guid

[Florian Fainelli]

On 12/11/2017 12:45 AM, Alexander Graf wrote:
> Commit bbf75dd9345d0b ("efi_loader: output load options in helloworld")
> introduced a const variable in efi_main() called loaded_image_guid which
> got populated from a constant struct.
> 
> While you would usually expect a compiler to realize that this variable
> should really just be a global pointer to .rodata, gcc disagrees and instead
> puts it on the stack. Unfortunately in some implementations of gcc it does
> so my calling memcpy() which we do not implement in our hello world
> environment.
> 
> So let's explicitly move it to a global variable which in turn puts it in
> .rodata reliably and gets rid of the memcpy().
> 
> Fixes: bbf75dd9345d0b ("efi_loader: output load options in helloworld")
> Reported-by: Florian Fainelli <f.faine...@gmail.com>
> Signed-off-by: Alexander Graf <ag...@suse.de>

Tested-by: Florian Fainelli <f.faine...@gmail.com>

Thanks Alexander!

> ---
>  lib/efi_loader/helloworld.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
> index e59c24c788..b8c147d7f2 100644
> --- a/lib/efi_loader/helloworld.c
> +++ b/lib/efi_loader/helloworld.c
> @@ -13,6 +13,8 @@
>  #include 
>  #include 
>  
> +static const efi_guid_t loaded_image_guid = LOADED_IMAGE_GUID;
> +
>  /*
>   * Entry point of the EFI application.
>   *
> @@ -26,7 +28,6 @@ efi_status_t EFIAPI efi_main(efi_handle_t handle,
>   struct efi_simple_text_output_protocol *con_out = systable->con_out;
>   struct efi_boot_services *boottime = systable->boottime;
>   struct efi_loaded_image *loaded_image;
> - const efi_guid_t loaded_image_guid = LOADED_IMAGE_GUID;
>   efi_status_t ret;
>  
>   con_out->output_string(con_out, L"Hello, world!\n");
> 

-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 15/18] efi_loader: output load options in helloworld

[Florian Fainelli]

On 12/09/2017 10:40 PM, Heinrich Schuchardt wrote:
> On 12/10/2017 12:09 AM, Florian Fainelli wrote:
>>
>>
>> On 11/26/2017 05:05 AM, Heinrich Schuchardt wrote:
>>> We need to test if we pass a valid image handle when loading
>>> and EFI application. This cannot be done in efi_selftest as
>>> it is not loaded as an image.
>>>
>>> So let's enhance helloworld a bit.
>>>
>>> Reviewed-by: Simon Glass <s...@chromium.org>
>>> Signed-off-by: Heinrich Schuchardt <xypron.g...@gmx.de>
>>
>> This particular patch/commit bbf75dd9345d0b1a7ec7a50016547eb7c759b7af
>> ("efi_loader: output load options in helloworld") was bisected and
>> causes the Lamobo_R1_defconfig build using the toolchain at [1] to fail
>> with:
>>
>> /home/fainelli/work/toolchains/stbgcc-6.3-1.1/bin/arm-linux-ld.bfd:
>> error: required section '.got' not found in the linker script
>> /home/fainelli/work/toolchains/stbgcc-6.3-1.1/bin/arm-linux-ld.bfd:
>> final link failed: Invalid operation
>> scripts/Makefile.lib:409: recipe for target
>> 'lib/efi_loader/helloworld_efi.so' failed
>> make[2]: *** [lib/efi_loader/helloworld_efi.so] Error 1
>> rm lib/efi_loader/helloworld.o
>> scripts/Makefile.build:425: recipe for target 'lib/efi_loader' failed
>> make[1]: *** [lib/efi_loader] Error 2
>>
>> [1]: https://github.com/Broadcom/stbgcc-6.3/releases/tag/stbgcc-6.3-1.1
>>
> 
> Isn't this fixed by
> http://git.denx.de/?p=u-boot.git;a=commit;h=3bb74f9800cdc4cf10a87f2725242c2565256654
> 
> "efi_loader helloworld.efi: Fix building with -Os" ?

Nope, my tree is at v2018.01-rc1-115-g335f7b1290ce which contains that
commit already.
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH v3 15/18] efi_loader: output load options in helloworld

[Florian Fainelli]

On 11/26/2017 05:05 AM, Heinrich Schuchardt wrote:
> We need to test if we pass a valid image handle when loading
> and EFI application. This cannot be done in efi_selftest as
> it is not loaded as an image.
> 
> So let's enhance helloworld a bit.
> 
> Reviewed-by: Simon Glass 
> Signed-off-by: Heinrich Schuchardt 

This particular patch/commit bbf75dd9345d0b1a7ec7a50016547eb7c759b7af
("efi_loader: output load options in helloworld") was bisected and
causes the Lamobo_R1_defconfig build using the toolchain at [1] to fail
with:

/home/fainelli/work/toolchains/stbgcc-6.3-1.1/bin/arm-linux-ld.bfd:
error: required section '.got' not found in the linker script
/home/fainelli/work/toolchains/stbgcc-6.3-1.1/bin/arm-linux-ld.bfd:
final link failed: Invalid operation
scripts/Makefile.lib:409: recipe for target
'lib/efi_loader/helloworld_efi.so' failed
make[2]: *** [lib/efi_loader/helloworld_efi.so] Error 1
rm lib/efi_loader/helloworld.o
scripts/Makefile.build:425: recipe for target 'lib/efi_loader' failed
make[1]: *** [lib/efi_loader] Error 2

[1]: https://github.com/Broadcom/stbgcc-6.3/releases/tag/stbgcc-6.3-1.1

> ---
> v3
>   no change
> v2
>   new patch
> ---
>  lib/efi_loader/helloworld.c | 37 +++--
>  1 file changed, 35 insertions(+), 2 deletions(-)
> 
> diff --git a/lib/efi_loader/helloworld.c b/lib/efi_loader/helloworld.c
> index 77130a36dd..e59c24c788 100644
> --- a/lib/efi_loader/helloworld.c
> +++ b/lib/efi_loader/helloworld.c
> @@ -5,19 +5,52 @@
>   * Written by Simon Glass 
>   *
>   * SPDX-License-Identifier: GPL-2.0+
> + *
> + * This program demonstrates calling a boottime service.
> + * It writes a greeting and the load options to the console.
>   */
>  
>  #include 
>  #include 
>  
> +/*
> + * Entry point of the EFI application.
> + *
> + * @handle   handle of the loaded image
> + * @systable system table
> + * @return   status code
> + */
>  efi_status_t EFIAPI efi_main(efi_handle_t handle,
>struct efi_system_table *systable)
>  {
>   struct efi_simple_text_output_protocol *con_out = systable->con_out;
>   struct efi_boot_services *boottime = systable->boottime;
> + struct efi_loaded_image *loaded_image;
> + const efi_guid_t loaded_image_guid = LOADED_IMAGE_GUID;
> + efi_status_t ret;
>  
>   con_out->output_string(con_out, L"Hello, world!\n");
> - boottime->exit(handle, 0, 0, NULL);
>  
> - return EFI_SUCCESS;
> + /* Get the loaded image protocol */
> + ret = boottime->handle_protocol(handle, _image_guid,
> + (void **)_image);
> + if (ret != EFI_SUCCESS) {
> + con_out->output_string(con_out,
> +L"Cannot open loaded image protocol\n");
> + goto out;
> + }
> + /* Output the load options */
> + con_out->output_string(con_out, L"Load options: ");
> + if (loaded_image->load_options_size && loaded_image->load_options)
> + con_out->output_string(con_out,
> +(u16 *)loaded_image->load_options);
> + else
> + con_out->output_string(con_out, L"");
> + con_out->output_string(con_out, L"\n");
> +
> +out:
> + boottime->exit(handle, ret, 0, NULL);
> +
> + /* We should never arrive here */
> + return ret;
>  }
> 

-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 4/4] configs: Update Lamobo_R1 with B53 switch options

[Florian Fainelli]

Enable CONFIG_B53_SWITCH, define the CPU/management port number (8) and
enable all 5 ports of the switch to be usable.

Reviewed-by: Stefan Roese <s...@denx.de>
Acked-by: Joe Hershberger <joe.hershber...@ni.com>
Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 configs/Lamobo_R1_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/Lamobo_R1_defconfig b/configs/Lamobo_R1_defconfig
index 84007ad374b8..19c977ef42ee 100644
--- a/configs/Lamobo_R1_defconfig
+++ b/configs/Lamobo_R1_defconfig
@@ -22,3 +22,6 @@ CONFIG_SUN7I_GMAC=y
 CONFIG_SCSI=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_B53_SWITCH=y
+CONFIG_B53_CPU_PORT=8
+CONFIG_B53_PHY_PORTS=0x1f
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 1/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

Add a minimalistic Broadcom BCM53xx (roboswitch) switch driver similar
to the Marvell MV88E617x. This takes care of configuring the minimum
amount out of the switch hardware such that each user visible port
(configurable) and the CPU port can forward packets between each other
while preserving isolation with other ports.

This is useful for e.g: the Lamobo R1 board featuring a Broadcom
BCM53125 switch.

Reviewed-by: Stefan Roese <s...@denx.de>
Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/phy/Kconfig  |  17 ++
 drivers/net/phy/Makefile |   1 +
 drivers/net/phy/b53.c| 629 +++
 drivers/net/phy/phy.c|   3 +
 include/phy.h|   1 +
 5 files changed, 651 insertions(+)
 create mode 100644 drivers/net/phy/b53.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index e32f1eb1c047..95b753432363 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -12,6 +12,23 @@ menuconfig PHYLIB
 
 if PHYLIB
 
+config B53_SWITCH
+   bool "Broadcom BCM53xx (RoboSwitch) Ethernet switch PHY support."
+   help
+ Enable support for Broadcom BCM53xx (RoboSwitch) Ethernet switches.
+ This currently supports BCM53125 and similar models.
+
+if B53_SWITCH
+
+config B53_CPU_PORT
+   int "CPU port"
+   default 8
+
+config B53_PHY_PORTS
+   hex "Bitmask of PHY ports"
+
+endif # B53_SWITCH
+
 config MV88E61XX_SWITCH
bool "Marvel MV88E61xx Ethernet switch PHY support."
 
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 1e264b2f2b03..f1980371c366 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -6,6 +6,7 @@
 #
 
 obj-$(CONFIG_BITBANGMII) += miiphybb.o
+obj-$(CONFIG_B53_SWITCH) += b53.o
 obj-$(CONFIG_MV88E61XX_SWITCH) += mv88e61xx.o
 obj-$(CONFIG_MV88E6352_SWITCH) += mv88e6352.o
 
diff --git a/drivers/net/phy/b53.c b/drivers/net/phy/b53.c
new file mode 100644
index ..185a2cddaba6
--- /dev/null
+++ b/drivers/net/phy/b53.c
@@ -0,0 +1,629 @@
+/*
+ * Copyright (C) 2017
+ * Broadcom
+ * Florian Fainelli <f.faine...@gmail.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * PHY driver for Broadcom BCM53xx (roboswitch) Ethernet switches.
+ *
+ * This driver configures the b53 for basic use as a PHY. The switch supports
+ * vendor tags and VLAN configuration that can affect the switching decisions.
+ * This driver uses a simple configuration in which all ports are only allowed
+ * to send frames to the CPU port and receive frames from the CPU port this
+ * providing port isolation (no cross talk).
+ *
+ * The configuration determines which PHY ports to activate using the
+ * CONFIG_B53_PHY_PORTS bitmask. Set bit N will active port N and so on.
+ *
+ * This driver was written primarily for the Lamobo R1 platform using a 
BCM53152
+ * switch but the BCM53xx being largely register compatible, extending it to
+ * cover other switches would be trivial.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Pseudo-PHY address (non configurable) to access internal registers */
+#define BRCM_PSEUDO_PHY_ADDR   30
+
+/* Maximum number of ports possible */
+#define B53_N_PORTS9
+
+#define B53_CTRL_PAGE  0x00 /* Control */
+#define B53_MGMT_PAGE  0x02 /* Management Mode */
+/* Port VLAN Page */
+#define B53_PVLAN_PAGE 0x31
+
+/* Control Page registers */
+#define B53_PORT_CTRL(i)   (0x00 + (i))
+#define   PORT_CTRL_RX_DISABLE BIT(0)
+#define   PORT_CTRL_TX_DISABLE BIT(1)
+#define   PORT_CTRL_RX_BCST_EN BIT(2) /* Broadcast RX (P8 only) */
+#define   PORT_CTRL_RX_MCST_EN BIT(3) /* Multicast RX (P8 only) */
+#define   PORT_CTRL_RX_UCST_EN BIT(4) /* Unicast RX (P8 only) */
+
+/* Switch Mode Control Register (8 bit) */
+#define B53_SWITCH_MODE0x0b
+#define   SM_SW_FWD_MODE   BIT(0)  /* 1 = Managed Mode */
+#define   SM_SW_FWD_EN BIT(1)  /* Forwarding Enable */
+
+/* IMP Port state override register (8 bit) */
+#define B53_PORT_OVERRIDE_CTRL 0x0e
+#define   PORT_OVERRIDE_LINK   BIT(0)
+#define   PORT_OVERRIDE_FULL_DUPLEXBIT(1) /* 0 = Half Duplex */
+#define   PORT_OVERRIDE_SPEED_S2
+#define   PORT_OVERRIDE_SPEED_10M  (0 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_SPEED_100M (1 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_SPEED_1000M(2 << PORT_OVERRIDE_SPEED_S)
+/* BCM5325 only */
+#define   PORT_OVERRIDE_RV_MII_25  BIT(4)
+#define   PORT_OVERRIDE_RX_FLOWBIT(4)
+#define   PORT_OVERRIDE_TX_FLOWBIT(5)
+/* BCM5301X only, requires setting 1000M */
+#define   PORT_OVERRIDE_SPEED_2000MBIT(6)
+#define   PORT_OVERRIDE_EN BIT(7) /* Use the register contents */
+
+#define B53_R

[U-Boot] [PATCH v4 3/4] net: phy: b53: Add b53_reg read/write commands

[Florian Fainelli]

Add a b53_reg read/write command which allows inspecting the switch
registers. Because the Broadcom BCM53xx registers have different sizes,
we need to split the accesses in 8, 16, 32, 48 or 64 bits to obtain
expected results.

Reviewed-by: Stefan Roese <s...@denx.de>
Acked-by: Joe Hershberger <joe.hershber...@ni.com>
Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/phy/b53.c | 139 ++
 1 file changed, 139 insertions(+)

diff --git a/drivers/net/phy/b53.c b/drivers/net/phy/b53.c
index 185a2cddaba6..f7f2d9f1eef2 100644
--- a/drivers/net/phy/b53.c
+++ b/drivers/net/phy/b53.c
@@ -627,3 +627,142 @@ int phy_b53_init(void)
 
return 0;
 }
+
+int do_b53_reg_read(const char *name, int argc, char * const argv[])
+{
+   u8 page, offset, width;
+   struct mii_dev *bus;
+   int ret = -EINVAL;
+   u64 value64 = 0;
+   u32 value32 = 0;
+   u16 value16 = 0;
+   u8 value8 = 0;
+
+   bus = miiphy_get_dev_by_name(name);
+   if (!bus) {
+   printf("unable to find MDIO bus: %s\n", name);
+   return ret;
+   }
+
+   page = simple_strtoul(argv[1], NULL, 16);
+   offset = simple_strtoul(argv[2], NULL, 16);
+   width = simple_strtoul(argv[3], NULL, 10);
+
+   switch (width) {
+   case 8:
+   ret = b53_mdio_read8(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%02x\n",
+  page, offset, value8);
+   break;
+   case 16:
+   ret = b53_mdio_read16(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%04x\n",
+  page, offset, value16);
+   break;
+   case 32:
+   ret = b53_mdio_read32(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%08x\n",
+  page, offset, value32);
+   break;
+   case 48:
+   ret = b53_mdio_read48(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%012llx\n",
+  page, offset, value64);
+   break;
+   case 64:
+   ret = b53_mdio_read48(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%016llx\n",
+  page, offset, value64);
+   break;
+   default:
+   printf("Unsupported width: %d\n", width);
+   break;
+   }
+
+   return ret;
+}
+
+int do_b53_reg_write(const char *name, int argc, char * const argv[])
+{
+   u8 page, offset, width;
+   struct mii_dev *bus;
+   int ret = -EINVAL;
+   u64 value64 = 0;
+   u32 value = 0;
+
+   bus = miiphy_get_dev_by_name(name);
+   if (!bus) {
+   printf("unable to find MDIO bus: %s\n", name);
+   return ret;
+   }
+
+   page = simple_strtoul(argv[1], NULL, 16);
+   offset = simple_strtoul(argv[2], NULL, 16);
+   width = simple_strtoul(argv[3], NULL, 10);
+   if (width == 48 || width == 64)
+   value64 = simple_strtoull(argv[4], NULL, 16);
+   else
+   value = simple_strtoul(argv[4], NULL, 16);
+
+   switch (width) {
+   case 8:
+   ret = b53_mdio_write8(bus, page, offset, value & 0xff);
+   break;
+   case 16:
+   ret = b53_mdio_write16(bus, page, offset, value);
+   break;
+   case 32:
+   ret = b53_mdio_write32(bus, page, offset, value);
+   break;
+   case 48:
+   ret = b53_mdio_write48(bus, page, offset, value64);
+   break;
+   case 64:
+   ret = b53_mdio_write64(bus, page, offset, value64);
+   break;
+   default:
+   printf("Unsupported width: %d\n", width);
+   break;
+   }
+
+   return ret;
+}
+
+int do_b53_reg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   const char *cmd, *mdioname;
+   int ret = 0;
+
+   if (argc < 2)
+   return cmd_usage(cmdtp);
+
+   cmd = argv[1];
+   --argc;
+   ++argv;
+
+   if (!strcmp(cmd, "write")) {
+   if (argc < 4)
+   return cmd_usage(cmdtp);
+   mdioname = argv[1];
+   --argc;
+   ++argv;
+   ret = do_b53_reg_write(mdioname, argc, argv);
+   } else if (!strcmp(cmd, "read")) {
+   if (argc < 5)
+   return cmd_usage(cmdtp);
+   mdioname = argv[1];
+   --argc;
+   ++argv;
+   ret = do_b53_reg_read(mdioname, argc, argv);
+   } else {
+   return cmd_usage(cmdtp);
+   }
+
+   return ret;
+}
+
+U_BOOT_CMD(b53_reg, 

[U-Boot] [PATCH v4 2/4] net: designware: Pad small packets

[Florian Fainelli]

Make sure that we pad small packets to a minimum length of 60 bytes
(without FCS). This is necessary to interface with Ethernet switches
that will reject RUNT frames unless padded correctly.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/designware.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 036d231071ca..56fa0ebd8f31 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "designware.h"
@@ -343,6 +344,8 @@ int designware_eth_enable(struct dw_eth_dev *priv)
return 0;
 }
 
+#define ETH_ZLEN   60
+
 static int _dw_eth_send(struct dw_eth_dev *priv, void *packet, int length)
 {
struct eth_dma_regs *dma_p = priv->dma_regs_p;
@@ -369,6 +372,8 @@ static int _dw_eth_send(struct dw_eth_dev *priv, void 
*packet, int length)
return -EPERM;
}
 
+   length = max(length, ETH_ZLEN);
+
memcpy((void *)data_start, packet, length);
 
/* Flush data to be sent */
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v4 0/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

Hi all,

This patch series adds support for the Broadcom BCM53xx switches, in particular
BCM53125 which is found no the Lamobo R1 board.

The driver is largely based on the DSA/b53 driver Linux driver and only
incorporates what is necessary to succesfully bring-up all ports (including the
management port) for boot over the network:

=> dhcp
dw_adjust_link: Speed: 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.0.11 (3 ms)
Using ethernet@01c5 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.11
Filename 'sun7i-a20-lamobo-r1-kernel.bin'.
Load address: 0x4200
Loading: #
 #
 
 11.6 MiB/s
done
Bytes transferred = 2371552 (242fe0 hex)
=> 

Joe there is one warning left which does not look legit to me since we now have
a help paragraph describing the config symbol:

WARNING: please write a paragraph that describes the config symbol fully
#34: FILE: drivers/net/phy/Kconfig:15:
+config B53_SWITCH

and one CHECK left which I intentionally did not fix because it makes the
definitions of the bits less clear:
CHECK: Prefer using the BIT macro
#134: FILE: drivers/net/phy/b53.c:63:
+#define   PORT_OVERRIDE_SPEED_100M (1 << PORT_OVERRIDE_SPEED_S)

Changes in v4:
- address most checkpatch.pl issues, couple remaining, one which looks bogus:


Changes in v3:
- dropped redundant phydev->priv assignment in b53_probe(), spotted by Joe

Changes in v2:

- collected Sefan's Reviewed-by and Joe's Acked-by tags
- use max() in drivers/net/designware.c as suggested by Joe

Florian Fainelli (4):
  net: phy: Add Broadcom BCM53xx switch driver
  net: designware: Pad small packets
  net: phy: b53: Add b53_reg read/write commands
  configs: Update Lamobo_R1 with B53 switch options

Florian Fainelli (4):
  net: phy: Add Broadcom BCM53xx switch driver
  net: designware: Pad small packets
  net: phy: b53: Add b53_reg read/write commands
  configs: Update Lamobo_R1 with B53 switch options

 configs/Lamobo_R1_defconfig |   3 +
 drivers/net/designware.c|   5 +
 drivers/net/phy/Kconfig |  17 +
 drivers/net/phy/Makefile|   1 +
 drivers/net/phy/b53.c   | 768 
 drivers/net/phy/phy.c   |   3 +
 include/phy.h   |   1 +
 7 files changed, 798 insertions(+)
 create mode 100644 drivers/net/phy/b53.c

-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 4/4] configs: Update Lamobo_R1 with B53 switch options

[Florian Fainelli]

Enable CONFIG_B53_SWITCH, define the CPU/management port number (8) and
enable all 5 ports of the switch to be usable.

Reviewed-by: Stefan Roese <s...@denx.de>
Acked-by: Joe Hershberger <joe.hershber...@ni.com>
Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 configs/Lamobo_R1_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/Lamobo_R1_defconfig b/configs/Lamobo_R1_defconfig
index 84007ad374b8..19c977ef42ee 100644
--- a/configs/Lamobo_R1_defconfig
+++ b/configs/Lamobo_R1_defconfig
@@ -22,3 +22,6 @@ CONFIG_SUN7I_GMAC=y
 CONFIG_SCSI=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_B53_SWITCH=y
+CONFIG_B53_CPU_PORT=8
+CONFIG_B53_PHY_PORTS=0x1f
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 1/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

Add a minimalistic Broadcom BCM53xx (roboswitch) switch driver similar
to the Marvell MV88E617x. This takes care of configuring the minimum
amount out of the switch hardware such that each user visible port
(configurable) and the CPU port can forward packets between each other
while preserving isolation with other ports.

This is useful for e.g: the Lamobo R1 board featuring a Broadcom
BCM53125 switch.

Reviewed-by: Stefan Roese <s...@denx.de>
Acked-by: Joe Hershberger 
Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/phy/Kconfig  |  14 ++
 drivers/net/phy/Makefile |   1 +
 drivers/net/phy/b53.c| 627 +++
 drivers/net/phy/phy.c|   3 +
 include/phy.h|   1 +
 5 files changed, 646 insertions(+)
 create mode 100644 drivers/net/phy/b53.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index e32f1eb1c047..609305b8ebf8 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -12,6 +12,20 @@ menuconfig PHYLIB
 
 if PHYLIB
 
+config B53_SWITCH
+   bool "Broadcom BCM53xx (roboswitch) Ethernet switch PHY support."
+
+if B53_SWITCH
+
+config B53_CPU_PORT
+   int "CPU port"
+   default 8
+
+config B53_PHY_PORTS
+   hex "Bitmask of PHY ports"
+
+endif # B53_SWITCH
+
 config MV88E61XX_SWITCH
bool "Marvel MV88E61xx Ethernet switch PHY support."
 
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 1e264b2f2b03..f1980371c366 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -6,6 +6,7 @@
 #
 
 obj-$(CONFIG_BITBANGMII) += miiphybb.o
+obj-$(CONFIG_B53_SWITCH) += b53.o
 obj-$(CONFIG_MV88E61XX_SWITCH) += mv88e61xx.o
 obj-$(CONFIG_MV88E6352_SWITCH) += mv88e6352.o
 
diff --git a/drivers/net/phy/b53.c b/drivers/net/phy/b53.c
new file mode 100644
index ..167ae0077eea
--- /dev/null
+++ b/drivers/net/phy/b53.c
@@ -0,0 +1,627 @@
+/*
+ * Copyright (C) 2017
+ * Broadcom
+ * Florian Fainelli <f.faine...@gmail.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * PHY driver for Broadcom BCM53xx (roboswitch) Ethernet switches.
+ *
+ * This driver configures the b53 for basic use as a PHY. The switch
+ * supports vendor tags and VLAN configuration that can affect the switching 
decisions.
+ * This driver uses a simple configuration in which all ports are only allowed 
to
+ * send frames to the CPU port and receive frames from the CPU port this 
providing
+ * port isolation (no cross talk).
+ *
+ * The configuration determines which PHY ports to activate using the
+ * CONFIG_B53_PHY_PORTS bitmask. Set bit N will active port N and so on.
+ *
+ * This driver was written primarily for the Lamobo R1 platform using a 
BCM53152
+ * switch but the BCM53xx being largely register compatible, extending it to 
cover
+ * other switches would be trivial.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Pseudo-PHY address (non configurable) to access internal registers */
+#define BRCM_PSEUDO_PHY_ADDR   30
+
+/* Maximum number of ports possible */
+#define B53_N_PORTS9
+
+#define B53_CTRL_PAGE  0x00 /* Control */
+#define B53_MGMT_PAGE  0x02 /* Management Mode */
+/* Port VLAN Page */
+#define B53_PVLAN_PAGE 0x31
+
+/* Control Page registers */
+#define B53_PORT_CTRL(i)   (0x00 + (i))
+#define   PORT_CTRL_RX_DISABLE BIT(0)
+#define   PORT_CTRL_TX_DISABLE BIT(1)
+#define   PORT_CTRL_RX_BCST_EN BIT(2) /* Broadcast RX (P8 only) */
+#define   PORT_CTRL_RX_MCST_EN BIT(3) /* Multicast RX (P8 only) */
+#define   PORT_CTRL_RX_UCST_EN BIT(4) /* Unicast RX (P8 only) */
+
+/* Switch Mode Control Register (8 bit) */
+#define B53_SWITCH_MODE0x0b
+#define   SM_SW_FWD_MODE   BIT(0)  /* 1 = Managed Mode */
+#define   SM_SW_FWD_EN BIT(1)  /* Forwarding Enable */
+
+/* IMP Port state override register (8 bit) */
+#define B53_PORT_OVERRIDE_CTRL 0x0e
+#define   PORT_OVERRIDE_LINK   BIT(0)
+#define   PORT_OVERRIDE_FULL_DUPLEXBIT(1) /* 0 = Half Duplex */
+#define   PORT_OVERRIDE_SPEED_S2
+#define   PORT_OVERRIDE_SPEED_10M  (0 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_SPEED_100M (1 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_SPEED_1000M(2 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_RV_MII_25  BIT(4) /* BCM5325 only */
+#define   PORT_OVERRIDE_RX_FLOWBIT(4)
+#define   PORT_OVERRIDE_TX_FLOWBIT(5)
+#define   PORT_OVERRIDE_SPEED_2000MBIT(6) /* BCM5301X only, requires 
setting 1000M */
+#define   PORT_OVERRIDE_EN BIT(7) /* Use the register contents */
+
+#define B53_RGMII_CTRL_IMP 0x60
+#define   RGMII_CTRL_ENABLE_GMII   BIT(7)
+#define   RGMII_CTRL_TIMING_SEL  

[U-Boot] [PATCH v3 2/4] net: designware: Pad small packets

[Florian Fainelli]

Make sure that we pad small packets to a minimum length of 60 bytes
(without FCS). This is necessary to interface with Ethernet switches
that will reject RUNT frames unless padded correctly.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/designware.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 036d231071ca..56fa0ebd8f31 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "designware.h"
@@ -343,6 +344,8 @@ int designware_eth_enable(struct dw_eth_dev *priv)
return 0;
 }
 
+#define ETH_ZLEN   60
+
 static int _dw_eth_send(struct dw_eth_dev *priv, void *packet, int length)
 {
struct eth_dma_regs *dma_p = priv->dma_regs_p;
@@ -369,6 +372,8 @@ static int _dw_eth_send(struct dw_eth_dev *priv, void 
*packet, int length)
return -EPERM;
}
 
+   length = max(length, ETH_ZLEN);
+
memcpy((void *)data_start, packet, length);
 
/* Flush data to be sent */
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 0/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

Hi all,

This patch series adds support for the Broadcom BCM53xx switches, in particular
BCM53125 which is found no the Lamobo R1 board.

The driver is largely based on the DSA/b53 driver Linux driver and only
incorporates what is necessary to succesfully bring-up all ports (including the
management port) for boot over the network:

=> dhcp
dw_adjust_link: Speed: 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.0.11 (3 ms)
Using ethernet@01c5 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.11
Filename 'sun7i-a20-lamobo-r1-kernel.bin'.
Load address: 0x4200
Loading: #
 #
 
 11.6 MiB/s
done
Bytes transferred = 2371552 (242fe0 hex)
=> 

Changes in v3:
- dropped redundant phydev->priv assignment in b53_probe(), spotted by Joe

Changes in v2:

- collected Sefan's Reviewed-by and Joe's Acked-by tags
- use max() in drivers/net/designware.c as suggested by Joe

Florian Fainelli (4):
  net: phy: Add Broadcom BCM53xx switch driver
  net: designware: Pad small packets
  net: phy: b53: Add b53_reg read/write commands
  configs: Update Lamobo_R1 with B53 switch options

 configs/Lamobo_R1_defconfig |   3 +
 drivers/net/designware.c|   5 +
 drivers/net/phy/Kconfig |  14 +
 drivers/net/phy/Makefile|   1 +
 drivers/net/phy/b53.c   | 765 
 drivers/net/phy/phy.c   |   3 +
 include/phy.h   |   1 +
 7 files changed, 792 insertions(+)
 create mode 100644 drivers/net/phy/b53.c

-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v3 3/4] net: phy: b53: Add b53_reg read/write commands

[Florian Fainelli]

Add a b53_reg read/write command which allows inspecting the switch
registers. Because the Broadcom BCM53xx registers have different sizes,
we need to split the accesses in 8, 16, 32, 48 or 64 bits to obtain
expected results.

Reviewed-by: Stefan Roese <s...@denx.de>
Acked-by: Joe Hershberger <joe.hershber...@ni.com>
Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/phy/b53.c | 138 ++
 1 file changed, 138 insertions(+)

diff --git a/drivers/net/phy/b53.c b/drivers/net/phy/b53.c
index 167ae0077eea..6fc8d5df1801 100644
--- a/drivers/net/phy/b53.c
+++ b/drivers/net/phy/b53.c
@@ -625,3 +625,141 @@ int phy_b53_init(void)
 
return 0;
 }
+
+int do_b53_reg_read(const char *name, int argc, char * const argv[])
+{
+   u8 page, offset, width;
+   struct mii_dev *bus;
+   int ret = -EINVAL;
+   u64 value64 = 0;
+   u32 value32 = 0;
+   u16 value16 = 0;
+   u8 value8 = 0;
+
+   bus = miiphy_get_dev_by_name(name);
+   if (!bus) {
+   printf("unable to find MDIO bus: %s\n", name);
+   return ret;
+   }
+
+   page = simple_strtoul(argv[1], NULL, 16);
+   offset = simple_strtoul(argv[2], NULL, 16);
+   width = simple_strtoul(argv[3], NULL, 10);
+
+   switch (width) {
+   case 8:
+   ret = b53_mdio_read8(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%02x\n",
+   page, offset, value8);
+   break;
+   case 16:
+   ret = b53_mdio_read16(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%04x\n",
+   page, offset, value16);
+   break;
+   case 32:
+   ret = b53_mdio_read32(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%08x\n",
+   page, offset, value32);
+   break;
+   case 48:
+   ret = b53_mdio_read48(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%012llx\n",
+   page, offset, value64);
+   break;
+   case 64:
+   ret = b53_mdio_read48(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%016llx\n",
+   page, offset, value64);
+   break;
+   default:
+   printf("Unsupported width: %d\n", width);
+   break;
+   }
+
+   return ret;
+}
+
+int do_b53_reg_write(const char *name, int argc, char * const argv[])
+{
+   u8 page, offset, width;
+   struct mii_dev *bus;
+   int ret = -EINVAL;
+   u64 value64 = 0;
+   u32 value = 0;
+
+   bus = miiphy_get_dev_by_name(name);
+   if (!bus) {
+   printf("unable to find MDIO bus: %s\n", name);
+   return ret;
+   }
+
+   page = simple_strtoul(argv[1], NULL, 16);
+   offset = simple_strtoul(argv[2], NULL, 16);
+   width = simple_strtoul(argv[3], NULL, 10);
+   if (width == 48 || width == 64)
+   value64 = simple_strtoull(argv[4], NULL, 16);
+   else
+   value = simple_strtoul(argv[4], NULL, 16);
+
+   switch (width) {
+   case 8:
+   ret = b53_mdio_write8(bus, page, offset, value & 0xff);
+   break;
+   case 16:
+   ret = b53_mdio_write16(bus, page, offset, value);
+   break;
+   case 32:
+   ret = b53_mdio_write32(bus, page, offset, value);
+   break;
+   case 48:
+   ret = b53_mdio_write48(bus, page, offset, value64);
+   break;
+   case 64:
+   ret = b53_mdio_write64(bus, page, offset, value64);
+   break;
+   default:
+   printf("Unsupported width: %d\n", width);
+   break;
+   }
+
+   return ret;
+}
+
+int do_b53_reg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   const char *cmd, *mdioname;
+   int ret = 0;
+
+   if (argc < 2)
+   return cmd_usage(cmdtp);
+
+   cmd = argv[1];
+   --argc;
+   ++argv;
+
+   if (!strcmp(cmd, "write")) {
+   if (argc < 4)
+   return cmd_usage(cmdtp);
+   mdioname = argv[1];
+   --argc;
+   ++argv;
+   ret = do_b53_reg_write(mdioname, argc, argv);
+   } else if (!strcmp(cmd, "read")) {
+   if (argc < 5)
+   return cmd_usage(cmdtp);
+   mdioname = argv[1];
+   --argc;
+   ++argv;
+   ret = do_b53_reg_read(mdioname, argc, argv);
+   } else
+   return cmd_usage(cmdtp);
+
+   return ret;
+}
+
+U_BOOT_CMD(b53_reg, 7, 

Re: [U-Boot] [PATCH v2 1/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

On 12/09/2017 10:40 AM, Florian Fainelli wrote:
> Add a minimalistic Broadcom BCM53xx (roboswitch) switch driver similar
> to the Marvell MV88E617x. This takes care of configuring the minimum
> amount out of the switch hardware such that each user visible port
> (configurable) and the CPU port can forward packets between each other
> while preserving isolation with other ports.
> 
> This is useful for e.g: the Lamobo R1 board featuring a Broadcom
> BCM53125 switch.
> 
> Reviewed-by: Stefan Roese <s...@denx.de>
> Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
> ---

[snip]

> +static int b53_probe(struct phy_device *phydev)
> +{
> + struct b53_device *dev;
> + int ret;
> +
> + dev = malloc(sizeof(*dev));
> + if (!dev)
> + return -ENOMEM;
> +
> + memset(dev, 0, sizeof(*dev));
> +
> + phydev->priv = dev;
> + dev->bus = phydev->bus;
> + dev->cpu_port = CONFIG_B53_CPU_PORT;
> +
> + ret = b53_switch_reset(phydev);
> + if (ret < 0)
> + return ret;
> +
> + phydev->priv = dev;

Looks like I missed Joe's comment here about the redundant assignment,
let me resubmit a v3 with this corrected.
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 4/4] configs: Update Lamobo_R1 with B53 switch options

[Florian Fainelli]

Enable CONFIG_B53_SWITCH, define the CPU/management port number (8) and
enable all 5 ports of the switch to be usable.

Reviewed-by: Stefan Roese <s...@denx.de>
Acked-by: Joe Hershberger <joe.hershber...@ni.com>
Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 configs/Lamobo_R1_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/Lamobo_R1_defconfig b/configs/Lamobo_R1_defconfig
index 84007ad374b8..19c977ef42ee 100644
--- a/configs/Lamobo_R1_defconfig
+++ b/configs/Lamobo_R1_defconfig
@@ -22,3 +22,6 @@ CONFIG_SUN7I_GMAC=y
 CONFIG_SCSI=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_B53_SWITCH=y
+CONFIG_B53_CPU_PORT=8
+CONFIG_B53_PHY_PORTS=0x1f
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 2/4] net: designware: Pad small packets

[Florian Fainelli]

Make sure that we pad small packets to a minimum length of 60 bytes
(without FCS). This is necessary to interface with Ethernet switches
that will reject RUNT frames unless padded correctly.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/designware.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 036d231071ca..56fa0ebd8f31 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include "designware.h"
@@ -343,6 +344,8 @@ int designware_eth_enable(struct dw_eth_dev *priv)
return 0;
 }
 
+#define ETH_ZLEN   60
+
 static int _dw_eth_send(struct dw_eth_dev *priv, void *packet, int length)
 {
struct eth_dma_regs *dma_p = priv->dma_regs_p;
@@ -369,6 +372,8 @@ static int _dw_eth_send(struct dw_eth_dev *priv, void 
*packet, int length)
return -EPERM;
}
 
+   length = max(length, ETH_ZLEN);
+
memcpy((void *)data_start, packet, length);
 
/* Flush data to be sent */
-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH v2 3/4] net: phy: b53: Add b53_reg read/write commands

[Florian Fainelli]

Add a b53_reg read/write command which allows inspecting the switch
registers. Because the Broadcom BCM53xx registers have different sizes,
we need to split the accesses in 8, 16, 32, 48 or 64 bits to obtain
expected results.

Reviewed-by: Stefan Roese <s...@denx.de>
Acked-by: Joe Hershberger <joe.hershber...@ni.com>
Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/phy/b53.c | 138 ++
 1 file changed, 138 insertions(+)

diff --git a/drivers/net/phy/b53.c b/drivers/net/phy/b53.c
index fa37d051130b..a68d2ae39fa9 100644
--- a/drivers/net/phy/b53.c
+++ b/drivers/net/phy/b53.c
@@ -627,3 +627,141 @@ int phy_b53_init(void)
 
return 0;
 }
+
+int do_b53_reg_read(const char *name, int argc, char * const argv[])
+{
+   u8 page, offset, width;
+   struct mii_dev *bus;
+   int ret = -EINVAL;
+   u64 value64 = 0;
+   u32 value32 = 0;
+   u16 value16 = 0;
+   u8 value8 = 0;
+
+   bus = miiphy_get_dev_by_name(name);
+   if (!bus) {
+   printf("unable to find MDIO bus: %s\n", name);
+   return ret;
+   }
+
+   page = simple_strtoul(argv[1], NULL, 16);
+   offset = simple_strtoul(argv[2], NULL, 16);
+   width = simple_strtoul(argv[3], NULL, 10);
+
+   switch (width) {
+   case 8:
+   ret = b53_mdio_read8(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%02x\n",
+   page, offset, value8);
+   break;
+   case 16:
+   ret = b53_mdio_read16(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%04x\n",
+   page, offset, value16);
+   break;
+   case 32:
+   ret = b53_mdio_read32(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%08x\n",
+   page, offset, value32);
+   break;
+   case 48:
+   ret = b53_mdio_read48(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%012llx\n",
+   page, offset, value64);
+   break;
+   case 64:
+   ret = b53_mdio_read48(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%016llx\n",
+   page, offset, value64);
+   break;
+   default:
+   printf("Unsupported width: %d\n", width);
+   break;
+   }
+
+   return ret;
+}
+
+int do_b53_reg_write(const char *name, int argc, char * const argv[])
+{
+   u8 page, offset, width;
+   struct mii_dev *bus;
+   int ret = -EINVAL;
+   u64 value64 = 0;
+   u32 value = 0;
+
+   bus = miiphy_get_dev_by_name(name);
+   if (!bus) {
+   printf("unable to find MDIO bus: %s\n", name);
+   return ret;
+   }
+
+   page = simple_strtoul(argv[1], NULL, 16);
+   offset = simple_strtoul(argv[2], NULL, 16);
+   width = simple_strtoul(argv[3], NULL, 10);
+   if (width == 48 || width == 64)
+   value64 = simple_strtoull(argv[4], NULL, 16);
+   else
+   value = simple_strtoul(argv[4], NULL, 16);
+
+   switch (width) {
+   case 8:
+   ret = b53_mdio_write8(bus, page, offset, value & 0xff);
+   break;
+   case 16:
+   ret = b53_mdio_write16(bus, page, offset, value);
+   break;
+   case 32:
+   ret = b53_mdio_write32(bus, page, offset, value);
+   break;
+   case 48:
+   ret = b53_mdio_write48(bus, page, offset, value64);
+   break;
+   case 64:
+   ret = b53_mdio_write64(bus, page, offset, value64);
+   break;
+   default:
+   printf("Unsupported width: %d\n", width);
+   break;
+   }
+
+   return ret;
+}
+
+int do_b53_reg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   const char *cmd, *mdioname;
+   int ret = 0;
+
+   if (argc < 2)
+   return cmd_usage(cmdtp);
+
+   cmd = argv[1];
+   --argc;
+   ++argv;
+
+   if (!strcmp(cmd, "write")) {
+   if (argc < 4)
+   return cmd_usage(cmdtp);
+   mdioname = argv[1];
+   --argc;
+   ++argv;
+   ret = do_b53_reg_write(mdioname, argc, argv);
+   } else if (!strcmp(cmd, "read")) {
+   if (argc < 5)
+   return cmd_usage(cmdtp);
+   mdioname = argv[1];
+   --argc;
+   ++argv;
+   ret = do_b53_reg_read(mdioname, argc, argv);
+   } else
+   return cmd_usage(cmdtp);
+
+   return ret;
+}
+
+U_BOOT_CMD(b53_reg, 7, 

[U-Boot] [PATCH v2 1/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

Add a minimalistic Broadcom BCM53xx (roboswitch) switch driver similar
to the Marvell MV88E617x. This takes care of configuring the minimum
amount out of the switch hardware such that each user visible port
(configurable) and the CPU port can forward packets between each other
while preserving isolation with other ports.

This is useful for e.g: the Lamobo R1 board featuring a Broadcom
BCM53125 switch.

Reviewed-by: Stefan Roese <s...@denx.de>
Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/phy/Kconfig  |  14 ++
 drivers/net/phy/Makefile |   1 +
 drivers/net/phy/b53.c| 629 +++
 drivers/net/phy/phy.c|   3 +
 include/phy.h|   1 +
 5 files changed, 648 insertions(+)
 create mode 100644 drivers/net/phy/b53.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index e32f1eb1c047..609305b8ebf8 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -12,6 +12,20 @@ menuconfig PHYLIB
 
 if PHYLIB
 
+config B53_SWITCH
+   bool "Broadcom BCM53xx (roboswitch) Ethernet switch PHY support."
+
+if B53_SWITCH
+
+config B53_CPU_PORT
+   int "CPU port"
+   default 8
+
+config B53_PHY_PORTS
+   hex "Bitmask of PHY ports"
+
+endif # B53_SWITCH
+
 config MV88E61XX_SWITCH
bool "Marvel MV88E61xx Ethernet switch PHY support."
 
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 1e264b2f2b03..f1980371c366 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -6,6 +6,7 @@
 #
 
 obj-$(CONFIG_BITBANGMII) += miiphybb.o
+obj-$(CONFIG_B53_SWITCH) += b53.o
 obj-$(CONFIG_MV88E61XX_SWITCH) += mv88e61xx.o
 obj-$(CONFIG_MV88E6352_SWITCH) += mv88e6352.o
 
diff --git a/drivers/net/phy/b53.c b/drivers/net/phy/b53.c
new file mode 100644
index ..fa37d051130b
--- /dev/null
+++ b/drivers/net/phy/b53.c
@@ -0,0 +1,629 @@
+/*
+ * Copyright (C) 2017
+ * Broadcom
+ * Florian Fainelli <f.faine...@gmail.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * PHY driver for Broadcom BCM53xx (roboswitch) Ethernet switches.
+ *
+ * This driver configures the b53 for basic use as a PHY. The switch
+ * supports vendor tags and VLAN configuration that can affect the switching 
decisions.
+ * This driver uses a simple configuration in which all ports are only allowed 
to
+ * send frames to the CPU port and receive frames from the CPU port this 
providing
+ * port isolation (no cross talk).
+ *
+ * The configuration determines which PHY ports to activate using the
+ * CONFIG_B53_PHY_PORTS bitmask. Set bit N will active port N and so on.
+ *
+ * This driver was written primarily for the Lamobo R1 platform using a 
BCM53152
+ * switch but the BCM53xx being largely register compatible, extending it to 
cover
+ * other switches would be trivial.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Pseudo-PHY address (non configurable) to access internal registers */
+#define BRCM_PSEUDO_PHY_ADDR   30
+
+/* Maximum number of ports possible */
+#define B53_N_PORTS9
+
+#define B53_CTRL_PAGE  0x00 /* Control */
+#define B53_MGMT_PAGE  0x02 /* Management Mode */
+/* Port VLAN Page */
+#define B53_PVLAN_PAGE 0x31
+
+/* Control Page registers */
+#define B53_PORT_CTRL(i)   (0x00 + (i))
+#define   PORT_CTRL_RX_DISABLE BIT(0)
+#define   PORT_CTRL_TX_DISABLE BIT(1)
+#define   PORT_CTRL_RX_BCST_EN BIT(2) /* Broadcast RX (P8 only) */
+#define   PORT_CTRL_RX_MCST_EN BIT(3) /* Multicast RX (P8 only) */
+#define   PORT_CTRL_RX_UCST_EN BIT(4) /* Unicast RX (P8 only) */
+
+/* Switch Mode Control Register (8 bit) */
+#define B53_SWITCH_MODE0x0b
+#define   SM_SW_FWD_MODE   BIT(0)  /* 1 = Managed Mode */
+#define   SM_SW_FWD_EN BIT(1)  /* Forwarding Enable */
+
+/* IMP Port state override register (8 bit) */
+#define B53_PORT_OVERRIDE_CTRL 0x0e
+#define   PORT_OVERRIDE_LINK   BIT(0)
+#define   PORT_OVERRIDE_FULL_DUPLEXBIT(1) /* 0 = Half Duplex */
+#define   PORT_OVERRIDE_SPEED_S2
+#define   PORT_OVERRIDE_SPEED_10M  (0 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_SPEED_100M (1 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_SPEED_1000M(2 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_RV_MII_25  BIT(4) /* BCM5325 only */
+#define   PORT_OVERRIDE_RX_FLOWBIT(4)
+#define   PORT_OVERRIDE_TX_FLOWBIT(5)
+#define   PORT_OVERRIDE_SPEED_2000MBIT(6) /* BCM5301X only, requires 
setting 1000M */
+#define   PORT_OVERRIDE_EN BIT(7) /* Use the register contents */
+
+#define B53_RGMII_CTRL_IMP 0x60
+#define   RGMII_CTRL_ENABLE_GMII   BIT(7)
+#define   RGMII_CTRL_TIMING_SELBIT(2)
+#define   RGMII

[U-Boot] [PATCH v2 0/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

Hi all,

This patch series adds support for the Broadcom BCM53xx switches, in particular
BCM53125 which is found no the Lamobo R1 board.

The driver is largely based on the DSA/b53 driver Linux driver and only
incorporates what is necessary to succesfully bring-up all ports (including the
management port) for boot over the network:

=> dhcp
dw_adjust_link: Speed: 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.0.11 (3 ms)
Using ethernet@01c5 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.11
Filename 'sun7i-a20-lamobo-r1-kernel.bin'.
Load address: 0x4200
Loading: #
 #
 
 11.6 MiB/s
done
Bytes transferred = 2371552 (242fe0 hex)
=> 

Changes in v2:

- collected Sefan's Reviewed-by and Joe's Acked-by tags
- use max() in drivers/net/designware.c as suggested by Joe

Florian Fainelli (4):
  net: phy: Add Broadcom BCM53xx switch driver
  net: designware: Pad small packets
  net: phy: b53: Add b53_reg read/write commands
  configs: Update Lamobo_R1 with B53 switch options

 configs/Lamobo_R1_defconfig |   3 +
 drivers/net/designware.c|   5 +
 drivers/net/phy/Kconfig |  14 +
 drivers/net/phy/Makefile|   1 +
 drivers/net/phy/b53.c   | 767 
 drivers/net/phy/phy.c   |   3 +
 include/phy.h   |   1 +
 7 files changed, 794 insertions(+)
 create mode 100644 drivers/net/phy/b53.c

-- 
2.14.1

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [RFC] Support for SGMII 2500

[Florian Fainelli]

On 11/28/2017 07:37 AM, Madalin-cristian Bucur wrote:
>> -Original Message-
>> From: Andrew Lunn [mailto:and...@lunn.ch]
>> Sent: Tuesday, November 28, 2017 4:13 PM
>> To: Madalin-cristian Bucur 
>> Subject: Re: [RFC] Support for SGMII 2500
>>
>>> Hi Andrew,
>>>
>>> Bhaskar is working on enabling a PFE [1] MAC connected to an Aquantia
>> AQR107
>>> PHY [2] on a LS1012AQDS board. Initially I've indicated 2500Base-X too,
>> but it
>>> seems the HW actually works in SGMII mode. The QDS boards are lower
>> volume,
>>> higher spec boards than the RDBs [3], they exercise most of the HW
>> capabilities.
>>
>> The webpage for the AQR107 lists 2500Base-X, so i assume the issue is
>> with the MAC? Ideally you want to use 2500Base-X, since this is wider
>> known.
>>
>> Anyway, you seem to have a legitimate need for it.
>>
>> However, i would prefer a different name. The convention is to put the
>> number first. So PHY_INTERFACE_MODE_2500SGMII.
>>
>>Andrew
> 
> OK,
> 
> I just wanted to make sure 2.5G SGMII is to be added separately from the
> "normal" SGMII, as it was done in u-boot. Thanks also for the naming hint.

Sorry for chiming in that late, but what is 2.5G SGMII exactly? Either
you can use SGMII auto-negotiation, and in which case, why is not 2.5G
selected, or you can't and you might want to use a fixed-link property then.
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

On 10/29/2017 08:30 PM, Florian Fainelli wrote:
> Le 10/19/17 à 21:45, Stefan Roese a écrit :
>> On 19.10.2017 23:50, Florian Fainelli wrote:
>>> On 10/14/2017 06:00 PM, Florian Fainelli wrote:
>>>> (this time after subscribing to the list)
>>>>
>>>> Hi all,
>>>>
>>>> This patch series adds support for the Broadcom BCM53xx switches, in
>>>> particular
>>>> BCM53125 which is found no the Lamobo R1 board.
>>>
>>> Thanks Stefan for the review. I suppose Joe should now queue those up,
>>> provided that he is happy with the patches and then submit a pull
>>> request?
>>
>> Yes, this is how it usually works.
> 
> Joe, should I do anything, are you happy with how the patches look like?

Ping? How do we get these moving?
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

Le 10/19/17 à 21:45, Stefan Roese a écrit :
> On 19.10.2017 23:50, Florian Fainelli wrote:
>> On 10/14/2017 06:00 PM, Florian Fainelli wrote:
>>> (this time after subscribing to the list)
>>>
>>> Hi all,
>>>
>>> This patch series adds support for the Broadcom BCM53xx switches, in
>>> particular
>>> BCM53125 which is found no the Lamobo R1 board.
>>
>> Thanks Stefan for the review. I suppose Joe should now queue those up,
>> provided that he is happy with the patches and then submit a pull
>> request?
> 
> Yes, this is how it usually works.

Joe, should I do anything, are you happy with how the patches look like?
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 0/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

On 10/14/2017 06:00 PM, Florian Fainelli wrote:
> (this time after subscribing to the list)
> 
> Hi all,
> 
> This patch series adds support for the Broadcom BCM53xx switches, in 
> particular
> BCM53125 which is found no the Lamobo R1 board.

Thanks Stefan for the review. I suppose Joe should now queue those up,
provided that he is happy with the patches and then submit a pull request?

> 
> The driver is largely based on the DSA/b53 driver Linux driver and only
> incorporates what is necessary to succesfully bring-up all ports (including 
> the
> management port) for boot over the network:
> 
> => dhcp
> dw_adjust_link: Speed: 1000, full duplex
> BOOTP broadcast 1
> DHCP client bound to address 192.168.0.11 (3 ms)
> Using ethernet@01c5 device
> TFTP from server 192.168.0.1; our IP address is 192.168.0.11
> Filename 'sun7i-a20-lamobo-r1-kernel.bin'.
> Load address: 0x4200
> Loading: #
>  #
>  
>      11.6 MiB/s
> done
> Bytes transferred = 2371552 (242fe0 hex)
> => 
> 
> 
> Florian Fainelli (4):
>   net: phy: Add Broadcom BCM53xx switch driver
>   net: designware: Pad small packets
>   net: phy: b53: Add b53_reg read/write commands
>   configs: Update Lamobo_R1 with B53 switch options
> 
>  configs/Lamobo_R1_defconfig |   3 +
>  drivers/net/designware.c|   4 +
>  drivers/net/phy/Kconfig |  14 +
>  drivers/net/phy/Makefile|   1 +
>  drivers/net/phy/b53.c   | 767 
> 
>  drivers/net/phy/phy.c   |   3 +
>  include/phy.h   |   1 +
>  7 files changed, 793 insertions(+)
>  create mode 100644 drivers/net/phy/b53.c
> 


-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/4] net: designware: Pad small packets

[Florian Fainelli]

Make sure that we pad small packets to a minimum length of 60 bytes
(without FCS). This is necessary to interface with Ethernet switches
that will reject RUNT frames unless padded correctly.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/designware.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 036d231071ca..10356a9abd0e 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -343,6 +343,8 @@ int designware_eth_enable(struct dw_eth_dev *priv)
return 0;
 }
 
+#define ETH_ZLEN   60
+
 static int _dw_eth_send(struct dw_eth_dev *priv, void *packet, int length)
 {
struct eth_dma_regs *dma_p = priv->dma_regs_p;
@@ -369,6 +371,8 @@ static int _dw_eth_send(struct dw_eth_dev *priv, void 
*packet, int length)
return -EPERM;
}
 
+   length = (length < ETH_ZLEN) ? ETH_ZLEN : length;
+
memcpy((void *)data_start, packet, length);
 
/* Flush data to be sent */
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 3/4] net: phy: b53: Add b53_reg read/write commands

[Florian Fainelli]

Add a b53_reg read/write command which allows inspecting the switch
registers. Because the Broadcom BCM53xx registers have different sizes,
we need to split the accesses in 8, 16, 32, 48 or 64 bits to obtain
expected results.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/phy/b53.c | 138 ++
 1 file changed, 138 insertions(+)

diff --git a/drivers/net/phy/b53.c b/drivers/net/phy/b53.c
index fa37d051130b..a68d2ae39fa9 100644
--- a/drivers/net/phy/b53.c
+++ b/drivers/net/phy/b53.c
@@ -627,3 +627,141 @@ int phy_b53_init(void)
 
return 0;
 }
+
+int do_b53_reg_read(const char *name, int argc, char * const argv[])
+{
+   u8 page, offset, width;
+   struct mii_dev *bus;
+   int ret = -EINVAL;
+   u64 value64 = 0;
+   u32 value32 = 0;
+   u16 value16 = 0;
+   u8 value8 = 0;
+
+   bus = miiphy_get_dev_by_name(name);
+   if (!bus) {
+   printf("unable to find MDIO bus: %s\n", name);
+   return ret;
+   }
+
+   page = simple_strtoul(argv[1], NULL, 16);
+   offset = simple_strtoul(argv[2], NULL, 16);
+   width = simple_strtoul(argv[3], NULL, 10);
+
+   switch (width) {
+   case 8:
+   ret = b53_mdio_read8(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%02x\n",
+   page, offset, value8);
+   break;
+   case 16:
+   ret = b53_mdio_read16(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%04x\n",
+   page, offset, value16);
+   break;
+   case 32:
+   ret = b53_mdio_read32(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%08x\n",
+   page, offset, value32);
+   break;
+   case 48:
+   ret = b53_mdio_read48(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%012llx\n",
+   page, offset, value64);
+   break;
+   case 64:
+   ret = b53_mdio_read48(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%016llx\n",
+   page, offset, value64);
+   break;
+   default:
+   printf("Unsupported width: %d\n", width);
+   break;
+   }
+
+   return ret;
+}
+
+int do_b53_reg_write(const char *name, int argc, char * const argv[])
+{
+   u8 page, offset, width;
+   struct mii_dev *bus;
+   int ret = -EINVAL;
+   u64 value64 = 0;
+   u32 value = 0;
+
+   bus = miiphy_get_dev_by_name(name);
+   if (!bus) {
+   printf("unable to find MDIO bus: %s\n", name);
+   return ret;
+   }
+
+   page = simple_strtoul(argv[1], NULL, 16);
+   offset = simple_strtoul(argv[2], NULL, 16);
+   width = simple_strtoul(argv[3], NULL, 10);
+   if (width == 48 || width == 64)
+   value64 = simple_strtoull(argv[4], NULL, 16);
+   else
+   value = simple_strtoul(argv[4], NULL, 16);
+
+   switch (width) {
+   case 8:
+   ret = b53_mdio_write8(bus, page, offset, value & 0xff);
+   break;
+   case 16:
+   ret = b53_mdio_write16(bus, page, offset, value);
+   break;
+   case 32:
+   ret = b53_mdio_write32(bus, page, offset, value);
+   break;
+   case 48:
+   ret = b53_mdio_write48(bus, page, offset, value64);
+   break;
+   case 64:
+   ret = b53_mdio_write64(bus, page, offset, value64);
+   break;
+   default:
+   printf("Unsupported width: %d\n", width);
+   break;
+   }
+
+   return ret;
+}
+
+int do_b53_reg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   const char *cmd, *mdioname;
+   int ret = 0;
+
+   if (argc < 2)
+   return cmd_usage(cmdtp);
+
+   cmd = argv[1];
+   --argc;
+   ++argv;
+
+   if (!strcmp(cmd, "write")) {
+   if (argc < 4)
+   return cmd_usage(cmdtp);
+   mdioname = argv[1];
+   --argc;
+   ++argv;
+   ret = do_b53_reg_write(mdioname, argc, argv);
+   } else if (!strcmp(cmd, "read")) {
+   if (argc < 5)
+   return cmd_usage(cmdtp);
+   mdioname = argv[1];
+   --argc;
+   ++argv;
+   ret = do_b53_reg_read(mdioname, argc, argv);
+   } else
+   return cmd_usage(cmdtp);
+
+   return ret;
+}
+
+U_BOOT_CMD(b53_reg, 7, 1, do_b53_reg,
+  "Broadcom B53 switch register access",
+  "write mdio

[U-Boot] [PATCH 4/4] configs: Update Lamobo_R1 with B53 switch options

[Florian Fainelli]

Enable CONFIG_B53_SWITCH, define the CPU/management port number (8) and
enable all 5 ports of the switch to be usable.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 configs/Lamobo_R1_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/Lamobo_R1_defconfig b/configs/Lamobo_R1_defconfig
index 84007ad374b8..19c977ef42ee 100644
--- a/configs/Lamobo_R1_defconfig
+++ b/configs/Lamobo_R1_defconfig
@@ -22,3 +22,6 @@ CONFIG_SUN7I_GMAC=y
 CONFIG_SCSI=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_B53_SWITCH=y
+CONFIG_B53_CPU_PORT=8
+CONFIG_B53_PHY_PORTS=0x1f
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

Add a minimalistic Broadcom BCM53xx (roboswitch) switch driver similar
to the Marvell MV88E617x. This takes care of configuring the minimum
amount out of the switch hardware such that each user visible port
(configurable) and the CPU port can forward packets between each other
while preserving isolation with other ports.

This is useful for e.g: the Lamobo R1 board featuring a Broadcom
BCM53125 switch.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/phy/Kconfig  |  14 ++
 drivers/net/phy/Makefile |   1 +
 drivers/net/phy/b53.c| 629 +++
 drivers/net/phy/phy.c|   3 +
 include/phy.h|   1 +
 5 files changed, 648 insertions(+)
 create mode 100644 drivers/net/phy/b53.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 4d02d8bb19a9..e4c4039ff0a4 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -12,6 +12,20 @@ menuconfig PHYLIB
 
 if PHYLIB
 
+config B53_SWITCH
+   bool "Broadcom BCM53xx (roboswitch) Ethernet switch PHY support."
+
+if B53_SWITCH
+
+config B53_CPU_PORT
+   int "CPU port"
+   default 8
+
+config B53_PHY_PORTS
+   hex "Bitmask of PHY ports"
+
+endif # B53_SWITCH
+
 config MV88E61XX_SWITCH
bool "Marvel MV88E61xx Ethernet switch PHY support."
 
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 54f32f606be3..b30e6496063a 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -6,6 +6,7 @@
 #
 
 obj-$(CONFIG_BITBANGMII) += miiphybb.o
+obj-$(CONFIG_B53_SWITCH) += b53.o
 obj-$(CONFIG_MV88E61XX_SWITCH) += mv88e61xx.o
 obj-$(CONFIG_MV88E6352_SWITCH) += mv88e6352.o
 
diff --git a/drivers/net/phy/b53.c b/drivers/net/phy/b53.c
new file mode 100644
index ..fa37d051130b
--- /dev/null
+++ b/drivers/net/phy/b53.c
@@ -0,0 +1,629 @@
+/*
+ * Copyright (C) 2017
+ * Broadcom
+ * Florian Fainelli <f.faine...@gmail.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * PHY driver for Broadcom BCM53xx (roboswitch) Ethernet switches.
+ *
+ * This driver configures the b53 for basic use as a PHY. The switch
+ * supports vendor tags and VLAN configuration that can affect the switching 
decisions.
+ * This driver uses a simple configuration in which all ports are only allowed 
to
+ * send frames to the CPU port and receive frames from the CPU port this 
providing
+ * port isolation (no cross talk).
+ *
+ * The configuration determines which PHY ports to activate using the
+ * CONFIG_B53_PHY_PORTS bitmask. Set bit N will active port N and so on.
+ *
+ * This driver was written primarily for the Lamobo R1 platform using a 
BCM53152
+ * switch but the BCM53xx being largely register compatible, extending it to 
cover
+ * other switches would be trivial.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Pseudo-PHY address (non configurable) to access internal registers */
+#define BRCM_PSEUDO_PHY_ADDR   30
+
+/* Maximum number of ports possible */
+#define B53_N_PORTS9
+
+#define B53_CTRL_PAGE  0x00 /* Control */
+#define B53_MGMT_PAGE  0x02 /* Management Mode */
+/* Port VLAN Page */
+#define B53_PVLAN_PAGE 0x31
+
+/* Control Page registers */
+#define B53_PORT_CTRL(i)   (0x00 + (i))
+#define   PORT_CTRL_RX_DISABLE BIT(0)
+#define   PORT_CTRL_TX_DISABLE BIT(1)
+#define   PORT_CTRL_RX_BCST_EN BIT(2) /* Broadcast RX (P8 only) */
+#define   PORT_CTRL_RX_MCST_EN BIT(3) /* Multicast RX (P8 only) */
+#define   PORT_CTRL_RX_UCST_EN BIT(4) /* Unicast RX (P8 only) */
+
+/* Switch Mode Control Register (8 bit) */
+#define B53_SWITCH_MODE0x0b
+#define   SM_SW_FWD_MODE   BIT(0)  /* 1 = Managed Mode */
+#define   SM_SW_FWD_EN BIT(1)  /* Forwarding Enable */
+
+/* IMP Port state override register (8 bit) */
+#define B53_PORT_OVERRIDE_CTRL 0x0e
+#define   PORT_OVERRIDE_LINK   BIT(0)
+#define   PORT_OVERRIDE_FULL_DUPLEXBIT(1) /* 0 = Half Duplex */
+#define   PORT_OVERRIDE_SPEED_S2
+#define   PORT_OVERRIDE_SPEED_10M  (0 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_SPEED_100M (1 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_SPEED_1000M(2 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_RV_MII_25  BIT(4) /* BCM5325 only */
+#define   PORT_OVERRIDE_RX_FLOWBIT(4)
+#define   PORT_OVERRIDE_TX_FLOWBIT(5)
+#define   PORT_OVERRIDE_SPEED_2000MBIT(6) /* BCM5301X only, requires 
setting 1000M */
+#define   PORT_OVERRIDE_EN BIT(7) /* Use the register contents */
+
+#define B53_RGMII_CTRL_IMP 0x60
+#define   RGMII_CTRL_ENABLE_GMII   BIT(7)
+#define   RGMII_CTRL_TIMING_SELBIT(2)
+#define   RGMII_CTRL_DLL_RXC   BIT(1)
+#define   RGMII_

[U-Boot] [PATCH 0/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

(this time after subscribing to the list)

Hi all,

This patch series adds support for the Broadcom BCM53xx switches, in particular
BCM53125 which is found no the Lamobo R1 board.

The driver is largely based on the DSA/b53 driver Linux driver and only
incorporates what is necessary to succesfully bring-up all ports (including the
management port) for boot over the network:

=> dhcp
dw_adjust_link: Speed: 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.0.11 (3 ms)
Using ethernet@01c5 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.11
Filename 'sun7i-a20-lamobo-r1-kernel.bin'.
Load address: 0x4200
Loading: #
 #
 
 11.6 MiB/s
done
Bytes transferred = 2371552 (242fe0 hex)
=> 


Florian Fainelli (4):
  net: phy: Add Broadcom BCM53xx switch driver
  net: designware: Pad small packets
  net: phy: b53: Add b53_reg read/write commands
  configs: Update Lamobo_R1 with B53 switch options

 configs/Lamobo_R1_defconfig |   3 +
 drivers/net/designware.c|   4 +
 drivers/net/phy/Kconfig |  14 +
 drivers/net/phy/Makefile|   1 +
 drivers/net/phy/b53.c   | 767 
 drivers/net/phy/phy.c   |   3 +
 include/phy.h   |   1 +
 7 files changed, 793 insertions(+)
 create mode 100644 drivers/net/phy/b53.c

-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 4/4] configs: Update Lamobo_R1 with B53 switch options

[Florian Fainelli]

Enable CONFIG_B53_SWITCH, define the CPU/management port number (8) and
enable all 5 ports of the switch to be usable.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 configs/Lamobo_R1_defconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/configs/Lamobo_R1_defconfig b/configs/Lamobo_R1_defconfig
index 84007ad374b8..19c977ef42ee 100644
--- a/configs/Lamobo_R1_defconfig
+++ b/configs/Lamobo_R1_defconfig
@@ -22,3 +22,6 @@ CONFIG_SUN7I_GMAC=y
 CONFIG_SCSI=y
 CONFIG_USB_EHCI_HCD=y
 CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
+CONFIG_B53_SWITCH=y
+CONFIG_B53_CPU_PORT=8
+CONFIG_B53_PHY_PORTS=0x1f
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 2/4] net: designware: Pad small packets

[Florian Fainelli]

Make sure that we pad small packets to a minimum length of 60 bytes
(without FCS). This is necessary to interface with Ethernet switches
that will reject RUNT frames unless padded correctly.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/designware.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/designware.c b/drivers/net/designware.c
index 036d231071ca..10356a9abd0e 100644
--- a/drivers/net/designware.c
+++ b/drivers/net/designware.c
@@ -343,6 +343,8 @@ int designware_eth_enable(struct dw_eth_dev *priv)
return 0;
 }
 
+#define ETH_ZLEN   60
+
 static int _dw_eth_send(struct dw_eth_dev *priv, void *packet, int length)
 {
struct eth_dma_regs *dma_p = priv->dma_regs_p;
@@ -369,6 +371,8 @@ static int _dw_eth_send(struct dw_eth_dev *priv, void 
*packet, int length)
return -EPERM;
}
 
+   length = (length < ETH_ZLEN) ? ETH_ZLEN : length;
+
memcpy((void *)data_start, packet, length);
 
/* Flush data to be sent */
-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

Add a minimalistic Broadcom BCM53xx (roboswitch) switch driver similar
to the Marvell MV88E617x. This takes care of configuring the minimum
amount out of the switch hardware such that each user visible port
(configurable) and the CPU port can forward packets between each other
while preserving isolation with other ports.

This is useful for e.g: the Lamobo R1 board featuring a Broadcom
BCM53125 switch.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/phy/Kconfig  |  14 ++
 drivers/net/phy/Makefile |   1 +
 drivers/net/phy/b53.c| 629 +++
 drivers/net/phy/phy.c|   3 +
 include/phy.h|   1 +
 5 files changed, 648 insertions(+)
 create mode 100644 drivers/net/phy/b53.c

diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 4d02d8bb19a9..e4c4039ff0a4 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -12,6 +12,20 @@ menuconfig PHYLIB
 
 if PHYLIB
 
+config B53_SWITCH
+   bool "Broadcom BCM53xx (roboswitch) Ethernet switch PHY support."
+
+if B53_SWITCH
+
+config B53_CPU_PORT
+   int "CPU port"
+   default 8
+
+config B53_PHY_PORTS
+   hex "Bitmask of PHY ports"
+
+endif # B53_SWITCH
+
 config MV88E61XX_SWITCH
bool "Marvel MV88E61xx Ethernet switch PHY support."
 
diff --git a/drivers/net/phy/Makefile b/drivers/net/phy/Makefile
index 54f32f606be3..b30e6496063a 100644
--- a/drivers/net/phy/Makefile
+++ b/drivers/net/phy/Makefile
@@ -6,6 +6,7 @@
 #
 
 obj-$(CONFIG_BITBANGMII) += miiphybb.o
+obj-$(CONFIG_B53_SWITCH) += b53.o
 obj-$(CONFIG_MV88E61XX_SWITCH) += mv88e61xx.o
 obj-$(CONFIG_MV88E6352_SWITCH) += mv88e6352.o
 
diff --git a/drivers/net/phy/b53.c b/drivers/net/phy/b53.c
new file mode 100644
index ..fa37d051130b
--- /dev/null
+++ b/drivers/net/phy/b53.c
@@ -0,0 +1,629 @@
+/*
+ * Copyright (C) 2017
+ * Broadcom
+ * Florian Fainelli <f.faine...@gmail.com>
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+/*
+ * PHY driver for Broadcom BCM53xx (roboswitch) Ethernet switches.
+ *
+ * This driver configures the b53 for basic use as a PHY. The switch
+ * supports vendor tags and VLAN configuration that can affect the switching 
decisions.
+ * This driver uses a simple configuration in which all ports are only allowed 
to
+ * send frames to the CPU port and receive frames from the CPU port this 
providing
+ * port isolation (no cross talk).
+ *
+ * The configuration determines which PHY ports to activate using the
+ * CONFIG_B53_PHY_PORTS bitmask. Set bit N will active port N and so on.
+ *
+ * This driver was written primarily for the Lamobo R1 platform using a 
BCM53152
+ * switch but the BCM53xx being largely register compatible, extending it to 
cover
+ * other switches would be trivial.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+/* Pseudo-PHY address (non configurable) to access internal registers */
+#define BRCM_PSEUDO_PHY_ADDR   30
+
+/* Maximum number of ports possible */
+#define B53_N_PORTS9
+
+#define B53_CTRL_PAGE  0x00 /* Control */
+#define B53_MGMT_PAGE  0x02 /* Management Mode */
+/* Port VLAN Page */
+#define B53_PVLAN_PAGE 0x31
+
+/* Control Page registers */
+#define B53_PORT_CTRL(i)   (0x00 + (i))
+#define   PORT_CTRL_RX_DISABLE BIT(0)
+#define   PORT_CTRL_TX_DISABLE BIT(1)
+#define   PORT_CTRL_RX_BCST_EN BIT(2) /* Broadcast RX (P8 only) */
+#define   PORT_CTRL_RX_MCST_EN BIT(3) /* Multicast RX (P8 only) */
+#define   PORT_CTRL_RX_UCST_EN BIT(4) /* Unicast RX (P8 only) */
+
+/* Switch Mode Control Register (8 bit) */
+#define B53_SWITCH_MODE0x0b
+#define   SM_SW_FWD_MODE   BIT(0)  /* 1 = Managed Mode */
+#define   SM_SW_FWD_EN BIT(1)  /* Forwarding Enable */
+
+/* IMP Port state override register (8 bit) */
+#define B53_PORT_OVERRIDE_CTRL 0x0e
+#define   PORT_OVERRIDE_LINK   BIT(0)
+#define   PORT_OVERRIDE_FULL_DUPLEXBIT(1) /* 0 = Half Duplex */
+#define   PORT_OVERRIDE_SPEED_S2
+#define   PORT_OVERRIDE_SPEED_10M  (0 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_SPEED_100M (1 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_SPEED_1000M(2 << PORT_OVERRIDE_SPEED_S)
+#define   PORT_OVERRIDE_RV_MII_25  BIT(4) /* BCM5325 only */
+#define   PORT_OVERRIDE_RX_FLOWBIT(4)
+#define   PORT_OVERRIDE_TX_FLOWBIT(5)
+#define   PORT_OVERRIDE_SPEED_2000MBIT(6) /* BCM5301X only, requires 
setting 1000M */
+#define   PORT_OVERRIDE_EN BIT(7) /* Use the register contents */
+
+#define B53_RGMII_CTRL_IMP 0x60
+#define   RGMII_CTRL_ENABLE_GMII   BIT(7)
+#define   RGMII_CTRL_TIMING_SELBIT(2)
+#define   RGMII_CTRL_DLL_RXC   BIT(1)
+#define   RGMII_

[U-Boot] [PATCH 3/4] net: phy: b53: Add b53_reg read/write commands

[Florian Fainelli]

Add a b53_reg read/write command which allows inspecting the switch
registers. Because the Broadcom BCM53xx registers have different sizes,
we need to split the accesses in 8, 16, 32, 48 or 64 bits to obtain
expected results.

Signed-off-by: Florian Fainelli <f.faine...@gmail.com>
---
 drivers/net/phy/b53.c | 138 ++
 1 file changed, 138 insertions(+)

diff --git a/drivers/net/phy/b53.c b/drivers/net/phy/b53.c
index fa37d051130b..a68d2ae39fa9 100644
--- a/drivers/net/phy/b53.c
+++ b/drivers/net/phy/b53.c
@@ -627,3 +627,141 @@ int phy_b53_init(void)
 
return 0;
 }
+
+int do_b53_reg_read(const char *name, int argc, char * const argv[])
+{
+   u8 page, offset, width;
+   struct mii_dev *bus;
+   int ret = -EINVAL;
+   u64 value64 = 0;
+   u32 value32 = 0;
+   u16 value16 = 0;
+   u8 value8 = 0;
+
+   bus = miiphy_get_dev_by_name(name);
+   if (!bus) {
+   printf("unable to find MDIO bus: %s\n", name);
+   return ret;
+   }
+
+   page = simple_strtoul(argv[1], NULL, 16);
+   offset = simple_strtoul(argv[2], NULL, 16);
+   width = simple_strtoul(argv[3], NULL, 10);
+
+   switch (width) {
+   case 8:
+   ret = b53_mdio_read8(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%02x\n",
+   page, offset, value8);
+   break;
+   case 16:
+   ret = b53_mdio_read16(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%04x\n",
+   page, offset, value16);
+   break;
+   case 32:
+   ret = b53_mdio_read32(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%08x\n",
+   page, offset, value32);
+   break;
+   case 48:
+   ret = b53_mdio_read48(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%012llx\n",
+   page, offset, value64);
+   break;
+   case 64:
+   ret = b53_mdio_read48(bus, page, offset, );
+   printf("page=0x%02x, offset=0x%02x, value=0x%016llx\n",
+   page, offset, value64);
+   break;
+   default:
+   printf("Unsupported width: %d\n", width);
+   break;
+   }
+
+   return ret;
+}
+
+int do_b53_reg_write(const char *name, int argc, char * const argv[])
+{
+   u8 page, offset, width;
+   struct mii_dev *bus;
+   int ret = -EINVAL;
+   u64 value64 = 0;
+   u32 value = 0;
+
+   bus = miiphy_get_dev_by_name(name);
+   if (!bus) {
+   printf("unable to find MDIO bus: %s\n", name);
+   return ret;
+   }
+
+   page = simple_strtoul(argv[1], NULL, 16);
+   offset = simple_strtoul(argv[2], NULL, 16);
+   width = simple_strtoul(argv[3], NULL, 10);
+   if (width == 48 || width == 64)
+   value64 = simple_strtoull(argv[4], NULL, 16);
+   else
+   value = simple_strtoul(argv[4], NULL, 16);
+
+   switch (width) {
+   case 8:
+   ret = b53_mdio_write8(bus, page, offset, value & 0xff);
+   break;
+   case 16:
+   ret = b53_mdio_write16(bus, page, offset, value);
+   break;
+   case 32:
+   ret = b53_mdio_write32(bus, page, offset, value);
+   break;
+   case 48:
+   ret = b53_mdio_write48(bus, page, offset, value64);
+   break;
+   case 64:
+   ret = b53_mdio_write64(bus, page, offset, value64);
+   break;
+   default:
+   printf("Unsupported width: %d\n", width);
+   break;
+   }
+
+   return ret;
+}
+
+int do_b53_reg(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
+{
+   const char *cmd, *mdioname;
+   int ret = 0;
+
+   if (argc < 2)
+   return cmd_usage(cmdtp);
+
+   cmd = argv[1];
+   --argc;
+   ++argv;
+
+   if (!strcmp(cmd, "write")) {
+   if (argc < 4)
+   return cmd_usage(cmdtp);
+   mdioname = argv[1];
+   --argc;
+   ++argv;
+   ret = do_b53_reg_write(mdioname, argc, argv);
+   } else if (!strcmp(cmd, "read")) {
+   if (argc < 5)
+   return cmd_usage(cmdtp);
+   mdioname = argv[1];
+   --argc;
+   ++argv;
+   ret = do_b53_reg_read(mdioname, argc, argv);
+   } else
+   return cmd_usage(cmdtp);
+
+   return ret;
+}
+
+U_BOOT_CMD(b53_reg, 7, 1, do_b53_reg,
+  "Broadcom B53 switch register access",
+  "write mdio

[U-Boot] [PATCH 0/4] net: phy: Add Broadcom BCM53xx switch driver

[Florian Fainelli]

(not subscribed to u-boot, please CC me while replying)

Hi all,

This patch series adds support for the Broadcom BCM53xx switches, in particular
BCM53125 which is found no the Lamobo R1 board.

The driver is largely based on the DSA/b53 driver Linux driver and only
incorporates what is necessary to succesfully bring-up all ports (including the
management port) for boot over the network:

=> dhcp
dw_adjust_link: Speed: 1000, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.0.11 (3 ms)
Using ethernet@01c5 device
TFTP from server 192.168.0.1; our IP address is 192.168.0.11
Filename 'sun7i-a20-lamobo-r1-kernel.bin'.
Load address: 0x4200
Loading: #
 #
 
 11.6 MiB/s
done
Bytes transferred = 2371552 (242fe0 hex)
=> 


Florian Fainelli (4):
  net: phy: Add Broadcom BCM53xx switch driver
  net: designware: Pad small packets
  net: phy: b53: Add b53_reg read/write commands
  configs: Update Lamobo_R1 with B53 switch options

 configs/Lamobo_R1_defconfig |   3 +
 drivers/net/designware.c|   4 +
 drivers/net/phy/Kconfig |  14 +
 drivers/net/phy/Makefile|   1 +
 drivers/net/phy/b53.c   | 767 
 drivers/net/phy/phy.c   |   3 +
 include/phy.h   |   1 +
 7 files changed, 793 insertions(+)
 create mode 100644 drivers/net/phy/b53.c

-- 
2.11.0

___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] phy: Add phy driver support for xilinx PCS/PMA core

[Florian Fainelli]

On 25/04/16 15:36, Joe Hershberger wrote:
> On Mon, Feb 15, 2016 at 3:54 AM, Michal Simek  wrote:
>> From: Siva Durga Prasad Paladugu 
>>
>> Add phy driver support for xilinx PCS/PMA core
>>
>> Signed-off-by: Siva Durga Prasad Paladugu 
>> Signed-off-by: Kedareswara rao Appana 
>> Signed-off-by: Michal Simek 
>> ---

[snip]

>> +static int xilinxphy_of_init(struct phy_device *phydev)
>> +{
>> +   struct udevice *dev = (struct udevice *)>dev;
>> +   u32 phytype;
>> +
>> +   debug("%s\n", __func__);
>> +   phytype = fdtdec_get_int(gd->fdt_blob, dev->of_offset, "phy-type", 
>> -1);
> 
> Is there a bindings document that can be included to describe this?

If that is meant to be the PHY type (MII, RGMII etc.) the standard
property name is either 'phy-mode' or 'phy-connection-type', the latter
being the one described in ePAPR, while the former has been widely
adopted by Linux nowadays (and other OSes possibly).

My 2 cents since I don't typically review u-boot changes.
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] NAND: Fix integer overflow in ONFI detection of chips = 4GiB

[Florian Fainelli]

From: Florian Fainelli flor...@openwrt.org

This patch sync with David's patch on Linux in nand_flash_detect_onfi()

commit 4ccb3b4497ce01fab4933704fe21581e30fda1a5
Author: David Woodhouse david.woodho...@intel.com
Date:   Fri Dec 3 16:36:34 2010 +

mtd: nand: Fix integer overflow in ONFI detection of chips = 4GiB

Signed-off-by: David Woodhouse david.woodho...@intel.com

Signed-off-by: Florian Fainelli flor...@openwrt.org
---
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index fa286a8..3cb92c1 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2482,7 +2482,7 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd,
mtd-writesize = le32_to_cpu(p-byte_per_page);
mtd-erasesize = le32_to_cpu(p-pages_per_block) * mtd-writesize;
mtd-oobsize = le16_to_cpu(p-spare_bytes_per_page);
-   chip-chipsize = le32_to_cpu(p-blocks_per_lun) * mtd-erasesize;
+   chip-chipsize = (uint64_t)le32_to_cpu(p-blocks_per_lun) * 
mtd-erasesize;
*busw = 0;
if (le16_to_cpu(p-features)  1)
*busw = NAND_BUSWIDTH_16;
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] NAND: rearrange ONFI revision checking, add ONFI 2.3

[Florian Fainelli]

From: Florian Fainelli flor...@openwrt.org

This patch sync with Brian's patch on Linux in nand_flash_detect_onfi()

commit b7b1a29d94c17e4341856381bccb4d17495bea60
Author: Brian Norris computersforpe...@gmail.com
Date:   Sun Dec 12 00:23:33 2010 -0800

mtd: nand: rearrange ONFI revision checking, add ONFI 2.3

In checking for the ONFI revision, the first conditional (for 
checking
unsupported ONFI) seems unnecessary.  All ONFI revisions should be
backwards-compatible; even if this is not the case on some newer 
ONFI
revision, it should simply fail the second version-checking if-else 
block
(i.e., the bit-fields for 1.0, 2.0, etc. would not be set to 1). 
Thus, we
move our unsupported condition after having checked each bit 
field.

Also, it's simple enough to add a condition for ONFI revision 2.3. 
Note
that this does *NOT* mean we handle all new features of ONFI 
versions
above 1.0.

Signed-off-by: Brian Norris computersforpe...@gmail.com
Acked-by: Florian Fainelli ffaine...@freebox.fr
Signed-off-by: David Woodhouse david.woodho...@intel.com

Signed-off-by: Florian Fainelli flor...@openwrt.org
---
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 3cb92c1..52f8575 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2461,20 +2461,24 @@ static int nand_flash_detect_onfi(struct mtd_info *mtd,
 
/* check version */
val = le16_to_cpu(p-revision);
-   if (val == 1 || val  (1  4)) {
-   printk(KERN_INFO %s: unsupported ONFI 
-   version: %d\n, __func__, val);
-   return 0;
-   }
-
-   if (val  (1  4))
+   if (val  (1  5))
+   chip-onfi_version = 23;
+   else if (val  (1  4))
chip-onfi_version = 22;
else if (val  (1  3))
chip-onfi_version = 21;
else if (val  (1  2))
chip-onfi_version = 20;
-   else
+   else if (val  (1  1))
chip-onfi_version = 10;
+   else
+   chip-onfi_version = 0;
+
+   if (!chip-onfi_version) {
+   printk(KERN_INFO %s: unsupported ONFI 
+   version: %d\n, __func__, val);
+   return 0;
+   }
 
if (!mtd-name)
mtd-name = p-model;
-- 
1.7.1

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [U-Boot, v4] NAND: add support for reading ONFI page table

[Florian Fainelli]

Le jeudi 17 mars 2011 00:42:55, Scott Wood a écrit :
 On Fri, Feb 25, 2011 at 12:01:34AM -, Florian Fainelli wrote:
  From: Florian Fainelli flor...@openwrt.org
  
  This patch adds support for reading an ONFI page parameter from a NAND
  device supporting it. If this is the case, struct nand_chip onfi_version
  member contains the supported ONFI version, 0 otherwise.
  
  This allows NAND drivers past nand_scan_ident to set the best timings for
  the NAND chip.
  
  Signed-off-by: Florian Fainelli flor...@openwrt.org
 
 Applied to u-boot-nand-flash next with this change:
 
 diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
 index 0d7c819..fa286a8 100644
 --- a/drivers/mtd/nand/nand_base.c
 +++ b/drivers/mtd/nand/nand_base.c
 @@ -2585,7 +2585,7 @@ static const struct nand_flash_dev
 *nand_get_flash_type(st type = nand_flash_ids;
 
 for (; type-name != NULL; type++)
 -   if (dev_id == type-id)
 +   if (*dev_id == type-id)
 break;

My bad, thanks for fixing this and committing the patch!
--
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] NAND: add support for reading ONFI page table

[Florian Fainelli]

Hello Scott,

(sorry for the lag in answering)

On Tuesday 15 February 2011 00:46:07 Scott Wood wrote:
 On Mon, 14 Feb 2011 16:48:01 +0100
 
 Florian Fainelli flor...@openwrt.org wrote:
  From: Florian Fainelli flor...@openwrt.org
  
  This patch adds support for reading an ONFI page parameter from a NAND
  device supporting it. If this is the case, struct nand_chip onfi_version
  member contains the supported ONFI version, 0 otherwise.
  
  This allows NAND drivers past nand_scan_ident to set the best timings for
  the NAND chip.
  
  Signed-off-by: Florian Fainelli flor...@openwrt.org
  ---
  Patch against your 'next' branch
 
 The 'next' branch is old, since I haven't pushed anything to it yet this
 cycle.  Base it on Wolfgang's 'next'.
 
  Changes since v1:
  - ifdef out ONFI detection code around CONFIG_SYS_NAND_ONFI_DETECTION
  - removed bogus comment
  - fixed busw variable usage
  - move non-ONFI detection code to its own function
  - fixed stylistic issues spotted by Scott
  
  Changes since v2:
  - reduce lenght of some lines down to 80 columns
  - change chip-options consistently wrt to ONFI detected or not
  - removed extra spaces
  
  diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
  index 5239c1f..7becb99 100644
  --- a/drivers/mtd/nand/nand_base.c
  +++ b/drivers/mtd/nand/nand_base.c
  @@ -2409,15 +2409,137 @@ static void nand_set_defaults(struct nand_chip
  *chip, int busw)
  
  chip-controller = chip-hwcontrol;
   
   }
  
  +#ifdef CONFIG_SYS_NAND_ONFI_DETECTION
  +static u16 onfi_crc16(u16 crc, u8 const *p, size_t len)
  +{
  +   int i;
  +
  +   while (len--) {
  +   crc ^= *p++  8;
  +   for (i = 0; i  8; i++)
  +   crc = (crc  1) ^ ((crc  0x8000) ? 0x8005 : 0);
  +   }
  +
  +   return crc;
  +}
 
 Is this different from what's in lib/crc16.c (other than appearing to have
 made a different speed/size tradeoff)?

Yes it is a different version of the CRC16 function.

 
  +#define ONFI_CRC_BASE  0x4F4E
 
 Is this ONFI-specific, or standard for crc16?
 
  +
  +/*
  + * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0
  otherwise + */
  +static int nand_flash_detect_onfi(struct mtd_info *mtd,
  +   struct nand_chip *chip,
  +   int *busw)
  +{
 
 [snip]
 
  +   chip-options = ~NAND_CHIPOPTIONS_MSK;
  +   chip-options |= NAND_NO_READRDY  NAND_CHIPOPTIONS_MSK;
 
 Won't this get overwritten by this later?

It will, thanks for spotting.
--
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4] NAND: add support for reading ONFI page table

[Florian Fainelli]

From: Florian Fainelli flor...@openwrt.org

This patch adds support for reading an ONFI page parameter from a NAND
device supporting it. If this is the case, struct nand_chip onfi_version
member contains the supported ONFI version, 0 otherwise.

This allows NAND drivers past nand_scan_ident to set the best timings for the
NAND chip.

Signed-off-by: Florian Fainelli flor...@openwrt.org
---
Patch against your 'master' branch

Changes since v1:
- ifdef out ONFI detection code around CONFIG_SYS_NAND_ONFI_DETECTION
- removed bogus comment
- fixed busw variable usage
- move non-ONFI detection code to its own function
- fixed stylistic issues spotted by Scott

Changes since v2:
- reduce lenght of some lines down to 80 columns
- change chip-options consistently wrt to ONFI detected or not
- removed extra spaces

Changes since v3:
- removed chip-options modification in nand_flash_detect_onfi because it is
  overwritten in nand_flash_detect() later

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 70c0593..9034945 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2409,15 +2409,134 @@ static void nand_set_defaults(struct nand_chip *chip, 
int busw)
chip-controller = chip-hwcontrol;
 }

+#ifdef CONFIG_SYS_NAND_ONFI_DETECTION
+static u16 onfi_crc16(u16 crc, u8 const *p, size_t len)
+{
+   int i;
+
+   while (len--) {
+   crc ^= *p++  8;
+   for (i = 0; i  8; i++)
+   crc = (crc  1) ^ ((crc  0x8000) ? 0x8005 : 0);
+   }
+
+   return crc;
+}
+
+/*
+ * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise
+ */
+static int nand_flash_detect_onfi(struct mtd_info *mtd,
+   struct nand_chip *chip,
+   int *busw)
+{
+   struct nand_onfi_params *p = chip-onfi_params;
+   int i;
+   int val;
+
+   chip-cmdfunc(mtd, NAND_CMD_READID, 0x20, -1);
+   if (chip-read_byte(mtd) != 'O' || chip-read_byte(mtd) != 'N' ||
+   chip-read_byte(mtd) != 'F' || chip-read_byte(mtd) != 'I')
+   return 0;
+
+   printk(KERN_INFO ONFI flash detected\n);
+   chip-cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
+   for (i = 0; i  3; i++) {
+   chip-read_buf(mtd, (uint8_t *)p, sizeof(*p));
+   if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
+   le16_to_cpu(p-crc)) {
+   printk(KERN_INFO ONFI param page %d valid\n, i);
+   break;
+   }
+   }
+
+   if (i == 3)
+   return 0;
+
+   /* check version */
+   val = le16_to_cpu(p-revision);
+   if (val == 1 || val  (1  4)) {
+   printk(KERN_INFO %s: unsupported ONFI 
+   version: %d\n, __func__, val);
+   return 0;
+   }
+
+   if (val  (1  4))
+   chip-onfi_version = 22;
+   else if (val  (1  3))
+   chip-onfi_version = 21;
+   else if (val  (1  2))
+   chip-onfi_version = 20;
+   else
+   chip-onfi_version = 10;
+
+   if (!mtd-name)
+   mtd-name = p-model;
+
+   mtd-writesize = le32_to_cpu(p-byte_per_page);
+   mtd-erasesize = le32_to_cpu(p-pages_per_block) * mtd-writesize;
+   mtd-oobsize = le16_to_cpu(p-spare_bytes_per_page);
+   chip-chipsize = le32_to_cpu(p-blocks_per_lun) * mtd-erasesize;
+   *busw = 0;
+   if (le16_to_cpu(p-features)  1)
+   *busw = NAND_BUSWIDTH_16;
+
+   return 1;
+}
+#else
+static inline int nand_flash_detect_onfi(struct mtd_info *mtd,
+   struct nand_chip *chip,
+   int *busw)
+{
+   return 0;
+}
+#endif
+
+static void nand_flash_detect_non_onfi(struct mtd_info *mtd,
+   struct nand_chip *chip,
+   const struct nand_flash_dev *type,
+   int *busw)
+{
+   /* Newer devices have all the information in additional id bytes */
+   if (!type-pagesize) {
+   int extid;
+   /* The 3rd id byte holds MLC / multichip data */
+   chip-cellinfo = chip-read_byte(mtd);
+   /* The 4th id byte is the important one */
+   extid = chip-read_byte(mtd);
+   /* Calc pagesize */
+   mtd-writesize = 1024  (extid  0x3);
+   extid = 2;
+   /* Calc oobsize */
+   mtd-oobsize = (8  (extid  0x01)) * (mtd-writesize  9);
+   extid = 2;
+   /* Calc blocksize. Blocksize is multiples of 64KiB */
+   mtd-erasesize = (64 * 1024)  (extid  0x03);
+   extid = 2;
+   /* Get buswidth information */
+   *busw = (extid  0x01) ? NAND_BUSWIDTH_16 : 0

[U-Boot] [PATCH v3] NAND: add support for reading ONFI page table

[Florian Fainelli]

From: Florian Fainelli flor...@openwrt.org

This patch adds support for reading an ONFI page parameter from a NAND
device supporting it. If this is the case, struct nand_chip onfi_version
member contains the supported ONFI version, 0 otherwise.

This allows NAND drivers past nand_scan_ident to set the best timings for the
NAND chip.

Signed-off-by: Florian Fainelli flor...@openwrt.org
---
Patch against your 'next' branch

Changes since v1:
- ifdef out ONFI detection code around CONFIG_SYS_NAND_ONFI_DETECTION
- removed bogus comment
- fixed busw variable usage
- move non-ONFI detection code to its own function
- fixed stylistic issues spotted by Scott

Changes since v2:
- reduce lenght of some lines down to 80 columns
- change chip-options consistently wrt to ONFI detected or not
- removed extra spaces

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 5239c1f..7becb99 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2409,15 +2409,137 @@ static void nand_set_defaults(struct nand_chip *chip, 
int busw)
chip-controller = chip-hwcontrol;
 }

+#ifdef CONFIG_SYS_NAND_ONFI_DETECTION
+static u16 onfi_crc16(u16 crc, u8 const *p, size_t len)
+{
+   int i;
+
+   while (len--) {
+   crc ^= *p++  8;
+   for (i = 0; i  8; i++)
+   crc = (crc  1) ^ ((crc  0x8000) ? 0x8005 : 0);
+   }
+
+   return crc;
+}
+
+/*
+ * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise
+ */
+static int nand_flash_detect_onfi(struct mtd_info *mtd,
+   struct nand_chip *chip,
+   int *busw)
+{
+   struct nand_onfi_params *p = chip-onfi_params;
+   int i;
+   int val;
+
+   chip-cmdfunc(mtd, NAND_CMD_READID, 0x20, -1);
+   if (chip-read_byte(mtd) != 'O' || chip-read_byte(mtd) != 'N' ||
+   chip-read_byte(mtd) != 'F' || chip-read_byte(mtd) != 'I')
+   return 0;
+
+   printk(KERN_INFO ONFI flash detected\n);
+   chip-cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
+   for (i = 0; i  3; i++) {
+   chip-read_buf(mtd, (uint8_t *)p, sizeof(*p));
+   if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
+   le16_to_cpu(p-crc)) {
+   printk(KERN_INFO ONFI param page %d valid\n, i);
+   break;
+   }
+   }
+
+   if (i == 3)
+   return 0;
+
+   /* check version */
+   val = le16_to_cpu(p-revision);
+   if (val == 1 || val  (1  4)) {
+   printk(KERN_INFO %s: unsupported ONFI 
+   version: %d\n, __func__, val);
+   return 0;
+   }
+
+   if (val  (1  4))
+   chip-onfi_version = 22;
+   else if (val  (1  3))
+   chip-onfi_version = 21;
+   else if (val  (1  2))
+   chip-onfi_version = 20;
+   else
+   chip-onfi_version = 10;
+
+   if (!mtd-name)
+   mtd-name = p-model;
+
+   mtd-writesize = le32_to_cpu(p-byte_per_page);
+   mtd-erasesize = le32_to_cpu(p-pages_per_block) * mtd-writesize;
+   mtd-oobsize = le16_to_cpu(p-spare_bytes_per_page);
+   chip-chipsize = le32_to_cpu(p-blocks_per_lun) * mtd-erasesize;
+   *busw = 0;
+   if (le16_to_cpu(p-features)  1)
+   *busw = NAND_BUSWIDTH_16;
+
+   chip-options = ~NAND_CHIPOPTIONS_MSK;
+   chip-options |= NAND_NO_READRDY  NAND_CHIPOPTIONS_MSK;
+
+   return 1;
+}
+#else
+static inline int nand_flash_detect_onfi(struct mtd_info *mtd,
+   struct nand_chip *chip,
+   int *busw)
+{
+   return 0;
+}
+#endif
+
+static void nand_flash_detect_non_onfi(struct mtd_info *mtd,
+   struct nand_chip *chip,
+   const struct nand_flash_dev *type,
+   int *busw)
+{
+   /* Newer devices have all the information in additional id bytes */
+   if (!type-pagesize) {
+   int extid;
+   /* The 3rd id byte holds MLC / multichip data */
+   chip-cellinfo = chip-read_byte(mtd);
+   /* The 4th id byte is the important one */
+   extid = chip-read_byte(mtd);
+   /* Calc pagesize */
+   mtd-writesize = 1024  (extid  0x3);
+   extid = 2;
+   /* Calc oobsize */
+   mtd-oobsize = (8  (extid  0x01)) * (mtd-writesize  9);
+   extid = 2;
+   /* Calc blocksize. Blocksize is multiples of 64KiB */
+   mtd-erasesize = (64 * 1024)  (extid  0x03);
+   extid = 2;
+   /* Get buswidth information */
+   *busw = (extid  0x01) ? NAND_BUSWIDTH_16 : 0;
+
+   } else

[U-Boot] [PATCH 1/2] NAND: add NAND_CMD_PARAM (0xec) definition

[Florian Fainelli]

From: Florian Fainelli flor...@openwrt.org

This command is used to read the device ONFI parameters page.

Signed-off-by: Florian Fainelli flor...@openwrt.org
---
 include/linux/mtd/nand.h |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index 94ad0c0..7db87e1 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -84,6 +84,7 @@ extern void nand_wait_ready(struct mtd_info *mtd);
 #define NAND_CMD_SEQIN 0x80
 #define NAND_CMD_RNDIN 0x85
 #define NAND_CMD_READID0x90
+#define NAND_CMD_PARAM 0xec
 #define NAND_CMD_ERASE20xd0
 #define NAND_CMD_RESET 0xff
 
-- 
1.7.2.3

___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 2/2] NAND: add support for reading ONFI page table

[Florian Fainelli]

From: Florian Fainelli flor...@openwrt.org

This patch adds support for reading an ONFI page parameter from a NAND device
supporting it. If this is the case, struct nand_chip onfi_version member
contains the supported ONFI version, 0 otherwise.

This allows NAND drivers past nand_scan_ident to set the best timings for the
NAND chip.

Signed-off-by: Florian Fainelli flor...@openwrt.org
---
 drivers/mtd/nand/nand_base.c |  129 ++---
 include/linux/mtd/nand.h |   68 ++
 2 files changed, 175 insertions(+), 22 deletions(-)

diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 21cc5a3..a3a0507 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2406,15 +2406,94 @@ static void nand_set_defaults(struct nand_chip *chip, 
int busw)
chip-controller = chip-hwcontrol;
 }
 
+static u16 onfi_crc16(u16 crc, u8 const *p, size_t len)
+{
+   int i;
+
+   while (len--) {
+   crc ^= *p++  8;
+   for (i = 0; i  8; i++)
+   crc = (crc  1) ^ ((crc  0x8000) ? 0x8005 : 0);
+   }
+
+   return crc;
+}
+
+/*
+ * Check if the NAND chip is ONFI compliant, returns 1 if it is, 0 otherwise
+ */
+static int nand_flash_detect_onfi(struct mtd_info *mtd, struct nand_chip *chip,
+   int busw)
+{
+   struct nand_onfi_params *p = chip-onfi_params;
+   int i;
+   int val;
+
+   /* try ONFI for unknow chip or LP */
+   chip-cmdfunc(mtd, NAND_CMD_READID, 0x20, -1);
+   if (chip-read_byte(mtd) != 'O' || chip-read_byte(mtd) != 'N' ||
+   chip-read_byte(mtd) != 'F' || chip-read_byte(mtd) != 'I')
+   return 0;
+
+   printk(KERN_INFO ONFI flash detected\n);
+   chip-cmdfunc(mtd, NAND_CMD_PARAM, 0, -1);
+   for (i = 0; i  3; i++) {
+   chip-read_buf(mtd, (uint8_t *)p, sizeof(*p));
+   if (onfi_crc16(ONFI_CRC_BASE, (uint8_t *)p, 254) ==
+   le16_to_cpu(p-crc)) {
+   printk(KERN_INFO ONFI param page %d valid\n, i);
+   break;
+   }
+   }
+
+   if (i == 3)
+   return 0;
+
+   /* check version */
+   val = le16_to_cpu(p-revision);
+   if (val == 1 || val  (1  4)) {
+   printk(KERN_INFO %s: unsupported ONFI version: %d\n,
+   __func__, val);
+   return 0;
+   }
+
+   if (val  (1  4))
+   chip-onfi_version = 22;
+   else if (val  (1  3))
+   chip-onfi_version = 21;
+   else if (val  (1  2))
+   chip-onfi_version = 20;
+   else
+   chip-onfi_version = 10;
+
+   if (!mtd-name)
+   mtd-name = p-model;
+
+   mtd-writesize = le32_to_cpu(p-byte_per_page);
+   mtd-erasesize = le32_to_cpu(p-pages_per_block) * mtd-writesize;
+   mtd-oobsize = le16_to_cpu(p-spare_bytes_per_page);
+   chip-chipsize = le32_to_cpu(p-blocks_per_lun) * mtd-erasesize;
+   busw = 0;
+   if (le16_to_cpu(p-features)  1)
+   busw = NAND_BUSWIDTH_16;
+
+   chip-options = ~NAND_CHIPOPTIONS_MSK;
+   chip-options |= (NAND_NO_READRDY |
+   NAND_NO_AUTOINCR)  NAND_CHIPOPTIONS_MSK;
+
+   return 1;
+}
+
 /*
  * Get the flash and manufacturer id and lookup if the type is supported
  */
 static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
  struct nand_chip *chip,
- int busw, int *maf_id)
+ int busw,
+ int *maf_id, int *dev_id)
 {
struct nand_flash_dev *type = NULL;
-   int i, dev_id, maf_idx;
+   int i, ret, maf_idx;
int tmp_id, tmp_manf;
 
/* Select the device */
@@ -2431,7 +2510,7 @@ static struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
 
/* Read manufacturer and device IDs */
*maf_id = chip-read_byte(mtd);
-   dev_id = chip-read_byte(mtd);
+   *dev_id = chip-read_byte(mtd);
 
/* Try again to make sure, as some systems the bus-hold or other
 * interface concerns can cause random data which looks like a
@@ -2446,16 +2525,16 @@ static struct nand_flash_dev 
*nand_get_flash_type(struct mtd_info *mtd,
tmp_manf = chip-read_byte(mtd);
tmp_id = chip-read_byte(mtd);
 
-   if (tmp_manf != *maf_id || tmp_id != dev_id) {
+   if (tmp_manf != *maf_id || tmp_id != *dev_id) {
printk(KERN_INFO %s: second ID read did not match 
   %02x,%02x against %02x,%02x\n, __func__,
-  *maf_id, dev_id, tmp_manf, tmp_id);
+  *maf_id, *dev_id, tmp_manf

[U-Boot] [PATCH v2] ehci-pci: print hccr, hcor and hc_lenght

[Florian Fainelli]

It is useful to know the EHCI-PCI hccr, hcor and hc_lenght to make sure it was
successfully registered, and at the correct location.

Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
Changes since v1:
- replaced printf by debug

diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 047902a..cff3438 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -53,6 +53,10 @@ int ehci_hcd_init(void)
hcor = (struct ehci_hcor *)((uint32_t) hccr +
HC_LENGTH(ehci_readl(hccr-cr_capbase)));
 
+   debug(EHCI-PCI init hccr 0x%x and hcor 0x%x hc_length %d\n,
+   (uint32_t)hccr, (uint32_t)hcor,
+   (uint32_t)HC_LENGTH(ehci_readl(hccr-cr_capbase)));
+
return 0;
 }
 


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ehci-pci: print hccr, hcor and hc_lenght

[Florian Fainelli]

Hi Remy,

Le Sunday 12 September 2010 12:01:18, Remy Bohmer a écrit :
 Hi Florian,
 
 2010/4/23 Florian Fainelli f.faine...@gmail.com:
  It is useful to know the EHCI-PCI hccr, hcor and hc_lenght to make sure
  it was successfully registered, and at the correct location.
  
  Signed-off-by: Florian Fainelli f.faine...@gmail.com
  ---
  diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
  index 047902a..4402abb 100644
  --- a/drivers/usb/host/ehci-pci.c
  +++ b/drivers/usb/host/ehci-pci.c
  @@ -53,6 +53,10 @@ int ehci_hcd_init(void)
 hcor = (struct ehci_hcor *)((uint32_t) hccr +
 HC_LENGTH(ehci_readl(hccr-cr_capbase)));
  
  +   printf(EHCI-PCI init hccr 0x%x and hcor 0x%x hc_length %d\n,
  +   (uint32_t)hccr, (uint32_t)hcor,
  +  
  (uint32_t)HC_LENGTH(ehci_readl(hccr-cr_capbase))); +
 
 I guess I missed this patch...

No problem.

 Should the 'printf' not be a 'debug' statement?

I think so, I will respin this patch. Thanks!
-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] NAND: show manufacturer and device ID for unknown chips

[Florian Fainelli]

Hey Scott,

On Wednesday 23 June 2010 23:53:01 Scott Wood wrote:
 From: Florian Fainelli flor...@openwrt.org
 
 When the NAND part is not supported, it is useful to show the manufacturer
 and device ID to help debugging and reporting.
 
 Signed-off-by: Florian Fainelli f.faine...@gmail.com
 Signed-off-by: Scott Wood scottw...@freescale.com
 ---
 Whitespace amended to be consistent with rest of file.

Thanks, I was just about to respin it.

 
 Applied to u-boot-nand-flash next.
 
  drivers/mtd/nand/nand_base.c |6 +-
  1 files changed, 5 insertions(+), 1 deletions(-)
 
 diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
 index 7171bdd..ed1c9c9 100644
 --- a/drivers/mtd/nand/nand_base.c
 +++ b/drivers/mtd/nand/nand_base.c
 @@ -2652,8 +2652,12 @@ static struct nand_flash_dev
 *nand_get_flash_type(struct mtd_info *mtd, }
   }
 
 - if (!type)
 + if (!type) {
 + printk(KERN_INFO %s: unknown NAND device: Manufacturer ID:
 + 0x%02x, Chip ID: 0x%02x\n, __func__,
 +*maf_id, dev_id);
   return ERR_PTR(-ENODEV);
 + }
 
   if (!mtd-name)
   mtd-name = type-name;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] NAND: show manufacturer and device ID for unknown chips

[Florian Fainelli]

Le Saturday 12 June 2010 20:59:25, Florian Fainelli a écrit :
 When the NAND part is not supported, it is useful to show the manufacturer
 and device ID to help debugging and reporting.
 
 Signed-off-by: Florian Fainelli f.faine...@gmail.com

Scott, anything from with the patch? Thanks!

 ---
 diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
 index 7171bdd..c1657de 100644
 --- a/drivers/mtd/nand/nand_base.c
 +++ b/drivers/mtd/nand/nand_base.c
 @@ -2652,8 +2652,12 @@ static struct nand_flash_dev
 *nand_get_flash_type(struct mtd_info *mtd, }
   }
 
 - if (!type)
 + if (!type) {
 + printk(KERN_INFO %s: unknown NAND device: Manufacturer ID :
 +  0x%02x, Chip ID: 0x%02x\n, __func__,
 + *maf_id, dev_id);
   return ERR_PTR(-ENODEV);
 + }
 
   if (!mtd-name)
   mtd-name = type-name;

-- 
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] NAND: show manufacturer and device ID for unknown chips

[Florian Fainelli]

When the NAND part is not supported, it is useful to show the manufacturer
and device ID to help debugging and reporting.

Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
diff --git a/drivers/mtd/nand/nand_base.c b/drivers/mtd/nand/nand_base.c
index 7171bdd..c1657de 100644
--- a/drivers/mtd/nand/nand_base.c
+++ b/drivers/mtd/nand/nand_base.c
@@ -2652,8 +2652,12 @@ static struct nand_flash_dev *nand_get_flash_type(struct 
mtd_info *mtd,
}
}
 
-   if (!type)
+   if (!type) {
+   printk(KERN_INFO %s: unknown NAND device: Manufacturer ID :
+0x%02x, Chip ID: 0x%02x\n, __func__,
+   *maf_id, dev_id);
return ERR_PTR(-ENODEV);
+   }
 
if (!mtd-name)
mtd-name = type-name;


___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ehci-pci: print hccr, hcor and hc_lenght

[Florian Fainelli]

It is useful to know the EHCI-PCI hccr, hcor and hc_lenght to make sure it was
successfully registered, and at the correct location.

Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index 047902a..4402abb 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -53,6 +53,10 @@ int ehci_hcd_init(void)
hcor = (struct ehci_hcor *)((uint32_t) hccr +
HC_LENGTH(ehci_readl(hccr-cr_capbase)));
 
+   printf(EHCI-PCI init hccr 0x%x and hcor 0x%x hc_length %d\n,
+   (uint32_t)hccr, (uint32_t)hcor,
+   (uint32_t)HC_LENGTH(ehci_readl(hccr-cr_capbase)));
+
return 0;
 }
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] cmd_nand: show nand scrub confirmation character

[Florian Fainelli]

When issuing a nand scrub command, the entered character is not displayed
this may be confusing. This patch makes the input character being displayed
if it is a 'y' so that an user knows he is about to scrub his nand.

Signed-off-by: Florian Fainelli f.faine...@gmail.com
---
diff --git a/common/cmd_nand.c b/common/cmd_nand.c
index 075a8af..69cc0a8 100644
--- a/common/cmd_nand.c
+++ b/common/cmd_nand.c
@@ -327,8 +327,10 @@ int do_nand(cmd_tbl_t * cmdtp, int flag, int argc, char 
*argv[])
 are sure of what you are doing!\n
 \nReally scrub this NAND flash? y/N\n);
 
-   if (getc() == 'y'  getc() == '\r') {
-   opts.scrub = 1;
+   if (getc() == 'y') {
+   puts(y);
+   if (getc() == '\r')
+   opts.scrub = 1;
} else {
puts(scrub aborted\n);
return -1;
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Any good __LOW COST__ MIPS SBC suggestion please

[Florian Fainelli]

Le samedi 6 mars 2010 21:42:52, Jerry Van Baren a écrit :
 Hi Balaji,
 
 Balaji Ravindran wrote:
  Hi all,
 
  I'm hunting for a __LOW COST__ MIPS/PPC SBC, something like TS-7200(but
  it is for ARM). Could anyone please suggest me a good one, that you guys
  have come across.
  My purpose is only for general driver development, and developing some
  MIPS / PPC porting skills.
 
  Also another true intension is, i have couple of 2600$$ BDI3000 JTAG
  debuggers for PPC and MIPS, lying idle in my office, and want to make
  some good use out of it :).
 
 Lucky dude.  :-)
 
  I was looking in the Boards directory to hunt for any MIPS based SBC
  boards, but found it hard to search.
 
  It will be nice, if its an SBC, and it has atleast 64/128 MB SDRAM, and
  16/32 MB flash, USB support, (i can;t expect a super fast processor, but
  a decent one like 166/200 Mhz should be ok)
 
 Two off-the-wall thoughts would be to use QEMU (the ultimate in low
 cost) or a MIPS-based wireless/firewall/router.  A fair number of the
 cheap ones use versions of the Realtek SoC processor, which is MIPS
 architecture:
http://www.linux-mips.org/wiki/Realtek_SOC

This is actually a really bad choice, unless you start using Realtek WiSoCs 
(RT30xx/RT28xx). RTL8186 and RTL8651B are using a Lexra core, which is famous 
for not having 4 patented instructions (lwl, lwr, swl and swr), which 
therefore requires a different toolchain. Also the Linux support is just non-
existent. Finally they use a brain-dead bootloader called ROME which only 
allows a couple of actions to be performed.

More seriously, buy a WRT160NL or WRT54GL from Linksys, which is equally cheap 
as those Realtek devices.

 
 As another possibility, you may be able to pick up a Lemote computer
 which uses the Loongson processor:
http://en.wikipedia.org/wiki/Loongson
http://en.wikipedia.org/wiki/Lemote

This is a much better choice :)
-- 
Cordialement, Florian Fainelli
--
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] EHCI hub not powering on port

[Florian Fainelli]

Hi again,

Enabling CONFIG_EHCI_IS_TDI in my board configuration file made it work.

On Monday 16 November 2009 13:54:19 Florian Fainelli wrote:
 Hi,
 
 On Friday 13 November 2009 17:02:26 Florian Fainelli wrote:
  Hi all,
 
  I am trying to make u-boot work with my EHCI controler and everything
  goes well up to when it comes to powering on the port:
 
 Forgot to mention that the hardware works fine with Linux and does not
  require any specific quirk.
--
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] EHCI hub not powering on port

[Florian Fainelli]

Hi,

On Friday 13 November 2009 17:02:26 Florian Fainelli wrote:
 Hi all,
 
 I am trying to make u-boot work with my EHCI controler and everything goes
  well up to when it comes to powering on the port:

Forgot to mention that the hardware works fine with Linux and does not require 
any specific quirk.

 
 Register 10011 NbrPorts 1
 USB EHCI 1.00
 scanning bus for devices... New Device 0
 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0
  length 0x40 set address 1
 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length
  0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index
  0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value
  0x200 index 0x0 length 0x9 usb_control_msg: request: 0x6, requesttype:
  0x80, value 0x200 index 0x0 length 0x19 get_conf_no 0 Result 25, wLength
  25
 if 0, ep 0
 ##EP epmaxpacketin[1] = 8
 set configuration 1
 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length
  0x0 new device strings: Mfr=1, Product=2, SerialNumber=0
 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0
  length 0xFF USB device number 1 default language ID 0x1
 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1
  length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302
  index 0x1 length 0xFF Manufacturer u-boot
 Product  EHCI Host Controller
 SerialNumber
 USB hub found
 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0
  length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900
  index 0x0 length 0x8 1 ports detected
 individual port power switching
 standalone hub
 individual port over-current protection
 power on to power good time: 20ms
 hub controller current requirement: 0mA
 port 1 is removable
 usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0
  length 0x4 get_hub_status returned status 0001, change 0901
 local power source is lost (inactive)
 no over-current condition exists
 enabling power on all ports
 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1
  length 0x0 port 1 returns 0
 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1
  length 0x4 Port 1 Status 0502 Change 
 1 USB Device(s) found
scanning bus for storage devices... 0 Storage Device(s) found
 
 
 According to the USB 2.0 specification paragraph 11.11, this is the correct
  behavior since both HUB_STATUS_LOCAL_POWER in wHubStatus and
  HUB_CHANGE_LOCAL_POWER in wHubChange are set. Issuing a port power feature
  to the port would have no effect.
 
 Has anyone already met similar problems with EHCI hubs integrated to EHCI
  controllers ?
 
 Thank you very much in advance.
 
--
Florian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] EHCI hub not powering on port

[Florian Fainelli]

Hi all,

I am trying to make u-boot work with my EHCI controler and everything goes well 
up to when it comes to powering on the port:

Register 10011 NbrPorts 1
USB EHCI 1.00
scanning bus for devices... New Device 0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 
0x40
set address 1
usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 
0x12
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 
0x9
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 
0x19
get_conf_no 0 Result 25, wLength 25
if 0, ep 0
##EP epmaxpacketin[1] = 8
set configuration 1
usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0
new device strings: Mfr=1, Product=2, SerialNumber=0
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 
0xFF
USB device number 1 default language ID 0x1
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 length 
0xFF
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 length 
0xFF
Manufacturer u-boot
Product  EHCI Host Controller
SerialNumber
USB hub found
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 
0x4
usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 
0x8
1 ports detected
individual port power switching
standalone hub
individual port over-current protection
power on to power good time: 20ms
hub controller current requirement: 0mA
port 1 is removable
usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4
get_hub_status returned status 0001, change 0901
local power source is lost (inactive)
no over-current condition exists
enabling power on all ports
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0
port 1 returns 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
Port 1 Status 0502 Change 
1 USB Device(s) found
   scanning bus for storage devices... 0 Storage Device(s) found


According to the USB 2.0 specification paragraph 11.11, this is the correct 
behavior since both HUB_STATUS_LOCAL_POWER in wHubStatus and 
HUB_CHANGE_LOCAL_POWER in wHubChange are set. Issuing a port power feature to 
the port would have no effect.

Has anyone already met similar problems with EHCI hubs integrated to EHCI 
controllers ?

Thank you very much in advance.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] serial: add support for the OMRPv2 simple wishbone UART

[Florian Fainelli]

Hi Wolfgang,

Le Tuesday 14 October 2008 15:08:14 Wolfgang Denk, vous avez écrit :
 It seems ther eis no board in the mainline U-Boot code which uses this
 driver.

 Do you plan to submit any board support that will actually use this
 driver?

Of course. I actually wanted to know about the good programming pratice before 
submitting it. 

 Accesses to device registers through  volatile  pointers  are  depre-
 cated. Please use the respective accessor macros / functions instead.

Ok, I could probably fixup the uartlite driver with another patch to use the 
proper accessors. I derived this driver from it.

 That's to set the baud rate. This function seems to be missing in your
 driver?

Baudrate is hardcoded in the IP core because it is very simple and occupyiong 
only a few LUTs. I do not think I will have to change the baudrate ever.

 Please write like this:

   while(IO_SERIAL_UCR  WUB_BUSY)
   ;

Ok.


  +void serial_puts(const char * s)
  +{
  +   while (*s) {
  +   serial_putc(*s++);
  +   }

 No curly braces for a single line statement, please.

  +   while(!(IO_SERIAL_UCR  WUB_DR));

 See above.

 This makes no sense to me - a  header  file  which  contains  just  a
 single line include for another header file?

I was following the uartlite/microblaze pratice, but that's right it does not 
make sense at all.

Thank you very much for your comments, when board support is ready I will 
resubmit everything in separate patches.
-- 
Cordialement, Florian Fainelli

OpenPattern SARL - Lead software architect
GSM: +33.632843955
109/111 rue des Côtes
78 600 Maisons-Laffitte
--


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot