[linux-sunxi] Re: [PATCH] clk: sunxi: Add CSI (camera's Sensors Interface) module clock driver for sun[457]i
Hi Maxime
I had a look at your display clock driver.The only issue I have is setting
the clock parents. A simple mask wont do it.
I guess using table is the only way. The CSI is only clock which is using
irregular parents mux. The remaining clocks
including VE, can be based on your display clock driver.
Thanx.
On Monday, March 21, 2016 at 7:42:48 PM UTC+11, Maxime Ripard wrote:
>
> Hi Yassin,
>
> On Thu, Mar 17, 2016 at 07:43:42PM +1100, yassin...@gmail.com
> wrote:
> > From: Yassin Jaffer <yassin...@gmail.com >
> >
> > This patch adds a composite clock type consisting of
> > a clock gate, mux, configurable dividers, and a reset control.
> >
> > Signed-off-by: Yassin Jaffer <yassin...@gmail.com >
> > ---
> > Documentation/devicetree/bindings/clock/sunxi.txt | 1 +
> > drivers/clk/sunxi/Makefile| 1 +
> > drivers/clk/sunxi/clk-a10-csi.c | 188
> ++
> > 3 files changed, 190 insertions(+)
> > create mode 100644 drivers/clk/sunxi/clk-a10-csi.c
> >
> > diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt
> b/Documentation/devicetree/bindings/clock/sunxi.txt
> > index e59f57b..c3826f7 100644
> > --- a/Documentation/devicetree/bindings/clock/sunxi.txt
> > +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
> > @@ -77,6 +77,7 @@ Required properties:
> > "allwinner,sun9i-a80-usb-mod-clk" - for usb gates + resets on
> A80
> > "allwinner,sun9i-a80-usb-phy-clk" - for usb phy gates + resets
> on A80
> > "allwinner,sun4i-a10-ve-clk" - for the Video Engine clock
> > +"allwinner,sun4i-a10-csi-clk" - for the CSI module
> >
> > Required properties for all clocks:
> > - reg : shall be the control register address for the clock.
> > diff --git a/drivers/clk/sunxi/Makefile b/drivers/clk/sunxi/Makefile
> > index 3fd7901..42ce752 100644
> > --- a/drivers/clk/sunxi/Makefile
> > +++ b/drivers/clk/sunxi/Makefile
> > @@ -7,6 +7,7 @@ obj-y += clk-a10-codec.o
> > obj-y += clk-a10-hosc.o
> > obj-y += clk-a10-mod1.o
> > obj-y += clk-a10-pll2.o
> > +obj-y += clk-a10-csi.o
> > obj-y += clk-a10-ve.o
> > obj-y += clk-a20-gmac.o
> > obj-y += clk-mod0.o
> > diff --git a/drivers/clk/sunxi/clk-a10-csi.c
> b/drivers/clk/sunxi/clk-a10-csi.c
> > new file mode 100644
> > index 000..f17d206
> > --- /dev/null
> > +++ b/drivers/clk/sunxi/clk-a10-csi.c
> > @@ -0,0 +1,188 @@
> > +/*
> > + * Copyright 2016 Yassin Jaffer
> > + *
> > + * Yassin Jaffer <yassin...@gmail.com >
> > + *
> > + * This program 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.
> > + *
> > + * This program 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.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static DEFINE_SPINLOCK(sun4i_csi_lock);
> > +
> > +#define SUN4I_CSI_PARENTS 5
> > +#define SUN4I_CSI_GATE_BIT 31
> > +#define SUN4I_CSI_RESET_BIT 30
> > +#define SUN4I_CSI_MUX_SHIFT 24
> > +#define SUN4I_CSI_DIV_WIDTH 5
> > +#define SUN4I_CSI_DIV_SHIFT 0
> > +
> > +static u32 sun4i_csi_mux_table[SUN4I_CSI_PARENTS] = {
> > +0x0,
> > +0x1,
> > +0x2,
> > +0x5,
> > +0x6,
> > +};
> > +
> > +struct csi_reset_data {
> > +void __iomem*reg;
> > +spinlock_t*lock; /* lock for reset
> handling */
> > +struct reset_controller_devrcdev;
> > +};
> > +
> > +static int sun4i_csi_assert(struct reset_controller_dev *rcdev,
> > +unsigned long id)
> > +{
> > +struct csi_reset_data *data = container_of(rcdev,
> > + struct
> csi_reset_data,
> > + rcdev);
> > +unsigned long flags;
> >
Re: [linux-sunxi] SUN4i CSI
Thank for that You just made my day.
On Friday, March 11, 2016 at 9:50:09 AM UTC+11, Maxime Ripard wrote:
>
> Hi Yassin,
>
> On Wed, Mar 09, 2016 at 05:27:52PM -0800, Yassin Jaffer wrote:
> >
> > Hi everyone
> >
> > I'm working on the CSI driver.
>
> Great, it was on my TODO-list :)
>
> > I failed to understand ( lack of documentation) which DMA is used to
> > transfer from the CSI. I can only find a reference in the bsp
> > driver for the DRAM
> >
> > CPU_DRAM_PADDR_ORG = 0x4000
> > HW_DMA_OFFSET= 0x
> >
> > dma_addr_t addr_org = videobuf_to_dma_contig(vb_buf) -
> > CPU_DRAM_PADDR_ORG + HW_DMA_OFFSET;
> >
> > And in the current sunxi 3.4
> >
> > addr_org = videobuf_to_dma_contig((struct videobuf_buffer *)buf);
> > if( (addr_org&0x4000)!=0 )
> > {
> > addr_org-=0x4000;
> > csi_dbg(3,"csi recal mem_addr=%p\n",addr_org);
> > }
> >
> >
> > There is also a reference to the DMA in os_mem_alloc which is used by
> the
> > ISP front end.
> > mem_man->dma_addr = mem_man->phy_addr + HW_DMA_OFFSET-
> > CPU_DRAM_PADDR_ORG;
>
> It has its own DMA controller. You just have to feed it with a
> DMA-capable buffer's physical address in the FIFO Buffer registers,
> and it should just work.
>
> 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.
[linux-sunxi] Re: SUN4i CSI
OK let me rephrase my issue . This what I understood so far from the bsp driver and the manual. CSI0 module for example has 3 channels and in each channel there is 3 FIFOs, each FIFO has 2 buffers( A & B). The output of the buffer(depends on the configuration ) will be available at the memory address(DRAM range) which is set by the output buffer address register. For me this looks like a DMA controller role which is similar to imx3 IPU !. My question. Is the main DMA controller has access to the CSI output buffers. And if not can I implement part of this driver using dma engin framework. Thank you in advance. -- 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] SUN4i CSI
Hi everyone
I'm working on the CSI driver.I failed to understand ( lack of
documentation) which DMA is used to transfer from the CSI.
I can only find a reference in the bsp driver for the DRAM
CPU_DRAM_PADDR_ORG = 0x4000
HW_DMA_OFFSET= 0x
dma_addr_t addr_org = videobuf_to_dma_contig(vb_buf) -
CPU_DRAM_PADDR_ORG + HW_DMA_OFFSET;
And in the current sunxi 3.4
addr_org = videobuf_to_dma_contig((struct videobuf_buffer *)buf);
if( (addr_org&0x4000)!=0 )
{
addr_org-=0x4000;
csi_dbg(3,"csi recal mem_addr=%p\n",addr_org);
}
There is also a reference to the DMA in os_mem_alloc which is used by the
ISP front end.
mem_man->dma_addr = mem_man->phy_addr + HW_DMA_OFFSET-
CPU_DRAM_PADDR_ORG;
Any hints will be appreciated.
--
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 v8 0/2] ASoc: sun4i-codec: Add FM, Line and Mic inputs
Hi Danny You don't seem to provide the full gain scale for most of the inputs any reason for that (Please check the user manual)? You are trying to add input capture support but your routing for FMIN/Line-In does not include the ADC as a sink. I would suggest if your patch cover playback only or add more descriptive comments. And can you please keep the history of your revisions. Best regards -- 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 v7 2/2] sun4i-codec: Add FM, Line and Mic inputs
Hi Danny
+ {"Capture Source", "Line-In", "Line-In"},
+ {"Capture Source", "FM", "FM"},
The ADC Capturing Sources routing doesn't look right.
There is no FM/Line-In source widgets for this routing n your patch.
+ {"Capture Source", "Line-In,Mic1", "Line-In"},
+ {"Capture Source", "Line-In,Mic1", "MIC1 Pre-Amplifier"},
and her too.
I'm not familiar with the CODEC ADC mux but you may want to use
{"Capture Source", "Line-In", "Line-In Right"},
{"Capture Source", "Line-In", "Line-In Left"},
{"Capture Source", "FM", "FM Right"},
{"Capture Source", "FM", "FM Left"},
Regards
On Sat, Dec 19, 2015 at 1:59 PM, Danny Milosavljevic wrote:
> This is the second part, actually adding FM, Line and Mic inputs.
>
> Signed-off-by: Danny Milosavljevic
> ---
> b/sound/soc/sunxi/sun4i-codec.c | 182
> +++-
> 1 file changed, 178 insertions(+), 4 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c
> index 6628e6e..9a9ad62 100644
> --- a/sound/soc/sunxi/sun4i-codec.c
> +++ b/sound/soc/sunxi/sun4i-codec.c
> @@ -59,9 +59,20 @@
> #define SUN4I_CODEC_DAC_ACTL_DACAENR (31)
> #define SUN4I_CODEC_DAC_ACTL_DACAENL (30)
> #define SUN4I_CODEC_DAC_ACTL_MIXEN (29)
> +#define SUN4I_CODEC_DAC_ACTL_LNG (26)
> +#define SUN4I_CODEC_DAC_ACTL_FMG (23)
> +#define SUN4I_CODEC_DAC_ACTL_MICG (20)
> +#define SUN4I_CODEC_DAC_ACTL_LLNS (19)
> +#define SUN4I_CODEC_DAC_ACTL_RLNS (18)
> +#define SUN4I_CODEC_DAC_ACTL_LFMS (17)
> +#define SUN4I_CODEC_DAC_ACTL_RFMS (16)
> #define SUN4I_CODEC_DAC_ACTL_LDACLMIXS (15)
> #define SUN4I_CODEC_DAC_ACTL_RDACRMIXS (14)
> #define SUN4I_CODEC_DAC_ACTL_LDACRMIXS (13)
> +#define SUN4I_CODEC_DAC_ACTL_MIC1LS(12)
> +#define SUN4I_CODEC_DAC_ACTL_MIC1RS(11)
> +#define SUN4I_CODEC_DAC_ACTL_MIC2LS(10)
> +#define SUN4I_CODEC_DAC_ACTL_MIC2RS(9)
> #define SUN4I_CODEC_DAC_ACTL_DACPAS(8)
> #define SUN4I_CODEC_DAC_ACTL_MIXPAS(7)
> #define SUN4I_CODEC_DAC_ACTL_PA_MUTE (6)
> @@ -87,8 +98,11 @@
> #define SUN4I_CODEC_ADC_ACTL_PREG1EN (29)
> #define SUN4I_CODEC_ADC_ACTL_PREG2EN (28)
> #define SUN4I_CODEC_ADC_ACTL_VMICEN(27)
> -#define SUN4I_CODEC_ADC_ACTL_VADCG (20)
> +#define SUN4I_CODEC_ADC_ACTL_PREG1_A10 (25)
> +#define SUN4I_CODEC_ADC_ACTL_PREG2_A10 (23)
> +#define SUN4I_CODEC_ADC_ACTL_ADCG (20)
> #define SUN4I_CODEC_ADC_ACTL_ADCIS (17)
> +#define SUN4I_CODEC_ADC_ACTL_LNRDF (16)
> #define SUN4I_CODEC_ADC_ACTL_PA_EN (4)
> #define SUN4I_CODEC_ADC_ACTL_DDE (3)
> #define SUN4I_CODEC_ADC_DEBUG (0x2c)
> @@ -100,6 +114,16 @@
> #define SUN7I_CODEC_AC_DAC_CAL (0x38)
> #define SUN7I_CODEC_AC_MIC_PHONE_CAL (0x3c)
>
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG1 (29)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PREG2 (26)
> +/* note: no idea where the output pins for the following are. */
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTG (5)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTEN (4)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTS3 (3)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTS2 (2)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTS1 (1)
> +#define SUN7I_CODEC_AC_MIC_PHONE_CAL_PHONEOUTS0 (0)
> +
> struct sun4i_codec {
> struct device *dev;
> struct regmap *regmap;
> @@ -509,19 +533,102 @@ static const struct snd_kcontrol_new
> sun4i_codec_pa_mute =
> SUN4I_CODEC_DAC_ACTL_PA_MUTE, 1, 0);
>
> static DECLARE_TLV_DB_SCALE(sun4i_codec_pa_volume_scale, -6300, 100, 1);
> +static DECLARE_TLV_DB_SCALE(sun4i_codec_linein_loopback_gain_scale,
> + -150,
> + 150,
> + 0);
> +static DECLARE_TLV_DB_SCALE(sun4i_codec_fmin_loopback_gain_scale,
> + -450,
> + 150,
> + 0);
> +static DECLARE_TLV_DB_SCALE(sun4i_codec_micin_loopback_gain_scale,
> + -450,
> + 150,
> + 0);
> +static DECLARE_TLV_DB_RANGE(sun4i_codec_micin_preamp_gain_scale_a10,
> + 0, 0, TLV_DB_SCALE_ITEM(0, 0, 0),
> + 1, 7, TLV_DB_SCALE_ITEM(3500, 300, 0));
> +static DECLARE_TLV_DB_SCALE(sun4i_codec_adc_gain_scale, -450,
[linux-sunxi] Re: [PATCH 3/4] input: Add new sun4i-keypad driver
Hi Maxime I appreciate your time and efforts . Do you need that rate to be enforced, or is it some leftover from the > allwinner BSP? I've found that clock rate works fine with the default denounce and scan cycle. By the way do you have any dev board which expose the keypad pins? I will try to submit a follow up patch to address these issues. Thank you again for your valuable review. Regards. On Thu, Sep 17, 2015 at 11:05 PM, Maxime Ripard < maxime.rip...@free-electrons.com> wrote: > Hi, > > On Wed, Sep 16, 2015 at 12:05:56AM +1000, yassinjaf...@gmail.com wrote: > > From: Yassin Jaffer <yassinjaf...@gmail.com> > > > > Allwinnner SUN4i Keypad controller is used to interface a SoC > > with a matrix-typekeypad device. > > The keypad controller supports multiple row and column lines. > > A key can be placed at each intersection of a unique > > row and a unique column. > > The keypad controller can sense a key-press and key-release and report > the > > event using a interrupt to the cpu. > > This patch adds a driver support to this. > > The keypad controller driver does not give proper information > > if more that two keys are selected. > > > > Signed-off-by: Yassin Jaffer <yassinjaf...@gmail.com> > > --- > > drivers/input/keyboard/Kconfig| 11 ++ > > drivers/input/keyboard/Makefile | 1 + > > drivers/input/keyboard/sun4i-keypad.c | 361 > ++ > > 3 files changed, 373 insertions(+) > > create mode 100644 drivers/input/keyboard/sun4i-keypad.c > > > > diff --git a/drivers/input/keyboard/Kconfig > b/drivers/input/keyboard/Kconfig > > index 2e80107..4f2f3f8 100644 > > --- a/drivers/input/keyboard/Kconfig > > +++ b/drivers/input/keyboard/Kconfig > > @@ -590,6 +590,17 @@ config KEYBOARD_SUN4I_LRADC > > To compile this driver as a module, choose M here: the > > module will be called sun4i-lradc-keys. > > > > +config KEYBOARD_SUN4I_KEYPAD > > + tristate "Allwinner sun4i keypad support" > > + depends on ARCH_SUNXI > > Is this IP found on all the know SoCs, or just a subset of them? > > You probably want to add || COMPILE_TEST in that depends on too. > > > + select INPUT_MATRIXKMAP > > + help > > + This selects support for the Allwinner keypad > > + on Allwinner sunxi SoCs. > > + > > + To compile this driver as a module, choose M here: the > > + module will be called sun4i-keypad. > > + > > config KEYBOARD_DAVINCI > > tristate "TI DaVinci Key Scan" > > depends on ARCH_DAVINCI_DM365 > > diff --git a/drivers/input/keyboard/Makefile > b/drivers/input/keyboard/Makefile > > index 1d416dd..d9f54b4 100644 > > --- a/drivers/input/keyboard/Makefile > > +++ b/drivers/input/keyboard/Makefile > > @@ -57,6 +57,7 @@ obj-$(CONFIG_KEYBOARD_STMPE)+= > stmpe-keypad.o > > obj-$(CONFIG_KEYBOARD_STOWAWAY) += stowaway.o > > obj-$(CONFIG_KEYBOARD_ST_KEYSCAN)+= st-keyscan.o > > obj-$(CONFIG_KEYBOARD_SUN4I_LRADC) += sun4i-lradc-keys.o > > +obj-$(CONFIG_KEYBOARD_SUN4I_KEYPAD) += sun4i-keypad.o > > obj-$(CONFIG_KEYBOARD_SUNKBD)+= sunkbd.o > > obj-$(CONFIG_KEYBOARD_TC3589X) += tc3589x-keypad.o > > obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o > > diff --git a/drivers/input/keyboard/sun4i-keypad.c > b/drivers/input/keyboard/sun4i-keypad.c > > new file mode 100644 > > index 000..995f9665 > > --- /dev/null > > +++ b/drivers/input/keyboard/sun4i-keypad.c > > @@ -0,0 +1,361 @@ > > +/* > > + * Allwinner sun4i keypad Controller driver > > + * > > + * Copyright (C) 2015 Yassin Jaffer <yassinjaf...@gmail.com> > > + * > > + * Parts of this software are based on (derived from): > > + * Copyright (C) 2013-2015 lim...@allwinnertech.com, > > + *qys<qinyongs...@allwinnertech.com> > > + * > > + * This program 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. > > + * > > + * This program 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. > > + */ > > + > > +#i
Re: [linux-sunxi] Re: Allwinner strips symbols from latest cedar binaries.
+1 On Sun, Mar 29, 2015 at 12:33 PM, Henrik Nordström hen...@henriknordstrom.net wrote: tor 2015-03-26 klockan 10:44 +0100 skrev Michal Suchanek: It was only worth having this list while decent Allwinner hardware was produced and Allwinner was somewhat cooperative with respect to development. It seems that period of both decent hardware based on Allwinner chips and Allwinner cooperation has ceased so there is not much point anymore except using the existing somewhat obsolete devices. Allwinner is actually much more cooperative today than they have ever been. But CedarX code have never been open, ever, and have always been a sore point in all discussions. My vote is to completely forget about any CedarX binary releases from Allwinner, and focus on the reverse engineered driver. Nothing good is likely to come from the Allwinner binary driver. To continue discussions about the binary driver only makes things worse for everyone involved. The reverse engineered driver needs some love for production use, but there is not and have never been any other viable path forward for CedarX development. 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. -- 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] [UBOOT NAND] [PATCH 0/4] Add nand reading support to u-boot
Hi Hans I was working on utilizing the DM framework for the nand driver, but this is going to take sometime , anyway I will try to submit the driver based on bbrezillon work. I'm quite happy if Daniel wants to pickup my work, besides Daniel patches are for the SPL nand driver. Regards On Tuesday, January 6, 2015 12:08:48 AM UTC+11, Hans de Goede wrote: Hi, On 02-01-15 09:53, Daniel Kochmański wrote: This is a series of patches to enable nand read functionality on sunxi devices. It uses DMA and is able to read from syndrome partitions and normal ones. Additionaly mksunxiboot tool is patched to be able to format resulting binary to be able to read from BROM, so NAND SPL builds are now possible. a20_nandread command is added for conveniance. Afaik DMA controller doesn't vary between a10 and a20, so this should work on a10 devices, but due to no a10 hardware it wasn't tested. First of all many thanks for working on this! I see that this is against linux-sunxi/u-boot-sunxi.git, that is not (really) being actively developed anymore, see: https://www.marshut.net/kuispp/linux-sunxi-u-boot-sunxi-is-no-longer-supported-time-to-switch-to-upstream-u-boot.html Can you please rebase on top of upstream u-boot, on top of the next branch: http://git.denx.de/?p=u-boot/u-boot-sunxi.git;a=shortlog;h=refs/heads/next ? Your patches all seem to only have a subject and not a proper commit message, please add a commit message to all of them describing the changes in somewhat more detail then you do in the subject, you could e.g. re-use bits of your coverletter. Also for upstream u-boot we require a Signed-off-by as part of the commit message, so please add a line like this one to all your commit messages: Signed-off-by: Daniel Kochmański dkoch...@antmicro.com javascript: You can make git do this automatically by specifying the -s option when committing, also please send further versions of this patch-set to the upstream u-boot list. Besides all the above, which is easily fixed, unfortunately we also have the problem (or luxury) that Yassin Jaffer (added to the CC) has also been working on nand support, re-using the upstream kernel code Boris Brezillon has been working on, see: https://github.com/yassinjaffer/u-boot/commits/sunxi-nand I believe that Yassin's version is better then yours because it re-uses existing nand infrastructure rather then more or less starting from scratch. But Yassin has not been very active on this, and has been reluctant to submit his work upstream because it has not been tested a lot yet. The best way forward may very well be you picking up Yassin's work (in coordination with Yassin), and submitting that to upstream u-boot. Yassin, I notice that the patches in your git repo do not have a Signed-off-by, can you please reply to this mail with your Signed-off-by to indicate that it is ok for us to add your Signed-off-by to your patches ? Regards, Hans Daniel Kochmański (4): sunxi: nand: add minimal nand driver (reading flash only). sunxi: mksunxiboot: increase block size, so checksum is correct on nand sunxi: nand: add nand spl boot option sunxi: nand: add a20_nandread command arch/arm/cpu/armv7/sunxi/board.c | 4 + board/sunxi/Makefile | 1 + board/sunxi/nand.c | 252 +++ common/Makefile | 1 + common/cmd_a20_nandread.c| 26 common/spl/spl_nand.c| 23 +++- include/configs/sunxi-common.h | 25 ++-- tools/mksunxiboot.c | 2 +- 8 files changed, 322 insertions(+), 12 deletions(-) create mode 100644 board/sunxi/nand.c create mode 100644 common/cmd_a20_nandread.c -- 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: mainline NAND
Hi Pierluigi
Can you send the output of your
*'mtdinfo -a '.*
and what version of mtd-utils you are using? 'versions less than 1.5.1
have a bug with MLC nands'
On Thu, Dec 25, 2014 at 7:54 PM, Pierluigi Scacchi scacc...@gmail.com
wrote:
Il giorno mercoledì 24 dicembre 2014 00:07:25 UTC+1, Michal Suchanek ha
scritto:
On 23 December 2014 at 16:13, scac...@gmail.com wrote:
Il giorno venerdì 19 dicembre 2014 05:53:18 UTC+1, Yassin Jaffer ha
scritto:
Hi Michal
This was answered previously by Brezillon . Please search the mailing
list.You have to force bad block erasure to get rid of AW's libnand layout
(which is overriding bad block markers).
Please follow these steps:
1) apply this patch [1]
2) boot on your new kernel and launch
$ flash_erase /dev/mtd0 0 0
3) revert the patch
4) Boot on your new kernel
Most of your bad blocks should be gone after that...
[1]http://code.bulix.org/k2v1hx-87237
Yes K9GBG08U0A has two variants of the chip ID and maybe more...
use some printk in the nand_base.c to get more accurate information
about your nand.
On Fri, Dec 19, 2014 at 7:44 AM, Michal Suchanek hram...@gmail.com
wrote:On 18 December 2014 at 14:13, Henrik Nordström
hen...@henriknordstrom.net wrote:
tor 2014-12-18 klockan 13:47 +0100 skrev Michal Suchanek:
Yes, that's what you can obviously do. If the ID listed in the
datasheet and the ID read by the kernel does not agree put the ID
read
in the table.
However, how is Joe User with a Chinese tablet supposed to add his
NAND chip?
If the chip supports JEDEC identification then it's supposedly
automatically configured.. sadly it seems most chineese tablets uses
non-JEDEC identified NAND chips.
If not then one need to go thru the manual process of finding the
datasheet and try to find needed parameters from there which means
opening the device to find the NAND chip model, search the Internet
for
a datasheet (if lucky), or find something usable in the Allwinner
drivers if you can find usable source version.
If a Joe User sent us this datasheet can we fabricate an ID entry
form
that datasheet alone? How?
Only if the datasheets lists usable identification strings,
something
many get wrong even from well known NAND manufacturers.
If not should we add a patch to the kernel to always print the full
ID? If so how can we believe *anything* in the datasheet if even
something as simple and basic as chip ID is wrong?
General timing data should be correct, but... honestly I have even
seen
page size and OOB size being specified wrongly in datasheets.
For many chips finding any reliable information is not easy.
hmm, the sunxi nand driver has this:
//NAND_CHIP_ID DieCnt SecCnt
PagCnt BlkCntOpOpt DatBlk Freq EccMode ReadRetry DDRType
OperationPar
{ {0xec, 0xd5, 0x94, 0x29, 0xff, 0xff, 0xff, 0xff }, 1, 8,
128, 4096, 0x0008, 974,30, 0, 0,0,
PhysicArchiPara3 }, // K9GAG08U0D
{ {0xec, 0xd5, 0x84, 0x72, 0xff, 0xff, 0xff, 0xff }, 1,16,
128, 2048, 0x, 950,24, 2, 0,0,
PhysicArchiPara3 }, // K9GAG08U0E
{ {0xec, 0xd5, 0x94, 0x76, 0x54, 0xff, 0xff, 0xff }, 1,16,
128, 2048, 0x0408, 950,30, 2, 0,0,
PhysicArchiPara3 }, // K9GAG08U0E
{ {0xec, 0xd3, 0x84, 0x72, 0xff, 0xff, 0xff, 0xff }, 1,16,
128, 1024, 0x, 950,24, 2, 0,0,
PhysicArchiPara3 }, // K9G8G08U0C
{ {0xec, 0xd7, 0x94, 0x76, 0xff, 0xff, 0xff, 0xff }, 1,16,
128, 4096, 0x0088, 974,30, 3, 0,0,
PhysicArchiPara3 }, // K9GBG08U0A
{ {0xec, 0xd7, 0x94, 0x7A, 0xff, 0xff, 0xff, 0xff }, 1,16,
128, 4096, 0x0088, 974,30, 3, 0,0,
PhysicArchiPara3 }, // K9GBG08U0A
{ {0xec, 0xde, 0xd5, 0x7A, 0x58, 0xff, 0xff, 0xff }, 2,16,
128, 4096, 0x0888, 974,30, 3, 0,0,
PhysicArchiPara3 }, // K9LCG08U0A
where 0x88 looks like NAND_MULTI_PROGRAM | NAND_RANDOM
and
974 ValidBlkRatio; //the valid block
ratio, based on 1024 blocks
30 AccessFreq; //the highest access
frequence of the nand flash chip, based on MHz
3 EccMode;//the Ecc Mode for the
nand flash chip, 0: bch-16, 1:bch-28, 2:bch_32
So there are two variants of the K9GBG08U0A chip ID there.
--
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...@googlegroups.com
Re: [linux-sunxi] Re: mainline NAND
Hi Michal
This was answered previously by Brezillon . Please search the mailing list.
You have to force bad block erasure to get rid of AW's libnand layout
(which is overriding bad block markers).
Please follow these steps:
1) apply this patch [1]
2) boot on your new kernel and launch
$ flash_erase /dev/mtd0 0 0
3) revert the patch
4) Boot on your new kernel
Most of your bad blocks should be gone after that...
[1]http://code.bulix.org/k2v1hx-87237
Yes K9GBG08U0A has two variants of the chip ID and maybe more...
use some printk in the nand_base.c to get more accurate information about
your nand.
On Fri, Dec 19, 2014 at 7:44 AM, Michal Suchanek hramr...@gmail.com wrote:
On 18 December 2014 at 14:13, Henrik Nordström
hen...@henriknordstrom.net wrote:
tor 2014-12-18 klockan 13:47 +0100 skrev Michal Suchanek:
Yes, that's what you can obviously do. If the ID listed in the
datasheet and the ID read by the kernel does not agree put the ID read
in the table.
However, how is Joe User with a Chinese tablet supposed to add his NAND
chip?
If the chip supports JEDEC identification then it's supposedly
automatically configured.. sadly it seems most chineese tablets uses
non-JEDEC identified NAND chips.
If not then one need to go thru the manual process of finding the
datasheet and try to find needed parameters from there which means
opening the device to find the NAND chip model, search the Internet for
a datasheet (if lucky), or find something usable in the Allwinner
drivers if you can find usable source version.
If a Joe User sent us this datasheet can we fabricate an ID entry form
that datasheet alone? How?
Only if the datasheets lists usable identification strings, something
many get wrong even from well known NAND manufacturers.
If not should we add a patch to the kernel to always print the full
ID? If so how can we believe *anything* in the datasheet if even
something as simple and basic as chip ID is wrong?
General timing data should be correct, but... honestly I have even seen
page size and OOB size being specified wrongly in datasheets.
For many chips finding any reliable information is not easy.
hmm, the sunxi nand driver has this:
//NAND_CHIP_ID DieCnt SecCnt
PagCnt BlkCntOpOpt DatBlk Freq EccMode ReadRetry DDRType
OperationPar
{ {0xec, 0xd5, 0x94, 0x29, 0xff, 0xff, 0xff, 0xff }, 1, 8,
128, 4096, 0x0008, 974,30, 0, 0,0,
PhysicArchiPara3 }, // K9GAG08U0D
{ {0xec, 0xd5, 0x84, 0x72, 0xff, 0xff, 0xff, 0xff }, 1,16,
128, 2048, 0x, 950,24, 2, 0,0,
PhysicArchiPara3 }, // K9GAG08U0E
{ {0xec, 0xd5, 0x94, 0x76, 0x54, 0xff, 0xff, 0xff }, 1,16,
128, 2048, 0x0408, 950,30, 2, 0,0,
PhysicArchiPara3 }, // K9GAG08U0E
{ {0xec, 0xd3, 0x84, 0x72, 0xff, 0xff, 0xff, 0xff }, 1,16,
128, 1024, 0x, 950,24, 2, 0,0,
PhysicArchiPara3 }, // K9G8G08U0C
{ {0xec, 0xd7, 0x94, 0x76, 0xff, 0xff, 0xff, 0xff }, 1,16,
128, 4096, 0x0088, 974,30, 3, 0,0,
PhysicArchiPara3 }, // K9GBG08U0A
{ {0xec, 0xd7, 0x94, 0x7A, 0xff, 0xff, 0xff, 0xff }, 1,16,
128, 4096, 0x0088, 974,30, 3, 0,0,
PhysicArchiPara3 }, // K9GBG08U0A
{ {0xec, 0xde, 0xd5, 0x7A, 0x58, 0xff, 0xff, 0xff }, 2,16,
128, 4096, 0x0888, 974,30, 3, 0,0,
PhysicArchiPara3 }, // K9LCG08U0A
where 0x88 looks like NAND_MULTI_PROGRAM | NAND_RANDOM
and
974 ValidBlkRatio; //the valid block
ratio, based on 1024 blocks
30 AccessFreq; //the highest access
frequence of the nand flash chip, based on MHz
3 EccMode;//the Ecc Mode for the
nand flash chip, 0: bch-16, 1:bch-28, 2:bch_32
So there are two variants of the K9GBG08U0A chip ID there.
--
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] Re: mainline NAND
Hi Michal
add the following to the nand id table
{K9GBG08U0A 32G 3.3V 8-bit,
{ .id = {0xec, 0xd7, 0x94, 0x7a, 0x54, 0x43} },
SZ_8K, SZ_4K, SZ_1M, 0, 6, 640, NAND_ECC_INFO(40, SZ_1K),
0 },
http://lxr.free-electrons.com/source/include/linux/mtd/nand.h#L787
On Thu, Dec 18, 2014 at 5:07 AM, Michal Suchanek hramr...@gmail.com wrote:
Hello,
On 17 December 2014 at 11:40, Boris BREZILLON b.brezillon@gmail.com
wrote:
Hi Michal
Le mardi 16 décembre 2014 19:01:58 UTC+1, Michal Suchanek a écrit :
Hello,
I tried to rebase the v7 patchset on top of 3.18 and add the DT
bindings on cubieboard:
https://github.com/hramrach/linux-sunxi/commit/a946d593ddcf443b0f035f6d39fe0c558189dacc
The nand driver fails equally on both cubieboard versions:
cubieboard:
[0.643554] calling nand_base_init+0x0/0x20 @ 1
[0.643565] initcall nand_base_init+0x0/0x20 returned 0 after 3 usecs
[0.643578] calling sunxi_nfc_driver_init+0x0/0x10 @ 1
[0.665751] nand: Could not find valid JEDEC parameter page; aborting
[0.670907] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7
[0.675949] nand: Samsung NAND 4GiB 3,3V 8-bit
[0.679098] nand: 4096MiB, MLC, page size: 8192, OOB size: 640
[0.683748] sunxi_nand 1c03000.nand: ECC init failed: -22
[0.687839] sunxi_nand 1c03000.nand: failed to init nand chips
[0.692440] sunxi_nand: probe of 1c03000.nand failed with error -22
[0.697500] initcall sunxi_nfc_driver_init+0x0/0x10 returned 0
after 52642 usecs
cubieboard2:
[0.666766] calling nand_base_init+0x0/0x20 @ 1
[0.666777] initcall nand_base_init+0x0/0x20 returned 0 after 3 usecs
[0.666790] calling sunxi_nfc_driver_init+0x0/0x10 @ 1
[0.683003] nand: Could not find valid JEDEC parameter page; aborting
[0.688159] nand: device found, Manufacturer ID: 0xec, Chip ID: 0xd7
[0.693201] nand: Samsung NAND 4GiB 3,3V 8-bit
[0.696349] nand: 4096MiB, MLC, page size: 8192, OOB size: 640
[0.700956] sunxi_nand 1c03000.nand: ECC init failed: -22
[0.705060] sunxi_nand 1c03000.nand: failed to init nand chips
[0.709658] sunxi_nand: probe of 1c03000.nand failed with error -22
[0.714768] initcall sunxi_nfc_driver_init+0x0/0x10 returned 0
after 46833 usecs
Is this expected or does somebody have the driver working on some
device?
As Henrik already answered, it seems that your NAND chip is not properly
defined in the nand_ids table [1].
Read your NAND datasheet and add a new entry (take a look at this one
[2] as
an example).
You should also fill the correct timing mode, though mode 0 should work
correctly on all recent NANDs.
The nand chip says Samsung 222 K9GBG08U0A SCB0
Is there some document on filling out his table?
It seems that 0xec 0xd7 matches info on top op page 80 of
http://www.datasheet4u.com/datasheet-pdf/Samsung/K9GBG08U0A/pdf.php?id=704185
But that table lists 0xec, 0xd7, 0x94, 0x76, 0x64, 0x43 and additional
debug output shows that the chip sends Manufacturer ID: 0xec, Chip
ID: 0xd7; 0x94 0x7a 0x54 0x43 0xec 0xd7 the last two bytes possibly
being wrap-around of the first two.
However, that document lists multitudes of identification strings.
Which one is used where in the table?
The document lists that there is 8k page and 640 oob which matches
existing output. It also says that that ecc is 40bit (1k + 80byte) on
page 5 which looks like value obtained by dividing that 640 oob data
by 8 to get oob amount per 1k - no staggering new information.
Some timing information is presented on pages 18-19 but the provided
table has way more data than a nand entry in the kernel table.
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.
--
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] multiple NAND flash chips?
Hi Vladimir You can try bbrezillon MTD driver https://github.com/bbrezillon/linux-sunxi/tree/sunxi-nand-v7. On Thu, Oct 23, 2014 at 8:26 PM, Vladimir Komendantskiy komendant...@gmail.com wrote: Hi, Does anybody have several NAND flash chips working simultaneously with either any of the (corrected) Allwinner block drivers or the MTD drivers? I'm thinking to build a programming adaptor for 3 or 4 chips. I'd appreciate if you let me know of your experiences with sunxi NAND controller chip enable lines. I haven't found any support for my latest 16 nm Hynix chip in the git tree, so I've added it by reverse-engineering on top of the Allwinner standalone driver 2.12 (hex). In fact, the 2.12 driver, at least in the form I was able to get, was still quite buggy even though it had less bugs compared to the current driver in sunxi-3.4. Also I've added support for a very similar Hynix chip that I don't have but which is featured in the A80 NAND flash binary blob. Both chips can work at 50 MHz, which is faster than any currently supported Hynix chips. As a remark, the version 2.9 of the Allwinner driver in sunxi-3.4 doesn't seem to work correctly with clean memory. It would need to be upgraded in the main sunxi-linux tree. I would never buy an Allwinner tablet with a NAND flash: not after looking in their driver code :) Thanks and regards, --Vladimir -- 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.
[linux-sunxi] linux-sunxi.org is down
Can someone give us update on why the website is down? Yassin jaffer -- 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: i2s audio codec support for sun7i
Hi Puneet Have a look into some on some of the drivers handle the regulators power. rtl8723bs sdio wifi for example. On Sat, Jun 21, 2014 at 4:49 PM, Puneet B punit...@gmail.com wrote: Here i am attaching my schematics of A20 board , KIndly tell how can pass get t 4 regulators for IOVDD,DVDD,AVDD,and DRVDD. Regards Punith -- 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] Re: i2s audio codec support for sun7i
if you are using 3.4 just add it to platform_add_devices in
arch/arm/plat-sunxi/devices.c
On Thu, Jun 19, 2014 at 8:41 PM, Puneet B punit...@gmail.com wrote:
Hi all,
I able to find the problem, it is because probe function of tlv320aic3x.c
is not calling.
so i am not able register it and also there is no board specific file
under arch/arm/ to assign i2c probe manually.
like
vim ./arch/arm/mach-s3c64xx/mach-crag6410-module.c
static struct i2c_board_info mxc_i2c0_board_info[] __initdata = {
{
I2C_BOARD_INFO(sgtl5000, 0x14),
},};
So how can i make probe of my external codec.
Your help will be greatly appreciable.
Regards
Punith
--
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] Re: i2s audio codec support for sun7i
ALSA ASoC splits an embedded audio system into three components:
Codec driver: The codec driver is platform independent and contains audio
controls, audio DAPM interface capabilities, codec DAPM definition and codec IO
functions.
Platform driver: The platform driver contains the audio dma engine and audio
interface drivers (e.g. I2S, AC97, PCM) for that platform.
Machine driver: The machine driver handles any machine specific controls and
audio events i.e. turning on an DAPM at start of playback.
you need to add this to platform driver and not to the codec driver
Yassin jaffer
On 20 Jun 2014, at 12:28 am, Puneet B punit...@gmail.com wrote:
Hi Yassin,
Here i did same thing but directly in codec driver ,
vim sound/soc/codec/tlv320aic3x.c
/* added by punith */
static struct i2c_board_info __initdata aic3x_i2c_board_info[] = {
{
.type = tlv320aic3x,
.addr = 0x18,
//.platform_data = axp_pdata,
//.irq = pmu_irq_id,
},
};
static int __init aic3x_modinit(void)
{
int ret = 0;
ret = i2c_add_driver(aic3x_i2c_driver);
printk(%s puneet\n,__func__);
/* addedd by punith*/
i2c_register_board_info(2, aic3x_i2c_board_info,
ARRAY_SIZE(aic3x_i2c_board_info));
if (ret != 0) {
printk(KERN_ERR Failed to register TLV320AIC3x I2C driver:
%d\n,
ret);
}
return ret;
}
But not yet able to probe the codec.
Regards
Punith
--
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] Booting devel device tree kernel on Cubietruck
sorry I did not realize that your are booting from NFS, I had my own mmc driver. I guess you could use initramfs. I've not tried to boot from NFS before. On Thu, May 22, 2014 at 3:56 PM, Yassin Jaffer yassinjaf...@gmail.comwrote: setenv bootargs console=ttyS0,115200 loglevel=9 earlyprintk root=/dev/mmcblk0p2 ro rootwait On Thu, May 22, 2014 at 2:26 PM, jonsm...@gmail.com jonsm...@gmail.comwrote: I can't get anywhere trying to boot a devel device tree kernel on Cubietruck. This is with https://github.com/jwrdegoede/linux-sunxi.git and the linux-devel branch. I don't get any boot output. I can boot a 3.4 kernel without problem. I followed these steps. http://linux-sunxi.org/Mainline_Kernel_Howto I also tried turning on low level printk but still no output U-Boot SPL 2014.04-10675-g44b53fd (May 19 2014 - 20:39:18) Board: Cubietruck DRAM: 2048 MiB CPU: 96000Hz, AXI/AHB/APB: 3/2/2 spl: not an uImage at 1600 U-Boot 2014.04-10675-g44b53fd (May 19 2014 - 20:39:18) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Cubietruck I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 In:serial Out: serial Err: serial Net: dwmac.1c5 Hit any key to stop autoboot: 0 sun7i# tftp 0x4900 /var/lib/tftpboot/ct.dtb dwmac.1c5 Waiting for PHY auto negotiation to complete done Speed: 1000, full duplex Using dwmac.1c5 device TFTP from server 192.168.1.50; our IP address is 192.168.1.51 Filename '/var/lib/tftpboot/ct.dtb'. Load address: 0x4900 Loading: ## 7.6 MiB/s done Bytes transferred = 24030 (5dde hex) sun7i# tftp 0x4600 /var/lib/tftpboot/uImage Speed: 1000, full duplex Using dwmac.1c5 device TFTP from server 192.168.1.50; our IP address is 192.168.1.51 Filename '/var/lib/tftpboot/uImage'. Load address: 0x4600 Loading: # # 12.3 MiB/s done Bytes transferred = 1837040 (1c07f0 hex) sun7i# env set fdt_high sun7i# sun7i# bootm 0x4600 - 0x4900 ## Booting kernel from Legacy Image at 4600 ... Image Name: Linux-3.15.0-rc5-80186-gb9505da Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1836976 Bytes = 1.8 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4900 Booting using the fdt blob at 0x4900 Loading Kernel Image ... OK Using Device Tree in place at 4900, end 49008ddd Starting kernel ... -- Jon Smirl jonsm...@gmail.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. -- 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] Booting devel device tree kernel on Cubietruck
setenv bootargs console=ttyS0,115200 loglevel=9 earlyprintk root=/dev/mmcblk0p2 ro rootwait On Thu, May 22, 2014 at 2:26 PM, jonsm...@gmail.com jonsm...@gmail.comwrote: I can't get anywhere trying to boot a devel device tree kernel on Cubietruck. This is with https://github.com/jwrdegoede/linux-sunxi.git and the linux-devel branch. I don't get any boot output. I can boot a 3.4 kernel without problem. I followed these steps. http://linux-sunxi.org/Mainline_Kernel_Howto I also tried turning on low level printk but still no output U-Boot SPL 2014.04-10675-g44b53fd (May 19 2014 - 20:39:18) Board: Cubietruck DRAM: 2048 MiB CPU: 96000Hz, AXI/AHB/APB: 3/2/2 spl: not an uImage at 1600 U-Boot 2014.04-10675-g44b53fd (May 19 2014 - 20:39:18) Allwinner Technology CPU: Allwinner A20 (SUN7I) Board: Cubietruck I2C: ready DRAM: 2 GiB MMC: SUNXI SD/MMC: 0 In:serial Out: serial Err: serial Net: dwmac.1c5 Hit any key to stop autoboot: 0 sun7i# tftp 0x4900 /var/lib/tftpboot/ct.dtb dwmac.1c5 Waiting for PHY auto negotiation to complete done Speed: 1000, full duplex Using dwmac.1c5 device TFTP from server 192.168.1.50; our IP address is 192.168.1.51 Filename '/var/lib/tftpboot/ct.dtb'. Load address: 0x4900 Loading: ## 7.6 MiB/s done Bytes transferred = 24030 (5dde hex) sun7i# tftp 0x4600 /var/lib/tftpboot/uImage Speed: 1000, full duplex Using dwmac.1c5 device TFTP from server 192.168.1.50; our IP address is 192.168.1.51 Filename '/var/lib/tftpboot/uImage'. Load address: 0x4600 Loading: # # 12.3 MiB/s done Bytes transferred = 1837040 (1c07f0 hex) sun7i# env set fdt_high sun7i# sun7i# bootm 0x4600 - 0x4900 ## Booting kernel from Legacy Image at 4600 ... Image Name: Linux-3.15.0-rc5-80186-gb9505da Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1836976 Bytes = 1.8 MiB Load Address: 40008000 Entry Point: 40008000 Verifying Checksum ... OK ## Flattened Device Tree blob at 4900 Booting using the fdt blob at 0x4900 Loading Kernel Image ... OK Using Device Tree in place at 4900, end 49008ddd Starting kernel ... -- Jon Smirl jonsm...@gmail.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. -- 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.
