[linux-sunxi] Re: A20 with Samsung's SDRAM 'K4B1G1646G BCK0'

[sufi al hussaini hassani kamili raheemi]

I'm very grateful to you @Siarhei, for having taken the time to write these 
very helpful replies. You're awesome!

I'll read how to get myself a uboot defconfig for my board, and will 
continue that way.
But first, I'm starting with 'sunxi-bootsetup-prototype' image, to make 
sure all's well hardware-wise. 

Thanks again!

On Tuesday, May 19, 2015 at 2:56:30 PM UTC+4, sufi al hussaini hassani 
kamili raheemi wrote:
>
> I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'. 
>
> The problem I'm facing now is that I'm not able to get it to boot. I keep 
> getting the following on debug UART:
>
> U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16)
> DRAM:Timeout initialising DRAM
>
> resetting ...
>
>  (Repeats infinitely)
>
>
> I suspected that the (old) '[dram_para]' in my FEX file was causing this, 
> as it was configured for 'K4B4G1646D' (which is widely used).
> So, I edited the FEX file based on the info I could gather from the 
> SDRAM's datasheet. It now looks like this:
>
>
> [dram_para]
> dram_baseaddr = 0x4000
> dram_clk = 384
> dram_type = 3
> dram_rank_num = 1
> dram_chip_density = 1024
> dram_io_width = 16
> dram_bus_width = 32
> dram_cas = 9
> dram_zq = 0x7f
> dram_odt_en = 0
> dram_size = 256
> dram_tpr0 = 0x42d899b7
> dram_tpr1 = 0xa090
> dram_tpr2 = 0x22a00
> dram_tpr3 = 0x0
> dram_tpr4 = 0x0
> dram_tpr5 = 0x0
> dram_emr1 = 0x4
> dram_emr2 = 0x10
> dram_emr3 = 0x0
>
> I tried booting with this but to no avail. The problem persists (same 
> error).
>
> I looked for ways to get the DRAM info directly from the hardware and 
> found meminfo in sunxi tools. 
> I was able to compile (and run) it (on a A20 based commercial board), but 
> I just can't figure out how to get it running on my board.
>
> Now, I'm confused- whether just setting the correct values in my FEX would 
> suffice or would I have to rebuild U-Boot.
> I would appreciate if someone could point me in the right direction to 
> solve this problem. 
>
> Thanks.
>

-- 
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: A20 with Samsung's SDRAM 'K4B1G1646G BCK0'

[Siarhei Siamashka]

On Tue, 19 May 2015 07:57:19 -0700 (PDT)
sufi al hussaini hassani kamili raheemi 
wrote:

> I tried building mainline u-boot as you suggested @Hans. Here's what I did 
> (please bear with me):
> 
> Compiled u-boot (natively on olimex A20-micro):
> (Installed dtc first)
> 
> > git clone git://git.denx.de/u-boot.git
> > make A20-OLinuXino_MICRO_defconfig
> > make

So you have an A20-OLinuXino_MICRO board, which is working fine. That's
very good. Using it you can learn quite a lot about the Allwinner
hardware in general.

And this experience should help with the other boards.

> Wrote the bootloader files to an SD card using:
> > sudo dd if=~/u-boot/u-boot.bin of=/dev/disk2 bs=1024 seek=32 
> > sudo dd if=~/u-boot/spl/sunxi-spl.bin of=/dev/disk2 bs=1024 seek=8

> However, I still (sadly) get the same error.
> U-Boot SPL 2015.07-rc1-00255-g0e6b7a2 (May 19 2015 - 16:55:13)
> 
> DRAM:Timeout initialising DRAM
>
> As seen above, this is a recent U-Boot version, so I'm guessing I did 
> compile the U-Boot alright.

Your U-Boot is configured for the A20-OLinuXino_MICRO board. Does
the A20-OLinuXino_MICRO board boot fine with this new freshly compiled
mainline U-Boot?

Using the A20-OLinuXino_MICRO config for a different Allwinner based
board may lead to unpredictable results. Each board has its own
defconfig file for a reason. You need to provide a proper defconfig
file for your board. To help people to succeed in this task, there
is a guide about bringing up new and previously unsupported devices:

   http://linux-sunxi.org/New_Device_howto

> But, the problem persists and I've run out of ideas. 
> 
> Any other suggestions? 
> Could there be any other reason (apart from DRAM parameters) that could be 
> causing this?

Based on the "Timeout initialising DRAM" error message, this is often
encountered when you have configured U-Boot for the wrong SoC type.
Is your board really using specifically the *A20* SoC?

And as an extra experiment, you may also try:

https://github.com/ssvb/sunxi-bootsetup/releases/tag/20141215-sunxi-bootsetup-prototype
If your board is really A10, A10s or A20 (and the hardware is not
defective), then you may successfully boot it with this SD card image.

-- 
Best regards,
Siarhei Siamashka

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: A20 with Samsung's SDRAM 'K4B1G1646G BCK0'

[Siarhei Siamashka]

On Tue, 19 May 2015 08:20:24 -0700 (PDT)
sufi al hussaini hassani kamili raheemi 
wrote:

> Has anyone tried this specific DRAM (Samsung's SDRAM 'K4B1G1646G BCK0')?

Regarding the "has anyone tried" part of the question, this particular
DDR3 chip does not seem to be very popular, according to the information
from http://linux-sunxi.org/DDR3

However this should not be a problem and DRAM should work just fine.
Assuming that the board itself is not defective.

> I was wondering if someone could provide me with '[dram_para]' for the FEX 
> file for this specific RAM.

The FEX file is not used by U-Boot at all. All the DRAM parameters are
configured in the U-Boot defconfig files. And this is explained at:

http://linux-sunxi.org/Mainline_U-boot#DRAM_Settings

The http://linux-sunxi.org/Fex_Guide#SDRAM section probably needs to
be adjusted and explicitly say that you don't want to touch this stuff
unless using the Allwinner's boot0 bootloader and/or livesuit.

If there is some other part of the wiki with misleading information,
please let us know.

-- 
Best regards,
Siarhei Siamashka

> 
> Thanks.
> 
> On Tuesday, May 19, 2015 at 2:56:30 PM UTC+4, sufi al hussaini hassani 
> kamili raheemi wrote:
> >
> > I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'. 
> >
> > The problem I'm facing now is that I'm not able to get it to boot. I keep 
> > getting the following on debug UART:
> >
> > U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16)
> > DRAM:Timeout initialising DRAM
> >
> > resetting ...
> >
> >  (Repeats infinitely)
> >
> >
> > I suspected that the (old) '[dram_para]' in my FEX file was causing this, 
> > as it was configured for 'K4B4G1646D' (which is widely used).
> > So, I edited the FEX file based on the info I could gather from the 
> > SDRAM's datasheet. It now looks like this:
> >
> >
> > [dram_para]
> > dram_baseaddr = 0x4000
> > dram_clk = 384
> > dram_type = 3
> > dram_rank_num = 1
> > dram_chip_density = 1024
> > dram_io_width = 16
> > dram_bus_width = 32
> > dram_cas = 9
> > dram_zq = 0x7f
> > dram_odt_en = 0
> > dram_size = 256
> > dram_tpr0 = 0x42d899b7
> > dram_tpr1 = 0xa090
> > dram_tpr2 = 0x22a00
> > dram_tpr3 = 0x0
> > dram_tpr4 = 0x0
> > dram_tpr5 = 0x0
> > dram_emr1 = 0x4
> > dram_emr2 = 0x10
> > dram_emr3 = 0x0
> >
> > I tried booting with this but to no avail. The problem persists (same 
> > error).
> >
> > I looked for ways to get the DRAM info directly from the hardware and 
> > found meminfo in sunxi tools. 
> > I was able to compile (and run) it (on a A20 based commercial board), but 
> > I just can't figure out how to get it running on my board.
> >
> > Now, I'm confused- whether just setting the correct values in my FEX would 
> > suffice or would I have to rebuild U-Boot.
> > I would appreciate if someone could point me in the right direction to 
> > solve this problem. 
> >
> > Thanks.
> >

-- 
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: A20 with Samsung's SDRAM 'K4B1G1646G BCK0'

[sufi al hussaini hassani kamili raheemi]

