[linux-sunxi] Using coreboot to boot from NAND witout boot0/boot1

[mrnuke]

Yes, it is possible. I've made a page on how to do exactly this:
http://linux-sunxi.org/Coreboot

The instructions are probably crap and you won't be able to follow through, 
but please let me know where you get stuck, so I can update the page 
accordingly, but it seems to be possible. I don't have anything on my NAND, so 
I was unable to boot a linux kernel all the way.

Alex

-- 
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] [A10] Getting u-boot onto freshly partitioned Nand for booting Linux

[Neal Peacock]

Answers in line.  Thanks
On Mar 9, 2014 11:34 AM, "hunter hu"  wrote:
>
> Hi Neal,
>
> Thanks for that.
>
> I have no idea about the magic signing value, I have 3 questions and
comments:
>
> 1> If I just use the original nandb.img which was dd out of the nand
itself, will that still be needed?

No but I think you will have to change at least one parameter.  I've got to
find my notes on it..

> 2> if I do create a magic signing value again, how would I do that?

Its in the tools directory of a linux-sunxi u-boot repo.

https://github.com/linux-sunxi/u-boot-sunxi/blob/sunxi/tools/mkenvimage.c

Again I've got some notes somewhere on how to use it.

> 3> would this why my previous lichee-dev u-boot.bin doesn't play well
with boot0/boot1? did I miss any magic value there?

There is a uboot signer in tools as well so maybe.  When booting from band
I stuck with the included Android u-boot.
>
> Thanks,
> -Hunter
>
>
> On Sunday, March 9, 2014 1:25:42 PM UTC-5, npeacock wrote:
>>
>> Hello,
>>
>> Seems like the structure was
>>
>> /dev/nandb < u-boot.env with magic signing value
>> /dev/nandc < the linux kernel, just dd copied on, make sure to clear
with zero in case yours its smaller
>> /dev/nandX < the root partition, which was defined in the u-boot.env, so
you could make it whatever you want, as long as it matches your env file.
If nandj is 5Gb then that is what I would use in my hacky approach.
>>
>> So is that more clear?  You'll need to put your linux kernel in nandc,
your adjusted uboot.env in nandb and your rootfs on a new partition on nandj
>>
>> I'll try to find the actual script and old images tonight.  I was having
a lot of trouble uploading large files and hadn't tried in awhile.
>>
>> Thanks.
>>
>> On 3/9/2014 11:07 AM, hunter hu wrote:
>>>
>>> Hi Neal,
>>>
>>> The link seems broken while I was trying to get the image: wget
http://pengpod.com/dl/images/pengpod1000-linaro-flashcard-2013.03.29.img.tar.gz
>>>
>>> However, I can set things up by following the same logic, but I need to
confirm one change, for nandb, what changes need to be made? I plan to edit
binary image out from my board, there are actually 2 entries for the
environment,
>>>
>>> one setup root=/dev/nandc
>>> the other setup root=/dev/nandd
>>>
>>> according to your notes, we will dd uImage into nandc, so say, if I
will use nandj (which is 5G in size) as the rootfs, should I change the
both nandc and nandd to nandj or just nandd to nandj?
>>>
>>> Thanks,
>>> -Hunter
>>>
>>> On Saturday, March 8, 2014 10:54:28 PM UTC-6, npeacock wrote:

 Here is a link for what I did on the PengPod where we used the
original u-boot from Android.
http://pengpod.com/pengwiki/index.php?title=Install_Linaro_to_the_internal_flash

 The only trick not listed was the u-boot environment had to be signed,
I can't remember the name of the tool but its in the u-boot repo.

 I think the first logo was displayed by boot1, before u-boot runs.


>
>
> Hi Timo,
>
> Thanks for the detailed answer to my questions, really appreciate
that.
>
> I have done the same thing, still I am stuck at the logo screen,
feels like there is something else is missing in my case.
>
> 1> I don't see any serial output from NAND boot, did you see anything
on the serial console if you were using serial output?
> 2> anyone knows if the logo has been displayed, does it imply that
u-boot.bin got loaded at all?
>
> I think in my case, the question is why u-boot.bin built from
sun5i_a13 with the CONFIG_BOOTCOMMAND modification doesn't print any output
at all?  in the common/main.c:
> 205 static inline int abortboot(int bootdelay)


