[linux-sunxi] Re: [PATCH v6] dma: sun4i: Add support for the DMA engine on sun[457]i SoCs
On Mon, May 18, 2015 at 02:16:14PM +0530, Vinod Koul wrote:
+static enum dma_status sun4i_dma_tx_status(struct dma_chan *chan,
+ dma_cookie_t cookie,
+ struct dma_tx_state *state)
+{
+ struct sun4i_dma_vchan *vchan = to_sun4i_dma_vchan(chan);
+ struct sun4i_dma_pchan *pchan = vchan-pchan;
+ struct sun4i_dma_contract *contract;
+ struct sun4i_dma_promise *promise;
+ struct virt_dma_desc *vd;
+ unsigned long flags;
+ enum dma_status ret;
+ size_t bytes = 0;
+
+ ret = dma_cookie_status(chan, cookie, state);
+ if (ret == DMA_COMPLETE)
+ return ret;
Pls check if state is valid before progressing ahead
Just one more question about this one. What should we return in the
case where state would be NULL ? DMA_ERROR?
Thanks,
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
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: Digital signature
[linux-sunxi] Re: [PATCH 2/3] MTD: spi-nor: check for short writes in spi_nor_write.
On 21 May 2015 at 01:38, Brian Norris computersforpe...@gmail.com wrote: + linux-spi, Mark On Thu, Apr 30, 2015 at 03:38:50PM +0200, Michal Suchanek wrote: My SPI controller driver does not support DMA so writes are truncated to FIFO size. Which SPI master driver? I am using sunxi SPI driver. The dmaengine support for sunxi is not yet in mainline kernel so the SPI master functionality is limited. Check the amount of data actually written by the driver. I'm not sure if we should just reactively use the retlen, or if we should be communicating such a limitation via the SPI API. Thoughts? Is there any driver that would break if the SPI master truncated writes when the message is too long rather than returning an error an refusing the transfer? m25p80 as is would because it assumes all data is always written. Some display driver I tried earlier has an option to limit transfer size actively in the driver. 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.
Re: [linux-sunxi] AXP221 support in sunxi-next may break sd card loading for A31 hummingbird
Hi,
On Thu, May 21, 2015 at 2:38 PM, Lawrence Yu lawy...@gmail.com wrote:
Hi,
On Mon, May 18, 2015 at 11:03 PM, Lawrence Yu lawy...@gmail.com wrote:
Hi,
On Mon, May 18, 2015 at 8:01 PM, Chen-Yu Tsai w...@csie.org wrote:
Hi,
On Mon, May 18, 2015 at 12:08 AM, Lawrence Y lawy...@gmail.com wrote:
Hi,
I'm not sure if it is my sdcard, my A31 hummingboard device, or
something I
am doing wrong, but I've been trying to boot an A31 hummingbird from an
sdcard using the kernel from the sunxi-next branch at
https://github.com/mripard/linux
33da8d2 - Merge tag 'ib-mfd-regulator-v4.2' into sunxi-next
and ran into a problem where the kernel would hang while waiting for
the
root device /dev/mmcblk0p2
If I use the sun6i-a31-hummingbird.dtb built from the linux mainline
the
sdcard will boot the root file system correctly, but if I use the
sun6i-a31-hummingbird.dtb from sunxi-next the kernel will hang while
waiting
for /dev/mmcblk0p2.
I ran a git bisect and narrowed down the commit that causes the problem
I am
seeing to
commit bab03561224baa536b98f1d137d2b6b5dd159763
Date: Tue Mar 10 19:59:21 2015 +0800
ARM: dts: sun6i: hummingbird: Add AXP221 regulator nodes
This patch adds the AXP221 regulators. Only the ones directly used
on the board are added.
Please let me know if there is anything I can do to help fix this
problem,
if it really is a problem. I have an A31 hummingbird available for
testing.
The latest commit you pointed to merges AXP221 support with regulators.
The Hummingbird A31 dts was also updated with the new regulator nodes.
Do you have AXP20X MFD and regulator support enabled?
CONFIG_MFD_AXP20X and CONFIG_REGULATOR_AXP20X should be y.
ChenYu
I tested with the sunxi_defconfig and confirmed that
CONFIG_INPUT_AXP20X_PEK=y
CONFIG_MFD_AXP20X=y
CONFIG_REGULATOR_AXP20X=y
are set in the .config file by the sunxi_defconfig and was used when the
root file system on the mmc card is not detected during the boot.
I did some more experimenting and found that if I change the vmmc-supply
for the mmc0 in the dts from vcc_3v0 to reg_vcc3v0 the root file system on
the sdcard will boot properly
@@ -119,7 +119,7 @@
mmc0 {
pinctrl-names = default;
pinctrl-0 = mmc0_pins_a, mmc0_cd_pin_hummingbird;
- vmmc-supply = vcc_3v0;
+ vmmc-supply = reg_vcc3v0;
bus-width = 4;
cd-gpios = pio 0 8 GPIO_ACTIVE_HIGH; /* PA8 */
cd-inverted;
I am going to try Han's suggestion of using the vcc_3v3 when I get a
chance to see if that makes it better.
Lawrence
I changed the vmmc-supply in the mmc0 dts section to be reg_vcc3v0 from
vcc_3v0 and the tablet seems to boot to login from the sdcard consistently
now.
I'm not sure if the AXP20x module is being loaded or not from the
hummingbird A31 dts file. I did a grep of the dmesg and there is no
occurrence of the string AXP in the dmesg logs during boot. If the AXP20x
module is not being loaded, maybe that could explain why the vcc_3v0 did not
work for the mmc0 section?
You should see something like the following:
axp20x 2-0068: AXP20x variant AXP221 found
input: axp20x-pek as
/devices/platform/soc@01c0/1f03400.i2c/i2c-2/2-0068/axp20x-pek/input/input0
axp20x 2-0068: AXP20X driver loaded
If not, either the AXP driver and/or the P2WI driver is missing.
Since you already mentioned you have AXP enabled, check
CONFIG_I2C_SUN6I_P2WI
for P2WI support. The AXP221 is not a standard I2C chip.
ChenYu
I also added some printk statements to the axp209 probe function that did
not emit anything to the dmesg output, but I'm not sure if that is
conclusive or not since I'm not sure if printk works in the probe.
Maybe someone could suggest a better way to tell if the AXP221 support is
being loaded?
Thanks!
Lawrence
--
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/3] ARM: dts: sun7i: Add uart2 support for BananaPi
On Thu, May 21, 2015 at 02:32:34PM +0200, Hans de Goede wrote: From: Michael Ring m...@michael-ring.org Uart2 is available at the bananapi io-pins, add a dts node for this (so that people can easily enable it) but leave it disabled as the pins are primarily intended for gpio as documented here: http://wiki.lemaker.org/Pin_definition So far the policy we had on this is only to add to the DT the primary purpose of these pins. Even though that might seem arbitrary, it's the only way to prevent anyone adding their own configuration for those pins, which would be a mess to maintain and use. It's even more true since that sort of thing is exactly where the overlays shine. So, I'm ok with adding the uart4, but the uart2 should go. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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: Digital signature
[linux-sunxi] Re: Allwinner R8 module
On Friday, May 15, 2015 at 7:07:53 PM UTC+3, Thomas Towne wrote: Hello anyone. I have Allwinner R8 SOC information and Pinmap information. Hi Thomas! Could you please share Allwinner R8 SOC information and Pinmap information? Maybe upload it somewhere? -- 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 1/3] ARM: dts: sun7i: Add uart4_pins_b definition
On Thu, May 21, 2015 at 02:32:33PM +0200, Hans de Goede wrote: From: Michael Ring m...@michael-ring.org Some boards (e.g. the BananaPro) use alternative pins for uart4, add a pinmux entry for these. Signed-off-by: Michael Ring m...@michael-ring.org Signed-off-by: Hans de Goede hdego...@redhat.com Applied, thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- 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: Digital signature
[linux-sunxi] Re: [PATCH 2/2] nand: sunxi: Add support for booting from internal NAND memory
Hi,
On 21-05-15 15:59, Roy Spliet wrote:
From: Daniel Kochmański dkochman...@turtle-solutions.eu
V2:
- Rename config option
- Move to separate driver
- fix DMA directly into RAM
- Many readability upgrades
- Drop R32 and W32 macros in favour of readl/writel respectively
- Use standard port controller methods for pinctl
- Make many NAND options semi-configurable
Signed-off-by: Roy Spliet r.spl...@ultimaker.com
---
arch/arm/cpu/armv7/sunxi/board.c | 12 +-
arch/arm/include/asm/arch-sunxi/gpio.h | 2 +
board/sunxi/Kconfig| 12 ++
board/sunxi/board.c| 27 +++
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/sunxi_nand_spl.c | 290 +
include/configs/sun4i.h| 1 +
include/configs/sun5i.h| 3 +
include/configs/sun7i.h| 2 +
include/configs/sun8i.h| 6 +
include/configs/sunxi-common.h | 20 +++
11 files changed, 374 insertions(+), 2 deletions(-)
create mode 100644 drivers/mtd/nand/sunxi_nand_spl.c
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 6718ae2..70f413f 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -111,8 +111,10 @@ void s_init(void)
#ifdef CONFIG_SPL_BUILD
/* The sunxi internal brom will try to loader external bootloader
* from mmc0, nand flash, mmc2.
- * Unfortunately we can't check how SPL was loaded so assume
- * it's always the first SD/MMC controller
+ *
+ * Unfortunately we can't check how SPL was loaded so assume it's
+ * always the first SD/MMC controller, unless it was explicitly
+ * stated that SPL is on nand flash.
*/
u32 spl_boot_device(void)
{
@@ -122,6 +124,12 @@ u32 spl_boot_device(void)
* enabled build. It has many restrictions and can only boot over USB.
*/
return BOOT_DEVICE_BOARD;
+#elif defined(CONFIG_SPL_NAND_SUPPORT)
+ /*
+* This is compile time configuration informing SPL, that it
+* was loaded from nand flash.
+*/
+ return BOOT_DEVICE_NAND;
#else
/*
* When booting from the SD card, the eGON.BT0 signature is expected
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 59d8210..2b49616 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -156,6 +156,8 @@ enum sunxi_gpio_number {
#define SUN4I_GPB_UART0 2
#define SUN5I_GPB_UART0 2
+#define SUNXI_GPC_NAND 2
+
#define SUNXI_GPC_SDC23
#define SUN6I_GPC_SDC34
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index a60d028..cf58d73 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -269,6 +269,18 @@ config MMC_SUNXI_SLOT_EXTRA
slot or emmc on mmc1 - mmc3. Setting this to 1, 2 or 3 will enable
support for this.
+config SPL_NAND_SUPPORT
+ bool SPL/NAND mode support
+ depends on SPL
+ default n
+ ---help---
+ This enables support for booting from NAND internal
+ memory. U-Boot SPL doesn't detect where is it load from,
+ therefore this option is needed to properly load image from
+ flash. Option also disables MMC functionality on U-Boot due to
+ initialization errors encountered, when both controllers are
+ enabled.
+
config USB0_VBUS_PIN
string Vbus enable pin for usb0 (otg)
default
There is a way to figure out if you're booting from sdcard or nand
actually, simply check if an sdcard is there and if it has the boot0
signature, if that is true, then we should be booting from sd, as those
are the checks the brom does itself to determine what to boot (*).
Since we support booting from internal emmc on boars which have it.
and those are connected to mmc2 rather then mmc0 we already have code
to check for this, see board/sunxi/board.c: board_mmc_init(), adapting this
for use to determine whether to look u-boot.bin from nand or mmc on
systems which have nand rather an emmc should be trivial.
So we should be able to build uniform SPL (and u-boot) binaries which work
for both nand and sdcard. Note that this is jyst FYI, I'm fine with merging
the patch as is and fixing this in a follow up patch.
*) Note this is not true on the A31 which prefers nand over sdcard unless
the fel pin is pulled down (or was it up), but is true on all other SoCs
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index d9f7691..121e655 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -22,6 +22,9 @@
#ifdef CONFIG_AXP221_POWER
#include axp221.h
#endif
+#ifdef CONFIG_NAND_SUNXI
+#include nand.h
+#endif
#include asm/arch/clock.h
#include asm/arch/cpu.h
#include asm/arch/display.h
@@ -34,6 +37,8 @@
#include linux/usb/musb.h
#include net.h
+#define CCMU_BASE
[linux-sunxi] Re: Proposal to add NAND-boot support for Sunxi SPL
Hi Roy, On 21-05-15 15:59, Roy Spliet wrote: The following patches take the work by Daniel Kochmánski, and make some heavy modifications for readability and functionality, based on Boris Brezillon's Linux driver. Tested on an Olimex Lime w/ A20. Patches are sent as RFC. Open questions: - Config options added are partially NAND-chip specific. Some options can be autodetected based on the NAND ID, others require either brute-forcing or config options like these. Do they belong in sunxi-common? Should we make a Kconfig option for this? If bikeshedding is desired, are defines in sunxi-common.h good enough for now? - Style is mostly kernel-like. Satisfied? - Daniel: do you think we can work from here? Please comment away! Cool stuff. Overall this looks good I'll reply with more detailed feedback to your individual patches, 2 questions: 1) Can you provide a quick howto (at developer level) on how to actually get the spl and u-boot into the nand, what I'm looking for is unstructions like this: a) Take this git repo + branch, build a kernel from it b) Look at this dts file for a nand settings example, adjust it for your board c) Once booted into the kernel using an updated dts you should have these block devices, dd spl to this one, and u-boot to this one. No more to go more detailed then that :) 2) What is the plan to add support for loading files from nand in u-boot proper, so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on nand ? 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 2/2] nand: sunxi: Add support for booting from internal NAND memory
On Thu, 2015-05-21 at 20:39 +0200, Hans de Goede wrote: [...] Please create a struct reflecting the register layout and then initialize a ptr to this struct from the base-address and get register addresses this way, this is how we deal with this in pretty much all other sunxi code, see e.g.: This isn't just sunxi, I believe it is u-boot's preferred way to do things generally. [...] Otherwise this looks like a good start, with the coding style issues fixed I would not be opposed against merging this as a first step to growing proper nand support. Ian, is that ok with you ? You mean with the coding style fixed but not (necessarily) all the other issues you pointed out (timeouts on loops, structs for register accesses)? I think at least the structs for register access stuff should be fixed first, especially given it was already raised in the previous round of review. 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] Re: [PATCH 1/2] nand: sunxi: change BLOCK_SIZE in mksunxiboot to match NAND block size
Hi,
On 21-05-15 15:59, Roy Spliet wrote:
From: Daniel Kochmański dkochman...@turtle-solutions.eu
This change is necessary to calculate correct checksum for NAND
boot. Works both for MMC and NAND. Without it BROM rejects boot image
as invalid (bad checksum). (Changes block size from 0x200 to 0x2000).
V2: Document decision in source too
Signed-off-by: Daniel Kochmański dkochman...@turtle-solutions.eu
Cc: Ian Campbell i...@hellion.org.uk
Cc: Hans De Goede hdego...@redhat.com
Signed-off-by: Roy Spliet r.spl...@ultimaker.com
Looks good: Reviewed-by: Hans de Goede hdego...@redhat.com
Regards,
Hans
---
tools/mksunxiboot.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index 0035f6e..3361251 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -65,7 +65,13 @@ int gen_check_sum(struct boot_file_head *head_p)
#define SUN4I_SRAM_SIZE 0x7600/* 0x7748+ is used by BROM */
#define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct boot_file_head))
-#define BLOCK_SIZE 512
+
+/*
+ * BROM (at least on A10 and A20) requires NAND-images to be explicitly aligned
+ * to a multiple of 8K, and rejects the image otherwise. MMC-images are fine
+ * with 512B blocks. To cater for both, align to the largest of the two.
+ */
+#define BLOCK_SIZE 0x2000
struct boot_img {
struct boot_file_head header;
--
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: [ANNOUNCE] Allwinner releasing CedarX open source
On Wed, May 20, 2015 at 12:05:53AM -0700, Andrea Venturi wrote: Hi Kevin, as a casual tinkerer of Allwinner (AW) SOCs, let me tell you i appreciate A LOT AW attitude and commitment for becoming more and more a proper citizen in the free software and open source community. This release is a step in a continuous process BUT is surely a step in the right direction. THANX! i really think AW, since the last few years, has been doing a breakthrough revolution in the so called internet of things (IoT) space.. not really because there are new features implemented in its SOCs but because AW is packing SO MUCH stuff in a cost effective chip that's enabling the next level of pervasive computing. you are permitting a world of programmable toys that can be effectively used and enable new products; i started playing with A10 some years ago with Tom Cubie's Cubieboard, but i'll cite also Olimex open source boards and Luke Leighton's EOMA86 effort as very interesting developments born thanx to your business proposition; now we are seeing the new H3 sold for 25$ as dev card, Orange PI mini 2, and the next to come Kickstarter campaign for a $9 board named CHIP.. it a staggering progression.. so the SOC is surely beefy, but for it to become cornerstone of new projects for advised people like the ones embodied in the linux-sunxi community, it has to be dependable i.e. you want it to be available and controllable for ever as software development progresses (and as we can see in the open source model, the snowball becomes avalanche pretty fast). that's why full disclosure and datasheets are more preferred than code drops as the latter is just a single representation (in the writer mindset and in the writer context) of a use case, the former gives everyone the freedom to do its own evaluation and choice and development/integration. coming to Cedarx, i for first believe everything now is going in the right direction toward full disclosure, and that's a GOOD THING. i suppose this is happening because the HW core is more or less exclusive of Allwinner chips. a really different issue is around the 2D/3D MALI 400MP core that's the last unknown big black box of the actual AW bulk lineup (i'll keep the PowerVR stuff out of my way with a 10 feet pole.. :-) i understand that, as it's a graphic core used in many competitors chips too, it's difficult for any chip house to step in and make a liberal move, surely it's a CORE out of chipmaker control as it's ARM own, then there's also the ARM attitude toward open community (well explained by libv mails) that's not helping too, here. it's something that surely has to be dealt in the future someway; anyway i would really appreciate a public statement from AW official on the matter (AW as a pretty huge ARM customer could make the difference here and get back some good PR recognition on this issue..) Supposed open source shops like Linaro, Jolla and Mozilla are not going there. Everyone is afraid of the big bad GPU providing troll in the corner. So i have little hope that a small fry like Allwinner, who until recently was happy to hide behind the chinese wall with respect to copyright violations, would invest any significant business and or political weight into pushing that troll into the right direction. at the end of the day, I understand AW (as all chipmakers) is living a hard time, having to be competitive EVERY day in this chip business (where the bulk of sales and revenues is on products like low cost Android tablets where end users are not interested into this kind of IP issues and development models..) so it struggles to find the right balance in the mix between hiding the secret sauce of the kitchen and sharing info with community who boosts development. let me tell i believe anyway AW would deserve at least the same public recognition that's going toward Raspi/Broadcom because they are key enablers of the open makers ecosystem and this could be a powerful business game changer in the longer term IMHO. so hat tip to Allwinner and keep up this good work with the growingly open attitude you are showing toward us, the people, your final customers in the end.. Yes, and no. Here it is a very obvious legal matter. Allwinner has no choice but to do this after (L)GPLed code has been discovered, or for kernel or uboot code. It would have been nice if we wouldn't have had to revert to the route of massive marketing damage to convince Allwinner to meet its legal obligations. Let's just hope that this course of action will now no longer be needed, and that Allwinner simply delivers upon its obligations, and perhaps exceeds them, as they only stand to gain from that. 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
[linux-sunxi] [PATCH 2/3] ARM: dts: sun7i: Add uart2 support for BananaPi
From: Michael Ring m...@michael-ring.org
Uart2 is available at the bananapi io-pins, add a dts node for this
(so that people can easily enable it) but leave it disabled as the pins
are primarily intended for gpio as documented here:
http://wiki.lemaker.org/Pin_definition
Signed-off-by: Michael Ring m...@michael-ring.org
[hdego...@redhat.com: Disable uart2 by default]
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun7i-a20-bananapi.dts | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
index 9f7b472..3e357ef 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapi.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapi.dts
@@ -58,6 +58,7 @@
serial0 = uart0;
serial1 = uart3;
serial2 = uart7;
+ serial3 = uart2;
};
chosen {
@@ -204,6 +205,12 @@
status = okay;
};
+uart2 {
+ pinctrl-names = default;
+ pinctrl-0 = uart2_pins_a;
+ status = disabled;
+};
+
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins_b;
--
2.4.1
--
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 1/3] ARM: dts: sun7i: Add uart4_pins_b definition
From: Michael Ring m...@michael-ring.org
Some boards (e.g. the BananaPro) use alternative pins for uart4, add a pinmux
entry for these.
Signed-off-by: Michael Ring m...@michael-ring.org
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun7i-a20.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index e04cdf9..99d48b4 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -844,6 +844,13 @@
allwinner,pull = SUN4I_PINCTRL_NO_PULL;
};
+ uart4_pins_b: uart4@1 {
+ allwinner,pins = PH4, PH5;
+ allwinner,function = uart4;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_NO_PULL;
+ };
+
uart5_pins_a: uart5@0 {
allwinner,pins = PI10, PI11;
allwinner,function = uart5;
--
2.4.1
--
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/3] ARM: dts: sun7i: Add uart4 support for BananaPro, disable uart2
From: Michael Ring m...@michael-ring.org
The BananaPro uses uart4 for the default rx/tx pins on the 40 pins connector,
so enable uart4.
Uart2 is also available at the bananapro io-pins, but like on the bananapi
the primary function of the pins is to act as gpios, see:
http://forum.lemaker.org/forum.php?mod=viewthreadtid=10852
Disable the uart2 node by default, but leave it in place so that people
can easily enable it.
Signed-off-by: Michael Ring m...@michael-ring.org
[hdego...@redhat.com: Disable uart2 by default]
Signed-off-by: Hans de Goede hdego...@redhat.com
---
arch/arm/boot/dts/sun7i-a20-bananapro.dts | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
index 45e2a02..4edb8a4 100644
--- a/arch/arm/boot/dts/sun7i-a20-bananapro.dts
+++ b/arch/arm/boot/dts/sun7i-a20-bananapro.dts
@@ -52,8 +52,9 @@
aliases {
serial0 = uart0;
- serial1 = uart2;
+ serial1 = uart4;
serial2 = uart7;
+ serial3 = uart2;
};
chosen {
@@ -253,6 +254,12 @@
uart2 {
pinctrl-names = default;
pinctrl-0 = uart2_pins_a;
+ status = disabled;
+};
+
+uart4 {
+ pinctrl-names = default;
+ pinctrl-0 = uart4_pins_b;
status = okay;
};
--
2.4.1
--
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/3] MTD: spi-nor: check for short writes in spi_nor_write.
On Thu, May 21, 2015 at 10:39:13AM +0200, Michal Suchanek wrote: On 21 May 2015 at 01:38, Brian Norris computersforpe...@gmail.com wrote: Why is this thread about SPI error handling CCed to quite so many people? Check the amount of data actually written by the driver. I'm not sure if we should just reactively use the retlen, or if we should be communicating such a limitation via the SPI API. Thoughts? Is there any driver that would break if the SPI master truncated writes when the message is too long rather than returning an error an refusing the transfer? Any such driver is buggy, the actual length transferred has always been a part of the SPI API. We should probably expose limitations so clients can query in advance (we don't at the minute) but it'd be a while before clients could rely on that information being useful and it's still possible things can be truncated by error. With modern drivers using transfer_one() where we have control of the chip select we do also have the ability to add support to the core for chopping large transfers up into smaller ones that the hardware can handle transparently. That won't for everything though since it depends on us being able to manually control the chip select which not all hardware can do. -- 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: Digital signature
[linux-sunxi] Re: [ANNOUNCE] Allwinner releasing CedarX open source
Hi Kevin, as a casual tinkerer of Allwinner (AW) SOCs, let me tell you i appreciate A LOT AW attitude and commitment for becoming more and more a proper citizen in the free software and open source community. This release is a step in a continuous process BUT is surely a step in the right direction. THANX! i really think AW, since the last few years, has been doing a breakthrough revolution in the so called internet of things (IoT) space.. not really because there are new features implemented in its SOCs but because AW is packing SO MUCH stuff in a cost effective chip that's enabling the next level of pervasive computing. you are permitting a world of programmable toys that can be effectively used and enable new products; i started playing with A10 some years ago with Tom Cubie's Cubieboard, but i'll cite also Olimex open source boards and Luke Leighton's EOMA86 effort as very interesting developments born thanx to your business proposition; now we are seeing the new H3 sold for 25$ as dev card, Orange PI mini 2, and the next to come Kickstarter campaign for a $9 board named CHIP.. it a staggering progression.. so the SOC is surely beefy, but for it to become cornerstone of new projects for advised people like the ones embodied in the linux-sunxi community, it has to be dependable i.e. you want it to be available and controllable for ever as software development progresses (and as we can see in the open source model, the snowball becomes avalanche pretty fast). that's why full disclosure and datasheets are more preferred than code drops as the latter is just a single representation (in the writer mindset and in the writer context) of a use case, the former gives everyone the freedom to do its own evaluation and choice and development/integration. coming to Cedarx, i for first believe everything now is going in the right direction toward full disclosure, and that's a GOOD THING. i suppose this is happening because the HW core is more or less exclusive of Allwinner chips. a really different issue is around the 2D/3D MALI 400MP core that's the last unknown big black box of the actual AW bulk lineup (i'll keep the PowerVR stuff out of my way with a 10 feet pole.. :-) i understand that, as it's a graphic core used in many competitors chips too, it's difficult for any chip house to step in and make a liberal move, surely it's a CORE out of chipmaker control as it's ARM own, then there's also the ARM attitude toward open community (well explained by libv mails) that's not helping too, here. it's something that surely has to be dealt in the future someway; anyway i would really appreciate a public statement from AW official on the matter (AW as a pretty huge ARM customer could make the difference here and get back some good PR recognition on this issue..) at the end of the day, I understand AW (as all chipmakers) is living a hard time, having to be competitive EVERY day in this chip business (where the bulk of sales and revenues is on products like low cost Android tablets where end users are not interested into this kind of IP issues and development models..) so it struggles to find the right balance in the mix between hiding the secret sauce of the kitchen and sharing info with community who boosts development. let me tell i believe anyway AW would deserve at least the same public recognition that's going toward Raspi/Broadcom because they are key enablers of the open makers ecosystem and this could be a powerful business game changer in the longer term IMHO. so hat tip to Allwinner and keep up this good work with the growingly open attitude you are showing toward us, the people, your final customers in the end.. Il giorno martedì 19 maggio 2015 02:47:45 UTC+2, kevin.z.m.zh ha scritto: Hi All, We're proud to announce a new code release today for CedarX. Before delving into the details, I'd like to share some context: 1. As a growing company, we are doing our best to understand the needs of the open source software community. This is a learning process. We're working with different people across the Linux development community to better understand best practices. 2. Open source software development is a collaborative process. It works because people genuinely want to help others improve and be successful. Some people are new and others help them learn the ropes over time. We hope that this same positive feedback process can be applied to GPL. ... -- 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: iNet K70E board
On Wednesday, January 22, 2014 at 10:52:27 PM UTC+7, Luc Verhaegen wrote:
On Wed, Jan 22, 2014 at 10:40:49AM -0500, ferar achkar wrote:
greetings Luc,
I am trying to build a boot-able SD card i.e.
*u-boot-sunxi-with-spl.bin* based on u-boot-sunxi source tree, for an
INET-K70E board that has currently a working android, I have generated
*u-boot-sunxi-with-spl.bin *based on your INet_K70HC board cfg, but it
did not boot, can you please advise on how you populated struct
dram_para in 'board/sunxi/dram_inet_k70hc.c' file:
static struct dram_para dram_para = { /// for INet_K70HC board as
authored by Luc Verhaegen l...@skynet.be 2014-01-02 06:37:24
.clock = 384,
.type = 3,
.rank_num = 1,
.density = 4096,
.io_width = 16,
.bus_width = 32,
.cas = 9,
.zq = 0x12331a7f,
.odt_en = 0,
.size = 1024,
.tpr0 = 0x42d899b7,
.tpr1 = 0xa090,
.tpr2 = 0x22a00,
.tpr3 = 0,
.tpr4 = 1,
.tpr5 = 0,
.emr1 = 0x4,
.emr2 = 0x10,
.emr3 = 0,
};
since the i have used the same script.bin currently on the nand flash, i
am not sure, but i think the dram_para values for INet_K70HC are not
correct for the INET-K70E board (below is a snapshot of the board).
much appreciated,
ferar
Do not send emails to people directly, especially when they are general
sunxi questions. Use the mailing list.
it did not boot could be a great many things. Attach serial and find
out.
The image attached shows only a tiny part of the board. So it usually
would not be very useful to begin with.
But... Even with this small part of the board visible, it is clear that
this is a completely different board from the k70hc. Please work through
the http://linux-sunxi.org/New_Device_howto meticulously before you do
anything else.
Luc Verhaegen.
here: http://thuvien.bkc.vn/Tablet/Firmware/2GOOD/2Good.VenusPro.rar
--
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: iNet K70E board
On Thu, May 21, 2015 at 03:00:14AM -0700, sand...@outlook.com wrote:
On Wednesday, January 22, 2014 at 10:52:27 PM UTC+7, Luc Verhaegen wrote:
On Wed, Jan 22, 2014 at 10:40:49AM -0500, ferar achkar wrote:
greetings Luc,
I am trying to build a boot-able SD card i.e.
*u-boot-sunxi-with-spl.bin* based on u-boot-sunxi source tree, for an
INET-K70E board that has currently a working android, I have generated
*u-boot-sunxi-with-spl.bin *based on your INet_K70HC board cfg, but it
did not boot, can you please advise on how you populated struct
dram_para in 'board/sunxi/dram_inet_k70hc.c' file:
static struct dram_para dram_para = { /// for INet_K70HC board as
authored by Luc Verhaegen l...@skynet.be 2014-01-02 06:37:24
.clock = 384,
.type = 3,
.rank_num = 1,
.density = 4096,
.io_width = 16,
.bus_width = 32,
.cas = 9,
.zq = 0x12331a7f,
.odt_en = 0,
.size = 1024,
.tpr0 = 0x42d899b7,
.tpr1 = 0xa090,
.tpr2 = 0x22a00,
.tpr3 = 0,
.tpr4 = 1,
.tpr5 = 0,
.emr1 = 0x4,
.emr2 = 0x10,
.emr3 = 0,
};
since the i have used the same script.bin currently on the nand flash, i
am not sure, but i think the dram_para values for INet_K70HC are not
correct for the INET-K70E board (below is a snapshot of the board).
much appreciated,
ferar
Do not send emails to people directly, especially when they are general
sunxi questions. Use the mailing list.
it did not boot could be a great many things. Attach serial and find
out.
The image attached shows only a tiny part of the board. So it usually
would not be very useful to begin with.
But... Even with this small part of the board visible, it is clear that
this is a completely different board from the k70hc. Please work through
the http://linux-sunxi.org/New_Device_howto meticulously before you do
anything else.
Luc Verhaegen.
here: http://thuvien.bkc.vn/Tablet/Firmware/2GOOD/2Good.VenusPro.rar
Thanks. I will pull that in on the weekend and extract the necessary
info then.
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.
[linux-sunxi] 2015 SBC survey by Linux Foundation/LinuxGizmos
Hi All, The Linux Foundation and Linux Gizmos are running (also) this year a survey on small-board computers, 1. http://www.linux.com/news/embedded-mobile/mobile-linux/831550-survey-best-linux-hacker-sbcs-for-under-200 2. http://linuxgizmos.com/rate-these-sub-200dollar-hacker-sbcs-win-one-of-20/ This year they include 54 SBCs, out of which 12 are based on Allwinner SoCs, a. Two from Olimex b. One from SinoVoip c. One from LeMaker d. Three from CubieTech e. Three from LinkSprite f. Two from Shenzhen Xunlong Software The result of the survey is to produce a Top 10 list based on popularity. The purpose of the survey appears to be to gauge interest in open designs of boards and get manufacturers to work towards that direction. Here are the guidelines for the inclusion of a new board to the list, http://linuxgizmos.com/rate-your-favorite-open-single-board-computers/#open-sbc-guidelines If a company is producing developer boards and satisfy the requirements for inclusion, they can provide five boards to the Linux Foundation so that they are given away to those that took the survey. At this survey, there are four different boards to be given away and none has an Allwinner SoC. Here is the survey, https://www.surveymonkey.com/r/2015SBCS Simos -- 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/2] nand: sunxi: Add support for booting from internal NAND memory
From: Daniel Kochmański dkochman...@turtle-solutions.eu
V2:
- Rename config option
- Move to separate driver
- fix DMA directly into RAM
- Many readability upgrades
- Drop R32 and W32 macros in favour of readl/writel respectively
- Use standard port controller methods for pinctl
- Make many NAND options semi-configurable
Signed-off-by: Roy Spliet r.spl...@ultimaker.com
---
arch/arm/cpu/armv7/sunxi/board.c | 12 +-
arch/arm/include/asm/arch-sunxi/gpio.h | 2 +
board/sunxi/Kconfig| 12 ++
board/sunxi/board.c| 27 +++
drivers/mtd/nand/Makefile | 1 +
drivers/mtd/nand/sunxi_nand_spl.c | 290 +
include/configs/sun4i.h| 1 +
include/configs/sun5i.h| 3 +
include/configs/sun7i.h| 2 +
include/configs/sun8i.h| 6 +
include/configs/sunxi-common.h | 20 +++
11 files changed, 374 insertions(+), 2 deletions(-)
create mode 100644 drivers/mtd/nand/sunxi_nand_spl.c
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 6718ae2..70f413f 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -111,8 +111,10 @@ void s_init(void)
#ifdef CONFIG_SPL_BUILD
/* The sunxi internal brom will try to loader external bootloader
* from mmc0, nand flash, mmc2.
- * Unfortunately we can't check how SPL was loaded so assume
- * it's always the first SD/MMC controller
+ *
+ * Unfortunately we can't check how SPL was loaded so assume it's
+ * always the first SD/MMC controller, unless it was explicitly
+ * stated that SPL is on nand flash.
*/
u32 spl_boot_device(void)
{
@@ -122,6 +124,12 @@ u32 spl_boot_device(void)
* enabled build. It has many restrictions and can only boot over USB.
*/
return BOOT_DEVICE_BOARD;
+#elif defined(CONFIG_SPL_NAND_SUPPORT)
+ /*
+* This is compile time configuration informing SPL, that it
+* was loaded from nand flash.
+*/
+ return BOOT_DEVICE_NAND;
#else
/*
* When booting from the SD card, the eGON.BT0 signature is expected
diff --git a/arch/arm/include/asm/arch-sunxi/gpio.h
b/arch/arm/include/asm/arch-sunxi/gpio.h
index 59d8210..2b49616 100644
--- a/arch/arm/include/asm/arch-sunxi/gpio.h
+++ b/arch/arm/include/asm/arch-sunxi/gpio.h
@@ -156,6 +156,8 @@ enum sunxi_gpio_number {
#define SUN4I_GPB_UART02
#define SUN5I_GPB_UART02
+#define SUNXI_GPC_NAND 2
+
#define SUNXI_GPC_SDC2 3
#define SUN6I_GPC_SDC3 4
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index a60d028..cf58d73 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -269,6 +269,18 @@ config MMC_SUNXI_SLOT_EXTRA
slot or emmc on mmc1 - mmc3. Setting this to 1, 2 or 3 will enable
support for this.
+config SPL_NAND_SUPPORT
+ bool SPL/NAND mode support
+ depends on SPL
+ default n
+ ---help---
+ This enables support for booting from NAND internal
+ memory. U-Boot SPL doesn't detect where is it load from,
+ therefore this option is needed to properly load image from
+ flash. Option also disables MMC functionality on U-Boot due to
+ initialization errors encountered, when both controllers are
+ enabled.
+
config USB0_VBUS_PIN
string Vbus enable pin for usb0 (otg)
default
diff --git a/board/sunxi/board.c b/board/sunxi/board.c
index d9f7691..121e655 100644
--- a/board/sunxi/board.c
+++ b/board/sunxi/board.c
@@ -22,6 +22,9 @@
#ifdef CONFIG_AXP221_POWER
#include axp221.h
#endif
+#ifdef CONFIG_NAND_SUNXI
+#include nand.h
+#endif
#include asm/arch/clock.h
#include asm/arch/cpu.h
#include asm/arch/display.h
@@ -34,6 +37,8 @@
#include linux/usb/musb.h
#include net.h
+#define CCMU_BASE 0x01c2
+
#if defined CONFIG_VIDEO_LCD_PANEL_I2C !(defined CONFIG_SPL_BUILD)
/* So that we can use pin names in Kconfig and sunxi_name_to_gpio() */
int soft_i2c_gpio_sda;
@@ -315,6 +320,28 @@ int board_mmc_init(bd_t *bis)
}
#endif
+void board_nand_init(void)
+{
+ uint32_t val;
+ unsigned int pin;
+ static u8 ports[] = CONFIG_NAND_SUNXI_GPC_PORTS;
+
+ /* Configure AHB muxes to connect output pins with NAND controller */
+ for (pin = 0; pin 16; pin++)
+ sunxi_gpio_set_cfgpin(SUNXI_GPC(pin), SUNXI_GPC_NAND);
+
+ for (pin = 0; pin ARRAY_SIZE(ports); pin++)
+ sunxi_gpio_set_cfgpin(SUNXI_GPC(ports[pin]), SUNXI_GPC_NAND);
+
+ /* un-gate NAND clock and clock source
+* This assumes that the clock was already correctly configured by
+* BootROM */
+ val = readl(CCMU_BASE + 0x60);
+ writel((val | 0x2000), CCMU_BASE + 0x60);
+ val = readl(CCMU_BASE + 0x80);
+ writel((val | 0x8000), CCMU_BASE + 0x80);
+}
+
void
[linux-sunxi] [PATCH 1/2] nand: sunxi: change BLOCK_SIZE in mksunxiboot to match NAND block size
From: Daniel Kochmański dkochman...@turtle-solutions.eu
This change is necessary to calculate correct checksum for NAND
boot. Works both for MMC and NAND. Without it BROM rejects boot image
as invalid (bad checksum). (Changes block size from 0x200 to 0x2000).
V2: Document decision in source too
Signed-off-by: Daniel Kochmański dkochman...@turtle-solutions.eu
Cc: Ian Campbell i...@hellion.org.uk
Cc: Hans De Goede hdego...@redhat.com
Signed-off-by: Roy Spliet r.spl...@ultimaker.com
---
tools/mksunxiboot.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/tools/mksunxiboot.c b/tools/mksunxiboot.c
index 0035f6e..3361251 100644
--- a/tools/mksunxiboot.c
+++ b/tools/mksunxiboot.c
@@ -65,7 +65,13 @@ int gen_check_sum(struct boot_file_head *head_p)
#define SUN4I_SRAM_SIZE 0x7600 /* 0x7748+ is used by BROM */
#define SRAM_LOAD_MAX_SIZE (SUN4I_SRAM_SIZE - sizeof(struct boot_file_head))
-#define BLOCK_SIZE 512
+
+/*
+ * BROM (at least on A10 and A20) requires NAND-images to be explicitly aligned
+ * to a multiple of 8K, and rejects the image otherwise. MMC-images are fine
+ * with 512B blocks. To cater for both, align to the largest of the two.
+ */
+#define BLOCK_SIZE 0x2000
struct boot_img {
struct boot_file_head header;
--
2.1.0
--
IMAGINE IT MAKE IT
Meet us online at Twitter http://twitter.com/ultimaker, Facebook
http://facebook.com/ultimaker, Google+ http://google.com/+Ultimaker
www.ultimaker.com
--
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] Proposal to add NAND-boot support for Sunxi SPL
The following patches take the work by Daniel Kochmánski, and make some heavy modifications for readability and functionality, based on Boris Brezillon's Linux driver. Tested on an Olimex Lime w/ A20. Patches are sent as RFC. Open questions: - Config options added are partially NAND-chip specific. Some options can be autodetected based on the NAND ID, others require either brute-forcing or config options like these. Do they belong in sunxi-common? Should we make a Kconfig option for this? If bikeshedding is desired, are defines in sunxi-common.h good enough for now? - Style is mostly kernel-like. Satisfied? - Daniel: do you think we can work from here? Please comment away! Roy -- IMAGINE IT MAKE IT Meet us online at Twitter http://twitter.com/ultimaker, Facebook http://facebook.com/ultimaker, Google+ http://google.com/+Ultimaker www.ultimaker.com -- 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: Proposal to add NAND-boot support for Sunxi SPL
Hi Roy, I could definitely use such a howto. I have applied the patches to the current mainline u-boot head and try to boot my A13-OlinXino Wifi board in FEL mode. I can compile and boot into u-boot via FEL. However, I get these errors when I have CONFIG_SPL_NAND_SUPPORT defined: U-Boot SPL 2015.07-rc1-00276-g77792f9-dirty (May 21 2015 - 19:15:54) DRAM: 512 MiB Failed to set core voltage! Can't set CPU frequency sunxi board_nand_init() Nand initialised Error: 1 ECC failures detected Error: 512 ECC failures detected This is my configs/A13-OLinuXino_defconfig looks like this: CONFIG_SYS_EXTRA_OPTIONS=CONS_INDEX=2,AXP209_POWER,USB_EHCI,SYS_MAX_NAND_DEVICE=1,SYS_NAND_BASE=0x00 CONFIG_NAND=y CONFIG_SUNXI_NAND=y CONFIG_SUNXI_DMA=y CONFIG_CMD_NAND=y CONFIG_SPL_NAND_SUPPORT=y CONFIG_SPL=y CONFIG_FDTFILE=sun5i-a13-olinuxino.dtb CONFIG_USB1_VBUS_PIN=PG11 CONFIG_VIDEO_HDMI=n CONFIG_VIDEO_VGA_VIA_LCD=y CONFIG_VIDEO_VGA_VIA_LCD_FORCE_SYNC_ACTIVE_HIGH=y # For use with the Olimex 7 LCD module, adjust timings for other displays # Set video-mode=sunxi:800x600-24@60,monitor=lcd in the env. to enable CONFIG_VIDEO_LCD_MODE=x:800,y:480,depth:18,pclk_khz:33000,le:16,ri:209,up:22,lo:22,hs:30,vs:1,sync:3,vmode:0 CONFIG_VIDEO_LCD_POWER=AXP0-0 CONFIG_VIDEO_LCD_BL_PWM=PB2 CONFIG_ARM=y CONFIG_ARCH_SUNXI=y CONFIG_MACH_SUN5I=y CONFIG_DRAM_CLK=408 CONFIG_DRAM_ZQ=123 CONFIG_DRAM_EMR1=0 CONFIG_DEFAULT_DEVICE_TREE=sun5i-a13-olinuxino I just found out in the sun5i-a13-olinuxino.dts file are no nand settings. I guess I can find the information in the linux-sunxi 3.4 kernels fex file for the olinuxio and need to convert to dts, correct? I am happy about any hints / comments. Thanks Alex On Thursday, May 21, 2015 at 11:08:24 AM UTC-7, Hans de Goede wrote: Hi Roy, On 21-05-15 15:59, Roy Spliet wrote: The following patches take the work by Daniel Kochmánski, and make some heavy modifications for readability and functionality, based on Boris Brezillon's Linux driver. Tested on an Olimex Lime w/ A20. Patches are sent as RFC. Open questions: - Config options added are partially NAND-chip specific. Some options can be autodetected based on the NAND ID, others require either brute-forcing or config options like these. Do they belong in sunxi-common? Should we make a Kconfig option for this? If bikeshedding is desired, are defines in sunxi-common.h good enough for now? - Style is mostly kernel-like. Satisfied? - Daniel: do you think we can work from here? Please comment away! Cool stuff. Overall this looks good I'll reply with more detailed feedback to your individual patches, 2 questions: 1) Can you provide a quick howto (at developer level) on how to actually get the spl and u-boot into the nand, what I'm looking for is unstructions like this: a) Take this git repo + branch, build a kernel from it b) Look at this dts file for a nand settings example, adjust it for your board c) Once booted into the kernel using an updated dts you should have these block devices, dd spl to this one, and u-boot to this one. No more to go more detailed then that :) 2) What is the plan to add support for loading files from nand in u-boot proper, so that we can get (e.g.) extlinux.conf + kernel +dtb from a /boot on nand ? 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 RFC] crypto: Add Allwinner Security System crypto accelerator
Hi Labbe, Can you tell me which kernel branch support dm-crypt on a20 platform. BR. On Wednesday, May 14, 2014 at 2:18:12 AM UTC+8, clabbe.montjoie wrote: Hello This is the driver for the Security System included in Allwinner SoC A20. Security System (SS for short) is a hardware cryptographic accelerator that support AES/MD5/SHA1/DES/3DES/PRNG algorithms. It could be found on others Allwinner SoC: - A10s, A10 and A31 diagram speak about it - A13 manual give the same datasheet for SS than A20 But I do not have access on any of those hardware, tests are welcome. This driver currently supports: - MD5 and SHA1 hash algorithms - AES block cipher in CBC mode with 128/196/256bits keys. - DES and 3DES block cipher in CBC mode - PRNG The driver exposes all those algorithms through the kernel cryptographic API. The driver support only CPU driven (aka poll mode) transfer mode since the DMA engine of the A20 does not have a driver yet. When setting .cra_priority to 300(more priority than krng), the PRNG seems not to be used (any of the dev_* message was never seen). But something use/lock it, because I cannot unload the module. So for the moment I have set its .cra_priority to 100 and need to investigate more. The performance are very good, up to x2 for hashing and 30/50% for AES: (r/s means requests per second) - MD5 without SS 1 requests of 16 bytes in 813409us (0.813409s) 12293.938477r/s 1 requests of 32 bytes in 824489us (0.824489s) 12128.724609r/s 1 requests of 64 bytes in 834231us (0.834231s) 11987.087891r/s 1 requests of 128 bytes in 851992us (0.851992s) 11737.199219r/s 1 requests of 256 bytes in 866311us (0.866311s) 11543.198242r/s 1 requests of 512 bytes in 909070us (0.909070s) 11000.252930r/s 1 requests of 1024 bytes in 956643us (0.956643s) 10453.220703r/s 1 requests of 2048 bytes in 1086405us (1.086405s) 9204.670898r/s 1 requests of 4096 bytes in 1338719us (1.338719s) 7469.827637r/s 1 requests of 8192 bytes in 1867788us (1.867788s) 5353.926758r/s 1 requests of 16384 bytes in 2972250us (2.972250s) 3364.454590r/s 1 requests of 32768 bytes in 4945905us (4.945905s) 2021.874634r/s 1 requests of 65536 bytes in 8971740us (8.971740s) 1114.610962r/s 1000 requests of 131072 bytes in 1705265us (1.705265s) 586.419128r/s 1000 requests of 262144 bytes in 3340201us (3.340201s) 299.383179r/s 1000 requests of 524288 bytes in 6552412us (6.552412s) 152.61r/s 1000 requests of 1048576 bytes in 13027299us (13.027299s) 76.761887r/s 1000 requests of 2097152 bytes in 25890814us (25.890814s) 38.623737r/s - MD5 with SS 1 requests of 16 bytes in 833828us (0.833828s) 11992.880859r/s 1 requests of 32 bytes in 839807us (0.839807s) 11907.498047r/s 1 requests of 64 bytes in 849816us (0.849816s) 11767.252930r/s 1 requests of 128 bytes in 859020us (0.859020s) 11641.172852r/s 1 requests of 256 bytes in 867209us (0.867209s) 11531.246094r/s 1 requests of 512 bytes in 886111us (0.886111s) 11285.267578r/s 1 requests of 1024 bytes in 934183us (0.934183s) 10704.541016r/s 1 requests of 2048 bytes in 1008961us (1.008961s) 9911.185547r/s 1 requests of 4096 bytes in 1171796us (1.171796s) 8533.908203r/s 1 requests of 8192 bytes in 1518018us (1.518018s) 6587.537109r/s 1 requests of 16384 bytes in 2665293us (2.665293s) 3751.932617r/s 1 requests of 32768 bytes in 3580903us (3.580903s) 2792.591797r/s 1 requests of 65536 bytes in 6260570us (6.260570s) 1597.298706r/s 1000 requests of 131072 bytes in 1164345us (1.164345s) 858.851990r/s 1000 requests of 262144 bytes in 2243004us (2.243004s) 445.830688r/s 1000 requests of 524288 bytes in 4404737us (4.404737s) 227.028305r/s 1000 requests of 1048576 bytes in 8720956us (8.720956s) 114.666328r/s 1000 requests of 2097152 bytes in 17383040us (17.383039s) 57.527336r/s - SHA1 without SS 1 requests of 16 bytes in 875042us (0.875042s) 11428.022461r/s 1 requests of 32 bytes in 823671us (0.823671s) 12140.769531r/s 1 requests of 64 bytes in 871748us (0.871748s) 11471.205078r/s 1 requests of 128 bytes in 862865us (0.862865s) 11589.298828r/s 1 requests of 256 bytes in 881417us (0.881417s) 11345.368164r/s 1 requests of 512 bytes in 950922us (0.950922s) 10516.109375r/s 1 requests of 1024 bytes in 1050256us (1.050256s) 9521.488281r/s 1 requests of 2048 bytes in 1258961us (1.258961s) 7943.057617r/s 1 requests of 4096 bytes in 1683097us (1.683097s) 5941.428223r/s 1 requests of 8192 bytes in 2526498us (2.526498s) 3958.047852r/s 1 requests of 16384 bytes in 4269592us (4.269592s) 2342.144287r/s 1 requests of 32768 bytes in 7602177us (7.602177s) 1315.412720r/s 1 requests of 65536 bytes in 14377450us (14.377450s) 695.533630r/s 1000 requests of 131072 bytes in 2765845us (2.765845s) 361.553162r/s 1000 requests of
[linux-sunxi] which kernel branch support dm-crypt on a20 platform.
hi,all, which kernel branch support dm-crypt on a20 platform. BR, Lyric. -- 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] which kernel branch support dm-crypt on a20 platform.
Le 22/05/2015 03:35, lyc.ac...@gmail.com a écrit : hi,all, which kernel branch support dm-crypt on a20 platform. BR, Lyric. -- For dm-crypt all kernel have it. But I think you speak about hardware accelerated ciphers and for this you need the security system driver. No kernel branch support it, it is a stand alone patch until it will be accepted in mainline kernel. Regards LABBE Corentin -- 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 v6] dma: sun4i: Add support for the DMA engine on sun[457]i SoCs
Hi Maxime, Vinod,
El 20/05/15 a las 18:17, Maxime Ripard escibió:
+static struct dma_async_tx_descriptor *
+sun4i_dma_prep_dma_cyclic(struct dma_chan *chan, dma_addr_t buf, size_t len,
+ size_t period_len, enum dma_transfer_direction dir,
+ unsigned long flags)
+{
+ struct sun4i_dma_vchan *vchan = to_sun4i_dma_vchan(chan);
+ struct dma_slave_config *sconfig = vchan-cfg;
+ struct sun4i_dma_promise *promise;
+ struct sun4i_dma_contract *contract;
+ dma_addr_t src, dest;
+ u32 endpoints;
+ int nr_periods, offset, plength, i;
+
+ if (!is_slave_direction(dir)) {
+ dev_err(chan2dev(chan), Invalid DMA direction\n);
+ return NULL;
+ }
+
+ if (vchan-is_dedicated) {
+ /*
+* As we are using this just for audio data, we need to use
+* normal DMA. There is nothing stopping us from supporting
+* dedicated DMA here as well, so if a client comes up and
+* requires it, it will be simple to implement it.
+*/
+ dev_err(chan2dev(chan),
+ Cyclic transfers are only supported on Normal DMA\n);
+ return NULL;
+ }
+
+ contract = generate_dma_contract();
+ if (!contract)
+ return NULL;
+
+ contract-is_cyclic = 1;
+
+ /* Figure out the endpoints and the address we need */
+ if (dir == DMA_MEM_TO_DEV) {
+ src = buf;
+ dest = sconfig-dst_addr;
+ endpoints = NDMA_CFG_SRC_DRQ_TYPE(NDMA_DRQ_TYPE_SDRAM) |
+ NDMA_CFG_DEST_DRQ_TYPE(vchan-endpoint) |
+ NDMA_CFG_DEST_FIXED_ADDR;
+ } else {
+ src = sconfig-src_addr;
+ dest = buf;
+ endpoints = NDMA_CFG_SRC_DRQ_TYPE(vchan-endpoint) |
+ NDMA_CFG_SRC_FIXED_ADDR |
+ NDMA_CFG_DEST_DRQ_TYPE(NDMA_DRQ_TYPE_SDRAM);
+ }
+
+ /*
+* We will be using half done interrupts to make two periods
+* out of a promise, so we need to program the DMA engine less
+* often
+*/
+ nr_periods = DIV_ROUND_UP(len / period_len, 2);
and why is that.. why don't you use actual period count here?
I must admit I don't really know on this one.
Emilio?
You mean why is it that I chose to divide len / period_len (is there
some other way to get period count that I'm missing?) by 2 and use half
done interrupts? The engine can interrupt on half-transfer, so we can
use this feature to program the engine half as often as if we didn't use
it (keep in mind the hardware doesn't support linked lists).
Say you have a set of periods (| marks the start/end, I for interrupt, P
for programming the engine to do a new transfer), the easy but slow way
would be to do
|---|---|---|---| (periods / promises)
P I,P I,P I,P I
Using half transfer interrupts you can do
|---|---| (promises as configured on hw)
|---|---|---|---| (periods)
P I I,P I I
Which requires half the engine programming for the same functionality.
Feel free to include these drawings on the comment if you think they'll
help.
+static struct dma_async_tx_descriptor *
+sun4i_dma_prep_slave_sg(struct dma_chan *chan, struct scatterlist *sgl,
+ unsigned int sg_len, enum dma_transfer_direction dir,
+ unsigned long flags, void *context)
+{
+ struct sun4i_dma_vchan *vchan = to_sun4i_dma_vchan(chan);
+ struct dma_slave_config *sconfig = vchan-cfg;
+ struct sun4i_dma_promise *promise;
+ struct sun4i_dma_contract *contract;
+ struct scatterlist *sg;
+ dma_addr_t srcaddr, dstaddr;
+ u32 endpoints, para;
+ int i;
+
+ if (!sgl)
+ return NULL;
+
+ if (!is_slave_direction(dir)) {
+ dev_err(chan2dev(chan), Invalid DMA direction\n);
+ return NULL;
+ }
+
+ contract = generate_dma_contract();
+ if (!contract)
+ return NULL;
+
+ /* Figure out endpoints */
+ if (vchan-is_dedicated dir == DMA_MEM_TO_DEV) {
+ endpoints = DDMA_CFG_SRC_DRQ_TYPE(DDMA_DRQ_TYPE_SDRAM) |
+ DDMA_CFG_SRC_ADDR_MODE(DDMA_ADDR_MODE_LINEAR) |
+ DDMA_CFG_DEST_DRQ_TYPE(vchan-endpoint) |
+ DDMA_CFG_DEST_ADDR_MODE(DDMA_ADDR_MODE_IO);
+ } else if (!vchan-is_dedicated dir == DMA_MEM_TO_DEV) {
+ endpoints = NDMA_CFG_SRC_DRQ_TYPE(NDMA_DRQ_TYPE_SDRAM) |
+ NDMA_CFG_DEST_DRQ_TYPE(vchan-endpoint) |
+ NDMA_CFG_DEST_FIXED_ADDR;
+ } else if (vchan-is_dedicated) {
+ endpoints = DDMA_CFG_SRC_DRQ_TYPE(vchan-endpoint) |
+
