Re: [linux-sunxi] Re: [PATCH sunxi-tools 0/5] FEL fixes
Hi,
On 02/24/2015 10:15 AM, Siarhei Siamashka wrote:
On Tue, 24 Feb 2015 04:18:40 +0200
Siarhei Siamashka siarhei.siamas...@gmail.com wrote:
This is the fix for the previously non-working 'fel spl' command
on Allwinner A13. And some other improvements.
Also available at:
https://github.com/ssvb/sunxi-tools/commits/20150223-fel-fixes
BTW, it would be great if somebody could test this branch on A23
hardware before we move on (because I don't have A23 to test it
myself). The USB FEL boot usage instructions are here:
http://linux-sunxi.org/FEL/USBBoot
Please paste the output of 'fel -v spl u-boot-sunxi-with-spl.bin'. It
should check and report some information about the MMU setup, which may
be important for additional tuning.
[hans@localhost sunxi-tools]$ sudo ./fel -v spl
~/projects/sunxi/u-boot/u-boot-sunxi-with-spl.bin
Reading the MMU translation table from 0x8000
Disabling I-cache, MMU and branch prediction... done.
= Executing the SPL... done.
Setting write-combine mapping for DRAM.
Setting cached mapping for BROM.
Writing back the MMU translation table.
Enabling I-cache, MMU and branch prediction... done.
This is with the attached patch, with this patch the A23 works fine.
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
From e95db2d9c8d97393749edae6638306c035294460 Mon Sep 17 00:00:00 2001
From: Hans de Goede hdego...@redhat.com
Date: Tue, 24 Feb 2015 19:15:14 +0100
Subject: [PATCH] Add fel spl support for A23
Signed-off-by: Hans de Goede hdego...@redhat.com
---
fel.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/fel.c b/fel.c
index 9ab0fe1..8126498 100644
--- a/fel.c
+++ b/fel.c
@@ -388,6 +388,11 @@ soc_sram_info soc_sram_info_table[] = {
.swap_buffers = a10_a13_a20_sram_swap_buffers,
},
{
+ .soc_id = 0x1650, /* Allwinner A23 */
+ .thunk_addr = 0x46E00, .thunk_size = 0x200,
+ .swap_buffers = a31_sram_swap_buffers,
+ },
+ {
.soc_id = 0x1633, /* Allwinner A31 */
.thunk_addr = 0x46E00, .thunk_size = 0x200,
.swap_buffers = a31_sram_swap_buffers,
--
2.3.0
Re: [linux-sunxi] [PATCH sunxi-tools 5/5] fel: Set the AUXCR L2EN bit for A10/A13
Hi, On 02/24/2015 08:04 PM, Siarhei Siamashka wrote: On Tue, 24 Feb 2015 18:11:22 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 02/24/2015 03:18 AM, Siarhei Siamashka wrote: This is needed to have feature parity with the normal boot mode, where the L2EN bit in the CP15 Auxiliary Control Register is set by the BROM code right from the start. And if L2EN is not set, then the Linux system ends up booted with the L2 cache disabled. According to the Cortex-A8 TRM, the L2 cache is only enabled when both L2EN bit and the C bit from the CP15 Control Register c1 are set. Because the BROM does not set the C bit, this change should not affect the functionality of the FEL mode in any way. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com Wouldn't it be better to do this in u-boot ? Yes, it was originally a patch for u-boot. But now I'm not so sure. The 'fel' tool tries to abstract this stuff and make the SPL uploaded via FEL look functionally equivalent to loading it from an SD card (except for patching the eGON.BT0 signature in memory and also using some areas in SRAM outside the first 32 KiB). The L2EN bit setup differs for the SD card boot and the FEL mode cases. So the 'fel' tool tries to correct this defect. Just because it can. Ah yes I see this a FEL only thing, so yes lets do this in the fel tool then: Acked-by: Hans de Goede hdego...@redhat.com Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools 0/5] FEL fixes
On Tue, 24 Feb 2015 04:18:40 +0200 Siarhei Siamashka siarhei.siamas...@gmail.com wrote: This is the fix for the previously non-working 'fel spl' command on Allwinner A13. And some other improvements. Also available at: https://github.com/ssvb/sunxi-tools/commits/20150223-fel-fixes BTW, it would be great if somebody could test this branch on A23 hardware before we move on (because I don't have A23 to test it myself). The USB FEL boot usage instructions are here: http://linux-sunxi.org/FEL/USBBoot Please paste the output of 'fel -v spl u-boot-sunxi-with-spl.bin'. It should check and report some information about the MMU setup, which may be important for additional tuning. Vishnu, if I understand it correctly, you have a work-in-progress u-boot support for A33 already? http://irclog.whitequark.org/linux-sunxi/2015-02-12#11822316; If it already works, then testing FEL USB boot on A33 would be very interesting too. Thanks. Siarhei Siamashka (5): fel: Add --verbose option and implement transfer speed reporting fel: Disable MMU to get more SRAM space and fix A13 problems fel: Faster USB transfers via 'fel write' to DRAM fel: Fix USB timeout on large transfers fel: Set the AUXCR L2EN bit for A10/A13 fel.c | 218 +- 1 file changed, 216 insertions(+), 2 deletions(-) -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Communication with Allwinner
Hi Wonder if they're willing to help out with the Cyanogenmod efforts. A dude going by the name of Christian Troy was claimed to have worked with Allwinner employees and released several Cyanogenmod distros for the A31, but the problem is he hasn't released any complete source archives, and others were having trouble building their own CM from scratch. It's a problem since right now they are totally overworked with their driver development tasks. But since we are going to mainline most of the drivers anyway within the next few months, it shouldn't be a problem to rebuild a CM for the sunxi platform. Also the design for the A64 will be designed the way that all the code will be available in upstream (linux-next at least). Also it was mostly Christian who has worked on the CM build together with the old team of which only a few are around (many have moved to other companies like Rockchip) so the people who were working on this CM build are no longer working at this company... I'd suggest contacting Christian Troy directly: http://forum.xda-developers.com/member.php?u=1237780 Sorry for the bad news and all the best -- David Lanzendörfer OpenSourceSupport GmbH System engineer and supporter http://www.o2s.ch/ -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
Re: [linux-sunxi] [PATCH 3.4 0/4] Various fixes to make linux-sunxi work with new u-boot
On Sat, 21 Feb 2015 16:47:20 +0100 Hans de Goede hdego...@redhat.com wrote: Hi all, Newer u-boot versions may chose a different (better) PLL6 / PLL5 setting and/or different voltage settings. Unfortunately the old linux-sunxi-3.4 kernels have a number of hardcoded assumptions about PLL5 speed, and in some cases override the bootloader chosen PLL6 / voltages in a bad way. This patch series fixes this and is intended for the sunxi-3.4 branch. The first 2 patches are already in sunxi-3.4/staging, but they should really also be added to the sunxi-3.4 branch. The 2 new patches should be added to both. Note that sunxi-3.4/staging currently does not work for me (on sun5i at least) (*) so these patches have only been tested on the sunxi-3.4 branch. Regards, Hans *) It does not boot at all for some reason, not a single message is printed on the serial console after u-boot has loaded the kernel. I'm afraid I do not have the time to investigate this. Thanks. I will allocate the next few days of my time on checking what's up with sunxi-3.4 and maybe we can make the final graduation release for it. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: New sunxi-tools v1.3 release planning
On Tue, 2015-02-24 at 11:31 +0200, Siarhei Siamashka wrote: On Mon, 23 Feb 2015 13:12:32 + Ian Campbell ijc+ub...@hellion.org.uk wrote: On Sun, 2015-02-22 at 18:55 +0200, Siarhei Siamashka wrote: We might want to push sunxi-tools into more Linux distributions than just Debian and Fedora. And the maintainers of these distributions could be not very much impressed with the current quality of the sunxi-tools build process :) At least from my PoV as the Debian maintainer it's not so bad, mostly because there isn't very much of it and it's pretty simple/basic. OK, thanks. So, I guess, this is one more vote in favour of keeping the existing makefile. FWIW I'm not opposed to a change to use autotools or whatever, I just wanted to say don't do it just for my benefit or whatever. The biggest issue from the Debian PoV is the binaries contained in the release -- Debian cannot (or does not want to) ship any binary which is not rebuilt as part of the package build, so I can't just use them. Rebuilding those binaries is hard because sadly cross-compilers are still a WIP in Debian and ensuring that an Arch:all package is built on a specific architecture (as someone in this thread suggested) is not easily achieved. I could just do each upload containing armhf binaries instead of relying on the buildd network, but that's just a workaround and in any case I prefer to do source only uploads where possible. The 'fel' tool now contains some bits of ARM assembly, which are converted into annotated C arrays. This may be stepping into a gray area. Yes. Pragmatically given the way it's presented with the source in comments right alongside I'd be fairly bullish about it being ok. Ultimately with Jessie being frozen the new version of the fel tool has to be targeting Stretch (and jessie-backports once it opens) and if there are no cross-compilers available by then I'd be quite surprised/cross. What is the Debian policy regarding the autogenerated 'configure' files? These days it is recommended best practice to regenerate them as part of the package build and there are helper tools to do so (dh_autoconf et al). Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 2/4] i2c: sunxi: Add Reduced Serial Bus (RSB) DT bindings documentation
Reduced Serial Bus (RSB) is an SMBus like bus used to communicate
with some PMICs (like the AXP223) or other peripherals.
The RSB DT bindings are pretty much the same as the one defined for
the marvell's mv64xxx controller, with the additional RSB specific
allwinner,rsb-hw-addr property for slave device nodes.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
.../devicetree/bindings/i2c/i2c-sunxi-rsb.txt | 50 ++
1 file changed, 50 insertions(+)
create mode 100644 Documentation/devicetree/bindings/i2c/i2c-sunxi-rsb.txt
diff --git a/Documentation/devicetree/bindings/i2c/i2c-sunxi-rsb.txt
b/Documentation/devicetree/bindings/i2c/i2c-sunxi-rsb.txt
new file mode 100644
index ..90aa5066873c
--- /dev/null
+++ b/Documentation/devicetree/bindings/i2c/i2c-sunxi-rsb.txt
@@ -0,0 +1,50 @@
+
+* Allwinner RSB (Reduced Serial Bus) controller
+
+Required properties :
+
+ - reg : Offset and length of the register set for the device.
+ - compatible : Should be allwinner,sun8i-a23-rsb.
+ - interrupts : The interrupt line connected to the RSB peripheral.
+ - clocks : The gate clk connected to the RSB peripheral.
+ - resets : The reset line connected to the RSB peripheral.
+
+Optional properties :
+
+ - clock-frequency : Desired RSB bus clock frequency in Hz. If not set
+the default frequency is 100kHz. Maximum is 20MHz.
+
+An RSB device node may contain up to 15 child nodes each encoding an RSB
+slave device.
+
+Slave device properties:
+ Required properties:
+ - reg : The runtime address used to access the device.
+ - allwinner,rsb-hw-addr : The RSB hardware address for the device. This
+is only used when configuring the runtime
+address of the device.
+
+ Valid runtime addresses - There are only 15 valid runtime addresses:
+
+ 0x17, 0x2d, 0x3a, 0x4e, 0x59, 0x63, 0x74, 0x8b,
+ 0x9c, 0xa6, 0xb1, 0xc5, 0xd2, 0xe8, 0xff
+
+
+Example:
+
+ rsb@01f03400 {
+ compatible = allwinner,sun8i-a23-rsb;
+ reg = 0x01f03400 0x400;
+ interrupts = 0 39 4;
+ clocks = apb0_gates 3;
+ clock-frequency = 300;
+ resets = apb0_rst 3;
+
+ axp223: pmic@2d {
+ compatible = x-powers,axp223, x-powers,axp221;
+ reg = 0x2d;
+ allwinner,rsb-hw-addr = 0x3e3;
+
+ /* ... */
+ };
+ };
--
2.1.4
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3/4] ARM: dts: sun8i: Add Reduced Serial Bus controller device node to A23 dtsi
This patch adds a device node for the Reduced Serial Bus (RSB)
controller and the defacto pinmux setting to the A23 dtsi.
Since there is only one possible pinmux setting for RSB, just
set it in the dtsi.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun8i-a23.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23.dtsi b/arch/arm/boot/dts/sun8i-a23.dtsi
index 382ebd137ee4..fd9b4c811a5f 100644
--- a/arch/arm/boot/dts/sun8i-a23.dtsi
+++ b/arch/arm/boot/dts/sun8i-a23.dtsi
@@ -600,6 +600,13 @@
#size-cells = 0;
#gpio-cells = 3;
+ r_rsb_pins: r_rsb {
+ allwinner,pins = PL0, PL1;
+ allwinner,function = s_rsb;
+ allwinner,drive = SUN4I_PINCTRL_20_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_UP;
+ };
+
r_uart_pins_a: r_uart@0 {
allwinner,pins = PL2, PL3;
allwinner,function = s_uart;
@@ -607,5 +614,19 @@
allwinner,pull = SUN4I_PINCTRL_NO_PULL;
};
};
+
+ r_rsb: i2c@01f03400 {
+ compatible = allwinner,sun8i-a23-rsb;
+ reg = 0x01f03400 0x400;
+ interrupts = GIC_SPI 39 IRQ_TYPE_LEVEL_HIGH;
+ clocks = apb0_gates 3;
+ clock-frequency = 300;
+ resets = apb0_rst 3;
+ pinctrl-names = default;
+ pinctrl-0 = r_rsb_pins;
+ status = disabled;
+ #address-cells = 1;
+ #size-cells = 0;
+ };
};
};
--
2.1.4
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 4/4] ARM: dts: sun8i: ippo-q8h-v5: Enable Reduced Serial Bus controller
The Reduced Serial Bus controller is used to talk to the onboard PMIC.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
b/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
index 4cb25f8267c8..31882e6e7a38 100644
--- a/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
+++ b/arch/arm/boot/dts/sun8i-a23-ippo-q8h-v5.dts
@@ -125,6 +125,10 @@
};
};
+r_rsb {
+ status = okay;
+};
+
r_uart {
pinctrl-names = default;
pinctrl-0 = r_uart_pins_a;
--
2.1.4
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: New sunxi-tools v1.3 release planning
On Mon, 23 Feb 2015 14:35:06 +0100
Benjamin Henrion zoo...@gmail.com wrote:
I am waiting for binary cross-compilers in debian for at least 10
years now, since I followed emdebian project.
For gentooers around, the ebuild is 18 lines:
http://data.gpo.zugaina.org/mkeyoverlay/dev-embedded/sunxi-tools/sunxi-tools-.ebuild
# Distributed under the terms of the GNU General Public License v2
# $Header: $
EAPI=5
EGIT_REPO_URI=git://github.com/linux-sunxi/sunxi-tools.git
inherit git-2 autotools
DESCRIPTION=Tools to help hacking Allwinner A10 devices.
HOMEPAGE=http://linux-sunxi.org/;
LICENSE=GPL-2
SLOT=0
IUSE=
DEPEND=virtual/libusb
src_install() {
dobin bin2fex
dobin bootinfo
dobin fel
dobin fex2bin
dobin fexc
dobin nand-part
dobin pio
}
This does not seem to have the crossdev dependency though? Along
with the necessary steps to ensure that the system has an ARM
crosscompler installed to pass it to the Makefile as the
'CROSS_COMPILE' parameter:
https://github.com/linux-sunxi/sunxi-tools/blob/d4e34bcb5a35/Makefile#L29
So, effectively, this ebuild is not rebuilding the ARM binaries either.
Also just like buildroot, it skips installing the 'meminfo' tool.
That's what we get for having no 'make install' target and relying on
the distro package maintainers to pick the right set of binaries.
For example, I would want to tell the users to Just install the
sunxi-tools package from your linux distro and run the meminfo tool.
But I obviously can't rely on this tool being available with the current
state of sunxi-tools packaging. Moreover, renaming the pio, bootinfo
and meminfo tools to avoid using generic names is left up to the
discretion of the distro maintainers now.
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Communication with Allwinner
Also you can find the patches here btw: https://github.com/christiantroy/allwinner_a31 Cheers -- David Lanzendörfer OpenSourceSupport GmbH System engineer and supporter http://www.o2s.ch/ -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: This is a digitally signed message part.
[linux-sunxi] [PATCH 1/4] i2c: sunxi: Add Reduced Serial Bus (RSB) support
The RSB controller looks like an SMBus controller which only supports byte and word data transfers. It can also do double-word data transfers, but the I2C subsystem does not support this, nor have we seen devices using this. The RSB differs from standard SMBus protocol on several aspects: - it uses addresses set at runtime to address slaves. Runtime addresses are sent to slaves using their 12bit hardware addresses. Up to 15 runtime addresses are available. - it adds a parity bit every 8bits of data and address for read and write accesses; this replaces the ack bit - only one read access is required to read a byte (instead of a write followed by a read access in standard SMBus protocol) - there's no Ack bit after each read access This means this bus cannot be used to interface with standard SMBus devices (known devices supporting this interface are the AXP223, AXP806, AXP809 PMICs and the AC100 codec/RTC). However the RSB protocol is an extension of P2WI, which was close enough to SMBus to be integrated into the I2C subsystem in commit 3e833490fae5 (i2c: sunxi: add P2WI (Push/Pull 2 Wire Interface) controller support). Signed-off-by: Chen-Yu Tsai w...@csie.org --- drivers/i2c/busses/Kconfig | 12 + drivers/i2c/busses/Makefile| 1 + drivers/i2c/busses/i2c-sunxi-rsb.c | 458 + 3 files changed, 471 insertions(+) create mode 100644 drivers/i2c/busses/i2c-sunxi-rsb.c diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index 22da9c2ffa22..cf9337877181 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -840,6 +840,18 @@ config I2C_SUN6I_P2WI This interface is used to connect to specific PMIC devices (like the AXP221). +config I2C_SUNXI_RSB + tristate Allwinner Reduced Serial Bus controller + depends on RESET_CONTROLLER + depends on MACH_SUN8I || MACH_SUN9I || COMPILE_TEST + help + If you say yes to this option, support will be included for the + Reduced Serial Bus controller embedded in some sunxi SOCs. + The RSB looks like an SMBus controller (which supports only byte + accesses), but requires setting runtime addresses for slave devices. + This interface is used to connect to specific PMIC devices (like the + AXP223) or peripherals (like the AC100). + config I2C_TEGRA tristate NVIDIA Tegra internal I2C controller depends on ARCH_TEGRA diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index 3638feb6677e..f95d50315003 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -81,6 +81,7 @@ obj-$(CONFIG_I2C_SIRF)+= i2c-sirf.o obj-$(CONFIG_I2C_ST) += i2c-st.o obj-$(CONFIG_I2C_STU300) += i2c-stu300.o obj-$(CONFIG_I2C_SUN6I_P2WI) += i2c-sun6i-p2wi.o +obj-$(CONFIG_I2C_SUNXI_RSB)+= i2c-sunxi-rsb.o obj-$(CONFIG_I2C_TEGRA)+= i2c-tegra.o obj-$(CONFIG_I2C_VERSATILE)+= i2c-versatile.o obj-$(CONFIG_I2C_WMT) += i2c-wmt.o diff --git a/drivers/i2c/busses/i2c-sunxi-rsb.c b/drivers/i2c/busses/i2c-sunxi-rsb.c new file mode 100644 index ..7e9be3e14b8a --- /dev/null +++ b/drivers/i2c/busses/i2c-sunxi-rsb.c @@ -0,0 +1,458 @@ +/* + * RSB (Reduced Serial Bus) driver. + * + * Author: Chen-Yu Tsai w...@csie.org + * + * This file is licensed under the terms of the GNU General Public License + * version 2. This program is licensed as is without any warranty of any + * kind, whether express or implied. + * + * The RSB controller looks like an SMBus controller which only supports + * byte and word data transfers. But, it differs from standard SMBus + * protocol on several aspects: + * - it uses addresses set at runtime to address slaves. Runtime addresses + * are sent to slaves using their 12bit hardware addresses. Up to 15 + * runtime addresses are available. + * - it adds a parity bit every 8bits of data and address for read and + * write accesses; this replaces the ack bit + * - only one read access is required to read a byte (instead of a write + * followed by a read access in standard SMBus protocol) + * - there's no Ack bit after each read access + * + * This means this bus cannot be used to interface with standard SMBus + * devices. Devices known to support this interface include the AXP223, + * AXP809, and AXP806 PMICs, and the AC100 audio codec, all from X-Powers. + * + * A description of the operation and wire protocol can be found in the + * RSB section of Allwinner's A80 user manual, which can be found at + * + * https://github.com/allwinner-zh/documents/tree/master/A80 + * + * This document is officially released by Allwinner. + * + * This driver is based on i2c-sun6i-p2wi.c, the P2WI bus driver. + * + */ +#include linux/clk.h +#include linux/i2c.h +#include linux/io.h +#include linux/interrupt.h +#include linux/jiffies.h +#include linux/module.h +#include linux/of.h
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
On Tuesday, February 24, 2015 at 8:24:32 AM UTC+11, Al Thomas wrote: Your description of handshaking made me wonder if that was the problem. Are you aware there are two serial protocols available on the chip? H4 uses the control lines and H5 that seems to use SLIP. Page 30 of the BCM20710 manual says H5 requires the use of an external LPO. CTS must be pulled low. So if RTS is asserted on the host to switch to UART transport after reset and RTS is kept high (so CTS low on the controller) the controller may expect H5. There is a Broadcom H5 version of the tools so I may try that when I get set up. Today I've tested asserting and negating RTS at various times. Host RTS must be asserted at the end of the reset pulse and for 30ms after to get the device to assert its RTS (our CTS). Since I check for CTS before sending this causes the program to time out. The device apparently doesn't send when host RTS is negated. The responses are buffered because I can get them later when I assert RTS. I tried sending some H5-specific commands but got no response. I've updated my repository because I found an ioctl bug in my patchram. Possibly significant. Cheers, Steven -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: New sunxi-tools v1.3 release planning
On 24 February 2015 at 11:00, Ian Campbell ijc+ub...@hellion.org.uk wrote: On Tue, 2015-02-24 at 11:31 +0200, Siarhei Siamashka wrote: On Mon, 23 Feb 2015 13:12:32 + Ian Campbell ijc+ub...@hellion.org.uk wrote: On Sun, 2015-02-22 at 18:55 +0200, Siarhei Siamashka wrote: We might want to push sunxi-tools into more Linux distributions than just Debian and Fedora. And the maintainers of these distributions could be not very much impressed with the current quality of the sunxi-tools build process :) At least from my PoV as the Debian maintainer it's not so bad, mostly because there isn't very much of it and it's pretty simple/basic. OK, thanks. So, I guess, this is one more vote in favour of keeping the existing makefile. FWIW I'm not opposed to a change to use autotools or whatever, I just wanted to say don't do it just for my benefit or whatever. Cross-compiling aside the problem is with the install target and scripts. We need an install target with prefix support to make installation reasonably easy for distributions, and we need that the scripts can find the tools. And we might want a program prefix to avoid possible conflict with other tools of the same name. Autotools can do that. Running the scripts through a sed script during installation may also. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/4] i2c: sunxi: Add Reduced Serial Bus (RSB) DT bindings documentation
On Tuesday 24 February 2015 18:29:02 Chen-Yu Tsai wrote:
+ rsb@01f03400 {
+ compatible = allwinner,sun8i-a23-rsb;
+ reg = 0x01f03400 0x400;
+ interrupts = 0 39 4;
+ clocks = apb0_gates 3;
+ clock-frequency = 300;
+ resets = apb0_rst 3;
+
+ axp223: pmic@2d {
+ compatible = x-powers,axp223, x-powers,axp221;
+ reg = 0x2d;
+ allwinner,rsb-hw-addr = 0x3e3;
+
+ /* ... */
+ };
+ };
The child node cannot have a 'reg' property if the parent does not
have #address-cells/#size-cells. You should add these as mandatory
properties in the list.
I don't really understand the need for having two addresses (runtime
and hardware). Could the runtime address be configured at runtime?
Alternatively, could you use #address-cells=2 and put both into
'reg'?
Arnd
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Communication with Allwinner
Ugh, I knew it. Chris disabled private messaging on his XDA profile. :'( On Sunday, February 15, 2015 at 5:02:38 AM UTC+8, David Lanzendörfer wrote: Hello As you have maybe already heard in IRC I've taken a trip to Zhuhai and met the engineers of Allwinner Technology (全志科技) in person. We decided that we want as much cooperation between the sunxi project and Allwinner as possible for upstreaming our device drivers. I've taken the job of managing the communication between Allwinner and you guys since there is some language barrier. Some of the engineers only hardly understand English and most of them do not understand English at all. So if you have questions about documentation or request assistance with some pieces of the code please email me and I will translate it into Chinese and pass it on to the relevant engineer. Also I will then pass on the translated answer back to you. Hopefully this works out All the best greatings from Switzerland David -- David Lanzendörfer OpenSourceSupport GmbH System engineer and supporter http://www.o2s.ch/ -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Communication with Allwinner
That's quite a drag. Also, I have to admit that I'm no programmer, but it would be nice if someone can at least give some pointers on how to use Christian's CM patches. Not to mention that he seems to have moved on from developing for Allwinner, and I'm afraid he might not even reply to my mail given the sheer number of requests he gets. What I only wanted was an alternative Cyanogenmod distribution others can work on rather than making do with something that has since been discontinued by the author. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Communication with Allwinner
Wonder if they're willing to help out with the Cyanogenmod efforts. A dude going by the name of Christian Troy was claimed to have worked with Allwinner employees and released several Cyanogenmod distros for the A31, but the problem is he hasn't released any complete source archives, and others were having trouble building their own CM from scratch. On Sunday, February 15, 2015 at 5:02:38 AM UTC+8, David Lanzendörfer wrote: Hello As you have maybe already heard in IRC I've taken a trip to Zhuhai and met the engineers of Allwinner Technology (全志科技) in person. We decided that we want as much cooperation between the sunxi project and Allwinner as possible for upstreaming our device drivers. I've taken the job of managing the communication between Allwinner and you guys since there is some language barrier. Some of the engineers only hardly understand English and most of them do not understand English at all. So if you have questions about documentation or request assistance with some pieces of the code please email me and I will translate it into Chinese and pass it on to the relevant engineer. Also I will then pass on the translated answer back to you. Hopefully this works out All the best greatings from Switzerland David -- David Lanzendörfer OpenSourceSupport GmbH System engineer and supporter http://www.o2s.ch/ -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/4] i2c: sunxi: Add Reduced Serial Bus (RSB) DT bindings documentation
On Tuesday 24 February 2015 22:01:26 Chen-Yu Tsai wrote:
On Tue, Feb 24, 2015 at 6:37 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 24 February 2015 18:29:02 Chen-Yu Tsai wrote:
+ rsb@01f03400 {
+ compatible = allwinner,sun8i-a23-rsb;
+ reg = 0x01f03400 0x400;
+ interrupts = 0 39 4;
+ clocks = apb0_gates 3;
+ clock-frequency = 300;
+ resets = apb0_rst 3;
+
+ axp223: pmic@2d {
+ compatible = x-powers,axp223, x-powers,axp221;
+ reg = 0x2d;
+ allwinner,rsb-hw-addr = 0x3e3;
+
+ /* ... */
+ };
+ };
I don't really understand the need for having two addresses (runtime
and hardware). Could the runtime address be configured at runtime?
You can, though the driver doesn't support this. I don't think the
I2C subsystem allows arbitrary device insertion during normal
operation, but maybe i2c-dev? I've tried using different addresses
for devices so they do get changed during the probe phase, just
to be sure that the code works, and it's not just sitting at
the address the bootloader used.
In any case, the distinction is more like burnt-in or hardwired
addresses vs software configurable addresses.
The simplest binding would the probably be to only put the
hardware address into the 'reg' property and always assign the
logical addresses dynamically.
Would that add a lot of complexity or does it have any other
downsides?
arnd
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/4] i2c: sunxi: Add Reduced Serial Bus (RSB) DT bindings documentation
On Tue, Feb 24, 2015 at 10:17 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 24 February 2015 22:01:26 Chen-Yu Tsai wrote:
On Tue, Feb 24, 2015 at 6:37 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 24 February 2015 18:29:02 Chen-Yu Tsai wrote:
+ rsb@01f03400 {
+ compatible = allwinner,sun8i-a23-rsb;
+ reg = 0x01f03400 0x400;
+ interrupts = 0 39 4;
+ clocks = apb0_gates 3;
+ clock-frequency = 300;
+ resets = apb0_rst 3;
+
+ axp223: pmic@2d {
+ compatible = x-powers,axp223, x-powers,axp221;
+ reg = 0x2d;
+ allwinner,rsb-hw-addr = 0x3e3;
+
+ /* ... */
+ };
+ };
I don't really understand the need for having two addresses (runtime
and hardware). Could the runtime address be configured at runtime?
You can, though the driver doesn't support this. I don't think the
I2C subsystem allows arbitrary device insertion during normal
operation, but maybe i2c-dev? I've tried using different addresses
for devices so they do get changed during the probe phase, just
to be sure that the code works, and it's not just sitting at
the address the bootloader used.
In any case, the distinction is more like burnt-in or hardwired
addresses vs software configurable addresses.
The simplest binding would the probably be to only put the
hardware address into the 'reg' property and always assign the
logical addresses dynamically.
Would that add a lot of complexity or does it have any other
downsides?
The hardware address is 12 bits wide. Any address higher than
0x3ff will be rejected by the I2C core. The AC100 is at 0xe89.
Assigning addresses dynamically means the driver has to keep
a lookup table to map the hardware address to the logical
address to issue the command to.
There's also the issue of dynamically assigned address colliding
with unlisted devices, though I think this would only happen in
the development / bring up phase of the device.
I think the first issue pretty much rules out putting the
hardware address into 'reg'.
Putting the logical address in the 'reg' property allows the
user to poke unlisted devices using i2c-tools, though this
is not so useful to the average user.
Regards,
ChenYu
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/4] i2c: sunxi: Add Reduced Serial Bus (RSB) DT bindings documentation
On Tue, Feb 24, 2015 at 6:37 PM, Arnd Bergmann a...@arndb.de wrote:
On Tuesday 24 February 2015 18:29:02 Chen-Yu Tsai wrote:
+ rsb@01f03400 {
+ compatible = allwinner,sun8i-a23-rsb;
+ reg = 0x01f03400 0x400;
+ interrupts = 0 39 4;
+ clocks = apb0_gates 3;
+ clock-frequency = 300;
+ resets = apb0_rst 3;
+
+ axp223: pmic@2d {
+ compatible = x-powers,axp223, x-powers,axp221;
+ reg = 0x2d;
+ allwinner,rsb-hw-addr = 0x3e3;
+
+ /* ... */
+ };
+ };
The child node cannot have a 'reg' property if the parent does not
have #address-cells/#size-cells. You should add these as mandatory
properties in the list.
Oops. I'll add them. A few of the other i2c bindings seem to be missing
it as well. Probably why I missed it.
I don't really understand the need for having two addresses (runtime
and hardware). Could the runtime address be configured at runtime?
You can, though the driver doesn't support this. I don't think the
I2C subsystem allows arbitrary device insertion during normal
operation, but maybe i2c-dev? I've tried using different addresses
for devices so they do get changed during the probe phase, just
to be sure that the code works, and it's not just sitting at
the address the bootloader used.
In any case, the distinction is more like burnt-in or hardwired
addresses vs software configurable addresses.
Alternatively, could you use #address-cells=2 and put both into
'reg'?
I sort of looked into it, and it seems the I2C subsystem won't mind
the extra address cell. Maxime also asked whether we could use 2
addresses, possibly with a reg-names property. Using 2 cells is simpler
though.
I'm open to other options, but I'd like to get some input, especially
from the device tree maintainers, before I change it.
Regards,
ChenYu
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
From: Steven Saunderson essat2...@gmail.com Sent: Tuesday, 24 February 2015, 10:28 Subject: Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth Today I've tested asserting and negating RTS at various times. Host RTS must be asserted at the end of the reset pulse and for 30ms after to get the device to assert its RTS (our CTS). Since I check for CTS before sending this causes the program to time out. The timing is good to know. Does it still work if you wait 10ms after the end of the reset pulse and then assert RTS for 20ms? If it does then it suggests the controller needs a few millisecond to re-initialise, the manual says 4.2ms of sleep occurs during initialisation, and then it needs a sufficiently long pulse on its CTS as zero (host RTS asserted) for it to recognise UART is the transport. I'm wondering if the GPIO script is necessary. The BCM20710 manual states on p.29 The CTS and RTS signals of the UART interface are used for BT wake (CTS) and Host wake (RTS) functions in addition to their normal function on the UART interface. Note that this applies for both H4 and H5 protocols. So asserting RTS on the host will wake the controller (its CTS goes low). This would mean the BT_WAKE GPIO would be unnecessary. Also the Broadcom tool sends an HCI reset command first. Could this be the same kind of reset as the GPIO control line? If so then the problem could be simply setting up the UART on the host correctly. The command stty -F /dev/ttyS1 --all on the 3.4 kernel and stty -F /dev/ttyS2 --all on the 3.19 kernel might give a clue as to what has changed in the initial configuration of the serial lines. Also for testing I wonder if cat /dev/ttyS2 | hexdump -C on one host terminal then something like echo -n -e \x01\x03\x0c\x00 /dev/ttyS2 on another host terminal would be any help. This example is the HCI reset command, but it may be a simple echo of any text would be enough to demonstrate the host and controller are talking correctly. The device apparently doesn't send when host RTS is negated. The responses are buffered because I can get them later when I assert RTS. This is good. It shows that full duplex handshaking is taking place. The best explanation I could find of this was https://bluegiga.zendesk.com/entries/23143152--REFERENCE-Using-or-bypassing-flow-control-with-UART-communication I think the host UART driver ( serial8250 ) should be dealing with the handshaking. It is hopefully just a question of getting it configured correctly at start up. I tried sending some H5-specific commands but got no response. Ho hum, another theory bites the dust. Thanks for trying it. Al -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH sunxi-tools 2/5] fel: Disable MMU to get more SRAM space and fix A13 problems
On Tue, 24 Feb 2015 18:08:55 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 02/24/2015 03:18 AM, Siarhei Siamashka wrote: The FEL BROM code has the MMU enabled for some reason (while I-cache and D-cache are disabled). Most likely the intention was to get a somewhat better performance. Everything is mapped as TEXCB=0 (strongly ordered), except for the 0x (SRAM) and 0xFFF0 (BROM) sections, which are mapped as TEXCB=00100 (normal uncached memory). This becomes a problem for the A13 SoC, because it has less SRAM than the other chips. A13 stores the MMU addresses translation table at 0x8000 and uses up 16 KiB of the SRAM space there (while the A10, A20 and A31s keep the MMU table in the secure SRAM at 0x2). And because the 'spl' command needs space for backing up the FEL stacks, it was clashing with the MMU table. The solution is simple. We just backup the addresses translation table and disable the MMU before running the SPL. And then restore it back to the original state. This fixes problems on A13. Re-enabling the MMU in the end is only necessary to avoid performance losses. For example, the transfer speed of the 'fel write' command on A20 would drop from ~320 KB/s to ~260 KB/s without MMU. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com Hmm, this is not ideal, but seems to be the only way, so: Acked-by: Hans de Goede hdego...@redhat.com It's not too bad. In fact I was puzzled about the whole purpose of having the MMU enabled in the first place. The only reasonable explanation is that it was a half-baked attempt to do performance tuning by picking somewhat better section attributes (which I'm in fact improving in the patch 3/5 to gain a real performance boost). If the MMU is not enabled, then by default memory is assumed to be cacheable for instruction fetches and strongly ordered for data accesses. And the U-Boot SPL disables the MMU as one of the first steps in start.S anyway. Here it only means a waste of 16 KiB of SRAM for us. So disabling the MMU while the SPL is running is quite reasonable. And this provides a valuable storage space, which guarantees the availability of full 32 KiB of SRAM for the SPL :-) I was even tempted to change the code to always use the MMU area as a backup storage space on all SoC variants. Re-enabling the MMU is still useful after the SPL has finished running, because the 'fel' tool potentially needs to upload large amounts of data to the DRAM at this stage. And here the performance does matter. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH sunxi-tools 3/5] fel: Faster USB transfers via 'fel write' to DRAM
On Tue, 24 Feb 2015 04:18:43 +0200
Siarhei Siamashka siarhei.siamas...@gmail.com wrote:
By adjusting the MMU translation table before restoring it
and by enabling the I-cache with branch prediction, we can
improve performance. The DRAM area (0x4000-0xC000)
becomes write-combine mapped and the BROM code becomes mapped
as cacheable memory. This is expected to be safe and should
not cause any coherency problems.
Transfer speed improvements:
A10 : ~330 KB/s - ~600 KB/s
A13 : ~330 KB/s - ~600 KB/s
A20 : ~320 KB/s - ~960 KB/s
A31s : ~250 KB/s - ~510 KB/s
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
---
fel.c | 35 +++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/fel.c b/fel.c
index e4d01a1..ed3bf64 100644
--- a/fel.c
+++ b/fel.c
@@ -473,9 +473,11 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle
*usb)
uint32_t i;
uint32_t arm_code[] = {
- /* Disable MMU */
+ /* Disable I-cache, MMU and branch prediction */
htole32(0xee110f10), /* mrc15, 0, r0, cr1, cr0, {0} */
htole32(0xe3c1), /* bicr0, r0, #1*/
+ htole32(0xe3c00a01), /* bicr0, r0, #4096 */
+ htole32(0xe3c00b02), /* bicr0, r0, #2048 */
htole32(0xee010f10), /* mcr15, 0, r0, cr1, cr0, {0} */
/* Return back to FEL */
htole32(0xe12fff1e), /* bx lr*/
@@ -513,7 +515,7 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle
*usb)
}
}
- pr_info(Disabling MMU...);
+ pr_info(Disabling I-cache, MMU and branch prediction...);
aw_fel_write(usb, arm_code, FEL_EXEC_SCRATCH_AREA, sizeof(arm_code));
aw_fel_execute(usb, FEL_EXEC_SCRATCH_AREA);
pr_info( done.\n);
@@ -527,20 +529,45 @@ void aw_restore_and_enable_mmu(libusb_device_handle
*usb, uint32_t *tt)
uint32_t ttbr0 = aw_get_ttbr0(usb);
uint32_t arm_code[] = {
- /* Enable MMU */
+ /* Invalidate I-cache, TLB and BTB */
+ htole32(0xe3a0), /* movr0, #0*/
+ htole32(0xee080f17), /* mcr15, 0, r0, cr8, cr7, {0} */
+ htole32(0xee070f15), /* mcr15, 0, r0, cr7, cr5, {0} */
+ htole32(0xee070fd5), /* mcr15, 0, r0, cr7, cr5, {6} */
+ htole32(0xf57ff04f), /* dsbsy*/
+ htole32(0xf57ff06f), /* isbsy*/
+ /* Enable I-cache, MMU and branch prediction */
htole32(0xee110f10), /* mrc15, 0, r0, cr1, cr0, {0} */
htole32(0xe381), /* orrr0, r0, #1*/
+ htole32(0xe3800a01), /* orrr0, r0, #4096 */
+ htole32(0xe3800b02), /* orrr0, r0, #2048 */
htole32(0xee010f10), /* mcr15, 0, r0, cr1, cr0, {0} */
/* Return back to FEL */
htole32(0xe12fff1e), /* bx lr*/
};
+ pr_info(Setting write-combine mapping for DRAM.\n);
+ for (i = (DRAM_BASE 20); i ((DRAM_BASE + DRAM_SIZE) 20); i++) {
+ /* Clear TEXCB bits */
+ tt[i] = ~((7 12) | (1 3) || (1 2));
A typo spotted, '|' needs to be used instead of '||' here.
In fact it does not affect anything, because the bits in question are
already set to 0 (strongly ordered memory). And the bit 0, which is
cleared by mistake, is already set to 0 too.
+ /* Set TEXCB to 00100 (Normal uncached mapping) */
+ tt[i] |= (1 12);
+ }
+
+ pr_info(Setting cached mapping for BROM.\n);
+ /* Clear TEXCB bits first */
+ tt[0xFFF] = ~((7 12) | (1 3) || (1 2));
The same here. And the typo also does not affect anything.
+ /* Set TEXCB to 00111 (Normal write-back cached mapping) */
+ tt[0xFFF] |= (1 12) | /* TEX */
+ (1 3) | /* C */
+ (1 2); /* B */
+
pr_info(Writing back the MMU translation table.\n);
for (i = 0; i 4096; i++)
tt[i] = htole32(tt[i]);
aw_fel_write(usb, tt, ttbr0, 16 * 1024);
- pr_info(Enabling MMU...);
+ pr_info(Enabling I-cache, MMU and branch prediction...);
aw_fel_write(usb, arm_code, FEL_EXEC_SCRATCH_AREA, sizeof(arm_code));
aw_fel_execute(usb, FEL_EXEC_SCRATCH_AREA);
pr_info( done.\n);
I'll fix these problems when pushing the patch.
--
Best regards,
Siarhei Siamashka
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more
Re: [linux-sunxi] [PATCH sunxi-tools 4/5] fel: Fix USB timeout on large transfers
Hi,
On 02/24/2015 03:18 AM, Siarhei Siamashka wrote:
Trying to use oversized initrd files (20 MB or more) can fail
with the libusb usb_bulk_send error -1 error message.
To address this problem, we can split the transfer into smaller
chunks and the problem disappears. Effectively, this is a revert
of the older fel: Increase timeout to 60 seconds instead of
splitting bulk transfers commmit.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Looks good:
Acked-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
fel.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/fel.c b/fel.c
index ed3bf64..965b270 100644
--- a/fel.c
+++ b/fel.c
@@ -73,11 +73,14 @@ static void pr_info(const char *fmt, ...)
}
}
+static const int AW_USB_MAX_BULK_SEND = 4 * 1024 * 1024; // 4 MiB per bulk
request
+
void usb_bulk_send(libusb_device_handle *usb, int ep, const void *data, int
length)
{
int rc, sent;
while (length 0) {
- rc = libusb_bulk_transfer(usb, ep, (void *)data, length, sent,
timeout);
+ int len = length AW_USB_MAX_BULK_SEND ? length :
AW_USB_MAX_BULK_SEND;
+ rc = libusb_bulk_transfer(usb, ep, (void *)data, len, sent,
timeout);
if (rc != 0) {
fprintf(stderr, libusb usb_bulk_send error %d\n, rc);
exit(2);
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH sunxi-tools 3/5] fel: Faster USB transfers via 'fel write' to DRAM
Hi,
On 02/24/2015 03:18 AM, Siarhei Siamashka wrote:
By adjusting the MMU translation table before restoring it
and by enabling the I-cache with branch prediction, we can
improve performance. The DRAM area (0x4000-0xC000)
becomes write-combine mapped and the BROM code becomes mapped
as cacheable memory. This is expected to be safe and should
not cause any coherency problems.
Transfer speed improvements:
A10 : ~330 KB/s - ~600 KB/s
A13 : ~330 KB/s - ~600 KB/s
A20 : ~320 KB/s - ~960 KB/s
A31s : ~250 KB/s - ~510 KB/s
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Looks good:
Acked-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
fel.c | 35 +++
1 file changed, 31 insertions(+), 4 deletions(-)
diff --git a/fel.c b/fel.c
index e4d01a1..ed3bf64 100644
--- a/fel.c
+++ b/fel.c
@@ -473,9 +473,11 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle
*usb)
uint32_t i;
uint32_t arm_code[] = {
- /* Disable MMU */
+ /* Disable I-cache, MMU and branch prediction */
htole32(0xee110f10), /* mrc15, 0, r0, cr1, cr0, {0} */
htole32(0xe3c1), /* bicr0, r0, #1*/
+ htole32(0xe3c00a01), /* bicr0, r0, #4096 */
+ htole32(0xe3c00b02), /* bicr0, r0, #2048 */
htole32(0xee010f10), /* mcr15, 0, r0, cr1, cr0, {0} */
/* Return back to FEL */
htole32(0xe12fff1e), /* bx lr*/
@@ -513,7 +515,7 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle
*usb)
}
}
- pr_info(Disabling MMU...);
+ pr_info(Disabling I-cache, MMU and branch prediction...);
aw_fel_write(usb, arm_code, FEL_EXEC_SCRATCH_AREA, sizeof(arm_code));
aw_fel_execute(usb, FEL_EXEC_SCRATCH_AREA);
pr_info( done.\n);
@@ -527,20 +529,45 @@ void aw_restore_and_enable_mmu(libusb_device_handle *usb,
uint32_t *tt)
uint32_t ttbr0 = aw_get_ttbr0(usb);
uint32_t arm_code[] = {
- /* Enable MMU */
+ /* Invalidate I-cache, TLB and BTB */
+ htole32(0xe3a0), /* movr0, #0*/
+ htole32(0xee080f17), /* mcr15, 0, r0, cr8, cr7, {0} */
+ htole32(0xee070f15), /* mcr15, 0, r0, cr7, cr5, {0} */
+ htole32(0xee070fd5), /* mcr15, 0, r0, cr7, cr5, {6} */
+ htole32(0xf57ff04f), /* dsbsy*/
+ htole32(0xf57ff06f), /* isbsy*/
+ /* Enable I-cache, MMU and branch prediction */
htole32(0xee110f10), /* mrc15, 0, r0, cr1, cr0, {0} */
htole32(0xe381), /* orrr0, r0, #1*/
+ htole32(0xe3800a01), /* orrr0, r0, #4096 */
+ htole32(0xe3800b02), /* orrr0, r0, #2048 */
htole32(0xee010f10), /* mcr15, 0, r0, cr1, cr0, {0} */
/* Return back to FEL */
htole32(0xe12fff1e), /* bx lr*/
};
+ pr_info(Setting write-combine mapping for DRAM.\n);
+ for (i = (DRAM_BASE 20); i ((DRAM_BASE + DRAM_SIZE) 20); i++) {
+ /* Clear TEXCB bits */
+ tt[i] = ~((7 12) | (1 3) || (1 2));
+ /* Set TEXCB to 00100 (Normal uncached mapping) */
+ tt[i] |= (1 12);
+ }
+
+ pr_info(Setting cached mapping for BROM.\n);
+ /* Clear TEXCB bits first */
+ tt[0xFFF] = ~((7 12) | (1 3) || (1 2));
+ /* Set TEXCB to 00111 (Normal write-back cached mapping) */
+ tt[0xFFF] |= (1 12) | /* TEX */
+(1 3) | /* C */
+(1 2); /* B */
+
pr_info(Writing back the MMU translation table.\n);
for (i = 0; i 4096; i++)
tt[i] = htole32(tt[i]);
aw_fel_write(usb, tt, ttbr0, 16 * 1024);
- pr_info(Enabling MMU...);
+ pr_info(Enabling I-cache, MMU and branch prediction...);
aw_fel_write(usb, arm_code, FEL_EXEC_SCRATCH_AREA, sizeof(arm_code));
aw_fel_execute(usb, FEL_EXEC_SCRATCH_AREA);
pr_info( done.\n);
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH sunxi-tools 2/5] fel: Disable MMU to get more SRAM space and fix A13 problems
Hi,
On 02/24/2015 03:18 AM, Siarhei Siamashka wrote:
The FEL BROM code has the MMU enabled for some reason (while
I-cache and D-cache are disabled). Most likely the intention was
to get a somewhat better performance. Everything is mapped as
TEXCB=0 (strongly ordered), except for the 0x (SRAM)
and 0xFFF0 (BROM) sections, which are mapped as TEXCB=00100
(normal uncached memory).
This becomes a problem for the A13 SoC, because it has less SRAM
than the other chips. A13 stores the MMU addresses translation
table at 0x8000 and uses up 16 KiB of the SRAM space there (while
the A10, A20 and A31s keep the MMU table in the secure SRAM at
0x2). And because the 'spl' command needs space for backing
up the FEL stacks, it was clashing with the MMU table.
The solution is simple. We just backup the addresses translation
table and disable the MMU before running the SPL. And then restore
it back to the original state. This fixes problems on A13.
Re-enabling the MMU in the end is only necessary to avoid performance
losses. For example, the transfer speed of the 'fel write' command
on A20 would drop from ~320 KB/s to ~260 KB/s without MMU.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Hmm, this is not ideal, but seems to be the only way, so:
Acked-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
fel.c | 127 ++
1 file changed, 127 insertions(+)
diff --git a/fel.c b/fel.c
index 0942deb..e4d01a1 100644
--- a/fel.c
+++ b/fel.c
@@ -429,6 +429,126 @@ static uint32_t fel_to_spl_thunk[] = {
#include fel-to-spl-thunk.h
};
+#defineFEL_EXEC_SCRATCH_AREA 0x2000
+#defineDRAM_BASE 0x4000
+#defineDRAM_SIZE 0x8000
+
+uint32_t aw_get_ttbr0(libusb_device_handle *usb)
+{
+ uint32_t ttbr0 = 0;
+ uint32_t arm_code[] = {
+ htole32(0xee122f10), /* mrc15, 0, r2, cr2, cr0, {0} */
+ htole32(0xe58f2008), /* strr2, [pc, #8] */
+ htole32(0xe12fff1e), /* bx lr*/
+ };
+
+ aw_fel_write(usb, arm_code, FEL_EXEC_SCRATCH_AREA, sizeof(arm_code));
+ aw_fel_execute(usb, FEL_EXEC_SCRATCH_AREA);
+ aw_fel_read(usb, 0x2014, ttbr0, sizeof(ttbr0));
+ ttbr0 = le32toh(ttbr0);
+ return ttbr0;
+}
+
+uint32_t aw_get_sctlr(libusb_device_handle *usb)
+{
+ uint32_t sctlr = 0;
+ uint32_t arm_code[] = {
+ htole32(0xee112f10), /* mrc15, 0, r2, cr1, cr0, {0} */
+ htole32(0xe58f2008), /* strr2, [pc, #8] */
+ htole32(0xe12fff1e), /* bx lr*/
+ };
+
+ aw_fel_write(usb, arm_code, FEL_EXEC_SCRATCH_AREA, sizeof(arm_code));
+ aw_fel_execute(usb, FEL_EXEC_SCRATCH_AREA);
+ aw_fel_read(usb, 0x2014, sctlr, sizeof(sctlr));
+ sctlr = le32toh(sctlr);
+ return sctlr;
+}
+
+uint32_t *aw_backup_and_disable_mmu(libusb_device_handle *usb)
+{
+ uint32_t *tt = malloc(16 * 1024);
+ uint32_t ttbr0 = aw_get_ttbr0(usb);
+ uint32_t sctlr = aw_get_sctlr(usb);
+ uint32_t i;
+
+ uint32_t arm_code[] = {
+ /* Disable MMU */
+ htole32(0xee110f10), /* mrc15, 0, r0, cr1, cr0, {0} */
+ htole32(0xe3c1), /* bicr0, r0, #1*/
+ htole32(0xee010f10), /* mcr15, 0, r0, cr1, cr0, {0} */
+ /* Return back to FEL */
+ htole32(0xe12fff1e), /* bx lr*/
+ };
+
+ if (!(sctlr 1)) {
+ fprintf(stderr, MMU is not enabled by BROM\n);
+ exit(1);
+ }
+
+ if ((sctlr 28) 1) {
+ fprintf(stderr, TEX remap is enabled!\n);
+ exit(1);
+ }
+
+ if (ttbr0 0x3FFF) {
+ fprintf(stderr, Unexpected TTBR0 (%08X)\n, ttbr0);
+ exit(1);
+ }
+
+ pr_info(Reading the MMU translation table from 0x%08X\n, ttbr0);
+ aw_fel_read(usb, ttbr0, tt, 16 * 1024);
+ for (i = 0; i 4096; i++)
+ tt[i] = le32toh(tt[i]);
+
+ /* Basic sanity checks to be sure that this is a valid table */
+ for (i = 0; i 4096; i++) {
+ if (((tt[i] 1) 1) != 1 || ((tt[i] 18) 1) != 0) {
+ fprintf(stderr, MMU: not a section descriptor\n);
+ exit(1);
+ }
+ if ((tt[i] 20) != i) {
+ fprintf(stderr, MMU: not a direct mapping\n);
+ exit(1);
+ }
+ }
+
+ pr_info(Disabling MMU...);
+ aw_fel_write(usb, arm_code, FEL_EXEC_SCRATCH_AREA, sizeof(arm_code));
+ aw_fel_execute(usb, FEL_EXEC_SCRATCH_AREA);
+ pr_info( done.\n);
+
+ return tt;
+}
+
+void
Re: [U-Boot] [linux-sunxi] [PATCH] sunxi: Make CONFIG_DRAM_TPR3 apply to sun[57]i
Hi,
On 02/24/2015 03:53 AM, Siarhei Siamashka wrote:
On Mon, 23 Feb 2015 20:44:10 +
Adam Sampson a...@offog.org wrote:
The tpr3 (timing skew) parameter is used in all supported versions of
the sunxi DRAM controller, but it was only enabled for sun4i in
47e3501a76894f4ba08bc61f33774bd5d39ff464.
Signed-off-by: Adam Sampson a...@offog.org
---
board/sunxi/dram_sun5i_auto.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/board/sunxi/dram_sun5i_auto.c b/board/sunxi/dram_sun5i_auto.c
index e52d54c..660b18e 100644
--- a/board/sunxi/dram_sun5i_auto.c
+++ b/board/sunxi/dram_sun5i_auto.c
@@ -24,7 +24,7 @@ static struct dram_para dram_para = {
# include dram_timings_sun4i.h
.active_windowing = 1,
#endif
- .tpr3 = 0,
+ .tpr3 = CONFIG_DRAM_TPR3,
.tpr4 = 0,
.tpr5 = 0,
.emr1 = CONFIG_DRAM_EMR1,
Oops. Thanks for spotting this.
Acked-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Thanks!
Queued up in u-boot-sunxi/next for merging, with Siarhei's ack,
Regards,
Hans
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH sunxi-tools 1/5] fel: Add --verbose option and implement transfer speed reporting
Hi,
On 02/24/2015 03:18 AM, Siarhei Siamashka wrote:
This allows to measure the USB data transfer speed for performance
tuning purposes.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Looks good:
Acked-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
fel.c | 38 +-
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/fel.c b/fel.c
index d18a1d8..0942deb 100644
--- a/fel.c
+++ b/fel.c
@@ -28,8 +28,10 @@
#include ctype.h
#include stdlib.h
#include stdio.h
+#include stdarg.h
#include errno.h
#include unistd.h
+#include sys/time.h
#include endian_compat.h
@@ -59,6 +61,17 @@ static const int AW_USB_WRITE = 0x12;
static int AW_USB_FEL_BULK_EP_OUT;
static int AW_USB_FEL_BULK_EP_IN;
static int timeout = 6;
+static int verbose = 0; /* Makes the 'fel' tool more talkative if non-zero */
+
+static void pr_info(const char *fmt, ...)
+{
+ va_list arglist;
+ if (verbose) {
+ va_start(arglist, fmt);
+ vprintf(fmt, arglist);
+ va_end(arglist);
+ }
+}
void usb_bulk_send(libusb_device_handle *usb, int ep, const void *data, int
length)
{
@@ -566,6 +579,14 @@ static int aw_fel_get_endpoint(libusb_device_handle *usb)
return 0;
}
+/* Less reliable than clock_gettime, but does not require linking with -lrt */
+static double gettime(void)
+{
+ struct timeval tv;
+ gettimeofday(tv, NULL);
+ return tv.tv_sec + (double)tv.tv_usec / 100.;
+}
+
int main(int argc, char **argv)
{
int rc;
@@ -575,7 +596,8 @@ int main(int argc, char **argv)
assert(rc == 0);
if (argc = 1) {
- printf(Usage: %s command arguments... [command...]\n
+ printf(Usage: %s [options] command arguments... [command...]\n
+ -v, --verbose Verbose logging\n
hex[dump] address lengthDumps memory region in
hex\n
dump address length Binary memory dump\n
exe[cute] address Call function
address\n
@@ -616,6 +638,13 @@ int main(int argc, char **argv)
exit(1);
}
+ if (argc 1 (strcmp(argv[1], --verbose) == 0 ||
+strcmp(argv[1], -v) == 0)) {
+ verbose = 1;
+ argc -= 1;
+ argv += 1;
+ }
+
while (argc 1 ) {
int skip = 1;
if (strncmp(argv[1], hex, 3) == 0 argc 3) {
@@ -632,9 +661,16 @@ int main(int argc, char **argv)
aw_fel_print_version(handle);
skip=1;
} else if (strcmp(argv[1], write) == 0 argc 3) {
+ double t1, t2;
size_t size;
void *buf = load_file(argv[3], size);
+ t1 = gettime();
aw_fel_write(handle, buf, strtoul(argv[2], NULL, 0),
size);
+ t2 = gettime();
+ if (t2 t1)
+ pr_info(Written %.1f KB in %.1f sec (speed: %.1f
KB/s)\n,
+ (double)size / 1000., t2 - t1,
+ (double)size / (t2 - t1) / 1000.);
free(buf);
skip=3;
} else if (strcmp(argv[1], read) == 0 argc 4) {
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH sunxi-tools 5/5] fel: Set the AUXCR L2EN bit for A10/A13
Hi,
On 02/24/2015 03:18 AM, Siarhei Siamashka wrote:
This is needed to have feature parity with the normal boot mode,
where the L2EN bit in the CP15 Auxiliary Control Register is set
by the BROM code right from the start. And if L2EN is not set,
then the Linux system ends up booted with the L2 cache disabled.
According to the Cortex-A8 TRM, the L2 cache is only enabled when
both L2EN bit and the C bit from the CP15 Control Register c1 are
set. Because the BROM does not set the C bit, this change should
not affect the functionality of the FEL mode in any way.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Wouldn't it be better to do this in u-boot ?
Regards,
Hans
p.s.
I'll go give this a test-run on an A23 tablet.
---
fel.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/fel.c b/fel.c
index 965b270..9ab0fe1 100644
--- a/fel.c
+++ b/fel.c
@@ -338,6 +338,7 @@ typedef struct {
uint32_t soc_id; /* ID of the SoC */
uint32_t thunk_addr; /* Address of the thunk code */
uint32_t thunk_size; /* Maximal size of the thunk code */
+ uint32_t needs_l2en; /* Set the L2EN bit */
sram_swap_buffers *swap_buffers;
} soc_sram_info;
@@ -373,11 +374,13 @@ soc_sram_info soc_sram_info_table[] = {
.soc_id = 0x1623, /* Allwinner A10 */
.thunk_addr = 0xAE00, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
+ .needs_l2en = 1,
},
{
.soc_id = 0x1625, /* Allwinner A13 */
.thunk_addr = 0xAE00, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
+ .needs_l2en = 1,
},
{
.soc_id = 0x1651, /* Allwinner A20 */
@@ -436,6 +439,19 @@ static uint32_t fel_to_spl_thunk[] = {
#define DRAM_BASE 0x4000
#define DRAM_SIZE 0x8000
+void aw_enable_l2_cache(libusb_device_handle *usb)
+{
+ uint32_t arm_code[] = {
+ htole32(0xee112f30), /* mrc15, 0, r2, cr1, cr0, {1} */
+ htole32(0xe3822002), /* orrr2, r2, #2*/
+ htole32(0xee012f30), /* mcr15, 0, r2, cr1, cr0, {1} */
+ htole32(0xe12fff1e), /* bx lr*/
+ };
+
+ aw_fel_write(usb, arm_code, FEL_EXEC_SCRATCH_AREA, sizeof(arm_code));
+ aw_fel_execute(usb, FEL_EXEC_SCRATCH_AREA);
+}
+
uint32_t aw_get_ttbr0(libusb_device_handle *usb)
{
uint32_t ttbr0 = 0;
@@ -619,6 +635,11 @@ void aw_fel_write_and_execute_spl(libusb_device_handle
*usb,
exit(1);
}
+ if (sram_info-needs_l2en) {
+ pr_info(Enabling the L2 cache\n);
+ aw_enable_l2_cache(usb);
+ }
+
tt = aw_backup_and_disable_mmu(usb);
swap_buffers = sram_info-swap_buffers;
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH sunxi-tools 5/5] fel: Set the AUXCR L2EN bit for A10/A13
On Tue, 24 Feb 2015 18:11:22 +0100 Hans de Goede hdego...@redhat.com wrote: Hi, On 02/24/2015 03:18 AM, Siarhei Siamashka wrote: This is needed to have feature parity with the normal boot mode, where the L2EN bit in the CP15 Auxiliary Control Register is set by the BROM code right from the start. And if L2EN is not set, then the Linux system ends up booted with the L2 cache disabled. According to the Cortex-A8 TRM, the L2 cache is only enabled when both L2EN bit and the C bit from the CP15 Control Register c1 are set. Because the BROM does not set the C bit, this change should not affect the functionality of the FEL mode in any way. Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com Wouldn't it be better to do this in u-boot ? Yes, it was originally a patch for u-boot. But now I'm not so sure. The 'fel' tool tries to abstract this stuff and make the SPL uploaded via FEL look functionally equivalent to loading it from an SD card (except for patching the eGON.BT0 signature in memory and also using some areas in SRAM outside the first 32 KiB). The L2EN bit setup differs for the SD card boot and the FEL mode cases. So the 'fel' tool tries to correct this defect. Just because it can. Regards, Hans p.s. I'll go give this a test-run on an A23 tablet. Thanks! It is also useful to test this with oversized SPLs (larger than 22 KiB). A23 most likely needs to use the same table entry as A31 to unlock full 32 KiB for the SPL. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] CubieTruck internal UARTs with 3.19 kernel for Bluetooth
On Wednesday, February 25, 2015 at 12:51:13 AM UTC+11, Al Thomas wrote: Host RTS must be asserted at the end of the reset pulse and for 30ms after to get the device to assert its RTS (our CTS). Since I check for CTS before sending this causes the program to time out. The timing is good to know. Does it still work if you wait 10ms after the end of the reset pulse and then assert RTS for 20ms? If it does then it suggests the controller needs a few millisecond to re-initialise, the manual says 4.2ms of sleep occurs during initialisation, and then it needs a sufficiently long pulse on its CTS as zero (host RTS asserted) for it to recognise UART is the transport. If CTS isn't low at the end of the reset pulse the device apparently doesn't react. Besides, any boot process that relied on a signal change at some precise point after the reset pulse would be inherently unreliable in a multi-tasking environment. I'm wondering if the GPIO script is necessary. The BCM20710 manual states on p.29 The CTS and RTS signals of the UART interface are used for BT wake (CTS) and Host wake (RTS) functions in addition to their normal function on the UART interface. Note that this applies for both H4 and H5 protocols. So asserting RTS on the host will wake the controller (its CTS goes low). This would mean the BT_WAKE GPIO would be unnecessary. Yes, playing with BT_WAKE is probably insignificant. But toggling BT_REST is critical unless the device is already in UART mode. Also the Broadcom tool sends an HCI reset command first. Could this be the same kind of reset as the GPIO control line? I don't think so. The firmware download is preceded and suceeded by HCI_reset. So HCI_reset doesn't clear the device RAM. But BT_REST powers off the device and I assume this will clear its RAM. I think the host UART driver ( serial8250 ) should be dealing with the handshaking. It is hopefully just a question of getting it configured correctly at start up. This could make things simpler. If you can configure the serial port for a null-modem environment then it might be possible to use the standard program. Cheers, Steven -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Allwinner GPL violations: definitive proof.
This was just posted on the allwinner github account: https://github.com/allwinner-zh/media-codec This contains: https://github.com/allwinner-zh/media-codec/blob/master/sunxi-cedarx/LIBRARY/CODEC/VIDEO/DECODER/libvdecoder.so This binary contains symbols from both ffmpeg (LGPL, but altered/hacked up) and libVP62 (anti-compiled from java, and taken off the web in 2006). The LGPL forces Allwinner to produce the full and complete source code of these binaries. How they are going to explain libVP62 to On2 Technologies, now google, is beyond me (cfr. http://en.wikipedia.org/wiki/VP6) With all the previous indiscretions, it was always possible to claim that there was some chance that Allwinner was not the source of the many violations. It was always pretty clear that Allwinner was the source, there were just too many coincidences, the violation was too all encompassing, and not a single device maker spilled the goods. The fact that they threw out a kernel tree with most code and all binaries removed, was, despite being a ludicrous and laughable action, another very clear sign that Allwinner was indeed the source of these violations. Now however, the fact that allwinner posted this very clearly shows that Allwinner is the source. It is absolutely unequivocal this time round. To top this off, it is 6 months after the last GPL violation shitstorm. This puts serious doubts behind the claims that Allwinner truly is learning and willing to cooperate. Allwinner, it is very high time to start playing nice. You've been at it for 4 years now and seem utterly incapable of or unwilling to change. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