>  206 {
>  207 int abort = 0;
>  208
>  209 #ifdef CONFIG_MENUPROMPT
>  210 printf(CONFIG_MENUPROMPT);
>  211 #else
>  212 printf("Hit any key to stop autoboot: %2d ", bootdelay);
>  213 #endif
>
> would always print "Hit any key to stop autoboot:", even if something
went wrong later? but I saw nothing from console, (UART1 that is I am using
and good with SD boot).
>
> Still baffled, :-(
>
> Regards,
> -Hunter
>
>
>
> On Saturday, March 8, 2014 1:07:44 PM UTC-6, Timo Schmiade wrote:
>>
>> Hi Patrick,
>>
>> > Looks to me like this is loading script.bin and uImage from nanda.
>>
>> thanks for pointing this out, you're of course right! nandb contains
>> my root filesystem, nanda is the boot partition.
>>
>> On Sat, Mar 8, 2014 at 3:24 PM, Patrick Wood 
wrote:
>> >
>> > Looks to me like this is loading script.bin and uImage from nanda.
>> >
>> > --
>> > You received this message because you are subscribed to a topic in
the Google Groups "linux-sunxi" group.
>> > To unsubscribe from this topic, visit
https://groups.google.com/d/topic/linux-sunxi/omgs3skJYDI/unsubscribe.
>> > To unsubscribe from this group and all of its topics, send an
email to 

Re: [linux-sunxi] Re: [PATCH 6/7] regulator: AXP20x: Add support for regulators subsystem

[Mark Brown]

On Tue, Mar 11, 2014 at 10:06:59PM +0100, Carlo Caione wrote:
> On Tue, Mar 11, 2014 at 07:29:40PM +, Mark Brown wrote:

> > With the above code the driver will return an error and never get as far
> > as registering the regulator.

> I agree, but if I register the regulators without having the constrains
> defined in the DT, when regulator_init_complete() is
> called, the regulators are disabled powering off the SoC (at least for
> DCDC2 and DCDC3).

Right, but the kernel will say what it's doing before it does so and
then the user can provide the appropriate setup in DT to force things
on.


signature.asc
Description: Digital signature

Re: [linux-sunxi] Re: [PATCH 6/7] regulator: AXP20x: Add support for regulators subsystem

[Carlo Caione]

On Tue, Mar 11, 2014 at 07:29:40PM +, Mark Brown wrote:
> On Tue, Mar 11, 2014 at 08:24:11PM +0100, Carlo Caione wrote:
> > On Mon, Mar 03, 2014 at 10:56:16AM +0900, Mark Brown wrote:
> 
> > > > +   regulators = of_find_node_by_name(np, "regulators");
> > > > +   if (!regulators) {
> > > > +   dev_err(&pdev->dev, "regulators node not found\n");
> > > > +   return -EINVAL;
> > > > +   }
> 
> > > The driver should be able to start up with no configuration provided at
> > > all except for the device being registered - the user won't be able to
> > > change anything but they will be able to read the current state of the
> > > hardware which can be useful for diagnostics.
> 
> > If the device is DT enabled and no configuration is provided for
> > regulators, these are disabled according to:
> 
> > http://lxr.linux.no/linux+v3.13.5/drivers/regulator/core.c#L3797
> 
> > Am I missing something or do you have any pointer?
> 
> With the above code the driver will return an error and never get as far
> as registering the regulator.

I agree, but if I register the regulators without having the constrains
defined in the DT, when regulator_init_complete() is
called, the regulators are disabled powering off the SoC (at least for
DCDC2 and DCDC3).

Thanks,

-- 
Carlo Caione

-- 
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] dt: How to best handle SPI pingroup declarations

[mrnuke]

I've been wanting to get SPI up and running on the cubie, which now is as 
simple as declaring the relevant nodes in devicetree. The issue here is how 
and where to declare the pingroups.

Take for example the fictional A1l sunli SoC:
SPI0 on sunli has 5 signals, each muxable to one of two pins:

signal | pin A | pin B 
---
CLK|  PB0  |  PF5
MOSI   |  PB1  |  PF6
MISO   |  PB2  |  PF6
CS0|  PB3  |  PF8
CS1|  PB4  |  PF0

One obvious solution would be to declare group_a and group_b. Simple. However, 
some boards may only use one of the CS signals. wens (sorry, I don't know your 
real name) suggested making a group for CLK,MOSI,MISO, one for CS0, and one 
for CS1. The peripheral would reference thegroup with CLK,MOSI,MISO, and one 
of the CS* groups. Considering our muxing options, that's a total of 6 
declarations.

And of course, this doesn't handle the case of boards doing funny things, such 
as using PF5, PB1, PB2, and PF8 for SPI. Such an arrangement is not 
impossible, and ight make sense depending on the arrangements of balls on the 
BGA package.

One other solution would be to declare each pin (clk_a, clk_b, mosi_s, mosi_b, 
etc) as a group, but that would be a crapload of declarations. That's a ton of 
unneeded bloat IMHO.

I think the best solution here is to just declare the pingroups in the board's 
dts, rather than the SoC's dtsi. Would this be acceptable for you guys?

Alex

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

Re: [linux-sunxi] Re: [PATCH 6/7] regulator: AXP20x: Add support for regulators subsystem

[Mark Brown]

On Tue, Mar 11, 2014 at 08:24:11PM +0100, Carlo Caione wrote:
> On Mon, Mar 03, 2014 at 10:56:16AM +0900, Mark Brown wrote:

> > > + regulators = of_find_node_by_name(np, "regulators");
> > > + if (!regulators) {
> > > + dev_err(&pdev->dev, "regulators node not found\n");
> > > + return -EINVAL;
> > > + }

> > The driver should be able to start up with no configuration provided at
> > all except for the device being registered - the user won't be able to
> > change anything but they will be able to read the current state of the
> > hardware which can be useful for diagnostics.

> If the device is DT enabled and no configuration is provided for
> regulators, these are disabled according to:

> http://lxr.linux.no/linux+v3.13.5/drivers/regulator/core.c#L3797

> Am I missing something or do you have any pointer?

With the above code the driver will return an error and never get as far
as registering the regulator.


signature.asc
Description: Digital signature

Re: [linux-sunxi] Re: [PATCH 6/7] regulator: AXP20x: Add support for regulators subsystem

[Carlo Caione]

On Mon, Mar 03, 2014 at 10:56:16AM +0900, Mark Brown wrote:


 
> > +   np = of_node_get(pdev->dev.parent->of_node);
> > +   if (!np)
> > +   return 0;
> > +
> > +   regulators = of_find_node_by_name(np, "regulators");
> > +   if (!regulators) {
> > +   dev_err(&pdev->dev, "regulators node not found\n");
> > +   return -EINVAL;
> > +   }
> 
> The driver should be able to start up with no configuration provided at
> all except for the device being registered - the user won't be able to
> change anything but they will be able to read the current state of the
> hardware which can be useful for diagnostics.

If the device is DT enabled and no configuration is provided for
regulators, these are disabled according to:

http://lxr.linux.no/linux+v3.13.5/drivers/regulator/core.c#L3797

Am I missing something or do you have any pointer?

Thanks,

-- 
Carlo Caione

-- 
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 PATCH v2 04/14] mtd: nand: define struct nand_timings

[Jason Gunthorpe]

On Mon, Mar 10, 2014 at 02:44:04PM +0100, Boris BREZILLON wrote:

> Some timings are missing here (see Table 55 in the ONFI spec):

Right..

The 'mode' covers only the raw electrical parameters needed to
exchange commands, other timings cover the commands
themselves. Notably the timing mode does not alter those parameters.

To me it seems tidy to keep the 'mode' timings contained in their own
struct and find other homes for the other parameters.

> -tR
> -tBERS
> -tCCS
> -tPLEBSY
> -...
> 
> I see at least 3 of those timings that could be useful (for the moment) :
> - tR: this one should be used to fill the chip_delay field
> - tPROG and tBERS: could be used within nand_wait to choose the timeo
>   value appropriately.

IIRC these timing values are really only necessary if the controller
does not support the READY/BUSY input, in that case drivers typically
seem to use 'chip_delay' which is the maximum possible command
execution time (a sleep long enough to guarentee that READY/BUSY is
de-asserted).

> Or should I create a new struct for these timings ?
> In the latter case how should I name it ?

struct onfi_command_timings ?

Regards,
Jason

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

Re: [linux-sunxi] Re: [RFC PATCH v2 08/14] mtd: nand: add sunxi NAND flash controller support

[Jason Gunthorpe]