Has anyone tried this specific DRAM (Samsung's SDRAM 'K4B1G1646G BCK0')?
I was wondering if someone could provide me with '[dram_para]' for the FEX 
file for this specific RAM.

Thanks.

On Tuesday, May 19, 2015 at 2:56:30 PM UTC+4, sufi al hussaini hassani 
kamili raheemi wrote:
>
> I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'. 
>
> The problem I'm facing now is that I'm not able to get it to boot. I keep 
> getting the following on debug UART:
>
> U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16)
> DRAM:Timeout initialising DRAM
>
> resetting ...
>
>  (Repeats infinitely)
>
>
> I suspected that the (old) '[dram_para]' in my FEX file was causing this, 
> as it was configured for 'K4B4G1646D' (which is widely used).
> So, I edited the FEX file based on the info I could gather from the 
> SDRAM's datasheet. It now looks like this:
>
>
> [dram_para]
> dram_baseaddr = 0x4000
> dram_clk = 384
> dram_type = 3
> dram_rank_num = 1
> dram_chip_density = 1024
> dram_io_width = 16
> dram_bus_width = 32
> dram_cas = 9
> dram_zq = 0x7f
> dram_odt_en = 0
> dram_size = 256
> dram_tpr0 = 0x42d899b7
> dram_tpr1 = 0xa090
> dram_tpr2 = 0x22a00
> dram_tpr3 = 0x0
> dram_tpr4 = 0x0
> dram_tpr5 = 0x0
> dram_emr1 = 0x4
> dram_emr2 = 0x10
> dram_emr3 = 0x0
>
> I tried booting with this but to no avail. The problem persists (same 
> error).
>
> I looked for ways to get the DRAM info directly from the hardware and 
> found meminfo in sunxi tools. 
> I was able to compile (and run) it (on a A20 based commercial board), but 
> I just can't figure out how to get it running on my board.
>
> Now, I'm confused- whether just setting the correct values in my FEX would 
> suffice or would I have to rebuild U-Boot.
> I would appreciate if someone could point me in the right direction to 
> solve this problem. 
>
> Thanks.
>

-- 
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 07/10] pinctrl: sunxi: Add H3 PIO controller support

[Maxime Ripard]

On Tue, May 19, 2015 at 04:04:58PM +0200, Linus Walleij wrote:
> On Fri, May 15, 2015 at 6:38 PM, Jens Kuske  wrote:
> 
> > The H3 uses the same pin controller as previous SoC's from Allwinner.
> > Add support for the pins controlled by the main PIO controller.
> >
> > Signed-off-by: Jens Kuske 
> 
> Waiting for Maxime's ACKs on these patches before merging.

There's still the modules issue being debated on another patch of this
serie, so there will probably be a v3 of these patches.

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 v2 04/10] pinctrl: sunxi: Prepare for building SoC specific drivers as modules

[Linus Walleij]

On Tue, May 19, 2015 at 9:55 AM, Maxime Ripard
 wrote:

>> Apart from that, currently the kernel panics some seconds after removing
>> the pinctrl module because mmc wants to access a gpio. Can this be
>> prevented somehow? I think pinctrl must not be removed once other
>> devices use any pin-related things.
>
> pinctrl_unregister doesn't look like it cares about whether or not
> there's users left in the system.

Both GPIO and pinctrl has this problem, Johan Hovold has been
looking at fixing the GPIO side of things.

Patches welcome.

Yours,
Linus Walleij

-- 
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: A20 with Samsung's SDRAM 'K4B1G1646G BCK0'

[sufi al hussaini hassani kamili raheemi]

I tried building mainline u-boot as you suggested @Hans. Here's what I did 
(please bear with me):

Compiled u-boot (natively on olimex A20-micro):
(Installed dtc first)

> git clone git://git.denx.de/u-boot.git
> make A20-OLinuXino_MICRO_defconfig
> make



Wrote the bootloader files to an SD card using:
> sudo dd if=~/u-boot/u-boot.bin of=/dev/disk2 bs=1024 seek=32 
> sudo dd if=~/u-boot/spl/sunxi-spl.bin of=/dev/disk2 bs=1024 seek=8



However, I still (sadly) get the same error.
U-Boot SPL 2015.07-rc1-00255-g0e6b7a2 (May 19 2015 - 16:55:13)

DRAM:Timeout initialising DRAM

As seen above, this is a recent U-Boot version, so I'm guessing I did 
compile the U-Boot alright.
But, the problem persists and I've run out of ideas. 

Any other suggestions? 
Could there be any other reason (apart from DRAM parameters) that could be 
causing this?

Thanks and regards,
Shoaib.

On Tuesday, May 19, 2015 at 2:56:30 PM UTC+4, sufi al hussaini hassani 
kamili raheemi wrote:
>
> I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'. 
>
> The problem I'm facing now is that I'm not able to get it to boot. I keep 
> getting the following on debug UART:
>
> U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16)
> DRAM:Timeout initialising DRAM
>
> resetting ...
>
>  (Repeats infinitely)
>
>
> I suspected that the (old) '[dram_para]' in my FEX file was causing this, 
> as it was configured for 'K4B4G1646D' (which is widely used).
> So, I edited the FEX file based on the info I could gather from the 
> SDRAM's datasheet. It now looks like this:
>
>
> [dram_para]
> dram_baseaddr = 0x4000
> dram_clk = 384
> dram_type = 3
> dram_rank_num = 1
> dram_chip_density = 1024
> dram_io_width = 16
> dram_bus_width = 32
> dram_cas = 9
> dram_zq = 0x7f
> dram_odt_en = 0
> dram_size = 256
> dram_tpr0 = 0x42d899b7
> dram_tpr1 = 0xa090
> dram_tpr2 = 0x22a00
> dram_tpr3 = 0x0
> dram_tpr4 = 0x0
> dram_tpr5 = 0x0
> dram_emr1 = 0x4
> dram_emr2 = 0x10
> dram_emr3 = 0x0
>
> I tried booting with this but to no avail. The problem persists (same 
> error).
>
> I looked for ways to get the DRAM info directly from the hardware and 
> found meminfo in sunxi tools. 
> I was able to compile (and run) it (on a A20 based commercial board), but 
> I just can't figure out how to get it running on my board.
>
> Now, I'm confused- whether just setting the correct values in my FEX would 
> suffice or would I have to rebuild U-Boot.
> I would appreciate if someone could point me in the right direction to 
> solve this problem. 
>
> Thanks.
>

-- 
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] [ANNOUNCE] Allwinner releasing CedarX open source

[Manuel Braga]

On Tue, 19 May 2015 08:44:13 +0800 "ke...@allwinnertech.com"
 wrote:
> 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.
> 

I am sorry, but i find curious the reference here to the GPL license.

In order of "Some people are new and others help them learn the ropes
over time.", i will try to explain.


This, have nothing to do with any particular license.
The GPL license is only the most known and used copyleft license, and
by being so, is the license that is more talked about. And by this, it
happened to be the license(LGPL) involved in ours "license issues".
It would happened with any other license, the problems are the existence
of the "issues" by itself.

The key point here, is that the existence of the "issues" is a
disrespect towards the developers that wrote those same software source
code, and in some cases did without paid and in their free time.

And is not with "license issues" that allwinner or any other will
attract the contribution of open source developers.

-- 
Manuel Braga

-- 
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 07/10] pinctrl: sunxi: Add H3 PIO controller support

[Linus Walleij]

On Fri, May 15, 2015 at 6:38 PM, Jens Kuske  wrote:

> The H3 uses the same pin controller as previous SoC's from Allwinner.
> Add support for the pins controlled by the main PIO controller.
>
> Signed-off-by: Jens Kuske 

Waiting for Maxime's ACKs on these patches before merging.

Yours,
Linus Walleij

-- 
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] [ANNOUNCE] Allwinner releasing CedarX open source

[Sergey Lapin]

> 1. New code architecture. Driver has been split into several plugins, one
> plugin per video format.
> 2. GPL-complaint. We have scanned and analyzed the code to ensure that
> there
> is no GPL code used or called.
> 3. Partial CedarX video decoder source code release. MPEG2, MPEG4, MJPEG,
> and
> H264 drivers source code available.
>

Thanks a lot, guys, for your hard work! Ayeee, I'm dancing in circles!

Looking forward for next steps.

>
> We hope this is helpful to everyone. If not, please let us know how we can
> improve. Thanks!
>
>  --
>  Best Regards,
> kevin.z.m
>
>
>  NOTICE: This e-mail and any included attachments are intended only for
> the sole use of named and intended recipient (s) only. If you are the named
> and intended recipient, please note that the information contained in this
> email and its embedded files are confidential and privileged. If you are
> neither the intended nor named recipient, you are hereby notified that any
> unauthorized review, use, disclosure, dissemination, distribution, or
> copying of this communication, or any of its contents, is strictly
> prohibited. Please reply to the sender and destroy the original message and
> all your records of this message (whether electronic or otherwise).
> Furthermore, you should not disclose to any other person, use, copy or
> disseminate the contents of this e-mail and/or the documents accompanying
> it.
>
> --
> 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.
>

-- 
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] [ANNOUNCE] Allwinner releasing CedarX open source

[Manuel Braga]

On Tue, 19 May 2015 08:44:13 +0800 "ke...@allwinnertech.com"
 wrote:
> 3. Partial CedarX video decoder source code release. MPEG2, MPEG4,
> MJPEG, and H264 drivers source code available.

And for the others codecs, what are allwinner plans?
Should we expect for them to also be released, and which and in what
time frame should be this expected to happen?

This would be a very useful information to have, because this would help
us decide if we also have to reverse engineering h265, or only wait for
your release.
As h265 is the next much wished codec to have, is certain it will be
reversed engineered if allwinner takes too long.

