Re: [PATCH V2 00/22] Multiplatform BMIPS kernel
On Thu, Nov 20, 2014 at 10:09 AM, Florian Fainelli wrote: > Slightly unrelated, did you also try to use drivers/bus/brcmstb_gisb.c > on these MIPS platforms? > > Its usefulness is probably lower on MIPS since we typically get accurate > bus errors to be decoded by the CPU and printed through the exception > handler, but I'd be curious if it works just fine as well. Unfortunately ERR_CAP_CLR (the first register) starts at offset 0x7e4 on 28nm, and offset 0x0c8 on 40nm/65nm. Just for fun I tried setting the base address to (0x104000c8 - 0x7e4) = 0x103ff8e4 on 7420, and then noticed that the CAP_HI_ADDR register only exists on the new chips with 40-bit addressing. This prevents the driver from reading the valid bit from the correct location, so the error handler exits prematurely. After manually hacking the code to renumber the registers, it worked again: # devmem 0x103c Data bus error, epc == 0040a21c, ra == 0040a1a0 brcmstb_gisb_arb_decode_addr: timeout at 0x103c [R timeout], core: cpu_0 Bus error # devmem 0x103c 32 0x5678 brcmstb_gisb_arb_decode_addr: timeout at 0x103c [W timeout], core: cpu_0 # Last night I fixed up the brcmstb reset driver to work with the old chips. I'm wondering if it makes sense to just split this work into a new patch series, since several of the BCM7xxx ARM drivers will need changes (both code and DT) to run on MIPS. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/22] Multiplatform BMIPS kernel
On 11/19/2014 07:55 PM, Kevin Cernekee wrote: > On Wed, Nov 19, 2014 at 7:04 PM, Brian Norris > wrote: >> On Sat, Nov 15, 2014 at 04:17:24PM -0800, Kevin Cernekee wrote: >>> The lack of a reboot handler is annoying; syscon-reboot probably won't work >>> on STB (because it requires two writes). >> >> Can't you reuse drivers/power/reset/brcmstb-reboot.c ? > > Oops, I ran a quick check earlier by grepping for "sun-top-ctrl" and > looking under drivers/reset, but assumed this driver wasn't merged yet > when nothing came up in the code. Thanks for the pointer. > > It looks like the current driver will work for 40nm, but 65nm uses > different bit positions: RESET_CTRL bit 3 to arm, and SW_RESET bit 31 > to trigger. I'll add a new "brcm,brcmstb-reboot-65nm" compatible > string to make this work. > > Also, we'll need to take Guenter Roeck's register_restart_handler() > patch in order to build on MIPS. Slightly unrelated, did you also try to use drivers/bus/brcmstb_gisb.c on these MIPS platforms? Its usefulness is probably lower on MIPS since we typically get accurate bus errors to be decoded by the CPU and printed through the exception handler, but I'd be curious if it works just fine as well. Thanks! -- Florian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/22] Multiplatform BMIPS kernel
On 11/19/2014 07:55 PM, Kevin Cernekee wrote: On Wed, Nov 19, 2014 at 7:04 PM, Brian Norris computersforpe...@gmail.com wrote: On Sat, Nov 15, 2014 at 04:17:24PM -0800, Kevin Cernekee wrote: The lack of a reboot handler is annoying; syscon-reboot probably won't work on STB (because it requires two writes). Can't you reuse drivers/power/reset/brcmstb-reboot.c ? Oops, I ran a quick check earlier by grepping for sun-top-ctrl and looking under drivers/reset, but assumed this driver wasn't merged yet when nothing came up in the code. Thanks for the pointer. It looks like the current driver will work for 40nm, but 65nm uses different bit positions: RESET_CTRL bit 3 to arm, and SW_RESET bit 31 to trigger. I'll add a new brcm,brcmstb-reboot-65nm compatible string to make this work. Also, we'll need to take Guenter Roeck's register_restart_handler() patch in order to build on MIPS. Slightly unrelated, did you also try to use drivers/bus/brcmstb_gisb.c on these MIPS platforms? Its usefulness is probably lower on MIPS since we typically get accurate bus errors to be decoded by the CPU and printed through the exception handler, but I'd be curious if it works just fine as well. Thanks! -- Florian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/22] Multiplatform BMIPS kernel
On Thu, Nov 20, 2014 at 10:09 AM, Florian Fainelli f.faine...@gmail.com wrote: Slightly unrelated, did you also try to use drivers/bus/brcmstb_gisb.c on these MIPS platforms? Its usefulness is probably lower on MIPS since we typically get accurate bus errors to be decoded by the CPU and printed through the exception handler, but I'd be curious if it works just fine as well. Unfortunately ERR_CAP_CLR (the first register) starts at offset 0x7e4 on 28nm, and offset 0x0c8 on 40nm/65nm. Just for fun I tried setting the base address to (0x104000c8 - 0x7e4) = 0x103ff8e4 on 7420, and then noticed that the CAP_HI_ADDR register only exists on the new chips with 40-bit addressing. This prevents the driver from reading the valid bit from the correct location, so the error handler exits prematurely. After manually hacking the code to renumber the registers, it worked again: # devmem 0x103c Data bus error, epc == 0040a21c, ra == 0040a1a0 brcmstb_gisb_arb_decode_addr: timeout at 0x103c [R timeout], core: cpu_0 Bus error # devmem 0x103c 32 0x5678 brcmstb_gisb_arb_decode_addr: timeout at 0x103c [W timeout], core: cpu_0 # Last night I fixed up the brcmstb reset driver to work with the old chips. I'm wondering if it makes sense to just split this work into a new patch series, since several of the BCM7xxx ARM drivers will need changes (both code and DT) to run on MIPS. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/22] Multiplatform BMIPS kernel
On Wed, Nov 19, 2014 at 7:04 PM, Brian Norris wrote: > On Sat, Nov 15, 2014 at 04:17:24PM -0800, Kevin Cernekee wrote: >> The lack of a reboot handler is annoying; syscon-reboot probably won't work >> on STB (because it requires two writes). > > Can't you reuse drivers/power/reset/brcmstb-reboot.c ? Oops, I ran a quick check earlier by grepping for "sun-top-ctrl" and looking under drivers/reset, but assumed this driver wasn't merged yet when nothing came up in the code. Thanks for the pointer. It looks like the current driver will work for 40nm, but 65nm uses different bit positions: RESET_CTRL bit 3 to arm, and SW_RESET bit 31 to trigger. I'll add a new "brcm,brcmstb-reboot-65nm" compatible string to make this work. Also, we'll need to take Guenter Roeck's register_restart_handler() patch in order to build on MIPS. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/22] Multiplatform BMIPS kernel
On Sat, Nov 15, 2014 at 04:17:24PM -0800, Kevin Cernekee wrote: > The lack of a reboot handler is annoying; syscon-reboot probably won't work > on STB (because it requires two writes). Can't you reuse drivers/power/reset/brcmstb-reboot.c ? Brian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/22] Multiplatform BMIPS kernel
On Sat, Nov 15, 2014 at 04:17:24PM -0800, Kevin Cernekee wrote: The lack of a reboot handler is annoying; syscon-reboot probably won't work on STB (because it requires two writes). Can't you reuse drivers/power/reset/brcmstb-reboot.c ? Brian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 00/22] Multiplatform BMIPS kernel
On Wed, Nov 19, 2014 at 7:04 PM, Brian Norris computersforpe...@gmail.com wrote: On Sat, Nov 15, 2014 at 04:17:24PM -0800, Kevin Cernekee wrote: The lack of a reboot handler is annoying; syscon-reboot probably won't work on STB (because it requires two writes). Can't you reuse drivers/power/reset/brcmstb-reboot.c ? Oops, I ran a quick check earlier by grepping for sun-top-ctrl and looking under drivers/reset, but assumed this driver wasn't merged yet when nothing came up in the code. Thanks for the pointer. It looks like the current driver will work for 40nm, but 65nm uses different bit positions: RESET_CTRL bit 3 to arm, and SW_RESET bit 31 to trigger. I'll add a new brcm,brcmstb-reboot-65nm compatible string to make this work. Also, we'll need to take Guenter Roeck's register_restart_handler() patch in order to build on MIPS. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V2 00/22] Multiplatform BMIPS kernel
This patch series implements a multiplatform target that runs on a
variety of different Broadcom chipsets based on the BMIPS CPUs. It
evolved out of the "BMIPS updates and BCM3384 platform support"
RFC posted earlier.
V1->V2:
- Add several more DTS files so the same kernel can boot on multiple
chips: BCM6328, BCM6368, BCM7125, BCM7346, BCM7360, BCM7420, BCM7425,
and as a very special bonus, the BCM3384 Viper CPU.
- Add irq-bcm7038-l1.c to support the BCM7xxx chipsets.
- Rename target from "bcm3384" to "bmips".
- Change L1_CACHE_SHIFT fix so it works correctly when multiple BMIPS
CPU types are selected.
- Drop dependency on rejected EARLYCON_FORCE changes.
- Delete most of my new irq.c, in favor of using the refactored
irq-bcm7120-l2.c.
- Add flush for BMIPS3300/BMIPS43xx readahead caches, to avoid
non-coherency after DMA_FROM_DEVICE operations.
- Utilize the new MIPS IRQ APIs from mips-for-linux-next.
- Tweak docs/copyrights/maintainership.
This series is based on 3.18-rc4, plus:
http://patchwork.linux-mips.org/bundle/cernekee/bmips-multi-v2-deps/?state=*
http://marc.info/?l=linux-usb=141305106215886=2 (all 3/3)
These are all queued for tty-next / irqchip-next / usb-next. Notably,
the proposed serial/pxa/ttyBCM coexistence changes are not required at
this time.
A couple of sample boot logs are posted here:
https://gist.github.com/cernekee/e53a6ff05292c3a78a94
checkpatch status:
The checkpatch warnings fall into two categories:
- Undocumented DT bindings. These SoCs use mostly-standard-looking
peripherals (OHCI/EHCI controllers, ethernet PHYs), but it may be
necessary to add extra code in the future to compensate for
hardware quirks. So the compatible string in the DTS file lists
both the generic device name (documented) and a more specific
identifier for the hardware present on the chip (undocumented).
- extern declarations for the __dtb_* symbols.
Known issues:
If the lockdep checks are enabled, I see a weird IRQ state mismatch
returning from e.g. sys_execve(). CP0 STATUS shows IE disabled, but
current->hardirqs_enabled == 1. Not sure if this is a problem with
my new code or something more general. It only shows up on
SMP && !PREEMPT builds.
Booting a HIGHMEM MIPS kernel on a system with cache aliases may fail
if the system has >256MB of memory. AFAICT this is a general problem
with the fallback logic in arch/mips/mm/init.c.
Many of the BCM63xx bootloaders impose severe restrictions on the kernel
size. This tends to cause a lot of trouble booting images that include
an initramfs (because we're still missing MTD support). One workaround
is to set CONFIG_PHYSICAL_START to a higher value, like 0x8100_.
Future work:
Many BCM7xxx boards can be freely switched between big endian and little
endian modes, with the latter being the default. It would be nice if we
could use identical DTS files for both configurations, since the LE/BE
setting mostly doesn't affect how the peripherals work. But currently a
few assumptions are hardcoded in there ("big-endian" USB register
properties and a hack to get the 16550 register addresses correct). I
submitted a patch to the DT/serial lists which adds a "native-endian"
property; if this is accepted and utilized by the drivers in question, it
will go a long way toward solving this problem.
Lots of peripherals are still missing, especially flash and bcm63xx_enet.
The lack of a reboot handler is annoying; syscon-reboot probably won't work
on STB (because it requires two writes). Some peripherals, like USB on
certain boards, need more work (possibly PHY drivers) and were left
disabled.
There are ways to retrieve other information from the legacy non-DT
bootloaders, but they're pretty hacky. The flash configuration is among
the worst of the bunch, because these chips can have up to 4 different
flash controllers, more than one can be active at a time, and the
bootloader just passes "hints" rather than explicit partition maps. For
specific boards it is sometimes OK to hardcode the map into the DTS file,
although most of the supported boards are user-reconfigurable and the
flash layouts may change from one bootloader version to the next.
There is currently no way to distinguish between different bcm63xx
board types (i.e. we can only identify the SoC, not the board). There
is a way to distinguish different bcm7xxx board types, although in
practice the data source is somewhat unreliable and doesn't always convey
all of the information needed to distinguish boards with different
capabilities.
The kernel makes a few assumptions about how the bootloader has set up
Broadcom-specific registers for e.g. USB. If/when power management
features are added, these registers will revert to their default settings
on resume, and somehow need to be set up again by Linux.
irq-bcm7120-l2.c is getting a little bloated and I'm not entirely happy
with the latest round of changes. In particular it would be
[PATCH V2 00/22] Multiplatform BMIPS kernel
This patch series implements a multiplatform target that runs on a variety of different Broadcom chipsets based on the BMIPS CPUs. It evolved out of the BMIPS updates and BCM3384 platform support RFC posted earlier. V1-V2: - Add several more DTS files so the same kernel can boot on multiple chips: BCM6328, BCM6368, BCM7125, BCM7346, BCM7360, BCM7420, BCM7425, and as a very special bonus, the BCM3384 Viper CPU. - Add irq-bcm7038-l1.c to support the BCM7xxx chipsets. - Rename target from bcm3384 to bmips. - Change L1_CACHE_SHIFT fix so it works correctly when multiple BMIPS CPU types are selected. - Drop dependency on rejected EARLYCON_FORCE changes. - Delete most of my new irq.c, in favor of using the refactored irq-bcm7120-l2.c. - Add flush for BMIPS3300/BMIPS43xx readahead caches, to avoid non-coherency after DMA_FROM_DEVICE operations. - Utilize the new MIPS IRQ APIs from mips-for-linux-next. - Tweak docs/copyrights/maintainership. This series is based on 3.18-rc4, plus: http://patchwork.linux-mips.org/bundle/cernekee/bmips-multi-v2-deps/?state=* http://marc.info/?l=linux-usbm=141305106215886w=2 (all 3/3) These are all queued for tty-next / irqchip-next / usb-next. Notably, the proposed serial/pxa/ttyBCM coexistence changes are not required at this time. A couple of sample boot logs are posted here: https://gist.github.com/cernekee/e53a6ff05292c3a78a94 checkpatch status: The checkpatch warnings fall into two categories: - Undocumented DT bindings. These SoCs use mostly-standard-looking peripherals (OHCI/EHCI controllers, ethernet PHYs), but it may be necessary to add extra code in the future to compensate for hardware quirks. So the compatible string in the DTS file lists both the generic device name (documented) and a more specific identifier for the hardware present on the chip (undocumented). - extern declarations for the __dtb_* symbols. Known issues: If the lockdep checks are enabled, I see a weird IRQ state mismatch returning from e.g. sys_execve(). CP0 STATUS shows IE disabled, but current-hardirqs_enabled == 1. Not sure if this is a problem with my new code or something more general. It only shows up on SMP !PREEMPT builds. Booting a HIGHMEM MIPS kernel on a system with cache aliases may fail if the system has 256MB of memory. AFAICT this is a general problem with the fallback logic in arch/mips/mm/init.c. Many of the BCM63xx bootloaders impose severe restrictions on the kernel size. This tends to cause a lot of trouble booting images that include an initramfs (because we're still missing MTD support). One workaround is to set CONFIG_PHYSICAL_START to a higher value, like 0x8100_. Future work: Many BCM7xxx boards can be freely switched between big endian and little endian modes, with the latter being the default. It would be nice if we could use identical DTS files for both configurations, since the LE/BE setting mostly doesn't affect how the peripherals work. But currently a few assumptions are hardcoded in there (big-endian USB register properties and a hack to get the 16550 register addresses correct). I submitted a patch to the DT/serial lists which adds a native-endian property; if this is accepted and utilized by the drivers in question, it will go a long way toward solving this problem. Lots of peripherals are still missing, especially flash and bcm63xx_enet. The lack of a reboot handler is annoying; syscon-reboot probably won't work on STB (because it requires two writes). Some peripherals, like USB on certain boards, need more work (possibly PHY drivers) and were left disabled. There are ways to retrieve other information from the legacy non-DT bootloaders, but they're pretty hacky. The flash configuration is among the worst of the bunch, because these chips can have up to 4 different flash controllers, more than one can be active at a time, and the bootloader just passes hints rather than explicit partition maps. For specific boards it is sometimes OK to hardcode the map into the DTS file, although most of the supported boards are user-reconfigurable and the flash layouts may change from one bootloader version to the next. There is currently no way to distinguish between different bcm63xx board types (i.e. we can only identify the SoC, not the board). There is a way to distinguish different bcm7xxx board types, although in practice the data source is somewhat unreliable and doesn't always convey all of the information needed to distinguish boards with different capabilities. The kernel makes a few assumptions about how the bootloader has set up Broadcom-specific registers for e.g. USB. If/when power management features are added, these registers will revert to their default settings on resume, and somehow need to be set up again by Linux. irq-bcm7120-l2.c is getting a little bloated and I'm not entirely happy with the latest round of changes. In particular it would be really nice if the