On Mon, Mar 10, 2014 at 12:17:31PM +0100, Boris BREZILLON wrote:
> Hello Jason,
> 
> Le 29/01/2014 20:10, Jason Gunthorpe a écrit :
> >On Wed, Jan 29, 2014 at 03:46:20PM -0300, Ezequiel Garcia wrote:
> >
> >>After CE# has been pulled high and then transitioned low again, the host
> >>should issue a Set Features to select the appropriate asynchronous timing 
> >>mode.
> >>"""
> >Oh, I had forgot you should do a set feature too
> >
> >Boris, I think the core core should handle this dance and the driver
> >should just implement a call back to change the timing mode on the
> >interface..
> >
> >If I ever get a moment I can work on support for timing setting in the
> >mvebu driver, I have boards here with ONFI NAND..
> 
> Any progress on this ?
> I'm about to post the 3rd version of this series and if you already have
> something working I could base my work on your proposal.

Sorry, no, I will try to look over your v3 though.

Regards,
Jason

-- 
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: Stk1160 driver

[André Kerber]

Ok I thought that I do not have to dive into building kernel modules using a 
ubuntu port un the cubieboard...

I have about 25MB/sec from USB port to sd card and about 30MB/sec to SATA and 
successfully captured stk1160 video including audio today using the easycap 
driver. The problem is that only the first 2 secs have >20 frames/sec, after 
that it is about 3-5 frames/sec and it says video frame buffer full. I will try 
it with an sata medium, perhaps it is the sd-card slot which is the bottleneck. 

thanks for the tips with the kernel modules!


Am 11.03.2014 um 15:52 schrieb Ezequiel Garcia 
:

> On Mar 11, Emilio López wrote:
 Do you have any idea? I definitely have a build in the modules directory...
>> 
>> You most likely have a broken symlink there. You (or someone else) probably
>> cross-built the kernel but didn't install the kernel headers there. You
>> should install them to build stk1160 on the cubieboard2 (or cross build
>> stk1160 as well).
>> 
> 
> Yeah, I suggest that you ask on kernelnewbies or somewhere else
> for instructions on how to build a kernel module.
> 
>>> Emilio? Hans? Do you think the USB on the cubieboard2 can transfer
>>> uncompressed (raw) video?
>>> stk1160 needs as much as 20 MiB/sec. on isoc URBs and so far I haven't
>>> seen many embedded systems
>>> possible of that throughput...
>> 
>> Should be ok I suppose; with a USB hard drive I get these unscientific
>> results:
>> 
> 
> USB hard drives most likely use block URBs, so those number are probably
> not of importance. On the other side, maybe you have a USB web camera that
> sends raw video. That would be a better test.
> 
> André:
> I really suggest that you confirm that you can get that much ISOC bandwidth
> from your USB before wasting your time. You would be one of the first one
> to report a successful stk1160 capture on this kind of devices.
> -- 
> Ezequiel García, 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.

Re: [U-Boot] Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)

[Tom Rini]

On Tue, Mar 11, 2014 at 03:21:54PM +, Ian Campbell wrote:
> On Tue, 2014-03-11 at 09:48 -0400, Tom Rini wrote:
> > On Tue, Mar 11, 2014 at 10:38:05AM +, Ian Campbell wrote:
> > > But what is the reason for the default behaviour of bootz doing things
> > > which do not conform to linux/Documentation/arm/Booting and therefore is
> > > not going to boot?
> > 
> > Because U-Boot is more than just ARM, and ARM boards not enforcing /
> > getting the correct behavour via fdt_high / initrd_high or bootm_low /
> > bootm_mapsize / bootm_size / CONFIG_SYS_BOOTMAPSZ.
> 
> So you consider this to be a board level problem, rather than an arch
> level one? (IOW we can't just fix this for all arm boards at once)

I'm not 100% sure.  An issue is that lowmem isn't always 512MB, it may
be 768MB.  That also may not really matter for this, I'm not sure.  But
part of the problem is that AFAICS no one provides a 100% correct
example today.  With some testing around now, for TI platforms (DDR
starts at 0x8000 it would be:
/*
 * We setup defaults based on constraints from the Linux kernel, which
 * should also be safe elsewhere.  We have the default load at 32MB into
 * DDR (for the kernel), FDT above 128MB (the maximum location for the
 * end of the kernel), and the ramdisk 512KB above that (allowing for
 * hopefully never seen large trees).  We say all of this must be within
 * the first 512MB as that will always be within the kernel lowmem and
 * thus visible via bootm_size.
 */
#define CONFIG_EXTRA_ENV_SETTINGS \
-   "loadaddr=0x8020\0" \
-   "fdtaddr=0x80F8\0" \
-   "fdt_high=0x\0" \
+   "loadaddr=0x8200\0" \
+   "fdtaddr=0x8800\0" \
+   "rdaddr=0x8808\0" \
+   "bootm_size=0x2000\0" \

All of that said, I could be convinced that we could try and make
common/image.c::getenv_bootm_size() smarter about defaults but we need
to take a lot of care there, and allow people to opt-out as that's
common code and how much lowmem we have is configurable a lot.

> [...]
> > > Should the global default be changed to either 0x (no
> > > relocation) or to start-of-ram+256MB (which should satisfy the kernels
> > > requirements without needing logic changes to handle "just after the
> > > 128MB boundary" as a concept).
> > > 
> > > Or is it intended that each board should opt-in to a sensible default
> > > via their default environment?
> > > 
> > > Does bootm suffer the same? I suspect it does, at least for fdt (since
> > > initrd has a load addr in the u-boot header).
> > 
> > SoCs should set a sane and correct set of values, using either of the
> > available mechanisms.  I think Tegra gets this all correct via
> > CONFIG_SYS_BOOTMAPSZ and I've been meaning to whack the various TI parts
> > as part of the generic distro work.
> 
> I took a look at BOOTMAPSZ on sunxi and it is using (16 << 20) which
> seems sensible, if a bit small, so perhaps something else is going
> wrong.
> 
> Tegra uses 256MB, might be worth giving that a go I guess.

Doing some playing around, BOOTMAPSZ isn't a complete solution, you need
bootm_low also set.  In fact, I found the best results with just doing
botom_low but there may be cases where you also want BOOTMAPSZ.

> > And keep in mind that when we set fdt/initrd_high to a non-0x
> > value we're setting a maximum that's still checked vs how much we have,
> > so setting base+512MB is probably a best default for cases where we may
> > run on boards with varying amounts of DDR.
> 
> I'm not sure I follow -- why is +512MB best?

I'm a fan of setting things to the maximum allowed, to allow for future
growth.  This would also allow for pretty giant ramdisks to be passed
which is unlikely but not impossible (I need to debug X and I can't use
nfs/sd/etc for root, let me assemble a big ramdisk with everything I
need).  Getting back to why this would be left up to the SoC/board
level, if for some reason there's a reason to not go up quite that high,
they can tweak it.

-- 
Tom


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH v5 6/8] ARM: dts: sun4i: Add support for mmc

[David Lanzendörfer]

Hi
> Oh, good catch, thanks! Fixed in the sunxi-devel branch
> in my *personal* git repo. I'll also push this to the official linux-sunxi
> sunxi-devel branch later today.
Fixed it for the next patch set as well.

-david

signature.asc
Description: This is a digitally signed message part.

[linux-sunxi] [PATCH] irqchip: sun4i: Fix acomment about mask register initialization

[Hans de Goede]

The comment was claiming that we were masking all irqs, while the code actually
*un*masks all of them.

Signed-off-by: Hans de Goede 
---
 drivers/irqchip/irq-sun4i.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index 3761bf1..749a355 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -109,7 +109,7 @@ static int __init sun4i_of_init(struct device_node *node,
writel(0, sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(1));
writel(0, sun4i_irq_base + SUN4I_IRQ_ENABLE_REG(2));
 
-   /* Mask all the interrupts */
+   /* Unmask all the interrupts, ENABLE_REG(x) is used for masking */
writel(0, sun4i_irq_base + SUN4I_IRQ_MASK_REG(0));
writel(0, sun4i_irq_base + SUN4I_IRQ_MASK_REG(1));
writel(0, sun4i_irq_base + SUN4I_IRQ_MASK_REG(2));
-- 
1.9.0

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

Re: [linux-sunxi] [PATCH] ARM: sun4i: dt: Add AXP209 support to the cubieboard

[Hans de Goede]

Hi,

Thanks for working on this, I've had this on my todo list myself.

Unfortunately is is not this easy.
On 03/11/2014 01:22 AM, mrnuke wrote:
> Signed-off-by: Alexandru Gagniuc 
> ---
>  arch/arm/boot/dts/sun4i-a10-cubieboard.dts | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts 
> b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> index 13088f0..7d8f889 100644
> --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
> @@ -88,6 +88,16 @@
> pinctrl-names = "default";
> pinctrl-0 = <&i2c0_pins_a>;
> status = "okay";
> +
> +   axp: axp20x@34 {
> +   reg = <0x34>;
> +   interrupt-parent = <&intc>;

This is not necessary, intc is the default parent

> +   interrupts = <0 8>;

This is wrong, sun4i interrupts take only one specifier.

> +
> +   axp,system-power-controller;
> +
> +   /include/ "x-powers-axp209.dtsi"
> +   };
> };
>  
> i2c1: i2c@01c2b000 {
> 

Moreover this does not work at all, because the sun4i irqchip has a bug
causing a hard hang as soon as you enable interrupt 0 and then trigger
it by pushing the power button.

Good news: I've just finished debugging this and it is working in
my personal repo's sunxi-devel branch now.

Regards,

Hans

-- 
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 v5 6/8] ARM: dts: sun4i: Add support for mmc

[Hans de Goede]

Hi,

Oh, good catch, thanks! Fixed in the sunxi-devel branch
in my *personal* git repo. I'll also push this to the official linux-sunxi
sunxi-devel branch later today.

Regards,

Hans



On 03/10/2014 10:49 PM, mr.nuke...@gmail.com wrote:
> On Tuesday, February 11, 2014 1:34:25 PM UTC-6, David Lanzendörfer wrote:
>> diff --git a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
>> b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
>> index b139ee6..20b976a 100644
>> --- a/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
>> +++ b/arch/arm/boot/dts/sun4i-a10-cubieboard.dts
>> @@ -33,6 +33,14 @@
>>  };
>>  
>>  };
>> +mmc0: mmc@01c0f000 {
>> +pinctrl-names = "default", "default";
>> +pinctrl-0 = <&mmc0_pins_a>;
>> +pinctrl-1 = <&mmc0_cd_pin_reference_design>;
>> +cd-gpios = <&pio 7 1 0>; /* PH1 */
>> +status = "okay";
>> +};
>> +
>>  pinctrl@01c20800 {
>>  
>>  led_pins_cubieboard: led_pins@0 {
>>  
>>  allwinner,pins = "PH20", "PH21";
>> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi
>> b/arch/arm/boot/dts/sun4i-a10.dtsi
>> index 9044c53..d040d37 100644
>> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
>> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
>> @@ -330,6 +330,46 @@
>>  #size-cells = <0>;
>>  
>>  };
>> +mmc0: mmc@01c0f000 {
>> +compatible = "allwinner,sun5i-a13-mmc";
> 
> Should be "allwinner,sun4i-a10-mmc", or we will hang the MMC driver on A10.
> 
>> +mmc1: mmc@01c1 {
>> +compatible = "allwinner,sun5i-a13-mmc";
> ditto
> 
>> +mmc2: mmc@01c11000 {
>> +compatible = "allwinner,sun5i-a13-mmc";
> ditto
> 
>> +mmc3: mmc@01c12000 {
>> +compatible = "allwinner,sun5i-a13-mmc";
> ditto
> 

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

[linux-sunxi] [PATCH] irqchip: sun4i: Fix irq 0 not working

[Hans de Goede]

SUN4I_IRQ_VECTOR_REG containing 0 can mean one of 2 things:
1) irq 0 pending
2) no more irqs pending

So we must loop always atleast once to make irq 0 work, otherwise irq 0
will never get serviced and we end up with a hard hang because
sun4i_handle_irq gets re-entered constantly.

Signed-off-by: Hans de Goede 
---
 drivers/irqchip/irq-sun4i.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-sun4i.c b/drivers/irqchip/irq-sun4i.c
index a5438d8..3761bf1 100644
--- a/drivers/irqchip/irq-sun4i.c
+++ b/drivers/irqchip/irq-sun4i.c
@@ -140,10 +140,16 @@ static asmlinkage void __exception_irq_entry 
sun4i_handle_irq(struct pt_regs *re
 {
u32 irq, hwirq;
 
+   /*
+* hwirq == 0 can mean one of 2 things:
+* 1) irq 0 pending
+* 2) no more irqs pending
+* So loop always atleast once to make irq 0 work.
+*/
hwirq = readl(sun4i_irq_base + SUN4I_IRQ_VECTOR_REG) >> 2;
-   while (hwirq != 0) {
+   do {
irq = irq_find_mapping(sun4i_irq_domain, hwirq);
handle_IRQ(irq, regs);
hwirq = readl(sun4i_irq_base + SUN4I_IRQ_VECTOR_REG) >> 2;
-   }
+   } while (hwirq != 0);
 }
-- 
1.9.0

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

Re: [U-Boot] Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)

[Ian Campbell]

On Tue, 2014-03-11 at 09:48 -0400, Tom Rini wrote:
> On Tue, Mar 11, 2014 at 10:38:05AM +, Ian Campbell wrote:
> > But what is the reason for the default behaviour of bootz doing things
> > which do not conform to linux/Documentation/arm/Booting and therefore is
> > not going to boot?
> 
> Because U-Boot is more than just ARM, and ARM boards not enforcing /
> getting the correct behavour via fdt_high / initrd_high or bootm_low /
> bootm_mapsize / bootm_size / CONFIG_SYS_BOOTMAPSZ.

So you consider this to be a board level problem, rather than an arch
level one? (IOW we can't just fix this for all arm boards at once)

[...]
> > Should the global default be changed to either 0x (no
> > relocation) or to start-of-ram+256MB (which should satisfy the kernels
> > requirements without needing logic changes to handle "just after the
> > 128MB boundary" as a concept).
> > 
> > Or is it intended that each board should opt-in to a sensible default
> > via their default environment?
> > 
> > Does bootm suffer the same? I suspect it does, at least for fdt (since
> > initrd has a load addr in the u-boot header).
> 
> SoCs should set a sane and correct set of values, using either of the
> available mechanisms.  I think Tegra gets this all correct via
> CONFIG_SYS_BOOTMAPSZ and I've been meaning to whack the various TI parts
> as part of the generic distro work.

I took a look at BOOTMAPSZ on sunxi and it is using (16 << 20) which
seems sensible, if a bit small, so perhaps something else is going
wrong.

Tegra uses 256MB, might be worth giving that a go I guess.

> And keep in mind that when we set fdt/initrd_high to a non-0x
> value we're setting a maximum that's still checked vs how much we have,
> so setting base+512MB is probably a best default for cases where we may
> run on boards with varying amounts of DDR.

I'm not sure I follow -- why is +512MB best?

Thanks,
Ian.

-- 
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] A31 pmic (axp221) support

[Hans de Goede]

Hi,

On 03/11/2014 01:15 PM, Olliver Schinagl wrote:
> On 03/10/14 22:31, Hans de Goede wrote:
>> Hi,
>>
>> On 03/10/2014 05:04 PM, Olliver Schinagl wrote:
>>> Hey Hans,
>>>
>>> I played with the a31 stuff in u-boot a while ago. Lacking hardware, there 
>>> was little I was able to do, but check out this patch that might (or not at 
>>> all) work/give an idea for the p2wi and pmic stuff.
>>>
>>> https://github.com/oliv3r/u-boot-sunxi/commit/52b8454fb8951e95da76b3d9ba82461adab5ee7f
>>>
>>> https://github.com/oliv3r/u-boot-sunxi/commit/d0c02cdba51a9e8434993b10c91e7bf0378864dd
>>
>> Cool, thanks for working on this! So you've a comment in there that the clk 
>> setup is
>> not done there, is it already done somewhere else, or is it simply missing at
>> this point ?
> I have to ask for a refresher of my memory, where exactly did you spot this?

In the commit msg of:
https://github.com/oliv3r/u-boot-sunxi/commit/52b8454fb8951e95da76b3d9ba82461adab5ee7f

Regards,

Hans

-- 
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] About decoding latency on A10 chip

[Olliver Schinagl]

On 03/11/14 15:33, lhavc2...@gmail.com wrote:

Hello everyone, I am developing a video streaming application that using A10 
board for live scenario, everything runs well but I found that there are 3 
frames delay on decoding phase. Seems there's no option for low-latency 
decoding in linux-armhf build of cedarv library, but the other one, armhf2, 
requires sunxi-mem interface that isn't implemented on A10's kernel. Is anyone 
else experiencing problem on this solution?  Thanks very much.

You speak of the binary blob, to which a prompt reply follows. Not 
supported here, ask Allwinner for support.


That said, you could always try the RE effort, 
http://linux-sunxi.org/Cederus


Olliver

--
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: Stk1160 driver

[Ezequiel Garcia]

On Mar 11, Emilio López wrote:
> >>Do you have any idea? I definitely have a build in the modules directory...
> 
> You most likely have a broken symlink there. You (or someone else) probably
> cross-built the kernel but didn't install the kernel headers there. You
> should install them to build stk1160 on the cubieboard2 (or cross build
> stk1160 as well).
> 

Yeah, I suggest that you ask on kernelnewbies or somewhere else
for instructions on how to build a kernel module.

> >Emilio? Hans? Do you think the USB on the cubieboard2 can transfer
> >uncompressed (raw) video?
> >stk1160 needs as much as 20 MiB/sec. on isoc URBs and so far I haven't
> >seen many embedded systems
> >possible of that throughput...
> 
> Should be ok I suppose; with a USB hard drive I get these unscientific
> results:
> 

USB hard drives most likely use block URBs, so those number are probably
not of importance. On the other side, maybe you have a USB web camera that
sends raw video. That would be a better test.

André:
I really suggest that you confirm that you can get that much ISOC bandwidth
from your USB before wasting your time. You would be one of the first one
to report a successful stk1160 capture on this kind of devices.
-- 
Ezequiel García, 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] About decoding latency on A10 chip

[lhavc2010]

Hello everyone, I am developing a video streaming application that using A10 
board for live scenario, everything runs well but I found that there are 3 
frames delay on decoding phase. Seems there's no option for low-latency 
decoding in linux-armhf build of cedarv library, but the other one, armhf2, 
requires sunxi-mem interface that isn't implemented on A10's kernel. Is anyone 
else experiencing problem on this solution?  Thanks very much.

-- 
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: Stk1160 driver

[Emilio López]

Hi there,

El 11/03/14 00:40, Ezequiel Garcia escribió:

André,

I'm leaving the question intact for context, and adding some folks.

On Mon, Mar 10, 2014 at 8:55 PM, André Kerber  wrote:


I am sorry to disturb you because of the old stk1160 driver, but I am very 
stuck and did not find any answer googling for more than 2 hours...

If you could give me a tip I would be very glad!  I am trying to use your 
driver on a cubieboard2 with ubuntu 12.04. If I try sudo make I always get the 
following error:

/lib/modules/3.4.79-sun7i+/build: No such file or directory.



You're probably using the backported driver, uh? Any chance you use a
newer kernel (> v3.7) ?


Probably not if you want a functional system :)


Do you have any idea? I definitely have a build in the modules directory...


You most likely have a broken symlink there. You (or someone else) 
probably cross-built the kernel but didn't install the kernel headers 
there. You should install them to build stk1160 on the cubieboard2 (or 
cross build stk1160 as well).



Emilio? Hans? Do you think the USB on the cubieboard2 can transfer
uncompressed (raw) video?
stk1160 needs as much as 20 MiB/sec. on isoc URBs and so far I haven't
seen many embedded systems
possible of that throughput...


Should be ok I suppose; with a USB hard drive I get these unscientific 
results:


emilio@mele:~$ echo 3|sudo tee /proc/sys/vm/drop_caches
3
emilio@mele:~$ LANG=C sudo -E dd if=/dev/sda of=/dev/null bs=4M count=200
200+0 records in
200+0 records out
838860800 bytes (839 MB) copied, 26.8201 s, 31.3 MB/s

(That's on a Host port; the OTG port is musb and would probably get 
around half that performance from what I've heard).


Cheers,

Emilio

--
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: [U-Boot] Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)

[Tom Rini]

On Tue, Mar 11, 2014 at 10:38:05AM +, Ian Campbell wrote:
> Adding u-boot list since I think this is a general issue/question.
> 
> On Sun, 2014-03-09 at 20:00 +0100, Olliver Schinagl wrote:
> > On 03/09/14 16:18, tyler.ba...@linaro.org wrote:
> > > On Sunday, March 9, 2014 8:06:27 AM UTC-7, tyler...@linaro.org wrote:
> > >> Hello,
> > >>
> > >> I am trying to boot the cubietruck with a minimal ramdisk. However, it
> > >> seems to hang at "Starting kernel..." whenever I pass bootz a
> > >> ramdisk load address.
> [...]
> > > Turl help me solve this in IRC. Needed to setenv initrd_high 
> > > '0x' in case anyone else runs into this.
> 
> > The http://linux-sunxi.org/Mainline_Kernel_Howto did mention this ;) but 
> > thanks for helping remind people!
> 
> Actually it mentions fdt_high but not initrd_high.
> 
> But what is the reason for the default behaviour of bootz doing things
> which do not conform to linux/Documentation/arm/Booting and therefore is
> not going to boot?

Because U-Boot is more than just ARM, and ARM boards not enforcing /
getting the correct behavour via fdt_high / initrd_high or bootm_low /
bootm_mapsize / bootm_size / CONFIG_SYS_BOOTMAPSZ.

> The docs recommend that DTB and initrd go just after the 128MB boundary.
> If either are loaded "too high" then the kernel will crash on boot,
> often in a tricky to diagnose way (I've chased it down more than once).
> It's especially annoying when one has carefully loaded everything at a
> suitable address in the first place ;-)

I have as well, sadly.

> Should the global default be changed to either 0x (no
> relocation) or to start-of-ram+256MB (which should satisfy the kernels
> requirements without needing logic changes to handle "just after the
> 128MB boundary" as a concept).
> 
> Or is it intended that each board should opt-in to a sensible default
> via their default environment?
> 
> Does bootm suffer the same? I suspect it does, at least for fdt (since
> initrd has a load addr in the u-boot header).

SoCs should set a sane and correct set of values, using either of the
available mechanisms.  I think Tegra gets this all correct via
CONFIG_SYS_BOOTMAPSZ and I've been meaning to whack the various TI parts
as part of the generic distro work.

And keep in mind that when we set fdt/initrd_high to a non-0x
value we're setting a maximum that's still checked vs how much we have,
so setting base+512MB is probably a best default for cases where we may
run on boards with varying amounts of DDR.

-- 
Tom


signature.asc
Description: Digital signature

Re: Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)

[Olliver Schinagl]

On 03/11/14 11:38, Ian Campbell wrote:

Adding u-boot list since I think this is a general issue/question.

On Sun, 2014-03-09 at 20:00 +0100, Olliver Schinagl wrote:

On 03/09/14 16:18, tyler.ba...@linaro.org wrote:

On Sunday, March 9, 2014 8:06:27 AM UTC-7, tyler...@linaro.org wrote:

Hello,

I am trying to boot the cubietruck with a minimal ramdisk. However, it
seems to hang at "Starting kernel..." whenever I pass bootz a
ramdisk load address.

[...]

Turl help me solve this in IRC. Needed to setenv initrd_high
'0x' in case anyone else runs into this.



The http://linux-sunxi.org/Mainline_Kernel_Howto did mention this ;) but
thanks for helping remind people!


Actually it mentions fdt_high but not initrd_high.

That is new to me ;)

I think it was discussed in depth as to why and what, but I forgot 
everything about it :p (been 5 or 6 months!)


http://irclog.whitequark.org/linux-sunxi/search?q=fdt_high

Should give a reasonable overview, only 20 or so entries for 2013 + 2014.

Olliver


But what is the reason for the default behaviour of bootz doing things
which do not conform to linux/Documentation/arm/Booting and therefore is
not going to boot?

The docs recommend that DTB and initrd go just after the 128MB boundary.
If either are loaded "too high" then the kernel will crash on boot,
often in a tricky to diagnose way (I've chased it down more than once).
It's especially annoying when one has carefully loaded everything at a
suitable address in the first place ;-)

Should the global default be changed to either 0x (no
relocation) or to start-of-ram+256MB (which should satisfy the kernels
requirements without needing logic changes to handle "just after the
128MB boundary" as a concept).

Or is it intended that each board should opt-in to a sensible default
via their default environment?

Does bootm suffer the same? I suspect it does, at least for fdt (since
initrd has a load addr in the u-boot header).

Ian.



--
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] A31 pmic (axp221) support

[Olliver Schinagl]

On 03/10/14 22:31, Hans de Goede wrote:

Hi,

On 03/10/2014 05:04 PM, Olliver Schinagl wrote:

Hey Hans,

I played with the a31 stuff in u-boot a while ago. Lacking hardware, there was 
little I was able to do, but check out this patch that might (or not at all) 
work/give an idea for the p2wi and pmic stuff.

https://github.com/oliv3r/u-boot-sunxi/commit/52b8454fb8951e95da76b3d9ba82461adab5ee7f

https://github.com/oliv3r/u-boot-sunxi/commit/d0c02cdba51a9e8434993b10c91e7bf0378864dd


Cool, thanks for working on this! So you've a comment in there that the clk 
setup is
not done there, is it already done somewhere else, or is it simply missing at
this point ?

I have to ask for a refresher of my memory, where exactly did you spot this?

From my weak memory, I recall this being setup elsewhere. u-boot is a 
little messy for sunxi and I think all clocks where setup somewhere. Or 
I did it, but I forgot ;)


olliver


Regards,

Hans



--
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] How is the kernel mainlining process?

[Olliver Schinagl]

On 03/11/14 11:19, Draplater wrote:

Have mmc support  been add yet?

SDIO Driver (WiP: Hans De Goede, David Lanzendörfer)

WiP -> Work in Progress.

I belive in the devel branches it works.


On Monday, March 10, 2014 9:48:28 PM UTC+8, Olliver Schinagl wrote:

On 03/06/14 05:59, Draplater wrote:
 > Website linux-sunxi writes:
 > "The upstream code does not support NAND, MMC or SATA, you can
only boot
 > off a USB harddisk." (from
http://linux-sunxi.org/Mainline_Kernel_Howto
)
 > Is there any changes? Is the mainline kernel still that unusable
now?
 >
That page is likly old and outdated. Sata support has been added, USB
support has been added around the same time, so that USB harddisk was
possible wasn't even true back then.

http://linux-sunxi.org/Mainlining_Effort


This is the latest and most up to date (kept) status.



--
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 u-boot] cmd_gpio: fix warning with GPIO_OSCILLATE

[Olliver Schinagl]

On 03/11/14 09:38, Ian Campbell wrote:

On Sun, 2014-03-09 at 20:10 +0100, Olliver Schinagl wrote:

Ian,

sorry for not replying earlier, but isn't that a bug-fix against the
generic U-Boot? In that case, it's probably wise to post it on the
u-boot mailing list :)


As Henrik says it's actually sunxi functionality.

This particular fix is already in the sunxi tree I think.
Yeah I read that mail a little later (my fault for having an e-mail 
backlog).


Sorry for the noise Ian!

Ollier


Ian.



--
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: A31 pmic (axp221) support

[Hans de Goede]

Hi,

On 03/11/2014 11:44 AM, Maxime Ripard wrote:
> Hi Hans,
> 
> (you should really fix your mailer, it has the bad habit of screwing
> the wrapping)

Yeah that is caused by enigmail, sorry about that it should be fixed now

> On Tue, Mar 11, 2014 at 11:16:16AM +0100, Hans de Goede wrote:
>>> There's still some subtleties I don't get yet, but the more I
>>> think about this, the more I feel like we'll have to write our own
>>> bus :(
>>
>> So on the bus things are different then with i2c, that does not mean
>> we cannot still pretend it is i2c to upper layers in the kernel.
> 
> The fact that it's not having any ACK, nor any address is kind of a
> show stopper. For all we now, we could just as much pretend it's SPI :)

According to:
https://github.com/oliv3r/u-boot-sunxi/commit/52b8454fb8951e95da76b3d9ba82461adab5ee7f

It does have a device address, and if I read your previous mail
correct, there is an ack.

>> I still believe we should try to make this some kind of pseudo i2c
>> controller and not do a new bus for this. If you look at the axp209
>> code intended for upstream then it uses a lot of i2c infra, not just
>> the bus stuff, but also things like devm_regmap_init_i2c, so if we
>> do our own bus we would need to write out own regamp glue for that
>> bus too.
> 
> Regmap isn't mandatory. At all. We can do perfectly fine without it.

True, but it is quite useful.

> 
> Plus, a lot of devices can actually be plugged onto several different
> buses, and have driver that add a small layer to access registers
> depending on which bus they're loaded from.
> 
> We could very well imagine having to use regmap for the i2c part, and
> p2wi bus calls for the A31's case.

This actually sounds like something which using a regmap would make
easier to do.


> 
>> And if we try and fail we can always define our own bus for this
>> later.
> 
> You can still ask the i2c maintainer, but I'm afraid I know his
> answer.

As said before I think we first need to learn more about how this
bus works before we can make a call one way or the other.

Regards,

Hans

-- 
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: Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)

[Priit Laes]

Ühel kenal päeval, T, 11.03.2014 kell 10:38, kirjutas Ian Campbell:
> Adding u-boot list since I think this is a general issue/question.
> 
> On Sun, 2014-03-09 at 20:00 +0100, Olliver Schinagl wrote:
> > On 03/09/14 16:18, tyler.ba...@linaro.org wrote:
> > > On Sunday, March 9, 2014 8:06:27 AM UTC-7, tyler...@linaro.org wrote:
> > >> Hello,
> > >>
> > >> I am trying to boot the cubietruck with a minimal ramdisk. However, it
> > >> seems to hang at "Starting kernel..." whenever I pass bootz a
> > >> ramdisk load address.
> [...]
> > > Turl help me solve this in IRC. Needed to setenv initrd_high 
> > > '0x' in case anyone else runs into this.
> 
> > The http://linux-sunxi.org/Mainline_Kernel_Howto did mention this ;) but 
> > thanks for helping remind people!
> 
> Actually it mentions fdt_high but not initrd_high.

Please document it there.

Päikest,
Priit Laes

-- 
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: A31 pmic (axp221) support

[Maxime Ripard]

Hi Hans,

(you should really fix your mailer, it has the bad habit of screwing
the wrapping)

On Tue, Mar 11, 2014 at 11:16:16AM +0100, Hans de Goede wrote:
> > There's still some subtleties I don't get yet, but the more I
> > think about this, the more I feel like we'll have to write our own
> > bus :(
> 
> So on the bus things are different then with i2c, that does not mean
> we cannot still pretend it is i2c to upper layers in the kernel.

The fact that it's not having any ACK, nor any address is kind of a
show stopper. For all we now, we could just as much pretend it's SPI :)

> I still believe we should try to make this some kind of pseudo i2c
> controller and not do a new bus for this. If you look at the axp209
> code intended for upstream then it uses a lot of i2c infra, not just
> the bus stuff, but also things like devm_regmap_init_i2c, so if we
> do our own bus we would need to write out own regamp glue for that
> bus too.

Regmap isn't mandatory. At all. We can do perfectly fine without it.

Plus, a lot of devices can actually be plugged onto several different
buses, and have driver that add a small layer to access registers
depending on which bus they're loaded from.

We could very well imagine having to use regmap for the i2c part, and
p2wi bus calls for the A31's case.

> And if we try and fail we can always define our own bus for this
> later.

You can still ask the i2c maintainer, but I'm afraid I know his
answer.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Default initrd and fdt load behaviour on ARM (Was: Re: [linux-sunxi] Re: Not able to boot ramdisk on cubietruck)

[Ian Campbell]

Adding u-boot list since I think this is a general issue/question.

On Sun, 2014-03-09 at 20:00 +0100, Olliver Schinagl wrote:
> On 03/09/14 16:18, tyler.ba...@linaro.org wrote:
> > On Sunday, March 9, 2014 8:06:27 AM UTC-7, tyler...@linaro.org wrote:
> >> Hello,
> >>
> >> I am trying to boot the cubietruck with a minimal ramdisk. However, it
> >> seems to hang at "Starting kernel..." whenever I pass bootz a
> >> ramdisk load address.
[...]
> > Turl help me solve this in IRC. Needed to setenv initrd_high 
> > '0x' in case anyone else runs into this.

> The http://linux-sunxi.org/Mainline_Kernel_Howto did mention this ;) but 
> thanks for helping remind people!

Actually it mentions fdt_high but not initrd_high.

But what is the reason for the default behaviour of bootz doing things
which do not conform to linux/Documentation/arm/Booting and therefore is
not going to boot?

The docs recommend that DTB and initrd go just after the 128MB boundary.
If either are loaded "too high" then the kernel will crash on boot,
often in a tricky to diagnose way (I've chased it down more than once).
It's especially annoying when one has carefully loaded everything at a
suitable address in the first place ;-)

Should the global default be changed to either 0x (no
relocation) or to start-of-ram+256MB (which should satisfy the kernels
requirements without needing logic changes to handle "just after the
128MB boundary" as a concept).

Or is it intended that each board should opt-in to a sensible default
via their default environment?

Does bootm suffer the same? I suspect it does, at least for fdt (since
initrd has a load addr in the u-boot header).

Ian.

-- 
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 v4 6/7] DMA: sun6i: Add driver for the Allwinner A31 DMA controller

[Shevchenko, Andriy]

On Tue, 2014-03-11 at 11:08 +0100, Maxime Ripard wrote:

[]

> > > + spin_lock_irq(&sdev->lock);
> > > + for (pchan_idx = 0; pchan_idx < NR_MAX_CHANNELS; pchan_idx++) {
> > > + pchan = &sdev->pchans[pchan_idx];
> > > +
> > > + if (pchan->vchan == NULL && !list_empty(&sdev->pending)) {
> > 
> > !pchan->vchan && ...
> 
> Ok.
> 
> > And you may decrease indentation level here if you use negative
> > condition.
> 
> Hmmm, I'm not following you here. What do you mean?

for () {
...
if (!(your current condition))
 continue;
... (do something else with decreased indentation level)
}

> > > + vchan = list_first_entry(&sdev->pending,
> > > +  struct sun6i_vchan, node);
> > > +
> > > + /* Remove from pending channels */
> > > + list_del_init(&vchan->node);
> > > + pchan_alloc |= BIT(pchan_idx);
> > > +
> > > + /* Mark this channel allocated */
> > > + pchan->vchan = vchan;
> > > + vchan->phy = pchan;
> > > + dev_dbg(sdev->slave.dev, "pchan %u: alloc vchan %p\n",
> > > + pchan->idx, &vchan->vc);
> > > + }
> > > + }
> > > + spin_unlock_irq(&sdev->lock);
> > > +
> > > + for (pchan_idx = 0; pchan_idx < NR_MAX_CHANNELS; pchan_idx++) {
> > > + if (pchan_alloc & BIT(pchan_idx)) {
> > 
> > Ditto.

Same here.

[]

> > > +#ifdef DEBUG
> > > + dev_dbg(chan2dev(chan), "First: %pad\n", &txd->p_lli);
> > 
> > dev_dbg is aware of DEBUG. So, please, remove that #ifdef at all.
> 
> Yep, but the line just below isn't.
> 
> The ifdef here is not really to prevent the call to dev_dbg, but rather...
> 
> > > + for (prev = txd->v_lli; prev != NULL; prev = prev->v_lli_next)
> 
> ... this.

It doesn't matter since implementation of sun6i_dma_dump_lli is (and
actually should be) aware of DEBUG already, because it's dev_dbg based.

> > 
> > You may remove '!= NULL' part.
> 
> Ok.
> 
> > > + sun6i_dma_dump_lli(vchan, prev);
> > > +#endif




-- 
Andy Shevchenko 
Intel Finland Oy
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki 
Business Identity Code: 0357606 - 4 
Domiciled in Helsinki 

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

-- 
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] g_mass_storage issues with 3.4.79+

[FW72]

Hi all!

I'm currently trying to use the g_mass_storage on a linux-sunxi 3.4.79+ 
kernel (A10-Olinuxino-lime board connected to Win7 host)
without success.

So far I learned that USB device mode might be (or is?) broken in current 
kernel - at least on Allwinner SOCs but maybe
my information is outdated?

I also tried to debug with an USB trace but so far I've only noticed that 
communications stops tight after negotiation phase
after Win7 driver got the serial number from the mass storage gadget.

Maybe someone more knowledgeable can shed some light on this issue or is 
there just some problem I've overseen to
make that work? (Hopefully)!

Thanks alot!

Frank

-- 
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] How is the kernel mainlining process?

[Draplater]

Have mmc support  been add yet?

On Monday, March 10, 2014 9:48:28 PM UTC+8, Olliver Schinagl wrote:
>
> On 03/06/14 05:59, Draplater wrote: 
> > Website linux-sunxi writes: 
> > "The upstream code does not support NAND, MMC or SATA, you can only boot 
> > off a USB harddisk." (from  http://linux-sunxi.org/Mainline_Kernel_Howto) 
>
> > Is there any changes? Is the mainline kernel still that unusable now? 
> > 
> That page is likly old and outdated. Sata support has been added, USB 
> support has been added around the same time, so that USB harddisk was 
> possible wasn't even true back then. 
>
> http://linux-sunxi.org/Mainlining_Effort 
>
> This is the latest and most up to date (kept) status. 
>

-- 
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: A31 pmic (axp221) support

[Hans de Goede]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

On 03/11/2014 10:21 AM, Maxime Ripard wrote:
> On Mon, Mar 10, 2014 at 10:29:02PM +0100, Hans de Goede wrote:
 Is this bus similar enough to i2c that we can use the i2c subsys for this, 
 maybe with an extra controller flag, or do we need to likely write a whole 
 new subsys for this ?
>>> 
>>> It really looks like I2C, except that at the end of each byte sent, there's 
>>> an extra parity bit sent. I think we don't really need a new bus for this, 
>>> but we can somehow fit this into I2C. We could do it through an extra 
>>> controller flag, but I'm not sure that it's actually needed, since we can 
>>> handle the parity bit in the driver and present a 8-bit interface to the 
>>> framework.
>> 
>> Sounds good (better then writing our own subsys). About the extra controller 
>> flag, that would be to opt-out of drivers which do auto bus scanning, as 
>> well as maybe to opt out of the creation of i2c-dev /dev nodes. As we're not 
>> really i2c and we may want to avoid userspace from poking the bus.
>> 
>> Anyways first we need to learn more about this.
> 
> Actually, I spoke a bit too quickly.
> 
> After spending some time on this yesterday, this is what I understood:
> 
> It's similar to I2C (and even more SMBUS) in many points: - It's using SDA 
> and SCL - It starts with a start condition, that is SDA beind pulled down 
> while SCL is high. - the master always handles SCL, and either the master or 
> the device handles SDA, depending on the direction. - Whenever the 
> transaction is done, the master will issue a stop condition
> 
> However, it also differs by some aspects: - It's a point to point bus, you 
> can only have one device. - Once the start condition is issued, you transmit 
> a direction bit, then the register address on the device on 8 bits, then 1 
> bit of parity. Then the device will ack it, and the communication goes on, 
> either sending or receiving data, depending on the direction. - Whenever 
> you're writing, the ACK flag is only sent at the end of the transaction by 
> the device, to acknowledge the fact that it received properly both the 
> address and the data to write. - Whenever you're reading, there's no ACK
> involved. If there's some kind of error (invalid address for example), the 
> device will just pull SDA up for the whole 9 clock cycles (8 bits of data + 
> parity). Since the parity check will be wrong, the master will now something 
> wrong happened.
> 
> So a standard communication on this bus will be: Writing:
> 
> +---+---+--++--++-+--+
>  | Start | 0 (m) | Register (m) | Parity (m) | Data (m) | Parity (m) | ACK 
> (s) | Stop | 
> +---+---+--++--++-+--+
> 
> Reading:
> 
> +---+---+--++--++--+ 
> | Start | 1 (m) | Register (m) | Parity (m) | Data (s) | Parity (s) | Stop | 
> +---+---+--++--++--+
> 
> 
> There's still some subtleties I don't get yet, but the more I think about 
> this, the more I feel like we'll have to write our own bus :(

So on the bus things are different then with i2c, that does not mean we cannot
still pretend it is i2c to upper layers in the kernel.

I still believe we should try to make this some kind of pseudo i2c
controller and not do a new bus for this. If you look at the axp209 code
intended for upstream then it uses a lot of i2c infra, not just the bus stuff,
but also things like devm_regmap_init_i2c, so if we do our own bus we would
need to write out own regamp glue for that bus too.

And if we try and fail we can always define our own bus for this later.

Regards,

Hans
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlMe4msACgkQF3VEtJrzE/vtDACeMZ7PalYqGhD53Pje4FS5hGIh
MVQAmgOGVtuM0Hba46UlI4v7UQs+jNEf
=smP1
-END PGP SIGNATURE-

-- 
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: Stk1160 driver

[André Kerber]

Hi!

Thanks for the very fast Response! Unfortunately there is no working Linux 
image for cubieboard2 with Linux kernel > 3.4 so I hoped to be able to use your 
stk1160 port. Capturing with the easycap driver works also, but after approx 10 
sec the video gets very slow and mencoder says video buffer full...but viewing 
the video input with mplayer over easycap driver works fine, so I think there 
is enough bandwidth for the uncompressed video over USB. My problem is that I 
cannot even make or make install your driver to test, it always displays the 
below mentioned error 2 (/lib/modules/3.4.79-sun7i+/build: No such file or 
directory.)
I have package build-essentials installed

Best,

André

> Am 11.03.2014 um 04:40 schrieb Ezequiel Garcia :
> 
> André,
> 
> I'm leaving the question intact for context, and adding some folks.
> 
>> On Mon, Mar 10, 2014 at 8:55 PM, André Kerber  wrote:
>> 
>> I am sorry to disturb you because of the old stk1160 driver, but I am very 
>> stuck and did not find any answer googling for more than 2 hours...
>> 
>> If you could give me a tip I would be very glad!  I am trying to use your 
>> driver on a cubieboard2 with ubuntu 12.04. If I try sudo make I always get 
>> the following error:
>> 
>> /lib/modules/3.4.79-sun7i+/build: No such file or directory.
> 
> You're probably using the backported driver, uh? Any chance you use a
> newer kernel (> v3.7) ?
> 
>> Do you have any idea? I definitely have a build in the modules directory...
> 
> Emilio? Hans? Do you think the USB on the cubieboard2 can transfer
> uncompressed (raw) video?
> stk1160 needs as much as 20 MiB/sec. on isoc URBs and so far I haven't
> seen many embedded systems
> possible of that throughput...
> -- 
> Ezequiel

-- 
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: Stk1160 driver

[Ezequiel Garcia]

André,

I'm leaving the question intact for context, and adding some folks.

On Mon, Mar 10, 2014 at 8:55 PM, André Kerber  wrote:
>
> I am sorry to disturb you because of the old stk1160 driver, but I am very 
> stuck and did not find any answer googling for more than 2 hours...
>
> If you could give me a tip I would be very glad!  I am trying to use your 
> driver on a cubieboard2 with ubuntu 12.04. If I try sudo make I always get 
> the following error:
>
> /lib/modules/3.4.79-sun7i+/build: No such file or directory.
>

You're probably using the backported driver, uh? Any chance you use a
newer kernel (> v3.7) ?

> Do you have any idea? I definitely have a build in the modules directory...
>

Emilio? Hans? Do you think the USB on the cubieboard2 can transfer
uncompressed (raw) video?
stk1160 needs as much as 20 MiB/sec. on isoc URBs and so far I haven't
seen many embedded systems
possible of that throughput...
-- 
Ezequiel

-- 
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] A31 pmic (axp221) support

[Richard W.M. Jones]

On Sun, Mar 09, 2014 at 08:41:35AM +0100, Hans de Goede wrote:
> Hi Maxime,
> 
> Yesterday I've been playing a bit with my Mele A1000G Quad, with the purpose 
> of
> trying to get usb and mmc working there. I already have wens' gmac patches 
> for the
> A31 in my tree, so for starters I tried to get that to work.

If you want me to test anything, let me know.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

-- 
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: A31 pmic (axp221) support

[Maxime Ripard]

On Mon, Mar 10, 2014 at 10:29:02PM +0100, Hans de Goede wrote:
> >> Is this bus similar enough to i2c that we can use the i2c subsys
> >> for this, maybe with an extra controller flag, or do we need to
> >> likely write a whole new subsys for this ?
> > 
> > It really looks like I2C, except that at the end of each byte
> > sent, there's an extra parity bit sent. I think we don't really
> > need a new bus for this, but we can somehow fit this into I2C. We
> > could do it through an extra controller flag, but I'm not sure
> > that it's actually needed, since we can handle the parity bit in
> > the driver and present a 8-bit interface to the framework.
> 
> Sounds good (better then writing our own subsys). About the extra
> controller flag, that would be to opt-out of drivers which do
> auto bus scanning, as well as maybe to opt out of the creation
> of i2c-dev /dev nodes. As we're not really i2c and we may want
> to avoid userspace from poking the bus.
> 
> Anyways first we need to learn more about this.

Actually, I spoke a bit too quickly.

After spending some time on this yesterday, this is what I understood:

It's similar to I2C (and even more SMBUS) in many points:
  - It's using SDA and SCL
  - It starts with a start condition, that is SDA beind pulled down
while SCL is high.
  - the master always handles SCL, and either the master or the device
handles SDA, depending on the direction.
  - Whenever the transaction is done, the master will issue a stop
condition

However, it also differs by some aspects:
  - It's a point to point bus, you can only have one device.
  - Once the start condition is issued, you transmit a direction bit,
then the register address on the device on 8 bits, then 1 bit of
parity. Then the device will ack it, and the communication goes
on, either sending or receiving data, depending on the direction.
  - Whenever you're writing, the ACK flag is only sent at the end of
the transaction by the device, to acknowledge the fact that it
received properly both the address and the data to write.
  - Whenever you're reading, there's no ACK involved. If there's some
kind of error (invalid address for example), the device will just
pull SDA up for the whole 9 clock cycles (8 bits of data +
parity). Since the parity check will be wrong, the master will now
something wrong happened.

So a standard communication on this bus will be:
Writing:

+---+---+--++--++-+--+
| Start | 0 (m) | Register (m) | Parity (m) | Data (m) | Parity (m) | ACK (s) | 
Stop |
+---+---+--++--++-+--+

Reading:

+---+---+--++--++--+
| Start | 1 (m) | Register (m) | Parity (m) | Data (s) | Parity (s) | Stop |
+---+---+--++--++--+


There's still some subtleties I don't get yet, but the more I think
about this, the more I feel like we'll have to write our own bus :(

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

[linux-sunxi] Re: [PATCH v4 6/7] DMA: sun6i: Add driver for the Allwinner A31 DMA controller

[Maxime Ripard]

On Mon, Mar 10, 2014 at 06:57:00PM +0100, Arnd Bergmann wrote:
> On Monday 10 March 2014 17:51:56 Maxime Ripard wrote:
> > > 
> > > Neither "pll6" nor "ahb1_mux" are listed in the DT binding. Also, why
> > > is it the driver's business to set the parent?
> > 
> > Those are global clocks, so it's not really part pof the driver
> > binding itself. But I can add them.
> 
> No better don't then. Can you change the clk_get() call to pass
> NULL as the device pointer to clarify this in the source though?

Ok.
 
> > About the reparenting itself, other devices are actually fine having
> > any parent they want, only the DMA is picky about it (at least, from
> > what we know), so it made sense to me to put it into the driver
> > itself. Where would you put it?
> 
> Maybe Mike Turquette has an idea. We have in the past discussed
> about cases where you want the default clock setting to be part
> of the clock provider in some property. Could that work here?

You mean in the DT? I guess it would yes.

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com


signature.asc
Description: Digital signature

Re: [linux-sunxi] [PATCH u-boot] cmd_gpio: fix warning with GPIO_OSCILLATE

[Ian Campbell]

On Sun, 2014-03-09 at 20:10 +0100, Olliver Schinagl wrote:
> Ian,
> 
> sorry for not replying earlier, but isn't that a bug-fix against the 
> generic U-Boot? In that case, it's probably wise to post it on the 
> u-boot mailing list :)

As Henrik says it's actually sunxi functionality.

This particular fix is already in the sunxi tree I think.

Ian.


signature.asc
Description: This is a digitally signed message part