Don't forget that, VP8 decoding, h264 encoding, jpeg encoding, was
also successful reversed engineered.
This is only to tell that, it is hardware documentation that we are
interested in, not the software in the form of your cedarx library.




> 
> We hope this is helpful to everyone. If not, please let us know how
> we can improve. Thanks!

In the socs datasheets, in the video engine features description, it has
as feature "alpha bending". Can we have more information what is mean by
this.

I tried my guess by poking random isp subengine registers but only we
could find is at the wiki page.
http://linux-sunxi.org/VE_Register_guide#ISP_Engine_Registers

If this is what it appears to be, then this would be very useful for
subtitles/osd, because if the bending can occur in the video engine,
then this is optimal in the performance point of view.

-- 
Manuel Braga

-- 
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: A20 with Samsung's SDRAM 'K4B1G1646G BCK0'

[sufi al hussaini hassani kamili raheemi]

Thanks for the guidance @Hans. 
I'm trying to build Mainline U-Boot  
now. 
Will post my progress here.

On Tuesday, May 19, 2015 at 2:56:30 PM UTC+4, sufi al hussaini hassani 
kamili raheemi wrote:
>
> I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'. 
>
> The problem I'm facing now is that I'm not able to get it to boot. I keep 
> getting the following on debug UART:
>
> U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16)
> DRAM:Timeout initialising DRAM
>
> resetting ...
>
>  (Repeats infinitely)
>
>
> I suspected that the (old) '[dram_para]' in my FEX file was causing this, 
> as it was configured for 'K4B4G1646D' (which is widely used).
> So, I edited the FEX file based on the info I could gather from the 
> SDRAM's datasheet. It now looks like this:
>
>
> [dram_para]
> dram_baseaddr = 0x4000
> dram_clk = 384
> dram_type = 3
> dram_rank_num = 1
> dram_chip_density = 1024
> dram_io_width = 16
> dram_bus_width = 32
> dram_cas = 9
> dram_zq = 0x7f
> dram_odt_en = 0
> dram_size = 256
> dram_tpr0 = 0x42d899b7
> dram_tpr1 = 0xa090
> dram_tpr2 = 0x22a00
> dram_tpr3 = 0x0
> dram_tpr4 = 0x0
> dram_tpr5 = 0x0
> dram_emr1 = 0x4
> dram_emr2 = 0x10
> dram_emr3 = 0x0
>
> I tried booting with this but to no avail. The problem persists (same 
> error).
>
> I looked for ways to get the DRAM info directly from the hardware and 
> found meminfo in sunxi tools. 
> I was able to compile (and run) it (on a A20 based commercial board), but 
> I just can't figure out how to get it running on my board.
>
> Now, I'm confused- whether just setting the correct values in my FEX would 
> suffice or would I have to rebuild U-Boot.
> I would appreciate if someone could point me in the right direction to 
> solve this problem. 
>
> Thanks.
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: New firmware for GSL1680

[sergk . admin]

Thank you for make it clear.

;-) Lets transform this knowledge into practical result! 


I have successfully compiled i2c-tools for x86 Android.
So, what is the exact command line to grab all loaded into GSL 1680 chip 
firmware?

i2cbus or i2cget? and how to use it , How via this toolset I could 
enumerate all 256 chunks of 128 bytes using information that chip resides 
on 0x40 I2c adress, dev is /dev/i2c-3, Page register is 0xF0 (8 bit too, so 
holds 256 addresses) and registers that store current 128 chunk are 
0x00-0x7F

Cheers, 
   Serge.

On Tuesday, May 19, 2015 at 1:48:14 PM UTC+3, Michal Suchanek wrote:
>
> On 19 May 2015 at 12:36,  > wrote: 
> > "On Tuesday, May 19, 2015 at 12:53:43 PM UTC+3, Michal Suchanek wrote: 
> > That's one page of the configuration which is 128 bytes or 32 integers. 
> > Writing the page register gives access (read or write) to different 
> pages. 
> > So one blob might have multiple such pages or the firmware can be 
> > composed of multiple pages stored in multiple blobs" 
> > 
> > 
> > Still not clear - where does stored these blobs? 
> > 
> > 0x00-0x7F = 128 items 128 * x =1 byte registers. So physically chip 
> could 
> > reside only 128 byte. 
> > 0xF0: PAGE register. Contains the memory page number currently mapped in 
> the 
> > 0x00-0x7F registers. 
> > 
> > 
> > What is logic of these  Page register and 0x00-0x7F registers? 
> > 
> > Am I right that firmware is loaded into ram splitted by 128 byte pages 
> and 
> > 0xF0 register contains a set of adressed in RAM of such 128 byte chunks? 
>
> Yes, that's what the datasheet says. F0 stores a page number and each 
> page has different set of registers to map to 00-7F. The chip has more 
> memory than can be accessible through i2c at any given time due to the 
> i2c 1 byte address limit so it uses paging to make more data 
> accessible. 
>
> 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] Re: Request for detaild for GSL1680 driver for porting to Linux x86_64 kernel on baytrail 3735f platform

[sergk . admin]

The problem is that there is usually NOAndroid kernel for device, for 
example Chuwi vi8 super with its plarform (vendor) drivers and platform 
initial settings.
Actually I have found of the way how to detect corresponding gpio pin but 
it is manual (scripted + manual) guessing (enumerating).
Moreover from kenel to kernel this is different gpio pin number. I still 
could not fix it how to immediately find out which exactly pin inside 
Z3735F architecture is used and how to find out it's number in any linux 
kernelю
Currently - I just enumerating all on concrete linux kernel and for each 
kernel finding out its number - :( this is ridiculous but its works!

Regards, 
   Serge.

On Tuesday, May 19, 2015 at 10:58:21 AM UTC+3, Henrik Nordström wrote:
>
> fre 2015-05-15 klockan 18:40 -0400 skrev jons...@gmail.com : 
> > Another way - hook up JTAG. Use boundary scan to toggle the pins. That 
> > will tell you the pin number. Look up the pin number and figure out 
> > the GPIO. 
>
> Or look at the source of the Android kernel running on the device for 
> any hints. 
>
> Regards 
> Henrik 
>
>
>
>

-- 
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] A20 with Samsung's SDRAM 'K4B1G1646G BCK0'

[Hans de Goede]

Hi,

On 19-05-15 12:56, sufi al hussaini hassani kamili raheemi wrote:

I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'.

The problem I'm facing now is that I'm not able to get it to boot. I keep
getting the following on debug UART:

U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16)


That is a pretty old u-boot we're doing all sunxi u-boot development upstream 
now:

http://git.denx.de/?p=u-boot.git;a=summary

And we are detecting the most important DRAM parameters (like bus-width) 
automatically
now. The only thing you need to set really is the clock-speed. So I think that
giving upstream u-boot a try on your board is a good idea.

Regards,

Hans




DRAM:Timeout initialising DRAM

resetting ...

 (Repeats infinitely)


I suspected that the (old) '[dram_para]' in my FEX file was causing this,
as it was configured for 'K4B4G1646D' (which is widely used).
So, I edited the FEX file based on the info I could gather from the SDRAM's
datasheet. It now looks like this:


[dram_para]
dram_baseaddr = 0x4000
dram_clk = 384
dram_type = 3
dram_rank_num = 1
dram_chip_density = 1024
dram_io_width = 16
dram_bus_width = 32
dram_cas = 9
dram_zq = 0x7f
dram_odt_en = 0
dram_size = 256
dram_tpr0 = 0x42d899b7
dram_tpr1 = 0xa090
dram_tpr2 = 0x22a00
dram_tpr3 = 0x0
dram_tpr4 = 0x0
dram_tpr5 = 0x0
dram_emr1 = 0x4
dram_emr2 = 0x10
dram_emr3 = 0x0

I tried booting with this but to no avail. The problem persists (same
error).

I looked for ways to get the DRAM info directly from the hardware and found
meminfo in sunxi tools.
I was able to compile (and run) it (on a A20 based commercial board), but I
just can't figure out how to get it running on my board.

Now, I'm confused- whether just setting the correct values in my FEX would
suffice or would I have to rebuild U-Boot.
I would appreciate if someone could point me in the right direction to
solve this problem.

Thanks.



--
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] A20 with Samsung's SDRAM 'K4B1G1646G BCK0'

[sufi al hussaini hassani kamili raheemi]

I have a board that's got A20 with Samsung's SDRAM 'K4B1G1646G BCK0'. 

The problem I'm facing now is that I'm not able to get it to boot. I keep 
getting the following on debug UART:

U-Boot SPL 2014.04-10706-g36080eb (Aug 19 2014 - 16:42:16)
DRAM:Timeout initialising DRAM

resetting ...

 (Repeats infinitely)


I suspected that the (old) '[dram_para]' in my FEX file was causing this, 
as it was configured for 'K4B4G1646D' (which is widely used).
So, I edited the FEX file based on the info I could gather from the SDRAM's 
datasheet. It now looks like this:


