[linux-sunxi] Re: [PATCH v2 13/26] drm/fb_cma_helper: Remove implicit call to disable_unused_functions
On Mon, Jan 25, 2016 at 12:19:27AM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Friday 15 January 2016 11:17:30 Daniel Vetter wrote: > > On Fri, Jan 15, 2016 at 01:13:05AM +0200, Laurent Pinchart wrote: > > > On Thursday 14 January 2016 16:24:56 Maxime Ripard wrote: > > >> The drm_fbdev_cma_init function always calls the > > >> drm_helper_disable_unused_functions. Since it's part of the usual probe > > >> process, all the drivers using that helper will end up having their > > >> encoder and CRTC disable functions called at probe if their device has > > >> not been reported as enabled. > > >> > > >> This could be fixed by reading out from the registers the current state > > >> of the device if it is enabled, but even that will not handle the case > > >> where the device is actually disabled. > > >> > > >> Moreover, the drivers using the atomic modesetting expect that their > > >> enable and disable callback to be called when the device is already > > >> enabled or disabled (respectively). > > >> > > >> We can however fix this issue by moving the call to > > >> drm_helper_disable_unused_functions out of drm_fbdev_cma_init and make > > >> the drivers needing it (all the drivers calling drm_fbdev_cma_init and > > >> not using the atomic modesetting) explicitly call it. > > > > > > I'd rather add it to all drivers that call drm_fbdev_cma_init(). All the > > > atomic ones must have special code to cope with it that could be rendered > > > useless by the removal of the drm_helper_disable_unused_functions() call. > > > That code should be removed too, and it would be easier to check drivers > > > one by one and fixing them individually (outside of this patch series, > > > unless you insist ;-)) when removing the explicit > > > drm_helper_disable_unused_functions() call. > > > > I had the same thought, but figured there's really no good reason ever to > > do this. I suspect most of that disable_unused_function stuff we have all > > over is supreme cargo-cult anyway ;-) > > I'm not sure you got my point. Yes, the drm_helper_disable_unused_functions() > call should be removed from atomic drivers, but that will leave support code > added for the sole reason of avoiding the crash in the drivers. That code > will > likely not be noticed and will stay there rotting. If we added > drm_helper_disable_unused_functions() calls to all atomic drivers then driver > authors will hopefully check carefully if there's any support code that can > be > removed when removing the function call. It would act as a kind of FIXME > reminder. drm_helper_disable_unused_functions() already prefers the ->disable callbacks over dpms, like atomic helpers. I don't think there's any dead code due to this change. The problem was that driver/hw blew up since it was disabled when the hw was off already. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.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: esata multiplier
Hi, on the website http://linux-sunxi.org/SATA#Caveats there is stated "Cheap > port multipliers like JMB321/JMB393", Im just wondering what are the > good esata multiplier, could you please suggest some? > Nope, since using PMs with A20 is no good idea at all (low performance, risk that people try to replace backup with RAID, reliability problems when setting up 'el cheapo' RAID this way). You might find some informations in the thread referenced form the link above about other PMs that are known to work (and consume many times more than a typical A20 board) Best, Thomas -- 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 v2 13/26] drm/fb_cma_helper: Remove implicit call to disable_unused_functions
Hi Daniel, On Friday 15 January 2016 11:17:30 Daniel Vetter wrote: > On Fri, Jan 15, 2016 at 01:13:05AM +0200, Laurent Pinchart wrote: > > On Thursday 14 January 2016 16:24:56 Maxime Ripard wrote: > >> The drm_fbdev_cma_init function always calls the > >> drm_helper_disable_unused_functions. Since it's part of the usual probe > >> process, all the drivers using that helper will end up having their > >> encoder and CRTC disable functions called at probe if their device has > >> not been reported as enabled. > >> > >> This could be fixed by reading out from the registers the current state > >> of the device if it is enabled, but even that will not handle the case > >> where the device is actually disabled. > >> > >> Moreover, the drivers using the atomic modesetting expect that their > >> enable and disable callback to be called when the device is already > >> enabled or disabled (respectively). > >> > >> We can however fix this issue by moving the call to > >> drm_helper_disable_unused_functions out of drm_fbdev_cma_init and make > >> the drivers needing it (all the drivers calling drm_fbdev_cma_init and > >> not using the atomic modesetting) explicitly call it. > > > > I'd rather add it to all drivers that call drm_fbdev_cma_init(). All the > > atomic ones must have special code to cope with it that could be rendered > > useless by the removal of the drm_helper_disable_unused_functions() call. > > That code should be removed too, and it would be easier to check drivers > > one by one and fixing them individually (outside of this patch series, > > unless you insist ;-)) when removing the explicit > > drm_helper_disable_unused_functions() call. > > I had the same thought, but figured there's really no good reason ever to > do this. I suspect most of that disable_unused_function stuff we have all > over is supreme cargo-cult anyway ;-) I'm not sure you got my point. Yes, the drm_helper_disable_unused_functions() call should be removed from atomic drivers, but that will leave support code added for the sole reason of avoiding the crash in the drivers. That code will likely not be noticed and will stay there rotting. If we added drm_helper_disable_unused_functions() calls to all atomic drivers then driver authors will hopefully check carefully if there's any support code that can be removed when removing the function call. It would act as a kind of FIXME reminder. > > Other than that the patch looks fine to me. > > So went ahead and applied to drm-misc. -- Regards, Laurent Pinchart -- 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] clk: sunxi: usb: Sort clk providers by chip family and name
The latest addition of H3 USB clocks placed them at the bottom. Move it
before A80 (sun9i), so they are sorted by SoC family then name.
Signed-off-by: Chen-Yu Tsai
---
drivers/clk/sunxi/clk-usb.c | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff --git a/drivers/clk/sunxi/clk-usb.c b/drivers/clk/sunxi/clk-usb.c
index 67b8e38f4ee9..5432b1c198a4 100644
--- a/drivers/clk/sunxi/clk-usb.c
+++ b/drivers/clk/sunxi/clk-usb.c
@@ -216,6 +216,18 @@ static void __init sun8i_a23_usb_setup(struct device_node
*node)
}
CLK_OF_DECLARE(sun8i_a23_usb, "allwinner,sun8i-a23-usb-clk",
sun8i_a23_usb_setup);
+static const struct usb_clk_data sun8i_h3_usb_clk_data __initconst = {
+ .clk_mask = BIT(19) | BIT(18) | BIT(17) | BIT(16) |
+BIT(11) | BIT(10) | BIT(9) | BIT(8),
+ .reset_mask = BIT(3) | BIT(2) | BIT(1) | BIT(0),
+};
+
+static void __init sun8i_h3_usb_setup(struct device_node *node)
+{
+ sunxi_usb_clk_setup(node, &sun8i_h3_usb_clk_data, &sun4i_a10_usb_lock);
+}
+CLK_OF_DECLARE(sun8i_h3_usb, "allwinner,sun8i-h3-usb-clk", sun8i_h3_usb_setup);
+
static const struct usb_clk_data sun9i_a80_usb_mod_data __initconst = {
.clk_mask = BIT(6) | BIT(5) | BIT(4) | BIT(3) | BIT(2) | BIT(1),
.reset_mask = BIT(19) | BIT(18) | BIT(17),
@@ -243,15 +255,3 @@ static void __init sun9i_a80_usb_phy_setup(struct
device_node *node)
sunxi_usb_clk_setup(node, &sun9i_a80_usb_phy_data, &a80_usb_phy_lock);
}
CLK_OF_DECLARE(sun9i_a80_usb_phy, "allwinner,sun9i-a80-usb-phy-clk",
sun9i_a80_usb_phy_setup);
-
-static const struct usb_clk_data sun8i_h3_usb_clk_data __initconst = {
- .clk_mask = BIT(19) | BIT(18) | BIT(17) | BIT(16) |
-BIT(11) | BIT(10) | BIT(9) | BIT(8),
- .reset_mask = BIT(3) | BIT(2) | BIT(1) | BIT(0),
-};
-
-static void __init sun8i_h3_usb_setup(struct device_node *node)
-{
- sunxi_usb_clk_setup(node, &sun8i_h3_usb_clk_data, &sun4i_a10_usb_lock);
-}
-CLK_OF_DECLARE(sun8i_h3_usb, "allwinner,sun8i-h3-usb-clk", sun8i_h3_usb_setup);
--
2.7.0
--
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 sunxi-tools 7/7] fel: Add fel spl command support for Allwinner A64
The SCTLR bits are somewhat different because the V bit is set
to 0 on A64 (Low exception vectors, base address 0x) and
the UNK bit (Reads of this bit return an UNKNOWN value) is also not
the same as on the other SoCs. So the SCTLR check can be relaxed.
Signed-off-by: Siarhei Siamashka
---
fel.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/fel.c b/fel.c
index d3d6f62..ee76f98 100644
--- a/fel.c
+++ b/fel.c
@@ -247,6 +247,7 @@ void aw_fel_print_version(libusb_device_handle *usb)
case 0x1633: soc_name="A31";break;
case 0x1651: soc_name="A20";break;
case 0x1650: soc_name="A23";break;
+ case 0x1689: soc_name="A64";break;
case 0x1639: soc_name="A80";break;
case 0x1667: soc_name="A33";break;
case 0x1673: soc_name="A83T";break;
@@ -492,6 +493,17 @@ sram_swap_buffers a31_sram_swap_buffers[] = {
};
/*
+ * A64 has a large SRAM C at 0x18000, which we use as a backup storage
+ * for FEL stacks. Also the SPL load address is 0x1 and it makes this
+ * SoC rather unique.
+ */
+sram_swap_buffers a64_sram_swap_buffers[] = {
+ { .buf1 = 0x11800, .buf2 = 0x18000, .size = 0x800 },
+ { .buf1 = 0x15C00, .buf2 = 0x18800, .size = 0x8000 - 0x5C00 },
+ { 0 } /* End of the table */
+};
+
+/*
* Use the SRAM section at 0x44000 as the backup storage. This is the memory,
* which is normally shared with the OpenRISC core (should we do an extra check
* to ensure that this core is powered off and can't interfere?).
@@ -542,6 +554,13 @@ soc_sram_info soc_sram_info_table[] = {
.swap_buffers = ar100_abusing_sram_swap_buffers,
},
{
+ .soc_id = 0x1689, /* Allwinner A64 */
+ .spl_addr = 0x1,
+ .scratch_addr = 0x11000,
+ .thunk_addr = 0x1AE00, .thunk_size = 0x200,
+ .swap_buffers = a64_sram_swap_buffers,
+ },
+ {
.soc_id = 0x1673, /* Allwinner A83T */
.scratch_addr = 0x1000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
@@ -840,8 +859,8 @@ uint32_t *aw_backup_and_disable_mmu(libusb_device_handle
*usb,
* checks needs to be relaxed).
*/
- /* Basically, ignore M/Z/I bits and expect no TEX remap */
- if ((sctlr & ~((1 << 12) | (1 << 11) | 1)) != 0x00C52078) {
+ /* Basically, ignore V/M/Z/I/UNK bits and expect no TEX remap */
+ if ((sctlr & ~((3 << 11) | (1 << 6) | 1)) != 0x00C50038) {
fprintf(stderr, "Unexpected SCTLR (%08X)\n", sctlr);
exit(1);
}
--
2.4.10
--
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 sunxi-tools 6/7] fel: Add "readl" and "writel" commands
The read/write operations done by FEL are not suitable for accessing
hardware registers. For example, trying to read a SID value using
the "read" or "hexdump" commands results in the following:
$ sunxi-fel hexdump 0x01c23800 4
01c23800: 87 00 00 00 __ __ __ __ __ __ __ __ __ __ __ __
Apparently, FEL tries to read data one byte at a time and this does
not always work correctly. Introducing new commands to explicitly
do 32-bit reads and writes helps:
$ sunxi-fel readl 0x01c23800
0x16254187
Signed-off-by: Siarhei Siamashka
---
fel.c | 44
1 file changed, 44 insertions(+)
diff --git a/fel.c b/fel.c
index a597e11..d3d6f62 100644
--- a/fel.c
+++ b/fel.c
@@ -654,6 +654,38 @@ void aw_write_arm_cp_reg(libusb_device_handle *usb,
soc_sram_info *sram_info,
aw_fel_execute(usb, sram_info->scratch_addr);
}
+uint32_t aw_fel_readl(libusb_device_handle *usb, uint32_t addr)
+{
+ soc_sram_info *sram_info = aw_fel_get_sram_info(usb);
+ uint32_t val = 0;
+ uint32_t arm_code[] = {
+ htole32(0xe59f0008), /* ldrr0, [pc, #8] */
+ htole32(0xe590), /* ldrr0, [r0] */
+ htole32(0xe58f), /* strr0, [pc] */
+ htole32(0xe12fff1e), /* bx lr */
+ htole32(addr)
+ };
+ aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
+ aw_fel_execute(usb, sram_info->scratch_addr);
+ aw_fel_read(usb, sram_info->scratch_addr + 16, &val, sizeof(val));
+ return le32toh(val);
+}
+
+void aw_fel_writel(libusb_device_handle *usb, uint32_t addr, uint32_t val)
+{
+ soc_sram_info *sram_info = aw_fel_get_sram_info(usb);
+ uint32_t arm_code[] = {
+ htole32(0xe59f0008), /* ldrr0, [pc, #8] */
+ htole32(0xe59f1008), /* ldrr1, [pc, #8] */
+ htole32(0xe5801000), /* strr1, [r0] */
+ htole32(0xe12fff1e), /* bx lr */
+ htole32(addr),
+ htole32(val)
+ };
+ aw_fel_write(usb, arm_code, sram_info->scratch_addr, sizeof(arm_code));
+ aw_fel_execute(usb, sram_info->scratch_addr);
+}
+
void aw_enable_l2_cache(libusb_device_handle *usb, soc_sram_info *sram_info)
{
uint32_t arm_code[] = {
@@ -1314,6 +1346,8 @@ int main(int argc, char **argv)
" hex[dump] address lengthDumps memory
region in hex\n"
" dump address length Binary memory
dump\n"
" exe[cute] address Call function
address\n"
+ " readl address Read 32-bit
value from device memory\n"
+ " writel address valueWrite 32-bit
value to device memory\n"
" read address length fileWrite memory
contents into file\n"
" write address file Store file
contents into memory\n"
" write-with-progress addr file \"write\" with
progress bar\n"
@@ -1380,6 +1414,16 @@ int main(int argc, char **argv)
} else if (strncmp(argv[1], "dump", 4) == 0 && argc > 3) {
aw_fel_dump(handle, strtoul(argv[2], NULL, 0),
strtoul(argv[3], NULL, 0));
skip = 3;
+ } else if (strcmp(argv[1], "readl") == 0 && argc > 2) {
+ uint32_t addr = strtoul(argv[2], NULL, 0);
+ uint32_t val = aw_fel_readl(handle, addr);
+ printf("0x%08x\n", val);
+ skip = 2;
+ } else if (strcmp(argv[1], "writel") == 0 && argc > 2) {
+ uint32_t addr = strtoul(argv[2], NULL, 0);
+ uint32_t val = strtoul(argv[3], NULL, 0);
+ aw_fel_writel(handle, addr, val);
+ skip = 3;
} else if (strncmp(argv[1], "exe", 3) == 0 && argc > 2) {
aw_fel_execute(handle, strtoul(argv[2], NULL, 0));
skip=3;
--
2.4.10
--
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 sunxi-tools 1/7] fel: Move backup area to higher addresses in SRAM on A10/A13/A20
Previously the backup area was allocated at the address 0x8000.
This is not very good because it means that the U-Boot SPL can
only safely use memory at addresses 0x-0x7FFF (32 KiB). But
if we move the backup area to the end of the SRAM A4, this can
allow U-Boot SPL to use memory 0x-0x9FFF (40 KiB). The BROM
can't load such large SPLs from the SD card. But the SPL still
can move its stack up to the 40 KiB boundary or do UCL or LZO
decompression at runtime to squeeze more code into it.
This patch makes the sunxi-fel tool compatible with 40 KiB SPLs,
even though the current U-Boot releases do not use them yet.
Signed-off-by: Siarhei Siamashka
---
fel.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/fel.c b/fel.c
index 59f0f72..0da3dc7 100644
--- a/fel.c
+++ b/fel.c
@@ -464,13 +464,17 @@ typedef struct {
* at 0x2000 (and growing down) for the IRQ handler. And another one at 0x7000
* (and also growing down) for the regular code. In order to use the whole
* 32 KiB in the A1/A2 sections of SRAM, we need to temporarily move these
- * stacks elsewhere. And the addresses above 0x7000 are also a bit suspicious,
- * so it might be safer to backup the 0x7000-0x8000 area too. On A10/A13/A20
- * we can use the SRAM section A3 (0x8000) for this purpose.
+ * stacks elsewhere. And the addresses 0x7D00-0x7FFF contain something
+ * importantant too (overwriting them kills FEL). On A10/A13/A20 we can use
+ * the SRAM sections A3/A4 (0x8000-0xBFFF) for this purpose.
*/
sram_swap_buffers a10_a13_a20_sram_swap_buffers[] = {
- { .buf1 = 0x01800, .buf2 = 0x8000, .size = 0x800 },
- { .buf1 = 0x05C00, .buf2 = 0x8800, .size = 0x8000 - 0x5C00 },
+ /* 0x1C00-0x1FFF (IRQ stack) */
+ { .buf1 = 0x01C00, .buf2 = 0xA400, .size = 0x0400 },
+ /* 0x5C00-0x6FFF (Stack) */
+ { .buf1 = 0x05C00, .buf2 = 0xA800, .size = 0x1400 },
+ /* 0x7C00-0x7FFF (Something important) */
+ { .buf1 = 0x07C00, .buf2 = 0xBC00, .size = 0x0400 },
{ 0 } /* End of the table */
};
@@ -490,21 +494,21 @@ soc_sram_info soc_sram_info_table[] = {
{
.soc_id = 0x1623, /* Allwinner A10 */
.scratch_addr = 0x2000,
- .thunk_addr = 0xAE00, .thunk_size = 0x200,
+ .thunk_addr = 0xA200, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
.needs_l2en = 1,
},
{
.soc_id = 0x1625, /* Allwinner A13 */
.scratch_addr = 0x2000,
- .thunk_addr = 0xAE00, .thunk_size = 0x200,
+ .thunk_addr = 0xA200, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
.needs_l2en = 1,
},
{
.soc_id = 0x1651, /* Allwinner A20 */
.scratch_addr = 0x2000,
- .thunk_addr = 0xAE00, .thunk_size = 0x200,
+ .thunk_addr = 0xA200, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
},
{
--
2.4.10
--
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 sunxi-tools 2/7] fel: Rename the backup buffers which use AR100 (OpenRISC) SRAM
That would be a more appropriate name. And A31 is going to
implement this in a different way and give the SRAM back to
OpenRISC.
Signed-off-by: Siarhei Siamashka
---
fel.c | 19 +--
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/fel.c b/fel.c
index 0da3dc7..419f16a 100644
--- a/fel.c
+++ b/fel.c
@@ -479,12 +479,11 @@ sram_swap_buffers a10_a13_a20_sram_swap_buffers[] = {
};
/*
- * A31 is very similar to A10/A13/A20, except that it has no SRAM at 0x8000.
- * So we use the SRAM section at 0x44000 instead. This is the memory, which
- * is normally shared with the OpenRISC core (should we do an extra check to
- * ensure that this core is powered off and can't interfere?).
+ * Use the SRAM section at 0x44000 as the backup storage. This is the memory,
+ * which is normally shared with the OpenRISC core (should we do an extra check
+ * to ensure that this core is powered off and can't interfere?).
*/
-sram_swap_buffers a31_sram_swap_buffers[] = {
+sram_swap_buffers ar100_abusing_sram_swap_buffers[] = {
{ .buf1 = 0x01800, .buf2 = 0x44000, .size = 0x800 },
{ .buf1 = 0x05C00, .buf2 = 0x44800, .size = 0x8000 - 0x5C00 },
{ 0 } /* End of the table */
@@ -515,32 +514,32 @@ soc_sram_info soc_sram_info_table[] = {
.soc_id = 0x1650, /* Allwinner A23 */
.scratch_addr = 0x2000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
- .swap_buffers = a31_sram_swap_buffers,
+ .swap_buffers = ar100_abusing_sram_swap_buffers,
},
{
.soc_id = 0x1633, /* Allwinner A31 */
.scratch_addr = 0x2000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
- .swap_buffers = a31_sram_swap_buffers,
+ .swap_buffers = ar100_abusing_sram_swap_buffers,
},
{
.soc_id = 0x1667, /* Allwinner A33 */
.scratch_addr = 0x2000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
- .swap_buffers = a31_sram_swap_buffers,
+ .swap_buffers = ar100_abusing_sram_swap_buffers,
},
{
.soc_id = 0x1673, /* Allwinner A83T */
.scratch_addr = 0x2000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
- .swap_buffers = a31_sram_swap_buffers,
+ .swap_buffers = ar100_abusing_sram_swap_buffers,
},
{
.soc_id = 0x1680, /* Allwinner H3 */
.scratch_addr = 0x2000,
.mmu_tt_addr = 0x44000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
- .swap_buffers = a31_sram_swap_buffers,
+ .swap_buffers = ar100_abusing_sram_swap_buffers,
},
{ 0 } /* End of the table */
};
--
2.4.10
--
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 sunxi-tools 5/7] fel: Move the temporary scratch buffer under the IRQ stack
Doing certain operations may need uploading and executing code
on the device. For example, such operations right now are
reading/writing ARM CP15 coprocessor registers. Uploading the
code to the device is naturally overwriting some part of SRAM
as a side effect. Right now it is not a problem, because the
CP15 coprocessor registers are only accessed as part of uploading
and executing U-Boot SPL. They are nicely timed not to cause
problems and the temporary scratch area gets overwritten by
the SPL code anyway.
But if we decide to provide access to such operations via
command line interface, then any side effects may potentially
cause problems for the users. Consider the following scenario:
sunxi-fel clear 0x2000 0x100 \
advanced-command-which-uploads-and-executes-code \
hexdump 0x2000 0x100
The user may rightfully expect that clearing a buffer in SRAM
to zero and then reading it back should show all zero bytes.
But inserting advanced commands in the middle may cause data
corruption.
In order to resolve this problem, just move the scratch area
away from the 0x2000-0x5BFF addresses range. These particular
addresses are already known to the users as a safe place for
their bare metal expariments in FEL mode. The "sunxi-fel spl"
command is a special case though and it is expected to
overwrite data in this area too.
A possible alternative would be to just backup & restore data
in the scratch area. But this has some disadvantages:
1. Extra code in the sunxi-fel tool and extra roundtrips over
USB to do the backup/restore job.
2. If we allow the OpenRISC core to use the 0x2000-0x5C00
range in SRAM A1, then this becomes unsafe and racy
(we can't really backup & restore data without causing
a temporarily glitch for the currently running code on
the OpenRISC core).
To sum it up. With this patch we make it so that now the
0x2000-0x5BFF range is freely available for the users of the
sunxi-fel tool. The 0x1000-0x1FFF range is off limits (the
upper part of it is used by the FEL IRQ handler, the lower
part of it is reserved for internal use by the sunxi-fel
tool). The 0x-0x1FFF addresses range is reserved for
passing data from the SPL to the main U-Boot binary (via
the SPL header) and is also off limits.
Signed-off-by: Siarhei Siamashka
---
fel.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/fel.c b/fel.c
index 40cb82a..a597e11 100644
--- a/fel.c
+++ b/fel.c
@@ -505,51 +505,51 @@ sram_swap_buffers ar100_abusing_sram_swap_buffers[] = {
soc_sram_info soc_sram_info_table[] = {
{
.soc_id = 0x1623, /* Allwinner A10 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0xA200, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
.needs_l2en = 1,
},
{
.soc_id = 0x1625, /* Allwinner A13 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0xA200, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
.needs_l2en = 1,
},
{
.soc_id = 0x1651, /* Allwinner A20 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0xA200, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
},
{
.soc_id = 0x1650, /* Allwinner A23 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
.swap_buffers = ar100_abusing_sram_swap_buffers,
},
{
.soc_id = 0x1633, /* Allwinner A31 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0x22E00, .thunk_size = 0x200,
.swap_buffers = a31_sram_swap_buffers,
},
{
.soc_id = 0x1667, /* Allwinner A33 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
.swap_buffers = ar100_abusing_sram_swap_buffers,
},
{
.soc_id = 0x1673, /* Allwinner A83T */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.thunk_addr = 0x46E00, .thunk_size = 0x200,
.swap_buffers = ar100_abusing_sram_swap_buffers,
},
{
.soc_id = 0x1680, /* Allwinner H3 */
- .scratch_addr = 0x2000,
+ .scratch_addr = 0x1000,
.mmu_tt_addr = 0x8000,
.thunk_addr = 0xA200, .thunk_size = 0x200,
.swap_buffers = a10_a13_a20_sram_swap_buffers,
--
2.4.10
[linux-sunxi] [PATCH sunxi-tools 3/7] fel: Move the backup storage to the SRAM B on A31
This allows the SRAM section A2 to be exclusively used by
the OpenRISC core.
Regarding the potential U-Boot SPL size. The SRAM section A1
only has 32 KiB. But at least the stack can be set at the end
of the SRAM section B. Or runtime UCL or LZO decompression can
be used to unpack the SPL code to 0x24000-0x2 and have
48 KiB of available space there.
Signed-off-by: Siarhei Siamashka
---
fel.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/fel.c b/fel.c
index 419f16a..71b12b5 100644
--- a/fel.c
+++ b/fel.c
@@ -479,6 +479,19 @@ sram_swap_buffers a10_a13_a20_sram_swap_buffers[] = {
};
/*
+ * A31 is very similar to A10/A13/A20, except that it has no SRAM at 0x8000.
+ * So we use the SRAM section B at 0x2-0x2 instead. In the FEL mode,
+ * the MMU translation table is allocated by the BROM at 0x2. But we can
+ * also safely use it as the backup storage because the MMU is temporarily
+ * disabled during the time of the SPL execution.
+ */
+sram_swap_buffers a31_sram_swap_buffers[] = {
+ { .buf1 = 0x01800, .buf2 = 0x2, .size = 0x800 },
+ { .buf1 = 0x05C00, .buf2 = 0x20800, .size = 0x8000 - 0x5C00 },
+ { 0 } /* End of the table */
+};
+
+/*
* Use the SRAM section at 0x44000 as the backup storage. This is the memory,
* which is normally shared with the OpenRISC core (should we do an extra check
* to ensure that this core is powered off and can't interfere?).
@@ -519,8 +532,8 @@ soc_sram_info soc_sram_info_table[] = {
{
.soc_id = 0x1633, /* Allwinner A31 */
.scratch_addr = 0x2000,
- .thunk_addr = 0x46E00, .thunk_size = 0x200,
- .swap_buffers = ar100_abusing_sram_swap_buffers,
+ .thunk_addr = 0x22E00, .thunk_size = 0x200,
+ .swap_buffers = a31_sram_swap_buffers,
},
{
.soc_id = 0x1667, /* Allwinner A33 */
--
2.4.10
--
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 sunxi-tools 4/7] fel: Move the backup storage to the SRAM section A1 on H3
This allows the SRAM section A2 to be exclusively used by
the OpenRISC core.
There are no substantial differences between H3 and A10/A13/A20.
It just has 64 KiB of SRAM starting at the address 0x0 instead
of 48 KiB.
Signed-off-by: Siarhei Siamashka
---
fel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fel.c b/fel.c
index 71b12b5..40cb82a 100644
--- a/fel.c
+++ b/fel.c
@@ -550,9 +550,9 @@ soc_sram_info soc_sram_info_table[] = {
{
.soc_id = 0x1680, /* Allwinner H3 */
.scratch_addr = 0x2000,
- .mmu_tt_addr = 0x44000,
- .thunk_addr = 0x46E00, .thunk_size = 0x200,
- .swap_buffers = ar100_abusing_sram_swap_buffers,
+ .mmu_tt_addr = 0x8000,
+ .thunk_addr = 0xA200, .thunk_size = 0x200,
+ .swap_buffers = a10_a13_a20_sram_swap_buffers,
},
{ 0 } /* End of the table */
};
--
2.4.10
--
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 sunxi-tools 0/7] fel: OpenRISC preparations and A64 support
The current sunxi-fel tool uses SRAM A2 as a backup storage for FEL stacks and a place to allocate the MMU translation table. But SRAM A2 is the fastest memory for the OpenRISC core and should be reserved for OpenRISC if we want to use it on A31/H3/A64. This patchset moves the FEL stacks backup storage and the MMU translation table to other SRAM areas. This fixes problems with the ar100-info application in the case when it is used after the DRAM is initialized by the "sunxi-fel spl" command (having the MMU table overwritten in SRAM A2 by the OpenRISC code is not good). Also because the SRAM layout gets changed anyway, ensure that the contiguous SRAM area available to the SPL is at least 40 KiB. The extra area beyond 32 KiB can be used at least for the stack and also provides an opportunity to support "oversized" SPL via LZO or UCL runtime decompression in the future. New readl/writel commands for reading/writing hardware registers, which can be used for various useful things (a more advanced OpenRISC support will need this functionality). The last patch (unrelated to the OpenRISC core) adds USB FEL boot support for Allwinner A64. Siarhei Siamashka (7): fel: Move backup area to higher addresses in SRAM on A10/A13/A20 fel: Rename the backup buffers which use AR100 (OpenRISC) SRAM fel: Move the backup storage to the SRAM B on A31 fel: Move the backup storage to the SRAM section A1 on H3 fel: Move the temporary scratch buffer under the IRQ stack fel: Add "readl" and "writel" commands fel: Add fel spl command support for Allwinner A64 fel.c | 135 -- 1 file changed, 107 insertions(+), 28 deletions(-) -- 2.4.10 -- 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] esata multiplier
Hello, on the website http://linux-sunxi.org/SATA#Caveats there is stated "Cheap port multipliers like JMB321/JMB393", Im just wondering what are the good esata multiplier, could you please suggest some? Thank you! Best, John -- 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] A64, arisc, SCPI and regulator handling
On Sat, Jan 23, 2016 at 07:42:49PM +0100, Karsten Merker wrote: > > > If the arisc firmware is required for basic bringup of the > > > system, this would mean that Debian would have to ship the > > > firmware as part of the installer images. This would only be > > > possible if the firmware fulfills the requirements for being > > > included in the "main" repository, which excludes any binary-only > > > vendor-supplied firmware file. > > > > I don't think that anyone considers the use of the vendor-supplied > > firmware. > > Then maybe I have misunderstood the discussion, but my impression > was that the idea was to use the vendor blob to access the PMIC. No, the plan was to use *a* blob. Since the original firmware provided by Allwinner doesn't support SCPI anyway (and that we probably can't use it in the end), it's never really been the plan to use it. > > > Even if we had a firmware implementation under a DFSG-compatible > > > license, inclusion in main would still pose a problem as we > > > cannot build it with the tools in main: there is no OpenRisc > > > support in mainline binutils and gcc and that will probably not > > > change in the forseeable future: > > > > > > https://people.debian.org/~mafm/posts/2015/20150421_about-the-debian-gnulinux-port-for-openrisc-or1k/ > > > > Regarding this blog. Very few of the problems mentioned there apply > > to us. What we need is just a simple bare-metal toolchain to build > > a very simple firmware. We don't need things like autotools and glibc, > > because we are not trying to build a huge Linux distribution for > > the OpenRISC architecture with lots of userland packages. > > As other people have also jumped on the "full linux port" thing: > I have never written that we would need a full-fledged Linux port > for the arisc. I have just pointed out that we lack mainline gcc > support for OpenRisc and pointed to a blog entry which describes > why that is the case. Even if we port Linux on that CPU, it doesn't have an MMU, so we could probably not run debian on it anyway, so having a gcc port in debian doesn't seem useful anyway. I'd think that as far as Debian is involved, it would only end up being a free (as in you have the source code) firmware that should be packaged somehow. > > > To avoid all these problems, I would like to strongly propose > > > doing the RSB and PMIC handling directly from the ARM core (as it > > > has been done for all other Allwinner SoCs) and not use the arisc > > > at all if that is technically feasible. > > > > Well, this would prevent us from ever having a decent suspend > > support among other things. > > I know nothing about the implementation details of suspend/resume, > but suspend/resume seems to work on lots of A10/A13/A20/A23/A33- > based android tablets, which to my knowledge don't have an extra > coprocessor for that. Can't the same mechanism be used on the > newer SoCs as well? Please excuse if this is stupid question - I > probably don't have the necessary technical background knowledge in > this area. You're mixing up very different things. First off, suspend / resume doesn't work in mainline. We could use a "software" suspend / resume implementation on all the SoCs you're talking about (and we will have to do it on the A10 and A20). However, on the newer SoCs (since the A31), we have that openrisc co-processor to help do that (and as far as I know, the Allwinner implementation does use it). What doesn't work anymore with the A64 is the PMIC communication, that is completely orthogonal. In the A64, the ARM CPUs cannot talk to the PMIC bus controller anymore, so we have to use the openrisc core there. And since we will have to do this work for the A64, we can also just use it for the A31 and later SoCs together, since they all share the same design. 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 RFC 15/15] ARM: dts: sun9i: cubieboard4: Enable hardware reset and HS-DDR for eMMC
On Thu, Jan 21, 2016 at 01:26:42PM +0800, Chen-Yu Tsai wrote: > mmc2 has a special pin for eMMC hardware reset, which is controllable > from the controller. Add the "mmc-cap-hw-reset" property to denote that > this controller supports this function, and the pins are actually used. > > Also increase the signal drive strength for mmc2 pins, for HS-DDR mode > support. > > Signed-off-by: Chen-Yu Tsai 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 RFC 14/15] ARM: dts: sun9i: a80-optimus: Enable hardware reset and HS-DDR for eMMC
On Thu, Jan 21, 2016 at 01:26:41PM +0800, Chen-Yu Tsai wrote: > mmc2 has a special pin for eMMC hardware reset, which is controllable > from the controller. Add the "mmc-cap-hw-reset" property to denote that > this controller supports this function, and the pins are actually used. > > Also increase the signal drive strength for mmc2 pins, for HS-DDR mode > support. > > Signed-off-by: Chen-Yu Tsai 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 RFC 13/15] ARM: dts: sun9i: Include SDC2_RST pin in mmc2_8bit_pins
On Thu, Jan 21, 2016 at 01:26:40PM +0800, Chen-Yu Tsai wrote: > mmc2_8bit_pins is used with eMMC chips, which also have a reset pin. > The MMC controller also has a reset output that is supported. > > Signed-off-by: Chen-Yu Tsai 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 RFC 10/15] ARM: dts: sun8i: Include SDC2_RST pin in mmc2_8bit_pins
On Thu, Jan 21, 2016 at 01:26:37PM +0800, Chen-Yu Tsai wrote: > mmc2_8bit_pins is used with eMMC chips, which also have a reset pin. > The MMC controller also has a reset output that is supported. > > Signed-off-by: Chen-Yu Tsai 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 RFC 09/15] ARM: dts: sun6i: sina31s: Switch to mmc3 for onboard eMMC
Hi,
On Sat, Jan 23, 2016 at 12:21:55PM +0800, Chen-Yu Tsai wrote:
> On Sat, Jan 23, 2016 at 4:39 AM, Maxime Ripard
> wrote:
> > Hi,
> >
> > On Thu, Jan 21, 2016 at 01:26:36PM +0800, Chen-Yu Tsai wrote:
> >> According to Allwinner, only mmc3 supports 8 bit DDR transfers for eMMC.
> >> Switch to mmc3 for the onboard eMMC, and also assign vqmmc for signal
> >> voltage sensing/switching, and "cap-mmc-hw-reset" to denote this
> >> instance can use eMMC hardware reset.
> >>
> >> Signed-off-by: Chen-Yu Tsai
> >> ---
> >> arch/arm/boot/dts/sun6i-a31s-sina31s-core.dtsi | 6 --
> >> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/arch/arm/boot/dts/sun6i-a31s-sina31s-core.dtsi
> >> b/arch/arm/boot/dts/sun6i-a31s-sina31s-core.dtsi
> >> index ea69fb8ad4d8..4ec0c8679b2e 100644
> >> --- a/arch/arm/boot/dts/sun6i-a31s-sina31s-core.dtsi
> >> +++ b/arch/arm/boot/dts/sun6i-a31s-sina31s-core.dtsi
> >> @@ -61,12 +61,14 @@
> >> };
> >>
> >> /* eMMC on core board */
> >> -&mmc2 {
> >> +&mmc3 {
> >> pinctrl-names = "default";
> >> - pinctrl-0 = <&mmc2_8bit_emmc_pins>;
> >> + pinctrl-0 = <&mmc3_8bit_emmc_pins>;
> >> vmmc-supply = <®_dcdc1>;
> >> + vqmmc-supply = <®_dcdc1>;
> >
> > That seems odd. IIRC the VCC was supposed to be fixed and VCCQ could
> > be either at 1.8 or 3V. Having the same regulator on both would make
> > VCCQ forced to 3.3V, which seems to go against your commit log.
> >
> > What's the catch ? :)
>
> That is how the board is routed. Which means the only use for
> vqmmc-supply is the driver will know that it can only do 3.3V,
> i.e. voltage sensing.
>
> It is the reason I requested Olimex to look into this. Allwinner
> reference designs all tie vqmmc directly to 3.3V.
>
> Actually with the latest driver patches, this is not even needed. To
> make the driver backward compatible, if no vqmmc-supply is given, it
> just assumes 3.3V signaling.
Ok. I've applied this patch and changed the commit log to remove the
voltage switching mention then, since it won't happen.
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 RFC 08/15] ARM: dts: sun6i: Add mmc3 pins for 8 bit emmc
Hi,
On Sat, Jan 23, 2016 at 07:04:54PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Sat, Jan 23, 2016 at 4:31 AM, Maxime Ripard
> wrote:
> > Hi,
> >
> > On Thu, Jan 21, 2016 at 01:26:35PM +0800, Chen-Yu Tsai wrote:
> >> mmc2 and mmc3 are available on the same pins, with different mux values.
> >> However, only mmc3 supports 8 bit DDR transfer modes.
> >>
> >> Since preference for mmc3 over mmc2 is due to DDR transfer modes, just
> >> set the drive strength to 40mA, which is needed for DDR.
> >>
> >> This pinmux setting also includes the hardware reset pin for emmc.
> >>
> >> Signed-off-by: Chen-Yu Tsai
> >> ---
> >> arch/arm/boot/dts/sun6i-a31.dtsi | 10 ++
> >> 1 file changed, 10 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi
> >> b/arch/arm/boot/dts/sun6i-a31.dtsi
> >> index b6ad7850fac6..1867af24ff52 100644
> >> --- a/arch/arm/boot/dts/sun6i-a31.dtsi
> >> +++ b/arch/arm/boot/dts/sun6i-a31.dtsi
> >> @@ -709,6 +709,16 @@
> >> allwinner,pull = ;
> >> };
> >>
> >> + mmc3_8bit_emmc_pins: mmc3@1 {
> >> + allwinner,pins = "PC6", "PC7", "PC8", "PC9",
> >> + "PC10", "PC11", "PC12",
> >> + "PC13", "PC14", "PC15",
> >> + "PC24";
> >> + allwinner,function = "mmc3";
> >> + allwinner,drive = ;
> >> + allwinner,pull = ;
> >> + };
> >> +
> >
> > Is that reset pin optional?
> >
> > If so, I'd prefer it to be a separate node, like we're doing for the
> > SPI chip selects for example.
> >
> > It allows more reusability between different devices without declaring
> > new nodes.
>
> All eMMC devices have a reset pin. The MMC standard specifies this as
> one way to reset the card, others being a special reset command, or
> powering the card off. It also notes a state when the card will not
> accept commands, and will require a power cycle or asserting the reset
> pin.
>
> I assume all designs would route this pin. The FEX files also have this
> pin included by default.
I was more concerned about the case were you'd have a 8bits bus
without an emmc. But I guess that can't happen, since all SD cards are
using a 4 bits width anyway.
I'll apply this patch.
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
