I did some investigation while ago, but the project I worked on, decided to
go with 32 bits Arduino.
But, IIRC, the 12 bits ADC can be used, and I think the VRef is only 0 -
1.8V...
R
On Monday, July 21, 2014 5:31:54 PM UTC-5, ra...@blue-cove.com wrote:
>
> On Sunday, June 2, 2013 4:28:39 PM
Hello Ian,
On 21-07-14 22:07, Ian Campbell wrote:
On Fri, 2014-07-18 at 20:47 +0200, Jeroen Hofstee wrote:
Hello Siarhei,
On 18-07-14 19:09, Siarhei Siamashka wrote:
This is needed to have feature parity with the normal boot mode,
where the L2EN bit in the CP15 Auxiliary Control Register is s
On Sunday, June 2, 2013 4:28:39 PM UTC-7, Rosimildo DaSilva wrote:
> Great info.
>
>
> I will do some testing when I get back ! ( too much traveling ! )
>
>
> R
Any follow-ups to this?
I'd love a 12 bit ADC at 2MHz, if someone can doc the useage. Might even be
worth money...
--
You receive
On Mon, 2014-07-21 at 22:39 +0200, Jeroen Hofstee wrote:
> Hello Ian,
>
> On 21-07-14 22:07, Ian Campbell wrote:
> > On Fri, 2014-07-18 at 20:47 +0200, Jeroen Hofstee wrote:
> >> Hello Siarhei,
> >>
> >> On 18-07-14 19:09, Siarhei Siamashka wrote:
> >>> This is needed to have feature parity with t
On Mon, 2014-07-21 at 19:39 +0100, Ian Campbell wrote:
>
> I expect this needs to be done on secondary processors. Need to keep
> that in mind if/when someone works on PSCI for sun[45]i.
Except as Tom points out on IRC, sun[45]i are both single core... Oops!
Ian.
--
You received this messag
On Fri, 2014-07-18 at 20:47 +0200, Jeroen Hofstee wrote:
> Hello Siarhei,
>
> On 18-07-14 19:09, Siarhei Siamashka wrote:
> > This is needed to have feature parity with the normal boot mode,
> > where the L2EN bit in the CP15 Auxiliary Control Register is set
> > by the BROM code right from the st
On Sat, 2014-07-19 at 12:59 +0200, Hans de Goede wrote:
> can you please rebase your set on top of this tree?
Yes, please.
> I understand this may be non trivial and thus may require some extra
> work from you side, and I'm sorry about that.
Me too.
Having been through the series though I don't
On Fri, 2014-07-18 at 19:23 +0300, Siarhei Siamashka wrote:
> In the case if the 'dram_para' struct does not specify the exact bus width
> or chip density, just use a trial and error method to find a usable
> configuration.
>
> Because all the major bugs in the DRAM initialization sequence are now
On Fri, 2014-07-18 at 19:23 +0300, Siarhei Siamashka wrote:
> The write recovery time is 15ns for all JEDEC DDR3 speed bins. And
> instead of hardcoding it to 10 cycles, it is possible to set tighter
> timings based on accurate calculations. For example, DRAM clock
> frequencies up to 533MHz need o
On Fri, 2014-07-18 at 19:23 +0300, Siarhei Siamashka wrote:
> All the known Allwinner A10/A13/A20 devices are using just single rank
> DDR3 memory. So don't pretend that we support DDR2 or more than one
> rank, because nobody could ever test these configurations for real and
> they are likely broke
On Fri, 2014-07-18 at 19:23 +0300, Siarhei Siamashka wrote:
> Add the necessary missing bits from the legacy u-boot-sunxi for the
> Allwinner A10 and A13 support (originally authored by Henrik Nordstrom,
> Stefan Roese, Oliver Schinagl and Hans de Goede).
>
> Signed-off-by: Siarhei Siamashka
Thi
On Fri, 2014-07-18 at 19:23 +0300, Siarhei Siamashka wrote:
> It is going to be useful in more than one place.
>
> Signed-off-by: Siarhei Siamashka
> ---
> arch/arm/cpu/armv7/sunxi/dram.c | 30 +++---
> 1 file changed, 19 insertions(+), 11 deletions(-)
>
> diff --git a/a
On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote:
> The stale error status should be cleared for all sun4i/sun5i/sun7i
> hardware and not just for sun7i. Also there are two types of DQS
> gate training errors ("found no result" and "found more than one
> possible result"). Both are handle
On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote:
> This configures the PLL5P clock frequency to something in the ballpark of
> 1GHz and allows more choices for MBUS and G2D clock frequency selection
> (using their own divisors). In particular, it enables the use of 2/3 clock
> speed rati
On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote:
> The sun5i hardware (Allwinner A13) introduced configurable MBUS clock speed.
> Allwinner A13 uses only 16-bit data bus width to connect the external DRAM,
> which is halved compared to the 32-bit data bus of sun4i (Allwinner A10), so
> i
On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote:
> Moved the impedance setup code part into a separate function. Added explicit
> wait for ZQ calibration completion before proceeding to the next
> initialization
> steps. Removed the CONFIG_SUN7I ifdef guard around the code, which has
>
On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote:
> Before driving the CKE pin (Clock Enable) high, the DDR3 spec requires
> to wait for additional 500 us after the RESET pin is de-asserted.
>
> The DRAM controller takes care of this delay by itself, using a
> configurable counter in the
On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote:
> The RESET pin needs to be kept low for at least 200 us according
> to the DDR3 spec. So just do it the right way.
>
> This issue did not cause any visible major problems earlier, because
> the DRAM RESET pin is usually already low after
On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote:
> If the dram->ppwrsctl (SDR_DPCR) register has the lowest bit set to 1, this
> means that DRAM is currently in self-refresh mode and retaining the old
> data. Since we have no idea what to do in this situation yet, just set this
> registe
On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote:
> The attempt to do DRAM parameters calibration in 'dramc_scan_dll_para()'
> function by trying different DLL adjustments and using the hardware
> DQS gate training result as a feedback is a great source of inspiration,
> but it just can't
On Sat, 2014-07-19 at 13:20 +0200, Hans de Goede wrote:
> Hi,
>
> On 07/18/2014 07:09 PM, Siarhei Siamashka wrote:
> > This is needed to have feature parity with the normal boot mode,
> > where the L2EN bit in the CP15 Auxiliary Control Register is set
> > by the BROM code right from the start.
>
On Fri, 2014-07-18 at 20:09 +0300, Siarhei Siamashka wrote:
>
> http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-June/004341.html
I think a better reference is
https://github.com/hno/Allwinner-Info/blob/master/FEL-usb/USB-protocol.txt
> +.syntax unified
> +.text
> +.arm
> +.arch armv7a
> +.
I found two documents that might be interesting to you. They are meant for
A10, but since A10 and A20 are really similar the chance is that pdf:s is
directly applicable to A20.
First one is in Chinese so google translate is your friend.
http://dl.cubieforums.com/pdf/A10_LCD%E8%B0%83%E8%AF%95%
On Fri, 2014-07-18 at 21:12 -0600, Simon Glass wrote:
> Hi Ian,
>
> On 18 July 2014 13:38, Ian Campbell wrote:
> >
> > This has been disabled for ARM in initr_scsi since that function was
> > introduced. However it works fine for me on Cubieboard and Cubietruck (with
> > the
> > upcoming AHCI gl
I started the process, see http://linux-sunxi.org/HD22
More to come.
On Monday, 21 July 2014 12:55:52 UTC+1, Luc Verhaegen wrote:
>
> As i said on the 11th:
>
>
>
> http://linux-sunxi.org/New_Device_howto
>
>
>
> Luc Verhaegen.
--
You received this message because you are subscribed to
Ok, I have some updates - it seems that my Boot1 was compiled with
SCRIPT_INSTALL_EARLY, so it doesn't fetch script.bin, but instead looks at
SCRIPT_BASE. Not really sure what's happening there, but I recompiled
drv_de.drv and using some printfs (__inf), I can verify that Boot1 gets the
old PH0
dtc was giving warnings for missing #address-cells and #size-cells for
the new sun6i-a31-hummingbird.dts, which has a i2c-based rtc device.
This patch adds the properties for all i2c controller nodes for sun6i.
Signed-off-by: Chen-Yu Tsai
---
Hi Maxime,
This is a fix to get rid of warnings fro
Hi,
Easy - I didn't :) I used some code from the new OV5640 driver (AF mostly),
but due to all the changes I did, I've decided to stick with the old
driver. Same goes for CSI. In fact new CSI driver only has some kernel
support for still image capture + somewhat better implementation for 16bit
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Em 21-07-2014 08:50, zs.gas...@gmail.com escreveu:
> Hi, Did you managed to have a working camera? I need to use it at
> full HD with 30fps. The device manufacturer confirmed that it is
> actually a Samsung S5K4EC sensor, for which the sunxi source d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Em 21-07-2014 09:32, Adilson Oliveira escreveu:
> Em 21-07-2014 08:50, zs.gas...@gmail.com escreveu:
>> Hi, Did you managed to have a working camera? I need to use it
>> at full HD with 30fps. The device manufacturer confirmed that it
>> is actually
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Em 21-07-2014 08:50, zs.gas...@gmail.com escreveu:
> Hi, Did you managed to have a working camera?
No, I'm waiting for the project approval to see what can be done.
> I need to use it at full HD with 30fps. The device manufacturer
> confirmed that
On Mon, Jul 21, 2014 at 04:50:12AM -0700, zs.gas...@gmail.com wrote:
> Hi,
> Did you managed to have a working camera?
> I need to use it at full HD with 30fps. The device manufacturer
> confirmed that it is actually a Samsung S5K4EC sensor, for which the
> sunxi source does not even have driver,
Hi,
How did you managed to make work the new driver from the Android source? Or you
used the old one with the old CSI driver as well?
I need a driver for Samsung S5K4EC camera, and there is not even source for
sunxi-linux :(
--
You received this message because you are subscribed to the Google
Hi,
Did you managed to have a working camera?
I need to use it at full HD with 30fps. The device manufacturer confirmed that
it is actually a Samsung S5K4EC sensor, for which the sunxi source does not
even have driver, so only possibility to use the Android one.
Does anybody have experience how
34 matches
Mail list logo