[dram_para]
dram_baseaddr = 0x4000
dram_clk = 384
dram_type = 3
dram_rank_num = 1
dram_chip_density = 1024
dram_io_width = 16
dram_bus_width = 32
dram_cas = 9
dram_zq = 0x7f
dram_odt_en = 0
dram_size = 256
dram_tpr0 = 0x42d899b7
dram_tpr1 = 0xa090
dram_tpr2 = 0x22a00
dram_tpr3 = 0x0
dram_tpr4 = 0x0
dram_tpr5 = 0x0
dram_emr1 = 0x4
dram_emr2 = 0x10
dram_emr3 = 0x0

I tried booting with this but to no avail. The problem persists (same 
error).

I looked for ways to get the DRAM info directly from the hardware and found 
meminfo in sunxi tools. 
I was able to compile (and run) it (on a A20 based commercial board), but I 
just can't figure out how to get it running on my board.

Now, I'm confused- whether just setting the correct values in my FEX would 
suffice or would I have to rebuild U-Boot.
I would appreciate if someone could point me in the right direction to 
solve this problem. 

Thanks.

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: New firmware for GSL1680

[Michal Suchanek]

On 19 May 2015 at 12:36,   wrote:
> "On Tuesday, May 19, 2015 at 12:53:43 PM UTC+3, Michal Suchanek wrote:
> That's one page of the configuration which is 128 bytes or 32 integers.
> Writing the page register gives access (read or write) to different pages.
> So one blob might have multiple such pages or the firmware can be
> composed of multiple pages stored in multiple blobs"
>
>
> Still not clear - where does stored these blobs?
>
> 0x00-0x7F = 128 items 128 * x =1 byte registers. So physically chip could
> reside only 128 byte.
> 0xF0: PAGE register. Contains the memory page number currently mapped in the
> 0x00-0x7F registers.
>
>
> What is logic of these  Page register and 0x00-0x7F registers?
>
> Am I right that firmware is loaded into ram splitted by 128 byte pages and
> 0xF0 register contains a set of adressed in RAM of such 128 byte chunks?

Yes, that's what the datasheet says. F0 stores a page number and each
page has different set of registers to map to 00-7F. The chip has more
memory than can be accessible through i2c at any given time due to the
i2c 1 byte address limit so it uses paging to make more data
accessible.

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] Re: New firmware for GSL1680

[sergk . admin]

"On Tuesday, May 19, 2015 at 12:53:43 PM UTC+3, Michal Suchanek wrote:
That's one page of the configuration which is 128 bytes or 32 integers. 
Writing the page register gives access (read or write) to different pages. 
So one blob might have multiple such pages or the firmware can be 
composed of multiple pages stored in multiple blobs"


Still not clear - where does stored these blobs?

0x00-0x7F = 128 items 128 * x =1 byte registers. So physically chip could 
reside only 128 byte.
0xF0: PAGE register. Contains the memory page number currently mapped in 
the 0x00-0x7F registers. 


What is logic of these  Page register and 0x00-0x7F registers?

Am I right that firmware is loaded into ram splitted by 128 byte pages and 
0xF0 register contains a set of adressed in RAM of such 128 byte chunks?


-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] Re: New firmware for GSL1680

[Michal Suchanek]

On 19 May 2015 at 11:39,   wrote:
> Sorry but your post makes it more weird.
> According https://linux-sunxi.org/GSL1680 page GSL1680 controller stores
> Firmware in 0x00-0x7F: these registers are used to load portions of the
> firmware
> This is only 128 8bit = 1byte registers.
> So main question is - does this registers = 128 1 byte registers store the
> whole firmware?

That's one page of the configuration which is 128 bytes or 32 integers.

Writing the page register gives access (read or write) to different pages.

So one blob might have multiple such pages or the firmware can be
composed of multiple pages stored in multiple blobs. Also there is
nothing stopping the driver writing the registers again after sending
the blob patching/adjusting some values or leaving them out from the
blob and sending them separately.

>
> What is the logic of working of controller chip with firmware?
>
> For example = why when I am loading firmware Silead.fw taken from my tablet
> from Windows 8.1  with ported Sergio Costas user space driver for GSL1680 I
> could not get correct feedback (coordinates that are read from 0x84-0x87
> ) for my 1280x800 touch? I have response for all but not 1280x800, acrtually
> weird coordinates like 1725x1120 or something close.

The logic is  that with the chip configurable you can save on PCB
design because you can design traces as convenient and configure which
trace connects where in firmware. The obvious result is that without
correct configuration the chip is useless so dumb non-configurable
chips are a win when dealing with non-cooperative vendors.

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] Re: New firmware for GSL1680

[sergk . admin]

Sorry but your post makes it more weird.
According https://linux-sunxi.org/GSL1680 page GSL1680 controller stores 
Firmware in 0x00-0x7F: these registers are used to load portions of the 
firmware 
This is only 128 8bit = 1byte registers.  
So main question is - does this registers = 128 1 byte registers store the 
whole firmware? 

If so - then why firmware files for example from Windows 8.1 or even 
extracted from mentioned above .ko file are more than 128 byte? (32KB 
extracted from .ko and 104KB for windows fw).

Or I missunderstand the logic, and 128 registers just used to load chunks 
of the firmware into RAM and through this registers there is iteraction 
with firmware code resided in RAM?

What is the logic of working of controller chip with firmware?

For example = why when I am loading firmware Silead.fw taken from my tablet 
from Windows 8.1  with ported Sergio Costas user space driver for GSL1680 I 
could not get correct feedback (coordinates that are read from 
0x84-0x87 ) for my 1280x800 touch? I have response for all but not 
1280x800, acrtually weird coordinates like 1725x1120 or something close.



On Tuesday, May 19, 2015 at 11:19:50 AM UTC+3, Michal Suchanek wrote:
>
> Hello, 
>
> On 19 May 2015 at 09:37,  > wrote: 
> > Sergio, 
> > Please help to make it clear - the logic of gsl1680 FW: 
> > 
> > Is it organized in chunks of 128 byte? and if so - does it mean that 
> current 
> > firmware = you should switch to the correct block of 128 byte between 
> loaded 
> > set of such 128 byte blocks? 
>
> The firmware is some random data that is sent over i2c and written to 
> the GSL configuration registers. 
>
> Some of the earlier modules had full i2c communication dump in the 
> form of 1-byte address 1-integer data. 
>
> Some had part of this dump with some values (like screen resolution) 
> computed dynamically and not stored in the firmware dump. 
>
> It seems that the configuration registers are organized in pages and 
> writing a particular register switches the accessible page. 
>
> Obviously, if you have a dump like this it can contain the writes to 
> page change register and contain multiple configuration pages in one 
> blob. 
>
> There is even a GSL datasheet that explains the details of the 
> protocol. It does not explain the content of the configuration area, 
> however. 
>
> Also see http://linux-sunxi.org/GSL1680 
>
> HTH 
>
> Michal 
>

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[linux-sunxi] Re: [PATCH v2 06/10] clk: sunxi: Add H3 clocks support

[Maxime Ripard]

