[linux-sunxi] Firmware extractor for GSL168x chips
Hi all:
I created a firmware extractor for these chips. Hope it is useful.
Some notes:
* Sometimes it fails in the first launch, but launching again with
exactly the same parameters works fine.
* Try to unload the touch module before running it, to avoid
interferences between both codes.
* Try first with a chunk size of 4 bytes, and change only to 2 or 1 if
it fails.
--
Nos leemos
RASTER(Linux user #228804)
ras...@rastersoft.com http://www.rastersoft.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.
/*
* Copyright 2015 Raster Software Vigo
*
*
* extract is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* extract is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program. If not, see http://www.gnu.org/licenses/.
*/
#include extract.h
#include errno.h
#include unistd.h
#include string.h
#include stdio.h
#include linux/i2c-dev.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include stdlib.h
#include linux/input.h
#include linux/uinput.h
#include math.h
#ifdef USE_FB
#include linux/fb.h
#endif
struct i2c_client {
int adapter;
};
static __inline__ void fw2buf(u8 *buf, const u32 *fw) {
u32 *u32_buf = (u32 *)buf;
*u32_buf = *fw;
}
static int gsl_ts_write(struct i2c_client *client, u8 addr, u8 *pdata, int datalen) {
int ret = 0;
u8 tmp_buf[128];
unsigned int bytelen;
if (client==NULL) {
return datalen+1;
}
if (datalen 125) {
printf(%s too big datalen = %d!\n, __func__, datalen);
return -1;
}
tmp_buf[0] = addr;
bytelen=1;
if (datalen != 0 pdata != NULL) {
memcpy(tmp_buf+1, pdata, datalen);
bytelen += datalen;
}
ret = write(client-adapter, tmp_buf, bytelen);
return ret;
}
static int gsl_ts_read(struct i2c_client *client, u8 addr, u8 *pdata, unsigned int datalen) {
int ret = 0;
if (datalen 126) {
printf(%s too big datalen = %d!\n, __func__, datalen);
return -1;
}
ret = write(client-adapter, addr, 1);
if (ret 0) {
printf(%s set data address fail!\n, __func__);
return ret;
}
return read(client-adapter, pdata, datalen);
}
static void reset_chip(struct i2c_client *client) {
u8 buf[1];
buf[0]=0x88;
gsl_ts_write(client, GSL_STATUS_REG, buf, 1);
usleep(1);
buf[0]=0x04;
gsl_ts_write(client, 0xe4, buf, 1);
usleep(1);
buf[0]=0x00;
gsl_ts_write(client, 0xbc, buf, 1);
usleep(1);
buf[0]=0x00;
gsl_ts_write(client, 0xbd, buf, 1);
usleep(1);
buf[0]=0x00;
gsl_ts_write(client, 0xbe, buf, 1);
usleep(1);
buf[0]=0x00;
gsl_ts_write(client, 0xbf, buf, 1);
usleep(1);
}
static void startup_chip(struct i2c_client *client) {
u8 tmp = 0x00;
gsl_ts_write(client, GSL_STATUS_REG, tmp, 1);
usleep(1);
}
int main(int argc, char **argv) {
struct i2c_client cliente;
int retval;
if (argc4) {
printf(Version 1\n);
printf(Format: extract DEVICE FW_FILE BLOCK_SIZE\n\n);
printf(DEVICE: path to the I2C device where the GSLx680 chip is connected\n);
printf(FW_FILE: path to the file where to store the current firmware\n);
printf(BLOCK_SIZE: size in bytes to read in one chunk. It can be 1, 2 or 4. Try the values until there aren't read errors.\n);
printf(\nWARNING: sometimes, the first execution fails, but launching the program again, with the same parameters, works.);
return 0;
}
char *adapter=NULL;
char *firmware=NULL;
int block_size=-1;
char *option;
int loop=1;
while(loopargc) {
option=argv[loop];
loop++;
if (adapter==NULL) {
adapter=strdup(option);
continue;
}
if (firmware==NULL) {
firmware=strdup(option);
continue;
}
if (block_size == -1) {
block_size=atoi(option);
continue;
}
printf(Too many parameters\n);
return -1;
}
printf(Connecting to device %s, storing at %s\n,adapter,firmware);
cliente.adapter=open(adapter,O_RDWR);
if (cliente.adapter0) {
printf(Can't open device %s\n,adapter);
return -1;
}
if (ioctl(cliente.adapter, I2C_SLAVE, GSLX680_I2C_ADDR) 0) {
printf(Error selecting device %d\n,GSLX680_I2C_ADDR);
return -2;
}
//reset_chip(cliente);
FILE *firmware_file = fopen(firmware,wb);
if (firmware_file == NULL) {
printf(Can't open the file %s for writting the firmware. Aborting\n,firmware);
return -3;
}
int memory_page;
int word_to_read;
u8 address = 0;
u8 page = 0;
u8
[linux-sunxi] Re: MMC clock gating broken on a20
On 24 May 2015 at 14:37, Michal Suchanek hramr...@gmail.com wrote: Hello, I tried to update the kernel on my cubieboards to something recent and while the a10 cubieboard works fine the a20 one won't boot. Looking at the console I found that the culprit is mmc clock so I disabled mmc clock gating and the board works. Doing more tests it turns out that the message comes from sunxi_mmc_oclk_onoff which is just unreliable so when you turn off mmc clock gating you are fine 99% of the time but with gating enabled the function gets called way too often and occasionally times out. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] MMC clock gating broken on a20
Hello, I tried to update the kernel on my cubieboards to something recent and while the a10 cubieboard works fine the a20 one won't boot. Looking at the console I found that the culprit is mmc clock so I disabled mmc clock gating and the board works. I went as far back as 3.19 and the issue is pretty much the same. The difference is that with linus master the clock gating seems more aggressive so the board does not even boot whereas with 3.19 it crashes shortly after booting fully. Anyone has some idea why the clock would fail re-enabling after gated? Supposedly the clock was already set up by the kernel when probing the mmc. Thanks Michal root@sunxi-a20:~# sunxi-mmc 1c0f000.mmc: fatal err update clk timeout mmcblk0: error -5 requesting status blk_update_request: I/O error, dev mmcblk0, sector 2048 Buffer I/O error on dev mmcblk0p1, logical block 0, lost async page write blk_update_request: I/O error, dev mmcblk0, sector 2056 Buffer I/O error on dev mmcblk0p1, logical block 1, lost async page write mmcblk0: error -5 sending status command, retrying mmcblk0: error -5 sending status command, retrying mmcblk0: error -5 sending status command, aborting blk_update_request: I/O error, dev mmcblk0, sector 6776 Buffer I/O error on dev mmcblk0p1, logical block 591, lost async page write mmcblk0: error -5 sending status command, retrying mmcblk0: error -5 sending status command, retrying mmcblk0: error -5 sending status command, aborting -- 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: Firmware extractor for GSL168x chips
Forgot to comment that this code extracts the firmware from a running GSL168x chip. This means that you should compile it statically and run it in the original Android system, to get the firmware. -- 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/2] mmc: sunxi: fix timeout in sunxi_mmc_oclk_onoff
The 250ms timeout is too short.
On my system enabling the oclk takes under 50ms and disabling slightly
over 100ms when idle. Under load disabling the clock can take over
350ms.
This does not make mmc clock gating look like good option to have on
sunxi but the system should not crash with mmc clock gating enabled
nonetheless.
This patch sets the timeout to 750ms and adds debug prints which show
how long enabling/disabling the clock took so more data can be collected
from other systems.
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
drivers/mmc/host/sunxi-mmc.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 4d3e1ff..7cdeecd 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -595,7 +595,7 @@ static irqreturn_t sunxi_mmc_handle_manual_stop(int irq,
void *dev_id)
static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
{
- unsigned long expire = jiffies + msecs_to_jiffies(250);
+ unsigned long start, end;
u32 rval;
rval = mmc_readl(host, REG_CLKCR);
@@ -604,6 +604,8 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host
*host, u32 oclk_en)
if (oclk_en)
rval |= SDXC_CARD_CLOCK_ON;
+ start = jiffies;
+ end = start + msecs_to_jiffies(750);
mmc_writel(host, REG_CLKCR, rval);
rval = SDXC_START | SDXC_UPCLK_ONLY | SDXC_WAIT_PRE_OVER;
@@ -611,15 +613,29 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host
*host, u32 oclk_en)
do {
rval = mmc_readl(host, REG_CMDR);
- } while (time_before(jiffies, expire) (rval SDXC_START));
+ } while (time_before(jiffies, end) (rval SDXC_START));
+ end = jiffies;
/* clear irq status bits set by the command */
mmc_writel(host, REG_RINTR,
mmc_readl(host, REG_RINTR) ~SDXC_SDIO_INTERRUPT);
if (rval SDXC_START) {
- dev_err(mmc_dev(host-mmc), fatal err update clk timeout\n);
+ dev_err(mmc_dev(host-mmc),
+ fatal err update oclk timeout. Could not %s in
%ims.\n,
+ oclk_en ? enable : disable,
+ jiffies_to_msecs(end-start));
return -EIO;
+ } else {
+ int msecs = jiffies_to_msecs(end-start);
+ const char *ing = oclk_en ? enabling : disabling;
+
+ if ((msecs 150) || (oclk_en (msecs 50)))
+ dev_warn(mmc_dev(host-mmc),
+%s oclk took %ims, ing, msecs);
+ else
+ dev_dbg(mmc_dev(host-mmc),
+%s oclk took %ims, ing, msecs);
}
return 0;
--
2.1.4
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 2/2] mmc: sunxi: Also set SDXC_LOW_POWER_ON
The function sunxi_mmc_oclk_onoff filters out the SDXC_LOW_POWER_ON flag but never sets it. Set SDXC_LOW_POWER_ON when oclk is disabled. Signed-off-by: Michal Suchanek hramr...@gmail.com --- drivers/mmc/host/sunxi-mmc.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c index 7cdeecd..e957888 100644 --- a/drivers/mmc/host/sunxi-mmc.c +++ b/drivers/mmc/host/sunxi-mmc.c @@ -603,6 +603,8 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en) if (oclk_en) rval |= SDXC_CARD_CLOCK_ON; + else + rval |= SDXC_LOW_POWER_ON; start = jiffies; end = start + msecs_to_jiffies(750); -- 2.1.4 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 0/2] sunxi a20 mmc timeout fix
Hello, I had serious problems with root filesustem on SD card on Cubieboard2 when clock gating was on. It turns out that sunxi_mmc_oclk_onoff has way too short timeout ofr setting the clock. So here are some patches for - bumping the timout - spamming dmesg when the time to set the clock seems too long - setting SDXC_LOW_POWER_ON which is unset but never set Also feel free to just bump the timeout to reasonably high value so the board can boot reliably with mmc clock gating enabled. Thanks Michal Michal Suchanek (2): mmc: sunxi: fix timeout in sunxi_mmc_oclk_onoff mmc: sunxi: Also set SDXC_LOW_POWER_ON drivers/mmc/host/sunxi-mmc.c | 24 +--- 1 file changed, 21 insertions(+), 3 deletions(-) -- 2.1.4 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [RFC 7/7] ARM: dts: sun9i: Add secure SRAM node used for MCPM SMP hotplug
On Wed, May 20, 2015 at 6:08 PM, Maxime Ripard
maxime.rip...@free-electrons.com wrote:
On Thu, May 14, 2015 at 02:10:11PM +0800, Chen-Yu Tsai wrote:
The A80 stores some magic flags in a portion of the secure SRAM. The
BROM jumps directly to the software entry point set by the SMP code
if the flags are set. This is required for CPU0 hotplugging.
Signed-off-by: Chen-Yu Tsai w...@csie.org
---
arch/arm/boot/dts/sun9i-a80.dtsi | 20
1 file changed, 20 insertions(+)
diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi
b/arch/arm/boot/dts/sun9i-a80.dtsi
index 1507bd2a88f0..0695215634d4 100644
--- a/arch/arm/boot/dts/sun9i-a80.dtsi
+++ b/arch/arm/boot/dts/sun9i-a80.dtsi
@@ -366,6 +366,26 @@
*/
ranges = 0 0 0 0x2000;
+ sram_b: sram@0002 {
+ /* 256 KiB secure SRAM at 0x2 */
+ compatible = mmio-sram;
+ reg = 0x0002 0x4;
+
We should probably add a property to that SRAM to tell the driver not
to access it if we're not booted in secure mode.
(CC-ing Heiko...)
That kind of puts architecture (ARM) dependent code into a platform
driver. Furthermore, AFAIK there isn't a safe way to check if we're
in secure mode or not. Checking SCR raises an undefined instruction
exception in non-secure mode. Can the kernel handle that? I really
don't understand this bit well.
Otherwise, bad things might happen.
The kernel (or rather the bootloader) boots in secure mode by default,
and we don't have any bootloader support to boot into non-secure mode
ATM. Couldn't we have the bootloader mark the SRAM as disabled when
booting into non-secure when we add that support?
ChenYu
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Firmware extractor for GSL168x chips
Thank you very much! This tool is one that what is missed in complete set of make it working GSL1680. Have ported your code to baytrail. 1st - these lines I think is rudшmental in section include (it is important for porting! ) and came from user space driver where was used uinput device. #include linux/input.h #include linux/uinput.h 2nd: It is unbelievable but on Chuwi vi8 looks that idiots put touch screen with more resolution than display resolution. After dumping I've got the same story from which I was started - resolution of something like x=1145 y=1725 - this is the same I have extracted from elf .ko file, this is the same I've got with loading Silead.fw taken from Win 8.1. On Chuwi Vi8 I dis this so: rmod gslx680_ts (be ready to connect external keyboard because touch will not work or use linux scripting\piping to get result) then I run twice!!! (only 2nd attempt was working) Kind regards, Serge Kolotylo. -- 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] Empty bootinfo dram layout parameters.
Hi Siarhei, As the resident sunxi dram controller expert, what do you make of this: [dram_para] dram_baseaddr = 0x4000 dram_clk = 408 dram_type = 3 dram_rank_num = -1 dram_chip_density = -1 dram_io_width = -1 dram_bus_width = -1 dram_cas = 9 dram_zq = 0x7f dram_odt_en = 0 dram_size = -1 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_tpr4 = 0x1 dram_tpr5 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 This is for the horribly incomplete http://linux-sunxi.org/Inet_k70e which has an A20, from the image which sandpox posted. The script.bin has the exact same info which bootinfo retrieves from BOOT0. I do not think i have seen such results before and i wonder where this information could otherwise be coming from. Perhaps any of the people in CC could finally fully run through the new device howto and post the output of meminfo (next to completing the rest of that page). 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] Re: New firmware for GSL1680
Ok, So fresh news and summary. Many many thanks to Sergio Costas for his work and assistance. He wrote and published FW extractor. I suppose it will be useful for someone trying to make it works GSL1680. In my case, Chuwi Vi8 super (baytrail architecture) it looks that chinese developers put in this tablet touch screen with higher resolution than display resolution. It means that what I have extracted from .ko elf file from the begining and what I have taken from Win 8.1 Silead.fw and what I've got with Sergio Costas's extractor - all these firmwares returns weird resolution 1145x1725 (may be allittle mistake ;-) due my fingers, but I think that I note it as correctly as I can). So, in case for Chuwi Vi8 super, baytrail architecture - the solution is still the same - add rescaling correlation to Sergio Costa's user space driver. Also I have not yet analyzed all working firmware files that I have but for me it looks weird that different size firmware works in the same manner. (in case of user space driver it is important the size of FW because the more it is the more its time consuming for loading it). It will be good to disassemble firmware for GSL1680 to understand what is it, I saw in some variants of firmware some comments to some portion of bytes (unfortunately in weird char layouts, probably chinese or closely). With best regards, Serge Kolotylo. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: New firmware for GSL1680
Ok, So fresh news and summary. Many many thanks to Sergio Costas for his work and assistance. He wrote and published FW extractor. I suppose it will be useful for someone trying to make it works GSL1680. In my case, Chuwi Vi8 super (baytrail architecture) it looks that chinese developers put in this tablet touch screen with higher resolution than display resolution. It means that what I have extracted from .ko elf file from the begining and what I have taken from Win 8.1 Silead.fw and what I've got with Sergio Costas's extractor - all these firmwares returns weird resolution 11145x1725 (may be allittle mistake ;-) due my fingers, but I think that I note it as correctly as I can). So, in case for Chuwi Vi8 super, baytrail architecture - the solution is still the same - add rescaling correlation to Sergio Costa's user space driver. Also I have not yet analyzed all working firmware files that I have but for me it looks weird that different size firmware works in the same manner. (in case of user space driver it is important the size of FW because the more it is the more its time consuming for loading it). It will be good to disassemble firmware for GSL1680 to understand what is it, I saw in some variants of firmware some comments to some portion of bytes (unfortunately in weird char layouts, probably chinese or closely). With best regards, Serge Kolotylo. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 1/2] mmc: sunxi: fix timeout in sunxi_mmc_oclk_onoff
Hi Michal,
On Mon, May 25, 2015 at 4:07 AM, Michal Suchanek hramr...@gmail.com wrote:
The 250ms timeout is too short.
On my system enabling the oclk takes under 50ms and disabling slightly
over 100ms when idle. Under load disabling the clock can take over
350ms.
This does not make mmc clock gating look like good option to have on
sunxi but the system should not crash with mmc clock gating enabled
nonetheless.
This patch sets the timeout to 750ms and adds debug prints which show
how long enabling/disabling the clock took so more data can be collected
from other systems.
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
drivers/mmc/host/sunxi-mmc.c | 22 +++---
1 file changed, 19 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
index 4d3e1ff..7cdeecd 100644
--- a/drivers/mmc/host/sunxi-mmc.c
+++ b/drivers/mmc/host/sunxi-mmc.c
@@ -595,7 +595,7 @@ static irqreturn_t sunxi_mmc_handle_manual_stop(int irq,
void *dev_id)
static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
{
- unsigned long expire = jiffies + msecs_to_jiffies(250);
+ unsigned long start, end;
u32 rval;
rval = mmc_readl(host, REG_CLKCR);
@@ -604,6 +604,8 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host
*host, u32 oclk_en)
if (oclk_en)
rval |= SDXC_CARD_CLOCK_ON;
+ start = jiffies;
+ end = start + msecs_to_jiffies(750);
You might want to make the timeout value a #define so it's not buried
in the code like this.
Thanks,
--
Julian Calaby
Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
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 Wed, May 20, 2015 at 11:55 PM, Chen-Yu Tsai w...@csie.org wrote:
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
Thank you for the suggestion, I think that was the piece I was missing!
After enabiling the CONFIG_I2C_SUN6I_P2WI on top of the sunxi_defconfig the
AXP driver for AXP221 gets loaded and seems to work. Tablet now appears to
reboot and power off as expected which is great!
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 v6] dma: sun4i: Add support for the DMA engine on sun[457]i SoCs
On Thu, May 21, 2015 at 09:47:35AM +0200, Maxime Ripard wrote:
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?
whatever dma_cookie_status returns
--
~Vinod
--
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 Thursday, May 21, 2015 at 5:12:07 PM UTC+7, Luc Verhaegen wrote:
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.
do you have a kernel source of this board? none of sun7i kernel work
--
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: [PATCH v9 4/4] crypto: Add Allwinner Security System crypto accelerator
On Sun, May 24, 2015 at 10:04:16AM +0200, Corentin LABBE wrote:
For aes_cbc it exists a test with 3 SG with .tap = { 496 - 20, 4, 16 }
But my driver handle that. (multiple of 4)
What do you think about adding a test with 16 SG of 1 byte ? (or 3 + 2 + 3 +
8 * 1)
Sure please send a patch.
Thanks,
--
Email: Herbert Xu herb...@gondor.apana.org.au
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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.