On Mon, May 18, 2015 at 11:45:50AM +0200, Jens Kuske wrote:
> Hi,
> 
> On 05/17/15 16:27, Maxime Ripard wrote:
> > On Fri, May 15, 2015 at 06:38:56PM +0200, Jens Kuske wrote:
> >> The H3 clock control unit is similar to the those of other sun8i family
> >> members like the A23.
> >>
> >> It makes use of the new multiple parents option for the bus gates.
> >> Some of the gates use the new AHB2 clock as parent, whose clock source
> >> is muxable between AHB1 and PLL6/2. The documentation isn't totally clear
> >> about which devices belong to AHB2 now, especially USB EHIC/OHIC, so it
> >> is mostly based on Allwinner kernel source code.
> >>
> >> Signed-off-by: Jens Kuske 
> >> ---
> >>  Documentation/devicetree/bindings/clock/sunxi.txt |  6 +++
> >>  drivers/clk/sunxi/clk-sunxi.c | 50 
> >> ++-
> >>  2 files changed, 55 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
> >> b/Documentation/devicetree/bindings/clock/sunxi.txt
> >> index 4fa11af..e367963 100644
> >> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> >> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> >> @@ -14,6 +14,7 @@ Required properties:
> >>"allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
> >>"allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
> >>"allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
> >> +  "allwinner,sun8i-h3-pll6-clk" - for the PLL6 clock on H3
> >>"allwinner,sun9i-a80-gt-clk" - for the GT bus clock on A80
> >>"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
> >>"allwinner,sun4i-a10-axi-clk" - for the AXI clock
> >> @@ -28,6 +29,7 @@ Required properties:
> >>"allwinner,sun7i-a20-ahb-gates-clk" - for the AHB gates on A20
> >>"allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
> >>"allwinner,sun6i-a31-ahb1-clk" - for the AHB1 clock on A31
> >> +  "allwinner,sun8i-h3-ahb2-clk" - for the AHB2 clock on H3
> >>"allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
> >>"allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
> >>"allwinner,sun9i-a80-ahb0-gates-clk" - for the AHB0 gates on A80
> >> @@ -55,6 +57,7 @@ Required properties:
> >>"allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
> >>"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
> >>"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
> >> +  "allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
> >>"allwinner,sun5i-a13-mbus-clk" - for the MBUS clock on A13
> >>"allwinner,sun4i-a10-mmc-clk" - for the MMC clock
> >>"allwinner,sun9i-a80-mmc-clk" - for mmc module clocks on A80
> >> @@ -95,6 +98,9 @@ The "allwinner,sun9i-a80-mmc-config-clk" clock also 
> >> requires:
> >>  For "allwinner,sun7i-a20-gmac-clk", the parent clocks shall be fixed rate
> >>  dummy clocks at 25 MHz and 125 MHz, respectively. See example.
> >>  
> >> +For "allwinner,sun8i-h3-bus-gates-clk", the parent clocks shall be
> >> +AHB1, AHB2, APB1 and APB2, in that order.
> >> +
> >>  Clock consumers should specify the desired clocks they use with a
> >>  "clocks" phandle cell. Consumers that are using a gated clock should
> >>  provide an additional ID in their clock property. This ID is the
> >> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> >> index afe560c..79364be 100644
> >> --- a/drivers/clk/sunxi/clk-sunxi.c
> >> +++ b/drivers/clk/sunxi/clk-sunxi.c
> >> @@ -771,6 +771,10 @@ static const struct mux_data sun6i_a31_ahb1_mux_data 
> >> __initconst = {
> >>.shift = 12,
> >>  };
> >>  
> >> +static const struct mux_data sun8i_h3_ahb2_mux_data __initconst = {
> >> +  .shift = 0,
> >> +};
> >> +
> >>  static void __init sunxi_mux_clk_setup(struct device_node *node,
> >>   struct mux_data *data)
> >>  {
> >> @@ -886,7 +890,7 @@ static void __init sunxi_divider_clk_setup(struct 
> >> device_node *node,
> >>   * sunxi_gates_clk_setup() - Setup function for leaf gates on clocks
> >>   */
> >>  
> >> -#define SUNXI_GATES_MAX_SIZE  64
> >> +#define SUNXI_GATES_MAX_SIZE  160
> >>  
> >>  struct gates_data {
> >>DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
> >> @@ -990,6 +994,36 @@ static const struct gates_data 
> >> sun8i_a23_apb2_gates_data __initconst = {
> >>.mask = {0x1F0007},
> >>  };
> >>  
> >> +#define BUS_GATE_PARENT_AHB1  0
> >> +#define BUS_GATE_PARENT_AHB2  1
> >> +#define BUS_GATE_PARENT_APB1  2
> >> +#define BUS_GATE_PARENT_APB2  3
> >> +
> >> +static const u8 sun8i_h3_bus_gates_parents[] __initconst = {
> >> +  BUS_GATE_PARENT_AHB1, BUS_GATE_PARENT_AHB1, BUS_GATE_PARENT_AHB1,
> >> +  BUS_GATE_PARENT_AHB1, BUS_GATE_PARENT_AHB1, BUS_GATE_PARENT_AHB1,
> >> +  BUS_GATE_PARENT_AHB1,
> > 
> >> BUS_GATE_PARENT_AHB2,
> >> BUS_GATE_PARENT_AHB1,
> >> +  BUS_GATE_PARENT_AHB1, BUS_GATE_PARENT_AHB1, BUS_GATE_PARENT_AHB1,
> >> +  BUS_GATE_PARE

[linux-sunxi] Re: [PATCH v2 03/10] clk: sunxi: Let divs clocks read the base factor clock name from devicetree

[Maxime Ripard]

On Mon, May 18, 2015 at 11:22:32AM +0200, Jens Kuske wrote:
> On 05/17/15 15:06, Maxime Ripard wrote:
> > On Fri, May 15, 2015 at 06:38:53PM +0200, Jens Kuske wrote:
> >> Currently, the sunxi clock driver gets the name for the base factor clock
> >> of divs clocks from the name field in factors_data. This prevents reusing
> >> of the factor clock for clocks with same properties, but different name.
> >>
> >> This commit makes the divs setup function try to get a name from
> >> clock-output-names in the devicetree. It also removes the name field where
> >> possible and merges the sun4i PLL5 and PLL6 clocks.
> >>
> >> The sun4i PLL5 clock doesn't have a output for the base factor clock,
> >> so we still have to use the name field there.
> >>
> >> Signed-off-by: Jens Kuske 
> >> ---
> >>  drivers/clk/sunxi/clk-sunxi.c | 22 --
> >>  1 file changed, 12 insertions(+), 10 deletions(-)
> >>
> >> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> >> index 17cba4d..afe560c 100644
> >> --- a/drivers/clk/sunxi/clk-sunxi.c
> >> +++ b/drivers/clk/sunxi/clk-sunxi.c
> >> @@ -708,18 +708,10 @@ static const struct factors_data sun4i_pll5_data 
> >> __initconst = {
> >>.name = "pll5",
> >>  };
> >>  
> >> -static const struct factors_data sun4i_pll6_data __initconst = {
> >> -  .enable = 31,
> >> -  .table = &sun4i_pll5_config,
> >> -  .getter = sun4i_get_pll5_factors,
> >> -  .name = "pll6",
> >> -};
> >> -
> >>  static const struct factors_data sun6i_a31_pll6_data __initconst = {
> >>.enable = 31,
> >>.table = &sun6i_a31_pll6_config,
> >>.getter = sun6i_a31_get_pll6_factors,
> >> -  .name = "pll6x2",
> >>  };
> >>  
> >>  static const struct factors_data sun5i_a13_ahb_data __initconst = {
> >> @@ -1099,7 +1091,7 @@ static const struct divs_data pll5_divs_data 
> >> __initconst = {
> >>  };
> >>  
> >>  static const struct divs_data pll6_divs_data __initconst = {
> >> -  .factors = &sun4i_pll6_data,
> >> +  .factors = &sun4i_pll5_data,
> >>.ndivs = 4,
> >>.div = {
> >>{ .shift = 0, .table = pll6_sata_tbl, .gate = 14 }, /* M, SATA 
> >> */
> >> @@ -1141,6 +1133,7 @@ static void __init sunxi_divs_clk_setup(struct 
> >> device_node *node,
> >>struct clk_gate *gate = NULL;
> >>struct clk_fixed_factor *fix_factor;
> >>struct clk_divider *divider;
> >> +  struct factors_data factors = *data->factors;
> >>void __iomem *reg;
> >>int ndivs = SUNXI_DIVS_MAX_QTY, i = 0;
> >>int flags, clkflags;
> >> @@ -1149,8 +1142,17 @@ static void __init sunxi_divs_clk_setup(struct 
> >> device_node *node,
> >>if (data->ndivs)
> >>ndivs = data->ndivs;
> >>  
> >> +  /* Try to find a name for base factor clock */
> >> +  for (i = 0; i < ndivs; i++) {
> >> +  if (data->div[i].self) {
> > 
> > I'm not sure we should expect the factor clock to have a self factor.
> 
> Maybe not, but in that case it would fall back to the name provided in
> the factors_data struct, as it is the case for sun4i pll5.

Which doesn't really solve the underlying issue, just make it work in
your (pll6/pll8) case.
 
> > what about taking the first output and taking the substring up to the
> > first "_" ?
> 
> That only works for the sun[457]i pll5 & pll6, for sun[68]i the base
> clock name would have to be "pll6x2".

Why?

It's called pll6 in the datasheet, it should really be called
pll6. The fact that there is some fixed factors or dividers on some
children only impacts those children, and not the system as a whole.

And the fact that the "base" clock is pll6x2 and not pll6 itself is
very debatable. How do you know which clock is the base one? Most
clocks are actually using pll6 as a reference.

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 v2 04/10] pinctrl: sunxi: Prepare for building SoC specific drivers as modules

[Maxime Ripard]

On Tue, May 19, 2015 at 04:02:39PM +0800, Chen-Yu Tsai wrote:
> On Tue, May 19, 2015 at 3:55 PM, Maxime Ripard
>  wrote:
> > On Mon, May 18, 2015 at 11:32:31AM +0200, Jens Kuske wrote:
> >> Hi,
> >>
> >> On 05/17/15 16:19, Maxime Ripard wrote:
> >> > On Fri, May 15, 2015 at 06:38:54PM +0200, Jens Kuske wrote:
> >> >> Add a remove function and export the init and remove function
> >> >> to allow us to build the SoC specific drivers as modules.
> >> >>
> >> >> Signed-off-by: Jens Kuske 
> >> >> ---
> >> >>  drivers/pinctrl/sunxi/pinctrl-sunxi.c | 25 +++--
> >> >>  drivers/pinctrl/sunxi/pinctrl-sunxi.h |  2 ++
> >> >>  2 files changed, 21 insertions(+), 6 deletions(-)
> >> >>
> >> >> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
> >> >> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> >> >> index f8e171b..4ef6b3d 100644
> >> >> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> >> >> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> >> >> @@ -856,7 +856,6 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
> >> >>struct sunxi_pinctrl *pctl;
> >> >>struct resource *res;
> >> >>int i, ret, last_pin;
> >> >> -  struct clk *clk;
> >> >>
> >> >>pctl = devm_kzalloc(&pdev->dev, sizeof(*pctl), GFP_KERNEL);
> >> >>if (!pctl)
> >> >> @@ -954,13 +953,13 @@ int sunxi_pinctrl_init(struct platform_device 
> >> >> *pdev,
> >> >>goto gpiochip_error;
> >> >>}
> >> >>
> >> >> -  clk = devm_clk_get(&pdev->dev, NULL);
> >> >> -  if (IS_ERR(clk)) {
> >> >> -  ret = PTR_ERR(clk);
> >> >> +  pctl->clk = devm_clk_get(&pdev->dev, NULL);
> >> >> +  if (IS_ERR(pctl->clk)) {
> >> >> +  ret = PTR_ERR(pctl->clk);
> >> >>goto gpiochip_error;
> >> >>}
> >> >>
> >> >> -  ret = clk_prepare_enable(clk);
> >> >> +  ret = clk_prepare_enable(pctl->clk);
> >> >>if (ret)
> >> >>goto gpiochip_error;
> >> >>
> >> >> @@ -1015,10 +1014,24 @@ int sunxi_pinctrl_init(struct platform_device 
> >> >> *pdev,
> >> >>return 0;
> >> >>
> >> >>  clk_error:
> >> >> -  clk_disable_unprepare(clk);
> >> >> +  clk_disable_unprepare(pctl->clk);
> >> >>  gpiochip_error:
> >> >>gpiochip_remove(pctl->chip);
> >> >>  pinctrl_error:
> >> >>pinctrl_unregister(pctl->pctl_dev);
> >> >>return ret;
> >> >>  }
> >> >> +EXPORT_SYMBOL(sunxi_pinctrl_init);
> >> >> +
> >> >> +int sunxi_pinctrl_remove(struct platform_device *pdev)
> >> >> +{
> >> >> +  struct sunxi_pinctrl *pctl = platform_get_drvdata(pdev);
> >> >> +
> >> >> +  gpiochip_remove(pctl->chip);
> >> >> +  pinctrl_unregister(pctl->pctl_dev);
> >> >> +
> >> >> +  clk_disable_unprepare(pctl->clk);
> >> >
> >> > We should also remove the domain and the interrupt mapping here.
> >>
> >> Ouch, I missed that. Only looked at the *_error: labels.
> >>
> >> Apart from that, currently the kernel panics some seconds after removing
> >> the pinctrl module because mmc wants to access a gpio. Can this be
> >> prevented somehow? I think pinctrl must not be removed once other
> >> devices use any pin-related things.
> >
> > pinctrl_unregister doesn't look like it cares about whether or not
> > there's users left in the system.
> >
> > Maybe the easiest path would be to just make this builtin like Paul
> > suggested then ... :/
> 
> Is there a way to mark modules as not removable? At least we can keep
> the multi-platform kernel image small.

If there's no module_exit, the module will only be removable through a
rmmod -f, which seems like an acceptable solution.

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

Re: [linux-sunxi] Re: New firmware for GSL1680

[Michal Suchanek]

Hello,

On 19 May 2015 at 09:37,   wrote:
> Sergio,
> Please help to make it clear - the logic of gsl1680 FW:
>
> Is it organized in chunks of 128 byte? and if so - does it mean that current
> firmware = you should switch to the correct block of 128 byte between loaded
> set of such 128 byte blocks?

The firmware is some random data that is sent over i2c and written to
the GSL configuration registers.

Some of the earlier modules had full i2c communication dump in the
form of 1-byte address 1-integer data.

Some had part of this dump with some values (like screen resolution)
computed dynamically and not stored in the firmware dump.

It seems that the configuration registers are organized in pages and
writing a particular register switches the accessible page.

Obviously, if you have a dump like this it can contain the writes to
page change register and contain multiple configuration pages in one
blob.

There is even a GSL datasheet that explains the details of the
protocol. It does not explain the content of the configuration area,
however.

Also see http://linux-sunxi.org/GSL1680

HTH

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] [ANNOUNCE] Allwinner releasing CedarX open source

[Luc Verhaegen]

On Tue, May 19, 2015 at 08:44:13AM +0800, ke...@allwinnertech.com wrote:
> 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.
> 
> With that context, here's an update on our CedarX code release (we welcome
> constructive feedback!)
> 
> 1. New code architecture. Driver has been split into several plugins, one
> plugin per video format.
> 2. GPL-complaint. We have scanned and analyzed the code to ensure that there
> is no GPL code used or called.
> 3. Partial CedarX video decoder source code release. MPEG2, MPEG4, MJPEG, and
> H264 drivers source code available.
> 
> We hope this is helpful to everyone. If not, please let us know how we can
> improve. Thanks!

This is a good first step, not only to try to meet some legal 
obligations, but also to support Allwinners customers and the sunxi 
community.

But...

The choice of exactly those codecs for a first(?) release, the fact that 
you underline the use of a code scanner/analyzer, and then the fact that 
Allwinner chose to turn this into a modular design with codecs as 
modules... All that seems to hint at Allwinner intending to keep 
upcoming modules as binaries. If this happens, not only will that be 
another massive marketing setback for Allwinner, but we will push the 
legal limits hard and force a full release of the source code of all 
binaries that allwinner has released so far. As said countless times 
before, the LGPL applies to the whole of the binaries Allwinner released 
before, not just those codecs where LGPLed code was used.

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: [PATCH v2 04/10] pinctrl: sunxi: Prepare for building SoC specific drivers as modules

[Chen-Yu Tsai]

On Tue, May 19, 2015 at 3:55 PM, Maxime Ripard
 wrote:
> On Mon, May 18, 2015 at 11:32:31AM +0200, Jens Kuske wrote:
>> Hi,
>>
>> On 05/17/15 16:19, Maxime Ripard wrote:
>> > On Fri, May 15, 2015 at 06:38:54PM +0200, Jens Kuske wrote:
>> >> Add a remove function and export the init and remove function
>> >> to allow us to build the SoC specific drivers as modules.
>> >>
>> >> Signed-off-by: Jens Kuske 
>> >> ---
>> >>  drivers/pinctrl/sunxi/pinctrl-sunxi.c | 25 +++--
>> >>  drivers/pinctrl/sunxi/pinctrl-sunxi.h |  2 ++
>> >>  2 files changed, 21 insertions(+), 6 deletions(-)
>> >>
>> >> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
>> >> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> >> index f8e171b..4ef6b3d 100644
>> >> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> >> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
>> >> @@ -856,7 +856,6 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
>> >>struct sunxi_pinctrl *pctl;
>> >>struct resource *res;
>> >>int i, ret, last_pin;
>> >> -  struct clk *clk;
>> >>
>> >>pctl = devm_kzalloc(&pdev->dev, sizeof(*pctl), GFP_KERNEL);
>> >>if (!pctl)
>> >> @@ -954,13 +953,13 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
>> >>goto gpiochip_error;
>> >>}
>> >>
>> >> -  clk = devm_clk_get(&pdev->dev, NULL);
>> >> -  if (IS_ERR(clk)) {
>> >> -  ret = PTR_ERR(clk);
>> >> +  pctl->clk = devm_clk_get(&pdev->dev, NULL);
>> >> +  if (IS_ERR(pctl->clk)) {
>> >> +  ret = PTR_ERR(pctl->clk);
>> >>goto gpiochip_error;
>> >>}
>> >>
>> >> -  ret = clk_prepare_enable(clk);
>> >> +  ret = clk_prepare_enable(pctl->clk);
>> >>if (ret)
>> >>goto gpiochip_error;
>> >>
>> >> @@ -1015,10 +1014,24 @@ int sunxi_pinctrl_init(struct platform_device 
>> >> *pdev,
>> >>return 0;
>> >>
>> >>  clk_error:
>> >> -  clk_disable_unprepare(clk);
>> >> +  clk_disable_unprepare(pctl->clk);
>> >>  gpiochip_error:
>> >>gpiochip_remove(pctl->chip);
>> >>  pinctrl_error:
>> >>pinctrl_unregister(pctl->pctl_dev);
>> >>return ret;
>> >>  }
>> >> +EXPORT_SYMBOL(sunxi_pinctrl_init);
>> >> +
>> >> +int sunxi_pinctrl_remove(struct platform_device *pdev)
>> >> +{
>> >> +  struct sunxi_pinctrl *pctl = platform_get_drvdata(pdev);
>> >> +
>> >> +  gpiochip_remove(pctl->chip);
>> >> +  pinctrl_unregister(pctl->pctl_dev);
>> >> +
>> >> +  clk_disable_unprepare(pctl->clk);
>> >
>> > We should also remove the domain and the interrupt mapping here.
>>
>> Ouch, I missed that. Only looked at the *_error: labels.
>>
>> Apart from that, currently the kernel panics some seconds after removing
>> the pinctrl module because mmc wants to access a gpio. Can this be
>> prevented somehow? I think pinctrl must not be removed once other
>> devices use any pin-related things.
>
> pinctrl_unregister doesn't look like it cares about whether or not
> there's users left in the system.
>
> Maybe the easiest path would be to just make this builtin like Paul
> suggested then ... :/

Is there a way to mark modules as not removable? At least we can keep
the multi-platform kernel image small.

-- 
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 04/10] pinctrl: sunxi: Prepare for building SoC specific drivers as modules

[Maxime Ripard]

On Mon, May 18, 2015 at 11:32:31AM +0200, Jens Kuske wrote:
> Hi,
> 
> On 05/17/15 16:19, Maxime Ripard wrote:
> > On Fri, May 15, 2015 at 06:38:54PM +0200, Jens Kuske wrote:
> >> Add a remove function and export the init and remove function
> >> to allow us to build the SoC specific drivers as modules.
> >>
> >> Signed-off-by: Jens Kuske 
> >> ---
> >>  drivers/pinctrl/sunxi/pinctrl-sunxi.c | 25 +++--
> >>  drivers/pinctrl/sunxi/pinctrl-sunxi.h |  2 ++
> >>  2 files changed, 21 insertions(+), 6 deletions(-)
> >>
> >> diff --git a/drivers/pinctrl/sunxi/pinctrl-sunxi.c 
> >> b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> >> index f8e171b..4ef6b3d 100644
> >> --- a/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> >> +++ b/drivers/pinctrl/sunxi/pinctrl-sunxi.c
> >> @@ -856,7 +856,6 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
> >>struct sunxi_pinctrl *pctl;
> >>struct resource *res;
> >>int i, ret, last_pin;
> >> -  struct clk *clk;
> >>  
> >>pctl = devm_kzalloc(&pdev->dev, sizeof(*pctl), GFP_KERNEL);
> >>if (!pctl)
> >> @@ -954,13 +953,13 @@ int sunxi_pinctrl_init(struct platform_device *pdev,
> >>goto gpiochip_error;
> >>}
> >>  
> >> -  clk = devm_clk_get(&pdev->dev, NULL);
> >> -  if (IS_ERR(clk)) {
> >> -  ret = PTR_ERR(clk);
> >> +  pctl->clk = devm_clk_get(&pdev->dev, NULL);
> >> +  if (IS_ERR(pctl->clk)) {
> >> +  ret = PTR_ERR(pctl->clk);
> >>goto gpiochip_error;
> >>}
> >>  
> >> -  ret = clk_prepare_enable(clk);
> >> +  ret = clk_prepare_enable(pctl->clk);
> >>if (ret)
> >>goto gpiochip_error;
> >>  
> >> @@ -1015,10 +1014,24 @@ int sunxi_pinctrl_init(struct platform_device 
> >> *pdev,
> >>return 0;
> >>  
> >>  clk_error:
> >> -  clk_disable_unprepare(clk);
> >> +  clk_disable_unprepare(pctl->clk);
> >>  gpiochip_error:
> >>gpiochip_remove(pctl->chip);
> >>  pinctrl_error:
> >>pinctrl_unregister(pctl->pctl_dev);
> >>return ret;
> >>  }
> >> +EXPORT_SYMBOL(sunxi_pinctrl_init);
> >> +
> >> +int sunxi_pinctrl_remove(struct platform_device *pdev)
> >> +{
> >> +  struct sunxi_pinctrl *pctl = platform_get_drvdata(pdev);
> >> +
> >> +  gpiochip_remove(pctl->chip);
> >> +  pinctrl_unregister(pctl->pctl_dev);
> >> +
> >> +  clk_disable_unprepare(pctl->clk);
> > 
> > We should also remove the domain and the interrupt mapping here.
> 
> Ouch, I missed that. Only looked at the *_error: labels.
> 
> Apart from that, currently the kernel panics some seconds after removing
> the pinctrl module because mmc wants to access a gpio. Can this be
> prevented somehow? I think pinctrl must not be removed once other
> devices use any pin-related things.

pinctrl_unregister doesn't look like it cares about whether or not
there's users left in the system.

Maybe the easiest path would be to just make this builtin like Paul
suggested then ... :/

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

Re: [linux-sunxi] Re: Request for detaild for GSL1680 driver for porting to Linux x86_64 kernel on baytrail 3735f platform

[Henrik Nordström]

fre 2015-05-15 klockan 18:40 -0400 skrev jonsm...@gmail.com:
> Another way - hook up JTAG. Use boundary scan to toggle the pins. That
> will tell you the pin number. Look up the pin number and figure out
> the GPIO.

Or look at the source of the Android kernel running on the device for
any hints.

Regards
Henrik



-- 
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 02/10] clk: sunxi: Add support for multiple parents to gates

[Maxime Ripard]

On Mon, May 18, 2015 at 11:11:34AM +0200, Jens Kuske wrote:
> Hi,
> 
> On 05/17/15 14:50, Maxime Ripard wrote:
> > Hi Jens,
> > 
> > On Fri, May 15, 2015 at 06:38:52PM +0200, Jens Kuske wrote:
> >> Some newer sunxi SoCs (A83T, H3) don't have individual registers for
> >> AHB1, APB1 and APB2 gates anymore, but one big bus gates area where each
> >> gate can have a different parent.
> >>
> >> The current clock driver sets the same parent for all gates in a group.
> >> This commit adds a new parents field to the gates_data structure, which
> >> allows us to specify an array of parent indices for every single gate.
> >>
> >> Signed-off-by: Jens Kuske 
> >> ---
> >>  drivers/clk/sunxi/clk-sunxi.c | 12 +++-
> >>  1 file changed, 11 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
> >> index 9a82f17..17cba4d 100644
> >> --- a/drivers/clk/sunxi/clk-sunxi.c
> >> +++ b/drivers/clk/sunxi/clk-sunxi.c
> >> @@ -898,6 +898,8 @@ static void __init sunxi_divider_clk_setup(struct 
> >> device_node *node,
> >>  
> >>  struct gates_data {
> >>DECLARE_BITMAP(mask, SUNXI_GATES_MAX_SIZE);
> >> +  /* If used, ARRAY_SIZE(parents) has to be >= bitmap_weight(mask) */
> >> +  const u8 *parents;
> >>  };
> >>  
> >>  static const struct gates_data sun4i_axi_gates_data __initconst = {
> >> @@ -1000,16 +1002,21 @@ static void __init sunxi_gates_clk_setup(struct 
> >> device_node *node,
> >> struct gates_data *data)
> >>  {
> >>struct clk_onecell_data *clk_data;
> >> +  const char *parents[SUNXI_MAX_PARENTS];
> >>const char *clk_parent;
> >>const char *clk_name;
> >>void __iomem *reg;
> >> +  int npar = 0;
> >>int qty;
> >>int i = 0;
> >>int j = 0;
> >>  
> >>reg = of_iomap(node, 0);
> >>  
> >> -  clk_parent = of_clk_get_parent_name(node, 0);
> >> +  while (npar < SUNXI_MAX_PARENTS &&
> >> + (parents[npar] = of_clk_get_parent_name(node, npar)) != NULL)
> >> +  npar++;
> >> +  clk_parent = parents[0];
> >>  
> >>/* Worst-case size approximation and memory allocation */
> >>qty = find_last_bit(data->mask, SUNXI_GATES_MAX_SIZE);
> >> @@ -1026,6 +1033,9 @@ static void __init sunxi_gates_clk_setup(struct 
> >> device_node *node,
> >>of_property_read_string_index(node, "clock-output-names",
> >>  j, &clk_name);
> >>  
> >> +  if (data->parents && !WARN_ON(data->parents[j] >= npar))
> >> +  clk_parent = parents[data->parents[j]];
> >> +
> > 
> > I'm currently removing that code, so I was more expecting a new
> > standalone driver for that clock.
> 
> How do you want to replace that code? To me this looks like a good way
> to set up all the different gates sunxi has.

By using clock-indices and moving all this gate stuff out of clk-sunxi
and into a new driver.

It's done already, I just need to make sure everything works at it
used to on all the SoCs.

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: New firmware for GSL1680

[sergk . admin]

Sergio, 
Please help to make it clear - the logic of gsl1680 FW:

Is it organized in chunks of 128 byte? and if so - does it mean that 
current firmware = you should switch to the correct block of 128 byte 
between loaded set of such 128 byte blocks?

On Monday, May 18, 2015 at 12:02:00 PM UTC+3, Sergio Costas wrote:
>
>  I would read all the 256 pages, and dump all them to my chip.
>
> On 18/05/15 11:00, sergk...@gmail.com  wrote:
>  
> Could you please explain more detailed this portion by reading registers 
> 00 to 7F for each 128-byte block.
>
> Questions:
>
> 1) Does it enough only one 128-byte block?
> 2) How to determine how much such 128byte blocks should be read and where 
> is the finish?
>
>
> On Monday, May 18, 2015 at 11:52:13 AM UTC+3, raste...@gmail.com wrote: 
>>
>> Check if you have the i2c tools in your android system, and try to use 
>> them to dump the firmware from the running chip. You should be able to do 
>> it by reading registers 00 to 7F for each 128-byte block, and writting in 
>> register 0xF0 the page you want to read.
>
>  
>
> -- 
> 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.

[linux-sunxi] Re: New firmware for GSL1680

[sergk . admin]

:( Unfortunately still no success. I have grabbed from .module ko from 
.rodata binaries for 
GSLX680_FW_TEST
GSLX680_FW_gsl_customer
GSLX680_FW_I81_GSL3676B_8001280_OGS_SG
GSLX680_FW_I802_GSL3676B_8001280_OGS_SG
GSLX680_FW_I802_GSL3676B_8001280_OGS_DZ
GSLX680_FW_I100_GSL3692_1280800_GG_SG
GSLX680_FW_I89_GSL3676B_19201200_OGS_SG
GSLX680_FW_I71_GSL1686F_1024600_PG_XLL
FW_I89_GSL3676B_19201200_OGS_DZ
GSLX680_FW_I86_GSL3676B_8001280_PG_FC_W

and have tried each of them  - there is no required resolution 1280x800 
from chip! in .ko file there are some other portions of data like

gsl_config_data_id_I81_GSL3676B_8001280_OGS_SG
gsl_config_data_id_I802_GSL3676B_8001280_OGS_SG
gsl_config_data_id_I802_GSL3676B_8001280_OGS_DZ
gsl_config_data_id_I100_GSL3692_1280800_GG_SG
gsl_config_data_id_I89_GSL3676B_19201200_OGS_SG
gsl_config_data_id_I71_GSL1686F_1024600_PG_XLL
gsl_config_data_id_I86_GSL3676B_8001280_PG_FC
gsl_config_data_id_I86_GSL3676B_8001280_OGS_SG
gsl_config_data_id_I706_GSL1686_OGS_6001024_DZ_70F2
gsl_config_data_id_I89_GSL3676B_19201200_OGS_DZ
gsl_config_data_id_I101_GSL3692_1280800_GG_FC_FC101S123
gsl_config_data_id_I86_GSL3676B_8001280_PG_FC_W
gsl_config_data_id_I892_GSL3676B_8001280_OGS_SG
gsl_alg_id_main

Looks like it is matter to do something before sending FW or in such data 
structure inside linux module it is not complete FW.
FW from 
https://code.google.com/p/yuandao-n90-window-dual-core-2/source/browse/drivers/input/touchscreen/gslx680_ts.h
  
on my Chuwi vi8 super (8" 1280x800) also does not work, completely even no 
reaction :(

So assuming - could anyone help to move forward with the following: 

Question 1) from mentioned above yundao FW in text form there are comments 
to some values in FW - it is possible to fix existing FW, that for example 
sends 1725x1200 coordinates  just with correction some portions of this FW?

Question 2): Statically linked binary i2cdump for Android x86=  I 
think, that my farther steps will be in direction pointed by Sergio Costas 
- I will try to grab under Android loaded into chip FW with i2ctools (still 
need statically linked  binaries for Baytrail x86 Android).

Question 3) I have Windows 8.1 too on my tablet and have firmware file from 
my tablet Silead.fw. It is able to load it, but still the same problem - 
resolution ot touch is not 1280x800 instead chip returns on this FW 
somthing like 1725x1120 
looks like it is not enough to have just file with FW, you should correctly 
load it :( but what to do as init  - it is still a question




-- 
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: [RFC 2/7] ARM: dts: sun9i: Add CCI-400 device nodes for A80

[Chen-Yu Tsai]

On Sun, May 17, 2015 at 10:51 PM, Maxime Ripard
 wrote:
> On Thu, May 14, 2015 at 02:10:06PM +0800, Chen-Yu Tsai wrote:
>> The A80 includes an ARM CCI-400 interconnect to support multi-cluster
>> CPU caches.
>>
>> Also add the default clock frequency for the CPUs.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  arch/arm/boot/dts/sun9i-a80.dtsi | 46 
>> 
>>  1 file changed, 46 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/sun9i-a80.dtsi 
>> b/arch/arm/boot/dts/sun9i-a80.dtsi
>> index ca272e92b85d..200e712fbf0e 100644
>> --- a/arch/arm/boot/dts/sun9i-a80.dtsi
>> +++ b/arch/arm/boot/dts/sun9i-a80.dtsi
>> @@ -58,48 +58,64 @@
>>   cpu0: cpu@0 {
>>   compatible = "arm,cortex-a7";
>>   device_type = "cpu";
>> + cci-control-port = <&cci_control0>;
>> + clock-frequency = <1200>;
>>   reg = <0x0>;
>>   };
>>
>>   cpu1: cpu@1 {
>>   compatible = "arm,cortex-a7";
>>   device_type = "cpu";
>> + cci-control-port = <&cci_control0>;
>> + clock-frequency = <1200>;
>>   reg = <0x1>;
>>   };
>>
>>   cpu2: cpu@2 {
>>   compatible = "arm,cortex-a7";
>>   device_type = "cpu";
>> + cci-control-port = <&cci_control0>;
>> + clock-frequency = <1200>;
>>   reg = <0x2>;
>>   };
>>
>>   cpu3: cpu@3 {
>>   compatible = "arm,cortex-a7";
>>   device_type = "cpu";
>> + cci-control-port = <&cci_control0>;
>> + clock-frequency = <1200>;
>>   reg = <0x3>;
>>   };
>>
>>   cpu4: cpu@100 {
>>   compatible = "arm,cortex-a15";
>>   device_type = "cpu";
>> + cci-control-port = <&cci_control1>;
>> + clock-frequency = <900>;
>
> Isn't the clock frequency property is supposed to be the maximum
> frequency of that CPU in Linux?
>
> It looks odd that the A15 are clocked at a lower frequency than the
> A7...

You're right. Looking at the FEX file, the A15s can go up to 1.8 GHz.
I'll update the numbers.

ChenYu

-- 
You received this message because you are subscribed to the Google Groups 
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [linux-sunxi] [ANNOUNCE] Allwinner releasing CedarX open source

[Andreas Baierl]

Hi Kevin,

Am 19.05.2015 um 02:44 schrieb ke...@allwinnertech.com:

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:

i'm glad to see, that AW tries to make a move in the right direction. 
Although steps are not finished.
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.

With that context, here's an update on our CedarX code release (we welcome
constructive feedback!)

1. New code architecture. Driver has been split into several plugins, one
plugin per video format.
2. GPL-complaint. We have scanned and analyzed the code to ensure that 
there

is no GPL code used or called.
3. Partial CedarX video decoder source code release. MPEG2, MPEG4, 
MJPEG, and

H264 drivers source code available.

I wonder, if you guys have ever recognized 
http://linux-sunxi.org/VE_Register_guide or 
http://linux-sunxi.org/Cedrus from our community wiki.
Most of the registers, that are needed to make the VE (MPEG1/2/4, H264) 
work without the recent source code drop or the old binaries, are known 
already - figured out by reverse engineering.
So, i wonder, why there are still missing register descriptions. For 
example 
https://github.com/allwinner-zh/media-codec/blob/master/sunxi-cedarx/SOURCE/vdecoder/include/veregister.h#L193 
, which are known to deal with the maf deinterlacer.
We hope this is helpful to everyone. If not, please let us know how we 
can improve. Thanks!


Although it's fine and essential to try to resolve the GPL issues by 
publishing the source code, another step to help the open source 
community will be to complete the register documentation, we already 
know in most parts anyway. In addition, there are missing some 
schematics about what versions of the VE is used within which SoC and 
what registers are available or have been altered. The user manuals are 
in genreal a good resource when someone wants to figure out sth about 
the registers, but the Video Engine is sadly completely missing there...


Please also read the other thread 
https://www.mail-archive.com/linux-sunxi@googlegroups.com/msg11469.html 
and think about the statements.


Best Regards,
kevin.z.m


Regards
Andreas


NOTICE: This e-mail and any included attachments are intended only for 
the sole use of named and intended recipient (s) only. If you are the 
named and intended recipient, please note that the information 
contained in this email and its embedded files are confidential and 
privileged. If you are neither the intended nor named recipient, you 
are hereby notified that any unauthorized review, use, disclosure, 
dissemination, distribution, or copying of this communication, or any 
of its contents, is strictly prohibited. Please reply to the sender 
and destroy the original message and all your records of this message 
(whether electronic or otherwise). Furthermore, you should not 
disclose to any other person, use, copy or disseminate the contents of 
this e-mail and/or the documents accompanying it. --
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.


--
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.