date:20140330

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

2014-03-30 Thread Hans de Goede

Hi,

On 03/31/2014 08:49 AM, Hans de Goede wrote:
> Hi,
> 
> On 03/30/2014 02:40 PM, Olliver Schinagl wrote:
>> On 03/30/2014 02:25 PM, Ian Campbell wrote:
>>> On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote:
 I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current
 u-boot-sunxi.git#sunxi) onto a SATA installation and have started a
 git clone of the kernel, after which I'll run a build and see what
 happens.
>>>
>>> So, I did the git clone, checkout, config and "make all -j4" has been
>>> running for quite a while now (>10 minutes) with no errors. While the
>>> make was running I've messed around with "git archive" to produce a
>>> tar.xz, got bored waiting for that, used wget to download a tar.xz from
>>> kernel.org and unpacked it. All with no errors.
>>>
>>> IOW I'm afraid it all looks OK to me.
>>>
>>> This is all running from a SATA disk with a 2A power supply.
>>>
>>> I'm about to go out for lunch, if it crashes etc while I'm out I'll let
>>> you know after I get back.
>> Looking forward to the result, but I'm sure it'll be fine ;)
>>
>> So i changed to the u-boot that comes with fedora 19 from hans, as I did all 
>> my previous work with that, and untarring of the extracted tarball works now.
>>
>> I have to make a deadline for my book (building the BSP, hence i bumped into 
>> this) and will do more compile/extraction tests in the next few days as time 
>> permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various 
>> things.
>>
>> If this is all deemed stable; then it can only be u-boot that somehow broke. 
>> The only thing I can imagine is tolerances or power usage somehow. Speaking 
>> of, during the extraction power jumped from just under 0.5 amps @ 4.85V = 
>> idle; to about 0.85 amps @ 4.75V.
> 
> Hmm, this might be caused by the FAST_MBUS stuff we've for A20 now a days.
> 
> You could try removing FAST_MBUS from the boards.cfg config options for
> the cubietruck, and see how a recent u-boot build that way works.

Oh and another thing to test is to try replacing your powersupply,
if is dropping that far below 5V then likely it is also outputting quite
a bit of noise and spikes on the powerline. Your battery won't help you
there since the power likely is not far enough below 5V to make it switch,
so the board keeps using the bad powersupply taking in all the noise and
power spikes.

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] Current u-boot crashes my cubietruck!

2014-03-30 Thread Hans de Goede

Hi,

On 03/30/2014 02:40 PM, Olliver Schinagl wrote:
> On 03/30/2014 02:25 PM, Ian Campbell wrote:
>> On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote:
>>> I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current
>>> u-boot-sunxi.git#sunxi) onto a SATA installation and have started a
>>> git clone of the kernel, after which I'll run a build and see what
>>> happens.
>>
>> So, I did the git clone, checkout, config and "make all -j4" has been
>> running for quite a while now (>10 minutes) with no errors. While the
>> make was running I've messed around with "git archive" to produce a
>> tar.xz, got bored waiting for that, used wget to download a tar.xz from
>> kernel.org and unpacked it. All with no errors.
>>
>> IOW I'm afraid it all looks OK to me.
>>
>> This is all running from a SATA disk with a 2A power supply.
>>
>> I'm about to go out for lunch, if it crashes etc while I'm out I'll let
>> you know after I get back.
> Looking forward to the result, but I'm sure it'll be fine ;)
> 
> So i changed to the u-boot that comes with fedora 19 from hans, as I did all 
> my previous work with that, and untarring of the extracted tarball works now.
> 
> I have to make a deadline for my book (building the BSP, hence i bumped into 
> this) and will do more compile/extraction tests in the next few days as time 
> permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various 
> things.
> 
> If this is all deemed stable; then it can only be u-boot that somehow broke. 
> The only thing I can imagine is tolerances or power usage somehow. Speaking 
> of, during the extraction power jumped from just under 0.5 amps @ 4.85V = 
> idle; to about 0.85 amps @ 4.75V.

Hmm, this might be caused by the FAST_MBUS stuff we've for A20 now a days.

You could try removing FAST_MBUS from the boards.cfg config options for
the cubietruck, and see how a recent u-boot build that way works.

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] sun6i SPL support status update

2014-03-30 Thread Chen-Yu Tsai

Hi Hans,

On Sun, Mar 30, 2014 at 8:04 PM, Hans de Goede  wrote:
> Hi,
>
> After wens pointed me to:
> http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;h=9275ca21ac99592c7d520a41c0914b359c27b913;hb=refs/heads/lichee/jb-4.2.2-a31
>
> I've tried to get a full SPL going on sun6i. No luck sofar,
> dropping in dram_sun6i.[c,h] +pll5 config seems to get the dram
> going, at least get_ram_size() likes it. But I cannot get the
> mmc to work in the SPL. I've narrowed this down to 2  problems,
> which I believe are related:
>
> 1) The mmc controller will simply not work with pll6 as source,
> after adding a test for the pll6 lock bit I believe this is caused
> by pll6 never locking.
>
> 2) When switching the mmc controller clocksource to OSC24M, then
> it does work, but gets stuck reading the first sector from the card.
> I believe this happens because the card is only being supplied 3.0V'
> rather then 3.3V.
>
> Note that the same code works fine in the no SPL u-boot when loaded
> through boot0 + boot1.
>
> Likely wrong power supply voltages are the culprit in both cases
> (the A31 also has a vdd-pll power pin.
>
> So it looks like the next step is to first get the pmic going in
> u-boot (which will be useful even if booted through boot0 + 1, to
> enable the nic-phy if nothing else).

The A23 lichee u-boot has drivers for P2WI (used in sun6i) and RSB
(reduced serial bus, used on A23):

https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/p2wi
https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/rsb

And also PMIC drivers:

https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/power

Judging from the code, my guess is AXP221 and AXP223 or differ in
the type of interface supported.

Hope this helps. :)

> And then see from there. Maybe I'll take a shot at this tonight,
> for now I'm going to spend some time with my family.


Cheers,
ChenYu

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

RE: [linux-sunxi] Issue - [cpu_freq] ERR:try to get regulator failed, core vdd will not changed!

2014-03-30 Thread Ma Haijun

Hi,

 

The virtual consumer driver itself looks odd too.

Is it a hack to enable user side to set the voltage, current and on/off state of
the regulators?

 

About these warning, I think the regulators should ether be marked as always_on,
or enabled by their consumers.

 

Haijun

 

Subject: Re: [linux-sunxi] Issue - [cpu_freq] ERR:try to get regulator failed,
core vdd will not changed!

 

After restoring to origin linux-sunxi stage/sunxi-3.4 branch's kernel &
sun7i_defconfig, the 'deferral' problem disappear. but 

[4.864677] Console: switching to colour frame buffer device 160x45
[4.893154] axp20_buck3: incomplete constraints, leaving on
[4.903500] axp20_buck2: incomplete constraints, leaving on
[4.913747] axp20_ldo4: incomplete constraints, leaving on
[4.923909] axp20_ldo3: incomplete constraints, leaving on
[4.934070] axp20_ldo2: incomplete constraints, leaving on
[4.944231] axp20_ldo1: incomplete constraints, leaving on

 

 

 

2014-03-31 10:26 GMT+08:00 Huang Benn mailto:benn.hu...@gmail.com> >:

 

 

2014-03-31 2:45 GMT+08:00 Olliver Schinagl mailto:oliver+l...@schinagl.nl> >:

 

On 03/30/2014 03:22 PM, Huang Benn wrote:

for 3.4 kernel, it fail to get regulator. who know what happen. I was
tracing the issue without success :P
anyone can help ? thanks

On what hardware is this happening? all a10/a20 or all axp20* based hardware?

The bug you point out does look odd., I don't think your supposed to pass NULL
to it, but what do I know ;)

Both exist on Cubieboard2 and Cubietruck. 


When I found the following code, I get surprised. I think it's a mistake to pass
NULL to regulator_get.

 //drvdata->regulator = regulator_get(&pdev->dev, reg_id);  //I've tried
this line, the same result.


drvdata->regulator = regulator_get(NULL, reg_id); - Bug ?
 //drvdata->regulator = regulator_get(NULL, "axp20_analog/fm");




 


Olliver


kernel: linux-sunxi/stage/sunxi-3.4


CODE:

drivers/power/axp_power/virtual20.c
static int regulator_virtual_consumer_probe(struct platform_device *pdev)
{
 char *reg_id = pdev->dev.platform_data;
 struct virtual_consumer_data *drvdata;
 int ret, i;

 pr_warning("[%s] enter1, pdev=%s, reg_id=%s\n", __FUNCTION__,
pdev->name, reg_id);

 drvdata = kzalloc(sizeof(struct virtual_consumer_data),
GFP_KERNEL);
 if (drvdata == NULL) {
 pr_warning("[%s] enter 2\n", __FUNCTION__);
 ret = -ENOMEM;
 goto err;
 }

 mutex_init(&drvdata->lock);

 pr_warning("[%s] pdev=%p, reg_id=%s\n", __FUNCTION__, pdev,
reg_id);

 //drvdata->regulator = regulator_get(&pdev->dev, reg_id);
drvdata->regulator = regulator_get(NULL, reg_id); - Bug ?
 //drvdata->regulator = regulator_get(NULL, "axp20_analog/fm");

 if (IS_ERR(drvdata->regulator)) {
ret = PTR_ERR(drvdata->regulator);
 pr_warning("[%s] enter3\n", __FUNCTION__);
 goto err;
 }



 

-- 
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] Issue - [cpu_freq] ERR:try to get regulator failed, core vdd will not changed!

2014-03-30 Thread Huang Benn

After restoring to origin linux-sunxi stage/sunxi-3.4 branch's kernel &
sun7i_defconfig, the 'deferral' problem disappear. but

[4.864677] Console: switching to colour frame buffer device 160x45
[4.893154] axp20_buck3: incomplete constraints, leaving on
[4.903500] axp20_buck2: incomplete constraints, leaving on
[4.913747] axp20_ldo4: incomplete constraints, leaving on
[4.923909] axp20_ldo3: incomplete constraints, leaving on
[4.934070] axp20_ldo2: incomplete constraints, leaving on
[4.944231] axp20_ldo1: incomplete constraints, leaving on





2014-03-31 10:26 GMT+08:00 Huang Benn :

>
>
>
> 2014-03-31 2:45 GMT+08:00 Olliver Schinagl :
>
> On 03/30/2014 03:22 PM, Huang Benn wrote:
>>
>>> for 3.4 kernel, it fail to get regulator. who know what happen. I was
>>> tracing the issue without success :P
>>> anyone can help ? thanks
>>>
>> On what hardware is this happening? all a10/a20 or all axp20* based
>> hardware?
>>
>> The bug you point out does look odd., I don't think your supposed to pass
>> NULL to it, but what do I know ;)
>>
> Both exist on Cubieboard2 and Cubietruck.
>
> When I found the following code, I get surprised. I think it's a mistake
> to pass NULL to regulator_get.
>
>  //drvdata->regulator = regulator_get(&pdev->dev, reg_id); //I've 
> tried this line, the same result.
>
> drvdata->regulator = regulator_get(NULL, reg_id); - Bug ?
>  //drvdata->regulator = regulator_get(NULL, "axp20_analog/fm");
>
>
>
>
>
>>
>> Olliver
>>
>>>
>>> kernel: linux-sunxi/stage/sunxi-3.4
>>>
>>>
>>> CODE:
>>>
>>> drivers/power/axp_power/virtual20.c
>>> static int regulator_virtual_consumer_probe(struct platform_device
>>> *pdev)
>>> {
>>>  char *reg_id = pdev->dev.platform_data;
>>>  struct virtual_consumer_data *drvdata;
>>>  int ret, i;
>>>
>>>  pr_warning("[%s] enter1, pdev=%s, reg_id=%s\n", __FUNCTION__,
>>> pdev->name, reg_id);
>>>
>>>  drvdata = kzalloc(sizeof(struct virtual_consumer_data),
>>> GFP_KERNEL);
>>>  if (drvdata == NULL) {
>>>  pr_warning("[%s] enter 2\n", __FUNCTION__);
>>>  ret = -ENOMEM;
>>>  goto err;
>>>  }
>>>
>>>  mutex_init(&drvdata->lock);
>>>
>>>  pr_warning("[%s] pdev=%p, reg_id=%s\n", __FUNCTION__, pdev,
>>> reg_id);
>>>
>>>  //drvdata->regulator = regulator_get(&pdev->dev, reg_id);
>>> drvdata->regulator = regulator_get(NULL, reg_id); - Bug ?
>>>  //drvdata->regulator = regulator_get(NULL, "axp20_analog/fm");
>>>
>>>  if (IS_ERR(drvdata->regulator)) {
>>> ret = PTR_ERR(drvdata->regulator);
>>>  pr_warning("[%s] enter3\n", __FUNCTION__);
>>>  goto err;
>>>  }
>>>
>>>
>>>
>>>
>>> --
>>> 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.
>>
>
>

-- 
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] Issue - [cpu_freq] ERR:try to get regulator failed, core vdd will not changed!

2014-03-30 Thread Huang Benn

2014-03-31 2:45 GMT+08:00 Olliver Schinagl :

> On 03/30/2014 03:22 PM, Huang Benn wrote:
>
>> for 3.4 kernel, it fail to get regulator. who know what happen. I was
>> tracing the issue without success :P
>> anyone can help ? thanks
>>
> On what hardware is this happening? all a10/a20 or all axp20* based
> hardware?
>
> The bug you point out does look odd., I don't think your supposed to pass
> NULL to it, but what do I know ;)
>
Both exist on Cubieboard2 and Cubietruck.

When I found the following code, I get surprised. I think it's a mistake to
pass NULL to regulator_get.

 //drvdata->regulator = regulator_get(&pdev->dev, reg_id);  //I've
tried this line, the same result.
drvdata->regulator = regulator_get(NULL, reg_id); - Bug ?
 //drvdata->regulator = regulator_get(NULL, "axp20_analog/fm");





>
> Olliver
>
>>
>> kernel: linux-sunxi/stage/sunxi-3.4
>>
>>
>> CODE:
>>
>> drivers/power/axp_power/virtual20.c
>> static int regulator_virtual_consumer_probe(struct platform_device *pdev)
>> {
>>  char *reg_id = pdev->dev.platform_data;
>>  struct virtual_consumer_data *drvdata;
>>  int ret, i;
>>
>>  pr_warning("[%s] enter1, pdev=%s, reg_id=%s\n", __FUNCTION__,
>> pdev->name, reg_id);
>>
>>  drvdata = kzalloc(sizeof(struct virtual_consumer_data),
>> GFP_KERNEL);
>>  if (drvdata == NULL) {
>>  pr_warning("[%s] enter 2\n", __FUNCTION__);
>>  ret = -ENOMEM;
>>  goto err;
>>  }
>>
>>  mutex_init(&drvdata->lock);
>>
>>  pr_warning("[%s] pdev=%p, reg_id=%s\n", __FUNCTION__, pdev,
>> reg_id);
>>
>>  //drvdata->regulator = regulator_get(&pdev->dev, reg_id);
>> drvdata->regulator = regulator_get(NULL, reg_id); - Bug ?
>>  //drvdata->regulator = regulator_get(NULL, "axp20_analog/fm");
>>
>>  if (IS_ERR(drvdata->regulator)) {
>> ret = PTR_ERR(drvdata->regulator);
>>  pr_warning("[%s] enter3\n", __FUNCTION__);
>>  goto err;
>>  }
>>
>>
>>
>>
>> --
>> 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.
>

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

Re: [linux-sunxi] Re: New u-boot sunxi-next available for testing

2014-03-30 Thread markus . roppelt

Am Donnerstag, 27. März 2014 19:50:32 UTC+1 schrieb Ezaul Zillmer:
> Ok Muito Obrigado!
> 
> 
> ;)
> 
> Em quinta-feira, 27 de março de 2014 15h19min58s UTC-3, Hans de Goede  
> escreveu:Hi,
> 
> 
> 
> To build this you should do:
> 
> 
> 
> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- Cubieboard2_config
> 
> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
> 
> 
> 
> Regards,
> 
> 
> 
> Hans
> 
> 
> 
> 
> 
> On 03/27/2014 06:33 PM, Ezaul Zillmer wrote:
> 
> > 
> 
> >>
> 
> >> Good Afternoon Doctor Hans 
> 
> >>
> 
> >>  
> 
> > 
> 
> >> Updated my u-boot
> 
> >>
> 
> >>       I wonder how was the logic I tried to compile it like this: 
> 
> >      
> 
> >       ./mkconfig ARCH=arm CPU=armv7 SOC=sunxi BOARD=Cubieboard2 
> 
> > 
> 
> >> make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
> 
> >>>
> 
> >>
> 
> >>> No dick: (could correct me where I am going wrong! 
> 
> >>
> 
> >>
> 
> >>> Hug Since Thank you much longer
> 
> >>
> 
> >>
> 
> >

Hi Hans,

I tested the new u-boot with your newest kernel (3.14.0-rc8+) on the cubietruck.

I found two issues so far. It seems that only one CPU is initialized correctly:

[0.049402] /cpus/cpu@0 missing clock-frequency property
[0.049433] /cpus/cpu@1 missing clock-frequency property
[0.049447] CPU0: thread -1, cpu 0, socket 0, mpidr 8000
[0.049479] Setting up static identity map for 0x4073f2d0 - 0x4073f368
[0.058595] CPU1: failed to boot: -38
[0.058647] Brought up 1 CPUs
[0.058655] SMP: Total of 1 processors activated.
[0.058662] CPU: All CPU(s) started in SVC mode.
[0.059721] devtmpfs: initialized
[0.064475] VFP support v0.3: implementor 41 architecture 2 part 30 variant 
7 rev 4

Also kvm does not work and there is no /dev/kvm device. 
[0.176760] kvm [1]: HYP mode not available

Here is the full dmesg output: http://pastebin.com/V72FAzmp

Greetings 
 Markus

-- 
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] Azpen A727 / A23 chip

2014-03-30 Thread Luc Verhaegen

On Sun, Mar 30, 2014 at 10:17:59AM -0700, Daniel J. Grinkevich wrote:
> I just got an Azpen A727 (some reason it's not on the company's website), 
> it runs the A23 chip.  I managed to find the serial TX but RX is still 
> unknown.  I started a wiki page, http://linux-sunxi.org/A727 .  If anyone 
> has any specific ideas or anyway I can help, I'm willing to probe it some 
> more.
> 
> Dan

Olliver is right, the http://linux-sunxi.org/New_Device_howto is where 
you should start. You will be guided through gathering all sorts of 
useful information and on creating a useful page which you and other can 
easily refer to. As Olliver states, getting memory info is a bit icky 
atm, we should fix that on the ippo Q88 devices some of us have already.

Also, it makes sense to name your device the inet_86dz as the 
motherboard said.

Btw, what triggered you to create this page layout? It feels as if you 
copied it from some other device page... Why did you choose exactly that 
other device? What should i fix (short of fixing _all_ remaining 48 
broken devices pages) so that others don't do the same and find the 
New_Device_Howto instead?

Luc Verhaegen.

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

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

2014-03-30 Thread Olliver Schinagl


On 03/30/2014 05:59 PM, Ian Campbell wrote:

On Sun, 2014-03-30 at 14:26 +0200, Olliver Schinagl wrote:

That said the sorts of random crashed you've been posting sound a lot
like either a DRAM issue or overheating. Either of which could be down
to u-boot setting up something wrong or bad hardware I suppose.

Overheating, maybe. It feels hottish to the touch, but can hold a finger
on it without any problem whatsoever. Not close to the pain point. So I
estimate < 50 C? Shouldn't be reason to be concerned imo.


Doesn't sound like it.


Power might be the problem, i see the input voltage under heavy load
drop to 4.65 Volts @ 0.9 amps


Could be that.


Have you checked the checksum of the tarball you are extracting and
tried unpacking it on a known good system?

The sha1sum matches, calculated on the board, so that's good. xz -d
completed successfully!

tar xvf fails however, with a big ass 5 page long oops.


I'd have thought that xz -d would be *far* more CPU intensive and
therefore liable to cause issues than tar xvf. If you were using
spinning rust rather than an SSD then I would be inclined to suspect the
power draw, but with you using an SSD I'm just not sure.


I agree! though even a heavily stressed CPU doesn't change power draw 
hugely. Ssvb and I did some power tests a few months ago on the list.


Additionally! I should mention, my CT has a battery backup which should 
be near full charge. a 1220 mAh battery, so even if the power supply 
should drop to low or something, Wens assured me that the battery would 
take over and no problem should be caused by bad power. Unless the 
battery has run down of course, which I highly doubt, especially seeing 
the constant current draw over USB.


So for now, I just hope it's not user error ...

Olliver



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] Current u-boot crashes my cubietruck!

2014-03-30 Thread Olliver Schinagl


On 03/30/2014 06:01 PM, Ian Campbell wrote:

On Sun, 2014-03-30 at 14:40 +0200, Olliver Schinagl wrote:

If this is all deemed stable; then it can only be u-boot that somehow
broke. The only thing I can imagine is tolerances or power usage
somehow.


I could only take one bit in some register being somehow different to
push your particular bit of kit over the edge.

That's something I might be inclined to investigate, i.e. dump out all
the DRAM, clock, power controller etc registers on working and
non-working u-boot's and diff them looking for unexplained differences.
Yeah that's probably a good idea; When I have some more freetime, I will 
add the dump reg function we have somewhere and start documenting/comparing.


For now, i wanna see how long it keeps running ;) It might not even be a 
dram thing, but a sata thing ... though the kernel hasn't changed :)


Olliver


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] Issue - [cpu_freq] ERR:try to get regulator failed, core vdd will not changed!

2014-03-30 Thread Olliver Schinagl


On 03/30/2014 03:22 PM, Huang Benn wrote:

for 3.4 kernel, it fail to get regulator. who know what happen. I was
tracing the issue without success :P
anyone can help ? thanks
On what hardware is this happening? all a10/a20 or all axp20* based 
hardware?


The bug you point out does look odd., I don't think your supposed to 
pass NULL to it, but what do I know ;)


Olliver


kernel: linux-sunxi/stage/sunxi-3.4


CODE:

drivers/power/axp_power/virtual20.c
static int regulator_virtual_consumer_probe(struct platform_device *pdev)
{
 char *reg_id = pdev->dev.platform_data;
 struct virtual_consumer_data *drvdata;
 int ret, i;

 pr_warning("[%s] enter1, pdev=%s, reg_id=%s\n", __FUNCTION__,
pdev->name, reg_id);

 drvdata = kzalloc(sizeof(struct virtual_consumer_data),
GFP_KERNEL);
 if (drvdata == NULL) {
 pr_warning("[%s] enter 2\n", __FUNCTION__);
 ret = -ENOMEM;
 goto err;
 }

 mutex_init(&drvdata->lock);

 pr_warning("[%s] pdev=%p, reg_id=%s\n", __FUNCTION__, pdev,
reg_id);

 //drvdata->regulator = regulator_get(&pdev->dev, reg_id);
drvdata->regulator = regulator_get(NULL, reg_id); - Bug ?
 //drvdata->regulator = regulator_get(NULL, "axp20_analog/fm");

 if (IS_ERR(drvdata->regulator)) {
ret = PTR_ERR(drvdata->regulator);
 pr_warning("[%s] enter3\n", __FUNCTION__);
 goto err;
 }


and I found the error "platform reg-20-cs-ldo2: Driver reg-20-cs-ldo2
requests probe deferral" is caused by the function
static int really_probe(struct device *dev, struct device_driver *drv)
at drivers/base/dd.c


LOGS:

[4.604562] Registering the dns_resolver key type
<6>VFP support v0.3: [4.611237] VFP support v0.3: implementor 41
architecture 2 part 30 variant 7 r4
implementor 41 architecture 2 part 30 variant 7 rev 4
<5>Registering SWP/SWPB emulation handler
[4.627459] Registering SWP/SWPB emulation handler
<4>[_regulator_get] 2
[4.634326] [_regulator_get] 2
<4>[_regulator_get] 3
[4.639396] [_regulator_get] 3
<3>[cpu_freq] ERR:try to get regulator failed, core vdd will not changed!
[4.648956] [cpu_freq] ERR:try to get regulator failed, core vdd will
not changed!
<6>[cpu_freq] INF:---V-F Table---
[4.662395] [cpu_freq] INF:---V-F
Table---
<6>[cpu_freq] INF:  voltage = 1450mvfrequency = 1008MHz
[4.674309] [cpu_freq] INF:  voltage = 1450mvfrequency = 1008MHz
<6>[cpu_freq] INF:  voltage = 1425mvfrequency =  912MHz
[4.685442] [cpu_freq] INF:  voltage = 1425mvfrequency =  912MHz
<6>[cpu_freq] INF:  voltage = 1350mvfrequency =  864MHz
[4.696585] [cpu_freq] INF:  voltage = 1350mvfrequency =  864MHz
<6>[cpu_freq] INF:  voltage = 1250mvfrequency =  720MHz
[4.707732] [cpu_freq] INF:  voltage = 1250mvfrequency =  720MHz
<6>[cpu_freq] INF:  voltage = 1150mvfrequency =  528MHz
[4.718871] [cpu_freq] INF:  voltage = 1150mvfrequency =  528MHz
<6>[cpu_freq] INF:  voltage = 1100mvfrequency =  312MHz
[4.730004] [cpu_freq] INF:  voltage = 1100mvfrequency =  312MHz
<6>[cpu_freq] INF:  voltage = 1050mvfrequency =  144MHz
[4.741137] [cpu_freq] INF:  voltage = 1050mvfrequency =  144MHz
<6>[cpu_freq] INF:  voltage = 1000mvfrequency =0MHz
[4.752272] [cpu_freq] INF:  voltage = 1000mvfrequency =0MHz
<6>[cpu_freq] INF:---
[4.764188] [cpu_freq]
INF:---
<6>[cpu_freq] INF:sunxi_cpufreq_initcall, get cpu frequency from
sysconfig, max freq: 1008MHz, min freqz
[4.780882] [cpu_freq] INF:sunxi_cpufreq_initcall, get cpu frequency
from sysconfig, max freq: 1008Mz
<6>registered taskstats version 1
[4.795506] registered taskstats version 1
<4>[really_probe] hdmi, hdmi
[4.803665] [really_probe] hdmi, hdmi
<6>I2C: i2c-5: HDMI I2C adapter
[4.810606] I2C: i2c-5: HDMI I2C adapter
<6>disp clks: lcd 7425 pre_scale 1 hdmi 7425 pll 29700 2x 0
[4.843568] disp clks: lcd 7425 pre_scale 1 hdmi 7425 pll
29700 2x 0
<6>Console: switching to colour frame buffer device 160x45
[5.405836] Console: switching to colour frame buffer device 160x45
<4>[really_probe] 5
[5.431016] [really_probe] 5
<6>sunxi-rtc sunxi-rtc: setting system clock to 2010-01-01 00:00:00 UTC
(1262304000)
[5.441668] sunxi-rtc sunxi-rtc: setting system clock to 2010-01-01
00:00:00 UTC (1262304000)
<4>BENN axp_regulator_init
[5.452640] BENN axp_regulator_init
<4>BENN axp_battery_init
[5.458493] BENN axp_battery_init
<4>BENN regulator_virtual_consumer_init
[5.465433] BENN regulator_virtual_consumer_init
<4>BENN virtual_init
[5.472241] BENN virtual_init
<4>[really_probe] reg-20-

Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-30 Thread Ian Campbell

On Sun, 2014-03-30 at 20:39 +0300, Siarhei Siamashka wrote:
> Yes, right now it needs sunxi-3.4 kernel, which is a bit more feature
> complete at the moment. That's a good point, appears that readme.txt
> also needs to be improved for more clarity.

While you are there it took me a few seconds to work out which binary I
should run once I'd run the build script.

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] Azpen A727 / A23 chip

2014-03-30 Thread Olliver Schinagl


On 03/30/2014 07:17 PM, Daniel J. Grinkevich wrote:

I just got an Azpen A727 (some reason it's not on the company's
website), it runs the A23 chip.  I managed to find the serial TX but RX
is still unknown.  I started a wiki page, http://linux-sunxi.org/A727 .
  If anyone has any specific ideas or anyway I can help, I'm willing to
probe it some more.
You could try by going over the New_Device_Howto though a lot of things 
might not work out right away. a10-meminfo won't work for example. Even 
so, having gone over the New_Device_Howto should get us a little bit closer.


Thanks for taking the time and effort!

Olliver


Dan

--
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] [PATCH 3.4] sun7i: enable performance counters

2014-03-30 Thread Olliver Schinagl


On 03/29/2014 08:44 PM, Alejandro Mery wrote:



On 27/03/14 13:00, Mans Rullgard wrote:

The PMUs on sun7i use the undocumented IRQs 152 and 153 for core 0 and 1
respectively.

Signed-off-by: Mans Rullgard 
---
   arch/arm/plat-sunxi/devices.c | 16 +++-
   1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/arch/arm/plat-sunxi/devices.c b/arch/arm/plat-sunxi/devices.c
index fdddc56..70fec7f 100644
--- a/arch/arm/plat-sunxi/devices.c
+++ b/arch/arm/plat-sunxi/devices.c
@@ -30,6 +30,7 @@
   #include 
   #include 
   #include 
+#include 

   #include 
   #include 
@@ -113,13 +114,13 @@ struct platform_device sw_pdev_nand =
.dev = {}
   };

-#ifndef CONFIG_ARCH_SUN7I
   static struct resource sunxi_pmu_resources[] = {
-   {
-   .start  = SW_INT_IRQNO_PLE_PFM,
-   .end= SW_INT_IRQNO_PLE_PFM,
-   .flags  = IORESOURCE_IRQ,
-   },
+#ifdef CONFIG_ARCH_SUN7I
+   DEFINE_RES_IRQ(152),
+   DEFINE_RES_IRQ(153),
+#else
+   DEFINE_RES_IRQ(SW_INT_IRQNO_PLE_PFM),
+#endif
   };

   struct platform_device sunxi_pmu_device = {
@@ -128,7 +129,6 @@ struct platform_device sunxi_pmu_device = {
.resource   = sunxi_pmu_resources,
.num_resources  = ARRAY_SIZE(sunxi_pmu_resources),
   };
-#endif

   #if defined(CONFIG_MALI_DRM) || defined(CONFIG_MALI_DRM_MODULE)
   static struct platform_device sunxi_device_mali_drm = {
@@ -143,9 +143,7 @@ static struct platform_device *sw_pdevs[] __initdata = {
   #endif
&sw_pdev_dmac,
&sw_pdev_nand,
-#ifndef CONFIG_ARCH_SUN7I
&sunxi_pmu_device,
-#endif
   #if defined(CONFIG_MALI_DRM) || defined(CONFIG_MALI_DRM_MODULE)
&sunxi_device_mali_drm,
   #endif



thanks! applied on stage/sunxi-3.4

time for a merge?
If you merge this to sunxi-3.4 also push it into the BSP as the main 
goto kernel, right now, it relies on some ancient 3.0 which is long 
obsoleted.


Olliver


cheers,
Alejandro Mery



--
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] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-30 Thread Siarhei Siamashka

On Sun, 30 Mar 2014 13:13:29 +0100
Ian Campbell  wrote:

> On Fri, 2014-03-28 at 12:42 +0200, Siarhei Siamashka wrote:
> > https://github.com/ssvb/lima-memtester
> 
> I needed the following to get it to build on my Debian rootfs.

Thanks for the fix, pushed to github.

> (and it turns out I can't run it anyway since I'm running a mainline
> kernel and haven't figured out mali.ko yet, for another time I think)

Yes, right now it needs sunxi-3.4 kernel, which is a bit more feature
complete at the moment. That's a good point, appears that readme.txt
also needs to be improved for more clarity.

In the mainline kernel we first need a display driver (sunxi-kms?),
which would provide emulation of the linux framebuffer interface among
other things. And then, I guess, the mali400 kernel driver could
be used with a bit of adaptation.

> -8<---
> 
> From 72624b5d665e576057a3a869117014ae6a998578 Mon Sep 17 00:00:00 2001
> From: Ian Campbell 
> Date: Sun, 30 Mar 2014 13:09:55 +0100
> Subject: [PATCH] Remove bashisms from scripts
> 
> [ "a" == "b" ] is a bashism, the portable alternative is [ "a" = "b" ].
> 
> Fixes the following issue on Debian where /bin/sh == dash:
> 
> # ./build-lima-memtester-static-binary.sh
> ./build-lima-memtester-static-binary.sh: 3: [: x: unexpected operator
> ./build-lima-memtester-static-binary.sh: 11: 
> ./build-lima-memtester-static-binary.sh: -DHAVE_NO_LIBMALI_BLOB: not found
> 
> The alternative would be to explicitly use #!/bin/bash in the script but since
> the fix is trivial we might as well make it.
> 
> Signed-off-by: Ian Campbell 
> ---
>  build-lima-memtester-static-binary.sh | 2 +-
>  build-textured-cube-static-binary.sh  | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/build-lima-memtester-static-binary.sh 
> b/build-lima-memtester-static-binary.sh
> index e84e51b..d253cbb 100755
> --- a/build-lima-memtester-static-binary.sh
> +++ b/build-lima-memtester-static-binary.sh
> @@ -1,6 +1,6 @@
>  #!/bin/sh
>  
> -if [ x$CC == "x" ]
> +if [ x$CC = "x" ]
>  then
>  echo Note: using 'gcc' as a compiler. But it is possible to do something
>  echo like \'export CC=foobar\' to override this.
> diff --git a/build-textured-cube-static-binary.sh 
> b/build-textured-cube-static-binary.sh
> index 61f3e95..cc9f5d0 100755
> --- a/build-textured-cube-static-binary.sh
> +++ b/build-textured-cube-static-binary.sh
> @@ -1,6 +1,6 @@
>  #!/bin/sh
>  
> -if [ x$CC == "x" ]
> +if [ x$CC = "x" ]
>  then
>  echo Note: using 'gcc' as a compiler. But it is possible to do something
>  echo like \'export CC=foobar\' to override this.

-- 
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] Azpen A727 / A23 chip

2014-03-30 Thread Daniel J. Grinkevich

I just got an Azpen A727 (some reason it's not on the company's website), 
it runs the A23 chip.  I managed to find the serial TX but RX is still 
unknown.  I started a wiki page, http://linux-sunxi.org/A727 .  If anyone 
has any specific ideas or anyway I can help, I'm willing to probe it some 
more.

Dan

-- 
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] Current u-boot crashes my cubietruck!

2014-03-30 Thread Ian Campbell

On Sun, 2014-03-30 at 14:40 +0200, Olliver Schinagl wrote:
> If this is all deemed stable; then it can only be u-boot that somehow 
> broke. The only thing I can imagine is tolerances or power usage 
> somehow.

I could only take one bit in some register being somehow different to
push your particular bit of kit over the edge.

That's something I might be inclined to investigate, i.e. dump out all
the DRAM, clock, power controller etc registers on working and
non-working u-boot's and diff them looking for unexplained differences.

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] Current u-boot crashes my cubietruck!

2014-03-30 Thread Ian Campbell

On Sun, 2014-03-30 at 14:26 +0200, Olliver Schinagl wrote:
> > That said the sorts of random crashed you've been posting sound a lot
> > like either a DRAM issue or overheating. Either of which could be down
> > to u-boot setting up something wrong or bad hardware I suppose.
> Overheating, maybe. It feels hottish to the touch, but can hold a finger 
> on it without any problem whatsoever. Not close to the pain point. So I 
> estimate < 50 C? Shouldn't be reason to be concerned imo.

Doesn't sound like it.

> Power might be the problem, i see the input voltage under heavy load 
> drop to 4.65 Volts @ 0.9 amps

Could be that.

> > Have you checked the checksum of the tarball you are extracting and
> > tried unpacking it on a known good system?
> The sha1sum matches, calculated on the board, so that's good. xz -d 
> completed successfully!
> 
> tar xvf fails however, with a big ass 5 page long oops.

I'd have thought that xz -d would be *far* more CPU intensive and
therefore liable to cause issues than tar xvf. If you were using
spinning rust rather than an SSD then I would be inclined to suspect the
power draw, but with you using an SSD I'm just not sure.

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] Current u-boot crashes my cubietruck!

2014-03-30 Thread Ian Campbell

On Sun, 2014-03-30 at 13:25 +0100, Ian Campbell wrote:
> I'm about to go out for lunch, if it crashes etc while I'm out I'll let
> you know after I get back.

It was fine. I've left it running in a loop repeatedly building kernels.

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] Re: A20 + OV5640 (parallel) issues

2014-03-30 Thread Ivan Kozic

Luckily not yet, it goes directly to the screen - this would be the next 
potential project. However, when I see how many issues disp driver has (and 
it's somewhat "documented"), I cannot imagine the issues with the VPU that 
you're having, knowing that even registers are not documented... Hopefully, 
it'll be a bit more functional when I get the second project.

On Saturday, March 29, 2014 10:56:49 PM UTC+1, Jon Smirl wrote:
>
> On Sat, Mar 29, 2014 at 4:34 PM, Ivan Kozic > 
> wrote: 
> > Hey getting closer :) There's still an issue with the LDO (I don't like 
> this 
> > debugfs issue) - check if you actually get sensor voltage first. If no, 
> > there's still something funny going on with AXP, so triple-check the Fex 
> > file for LDO init. Check with a multimeter whether you really get 2V8. 
> > Ok, so the I2C stuff is located in the driver itself - just look at the 
> > functions in the mt9d112 driver file (something like sensor_read and 
> > sensor_write) - there you should see if the sensor address is correct. 
> Also 
> > bear in mind which I2C bus is used for sensor in the fex file for your 
> > sensor - mine is twi0, but it can easily be that you've connected the 
> sensor 
> > to something else (on Olinuxino twi2 was also close to route for 
> instance so 
> > I made assembly options on my interface to either use TWI0 or TWI2, as I 
> > didn't really know what is implemented in the kernel and what's not at 
> the 
> > time...). 
> > If you're using level converters for I2C, check them as well, especially 
> > OE's. 
>
> Are you planning on feeding this into the h.264 compression engine? 
> That's where I got stuck with not enough compression being done - 
> output stream is too many MB/s. 
>
>
> > 
> > 
> > On Fri, Mar 28, 2014 at 11:47 PM, > 
> wrote: 
> >> 
> >> пятница, 28 марта 2014 г., 11:41:49 UTC+2 пользователь Ivan Kozic 
> написал: 
> >> > Hi, 
> >> > 
> >> > You haven't given much info about this - take care with Cubieboard 1 
> & 2 
> >> > - as far as I can remember they don't have PIXCLK routed for CSI0 
> port, so 
> >> > it's completely unusable. You should use CSI1. 
> >> > 
> >> > Regarding the seg fault - not sure how you connected the power 
> supplies 
> >> > to the sensor, but these regulator_enable are for AXP IC - if you 
> connected 
> >> > the sensor to the AXP, you need to use them I guess. I for instance 
> have 
> >> > just connected the sensor supply to fixed LDO's coming from either 
> 3V3 or 
> >> > 5V, which is always alive, so I don't really need them, but 
> nevertheless 
> >> > they aren't commented out in my driver (WiP, so still dirty) and they 
> are 
> >> > working, so maybe the culprit is something else. 
> >> > 
> >> > You didn't say which test application or given any snippets, but if 
> it's 
> >> > the one coming with the driver (app_test_ok or something similar), by 
> Rockie 
> >> > Cheng (this name always amuses me :) ), then it's full of bugs and 
> issues 
> >> > and you should carefully go through every step and clean the crap 
> code out 
> >> > (a lot of it is crap). Better yet, write a much simpler V4L2 test app 
> >> > yourself. 
> >> > 
> >> > Things that also pop is the old kernel (I'm using 3.4.75 and this is 
> >> > already like couple of months old) and this Linaro rootfs (don't know 
> about 
> >> > this - is it fully supported on Cubies?). You should probably use 
> newer 
> >> > kernel just to be sure that something stupid is not breaking. 
> >> > 
> >> > Also take care with drivers - the one for OV5640 is very badly 
> written 
> >> > and full of bugs and I don't think that the supplied sensor settings 
> are 
> >> > usable for anyone (they are all like 3.75 and 7.5 fps, most of them 
> just 
> >> > wrong). Also sun4i_csi driver is bad (you can read some of the issues 
> on 
> >> > this thread, but there are other threads as well). So mostly for a 
> >> > functional system all this needs to be cleaned and rewritten. 
> >> > 
> >> > On Thursday, March 27, 2014 11:54:08 PM UTC+1, rdv...@gmail.com 
> >> > wrote:Hello guys, 
> >> > I want to get camera module mt9d112 working on cubieboard a10 
> over 
> >> > CSI. I am using ubuntu linaro with kernel version 3.4.61. Test 
> application 
> >> > crashes with seg fault on (regulator_enable+0x4/0x1f8) from 
> [] 
> >> > (sensor_power+0x190/0x398 [mt9d112]). Could you please help me to 
> figure out 
> >> > where the issue is? How can I debug kernel module? 
> >> 
> >> You are right for testing I using app_test_ok. This test application is 
> >> full of mistakes but for now I did not even successfuly initialized 
> camera 
> >> module. 
> >> I have connected VCC of camera module to CSI1_IO_2V8 pin on the board 
> and 
> >> other pins to the rest of CSI ports. The CSI1_IO_2V8 is actually LDO4 
> of 
> >> AXP20 and I finally found in AllWinner documentation that string 
> "axp_hdmi" 
> >> should be used in script.fex instead of axp_p11 as described in 
> tutorial. By 
> >> the way the tutori

[linux-sunxi] Issue - [cpu_freq] ERR:try to get regulator failed, core vdd will not changed!

2014-03-30 Thread Huang Benn

for 3.4 kernel, it fail to get regulator. who know what happen. I was
tracing the issue without success :P
anyone can help ? thanks

kernel: linux-sunxi/stage/sunxi-3.4


CODE:

drivers/power/axp_power/virtual20.c
static int regulator_virtual_consumer_probe(struct platform_device *pdev)
{
char *reg_id = pdev->dev.platform_data;
struct virtual_consumer_data *drvdata;
int ret, i;

pr_warning("[%s] enter1, pdev=%s, reg_id=%s\n", __FUNCTION__,
pdev->name, reg_id);

drvdata = kzalloc(sizeof(struct virtual_consumer_data), GFP_KERNEL);
if (drvdata == NULL) {
pr_warning("[%s] enter 2\n", __FUNCTION__);
ret = -ENOMEM;
goto err;
}

mutex_init(&drvdata->lock);

pr_warning("[%s] pdev=%p, reg_id=%s\n", __FUNCTION__, pdev, reg_id);

//drvdata->regulator = regulator_get(&pdev->dev, reg_id);
drvdata->regulator = regulator_get(NULL, reg_id);
- Bug ?
//drvdata->regulator = regulator_get(NULL, "axp20_analog/fm");

if (IS_ERR(drvdata->regulator)) {
ret = PTR_ERR(drvdata->regulator);
pr_warning("[%s] enter3\n", __FUNCTION__);
goto err;
}


and I found the error "platform reg-20-cs-ldo2: Driver reg-20-cs-ldo2
requests probe deferral" is caused by the function
static int really_probe(struct device *dev, struct device_driver *drv)
at drivers/base/dd.c


LOGS:

[4.604562] Registering the dns_resolver key type
<6>VFP support v0.3: [4.611237] VFP support v0.3: implementor 41
architecture 2 part 30 variant 7 r4
implementor 41 architecture 2 part 30 variant 7 rev 4
<5>Registering SWP/SWPB emulation handler
[4.627459] Registering SWP/SWPB emulation handler
<4>[_regulator_get] 2
[4.634326] [_regulator_get] 2
<4>[_regulator_get] 3
[4.639396] [_regulator_get] 3
<3>[cpu_freq] ERR:try to get regulator failed, core vdd will not changed!
[4.648956] [cpu_freq] ERR:try to get regulator failed, core vdd will
not changed!
<6>[cpu_freq] INF:---V-F Table---
[4.662395] [cpu_freq] INF:---V-F
Table---
<6>[cpu_freq] INF:  voltage = 1450mvfrequency = 1008MHz
[4.674309] [cpu_freq] INF:  voltage = 1450mvfrequency = 1008MHz
<6>[cpu_freq] INF:  voltage = 1425mvfrequency =  912MHz
[4.685442] [cpu_freq] INF:  voltage = 1425mvfrequency =  912MHz
<6>[cpu_freq] INF:  voltage = 1350mvfrequency =  864MHz
[4.696585] [cpu_freq] INF:  voltage = 1350mvfrequency =  864MHz
<6>[cpu_freq] INF:  voltage = 1250mvfrequency =  720MHz
[4.707732] [cpu_freq] INF:  voltage = 1250mvfrequency =  720MHz
<6>[cpu_freq] INF:  voltage = 1150mvfrequency =  528MHz
[4.718871] [cpu_freq] INF:  voltage = 1150mvfrequency =  528MHz
<6>[cpu_freq] INF:  voltage = 1100mvfrequency =  312MHz
[4.730004] [cpu_freq] INF:  voltage = 1100mvfrequency =  312MHz
<6>[cpu_freq] INF:  voltage = 1050mvfrequency =  144MHz
[4.741137] [cpu_freq] INF:  voltage = 1050mvfrequency =  144MHz
<6>[cpu_freq] INF:  voltage = 1000mvfrequency =0MHz
[4.752272] [cpu_freq] INF:  voltage = 1000mvfrequency =0MHz
<6>[cpu_freq] INF:---
[4.764188] [cpu_freq]
INF:---
<6>[cpu_freq] INF:sunxi_cpufreq_initcall, get cpu frequency from sysconfig,
max freq: 1008MHz, min freqz
[4.780882] [cpu_freq] INF:sunxi_cpufreq_initcall, get cpu frequency
from sysconfig, max freq: 1008Mz
<6>registered taskstats version 1
[4.795506] registered taskstats version 1
<4>[really_probe] hdmi, hdmi
[4.803665] [really_probe] hdmi, hdmi
<6>I2C: i2c-5: HDMI I2C adapter
[4.810606] I2C: i2c-5: HDMI I2C adapter
<6>disp clks: lcd 7425 pre_scale 1 hdmi 7425 pll 29700 2x 0
[4.843568] disp clks: lcd 7425 pre_scale 1 hdmi 7425 pll
29700 2x 0
<6>Console: switching to colour frame buffer device 160x45
[5.405836] Console: switching to colour frame buffer device 160x45
<4>[really_probe] 5
[5.431016] [really_probe] 5
<6>sunxi-rtc sunxi-rtc: setting system clock to 2010-01-01 00:00:00 UTC
(1262304000)
[5.441668] sunxi-rtc sunxi-rtc: setting system clock to 2010-01-01
00:00:00 UTC (1262304000)
<4>BENN axp_regulator_init
[5.452640] BENN axp_regulator_init
<4>BENN axp_battery_init
[5.458493] BENN axp_battery_init
<4>BENN regulator_virtual_consumer_init
[5.465433] BENN regulator_virtual_consumer_init
<4>BENN virtual_init
[5.472241] BENN virtual_init
<4>[really_probe] reg-20-cs-ldo2, reg-20-cs-ldo2
[5.479698] [really_probe] reg-20-cs-ldo2, reg-20-cs-ldo2
<4>[regulator_virtual_consumer_probe] enter1, pdev=reg-20-cs-ldo2,
reg_id=axp20_analog/fm
[5.493018] [regulator_virtual_consumer_probe] enter1,
pdev=reg-20-cs-ldo2, r

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

2014-03-30 Thread Olliver Schinagl


On 03/30/2014 02:25 PM, Ian Campbell wrote:

On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote:

I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current
u-boot-sunxi.git#sunxi) onto a SATA installation and have started a
git clone of the kernel, after which I'll run a build and see what
happens.


So, I did the git clone, checkout, config and "make all -j4" has been
running for quite a while now (>10 minutes) with no errors. While the
make was running I've messed around with "git archive" to produce a
tar.xz, got bored waiting for that, used wget to download a tar.xz from
kernel.org and unpacked it. All with no errors.

IOW I'm afraid it all looks OK to me.

This is all running from a SATA disk with a 2A power supply.

I'm about to go out for lunch, if it crashes etc while I'm out I'll let
you know after I get back.

Looking forward to the result, but I'm sure it'll be fine ;)

So i changed to the u-boot that comes with fedora 19 from hans, as I did 
all my previous work with that, and untarring of the extracted tarball 
works now.


I have to make a deadline for my book (building the BSP, hence i bumped 
into this) and will do more compile/extraction tests in the next few 
days as time permits on hans's u-boot. I'll run some of ssvb's 
benchmarks to test various things.


If this is all deemed stable; then it can only be u-boot that somehow 
broke. The only thing I can imagine is tolerances or power usage 
somehow. Speaking of, during the extraction power jumped from just under 
0.5 amps @ 4.85V = idle; to about 0.85 amps @ 4.75V.


Olliver


This is all on a cubietruck BTW.

ditto ;)


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] How do I add I2C RTC driver to platform?

2014-03-30 Thread Dave McLaughlin

I am trying to add the DS1307 driver to my platform. I know the DS1307 is 
present as I can run test code and read the registers. It's on the I2C-0 
bus.

I have built the driver into the kernel and I can see the following in 
dmesg output.

i2c-core: driver [rtc-ds1307] registered

but when the system boots further into the loading it displays the 
following:

drivers/rtc/hctosys.c: unable to open rtc device (rtc0)

I have tried to call the following code in *core.c* during the sun7i_init 
call, which is called before the failed line above.

i2c_register_board_info(0, ds1307_i2c_board_info,
ARRAY_SIZE(ds1307_i2c_board_info));

with the following struct:

static struct i2c_board_info __initdata ds1307_i2c_board_info[] = {
 {
 .type = "rtc-ds1307",
 .addr = 0x68,
 },
};

but the ds1307 driver *probe* function never gets called.I read elsewhere 
that I2C devices don't get probed as such so how do I get the probe 
function to be called?


-- 
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] Current u-boot crashes my cubietruck!

2014-03-30 Thread Ian Campbell

On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote:
> I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current
> u-boot-sunxi.git#sunxi) onto a SATA installation and have started a
> git clone of the kernel, after which I'll run a build and see what
> happens.

So, I did the git clone, checkout, config and "make all -j4" has been
running for quite a while now (>10 minutes) with no errors. While the
make was running I've messed around with "git archive" to produce a
tar.xz, got bored waiting for that, used wget to download a tar.xz from
kernel.org and unpacked it. All with no errors.

IOW I'm afraid it all looks OK to me.

This is all running from a SATA disk with a 2A power supply.

I'm about to go out for lunch, if it crashes etc while I'm out I'll let
you know after I get back.

This is all on a cubietruck BTW.

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] Current u-boot crashes my cubietruck!

2014-03-30 Thread Olliver Schinagl


On 03/30/2014 01:26 PM, Ian Campbell wrote:

On Sun, 2014-03-30 at 12:58 +0200, Olliver Schinagl wrote:


4271202 sunxi: add board hcore hc860
seems to be un-able to extract the tar-ball and causes an oops.


That's from ages ago, isn't it?
It is! I will now use the u-boot from even older; that came with 
fedora19, very conservative, but also 'known to be somewhat good'




Are you sure it isn't some other component which has changed recently,
e.g. the kernel?
Software wise, i'm running it quite conservative really, really old 
stuff so to say.


That said the sorts of random crashed you've been posting sound a lot
like either a DRAM issue or overheating. Either of which could be down
to u-boot setting up something wrong or bad hardware I suppose.
Overheating, maybe. It feels hottish to the touch, but can hold a finger 
on it without any problem whatsoever. Not close to the pain point. So I 
estimate < 50 C? Shouldn't be reason to be concerned imo.


Power might be the problem, i see the input voltage under heavy load 
drop to 4.65 Volts @ 0.9 amps



This is on an SSD, with a 2amps charger. I ran tinymembenches before
never exceeding 0.7 amps; could someone confirm this on the cubietruck?


I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current
u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git
clone of the kernel, after which I'll run a build and see what happens.

Cool, the strange thing is, u-boot cloned and compiled fine :(



Have you checked the checksum of the tarball you are extracting and
tried unpacking it on a known good system?
The sha1sum matches, calculated on the board, so that's good. xz -d 
completed successfully!


tar xvf fails however, with a big ass 5 page long oops.

Olliver


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] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

2014-03-30 Thread Ian Campbell

On Fri, 2014-03-28 at 12:42 +0200, Siarhei Siamashka wrote:
> https://github.com/ssvb/lima-memtester

I needed the following to get it to build on my Debian rootfs.

(and it turns out I can't run it anyway since I'm running a mainline
kernel and haven't figured out mali.ko yet, for another time I think)

-8<---

>From 72624b5d665e576057a3a869117014ae6a998578 Mon Sep 17 00:00:00 2001
From: Ian Campbell 
Date: Sun, 30 Mar 2014 13:09:55 +0100
Subject: [PATCH] Remove bashisms from scripts

[ "a" == "b" ] is a bashism, the portable alternative is [ "a" = "b" ].

Fixes the following issue on Debian where /bin/sh == dash:

# ./build-lima-memtester-static-binary.sh
./build-lima-memtester-static-binary.sh: 3: [: x: unexpected operator
./build-lima-memtester-static-binary.sh: 11: 
./build-lima-memtester-static-binary.sh: -DHAVE_NO_LIBMALI_BLOB: not found

The alternative would be to explicitly use #!/bin/bash in the script but since
the fix is trivial we might as well make it.

Signed-off-by: Ian Campbell 
---
 build-lima-memtester-static-binary.sh | 2 +-
 build-textured-cube-static-binary.sh  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/build-lima-memtester-static-binary.sh 
b/build-lima-memtester-static-binary.sh
index e84e51b..d253cbb 100755
--- a/build-lima-memtester-static-binary.sh
+++ b/build-lima-memtester-static-binary.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-if [ x$CC == "x" ]
+if [ x$CC = "x" ]
 then
 echo Note: using 'gcc' as a compiler. But it is possible to do something
 echo like \'export CC=foobar\' to override this.
diff --git a/build-textured-cube-static-binary.sh 
b/build-textured-cube-static-binary.sh
index 61f3e95..cc9f5d0 100755
--- a/build-textured-cube-static-binary.sh
+++ b/build-textured-cube-static-binary.sh
@@ -1,6 +1,6 @@
 #!/bin/sh
 
-if [ x$CC == "x" ]
+if [ x$CC = "x" ]
 then
 echo Note: using 'gcc' as a compiler. But it is possible to do something
 echo like \'export CC=foobar\' to override this.
-- 
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.

[linux-sunxi] sun6i SPL support status update

2014-03-30 Thread Hans de Goede

Hi,

After wens pointed me to:
http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;h=9275ca21ac99592c7d520a41c0914b359c27b913;hb=refs/heads/lichee/jb-4.2.2-a31

I've tried to get a full SPL going on sun6i. No luck sofar,
dropping in dram_sun6i.[c,h] +pll5 config seems to get the dram
going, at least get_ram_size() likes it. But I cannot get the
mmc to work in the SPL. I've narrowed this down to 2 problems,
which I believe are related:

1) The mmc controller will simply not work with pll6 as source,
after adding a test for the pll6 lock bit I believe this is caused
by pll6 never locking.

2) When switching the mmc controller clocksource to OSC24M, then
it does work, but gets stuck reading the first sector from the card.
I believe this happens because the card is only being supplied 3.0V'
rather then 3.3V.

Note that the same code works fine in the no SPL u-boot when loaded
through boot0 + boot1.

Likely wrong power supply voltages are the culprit in both cases
(the A31 also has a vdd-pll power pin.

So it looks like the next step is to first get the pmic going in
u-boot (which will be useful even if booted through boot0 + 1, to
enable the nic-phy if nothing else).

And then see from there. Maybe I'll take a shot at this tonight,
for now I'm going to spend some time with my family.

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] Current u-boot crashes my cubietruck!

2014-03-30 Thread Ian Campbell

On Sun, 2014-03-30 at 12:58 +0200, Olliver Schinagl wrote:

> 4271202 sunxi: add board hcore hc860
> seems to be un-able to extract the tar-ball and causes an oops.

That's from ages ago, isn't it?

Are you sure it isn't some other component which has changed recently,
e.g. the kernel?

That said the sorts of random crashed you've been posting sound a lot
like either a DRAM issue or overheating. Either of which could be down
to u-boot setting up something wrong or bad hardware I suppose.

> This is on an SSD, with a 2amps charger. I ran tinymembenches before 
> never exceeding 0.7 amps; could someone confirm this on the cubietruck?

I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current
u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git
clone of the kernel, after which I'll run a build and see what happens.

Have you checked the checksum of the tarball you are extracting and
tried unpacking it on a known good system?

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] Current u-boot crashes my cubietruck!

2014-03-30 Thread Olliver Schinagl


On 03/30/2014 12:43 PM, Olliver Schinagl wrote:

On 03/30/2014 12:33 PM, Olliver Schinagl wrote:

On 03/30/2014 12:25 PM, Olliver Schinagl wrote:

Status update:

d2a8c8d Merge tag 'v2014.04-rc2' into sunxi

seems stable and was able to compile u-boot on itself ;)
linux-sunxi kept failing due to remote hung endpoints while fetching the
full git tree, nothing unexpected there.


4362605 Merge remote-tracking branch
'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi

So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz
causes no issues yet. I'll keep using that rev for a few hours then go
onto the next one.


I shouted too early :(

[  508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0)
[  508.901743] Stack: (0xee5f9e78 to 0xee5fa000)
[  508.910451] 9e60:
  01f9 c006bab0
[  508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c
c0782b28 d1015788 ee5f9f10
[  508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010
 c051a038 c012bc38
[  508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 
ee639800 ee63989c 
[  508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007
c05442e4 c0292504 c077f97c
[  508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000
ee5f8028 ee5f8000 
[  508.986932] 9f20: 0005 c02935c0 ee825a40  0001
ee5f8000 c000e108 c003d5b8
[  508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 
ee4f9880 ee5038f0 c023b764
[  509.012692] 9f60: ee4f98b8 eeb9d080  ee5f8000 00f8
c000e108 ee5f8000 
[  509.025742] 9f80: 0005 c003db38  0006efae b6f4
b6f4 00f8 c003dbc4
[  509.038900] 9fa0:  c000df00 0006efae b6f4 
0006ef9a b6fbc4c0 
[  509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898
008513f8 000171d8 0005
[  509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030
  
[  509.078413] [] (tty_ldisc_hangup+0x3c/0x2a4) from
[] (__tty_hangup+0x124/0x378)
[  509.097651] [] (__tty_hangup+0x124/0x378) from []
(disassociate_ctty+0x7c/0x240)
[  509.117536] [] (disassociate_ctty+0x7c/0x240) from
[] (do_exit+0x294/0x784)
[  509.131797] [] (do_exit+0x294/0x784) from []
(do_group_exit+0x54/0xc8)
[  509.145622] [] (do_group_exit+0x54/0xc8) from []
(__wake_up_parent+0x0/0x20)
[  509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018)
[  509.171733] ---[ end trace 0b4cd254dfcafc0c ]---
[  509.181906] Fixing recursive fault but reboot is needed!

Going back to the parent rev,
d3686aa sunxi: use a 4MB malloc pool
and report then :)

Right, this one doesn't seem to crash; but I cant extract the .xz either...

linux-sunxi/.git/objects/pack/pack-06962d550c8aab83282655647120ce3552ca5b0e.idx
xz: (stdin): Compressed data is corrupt
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

and that constantly, sometimes it gets to go 1 file further ...

ironically the sha1 calculation worked fine

I'll go back to pre-merge and double check that.

4271202 sunxi: add board hcore hc860
seems to be un-able to extract the tar-ball and causes an oops.


[  450.179006] [] (__list_del_entry+0x8/0xb8) from 
[] (list_del+0xc/0x24)
[  450.199528] [] (list_del+0xc/0x24) from [] 
(__rmqueue+0x70/0x370)
[  450.219659] [] (__rmqueue+0x70/0x370) from [] 
(get_page_from_freelist+0x324/0x4b8)
[  450.253607] [] (get_page_from_freelist+0x324/0x4b8) from 
[] (__alloc_pages_nodemask+0x18c/0x7b4)
[  450.289644] [] (__alloc_pages_nodemask+0x18c/0x7b4) from 
[] (new_slab+0x84/0x23c)
[  450.325304] [] (new_slab+0x84/0x23c) from [] 
(__slab_alloc.constprop.54+0x20c/0x450)
[  450.362016] [] (__slab_alloc.constprop.54+0x20c/0x450) from 
[] (kmem_cache_alloc+0x70/0x18c)
[  450.400291] [] (kmem_cache_alloc+0x70/0x18c) from 
[] (ext4_alloc_inode+0x20/0xbc)
[  450.438405] [] (ext4_alloc_inode+0x20/0xbc) from 
[] (alloc_inode+0x24/0x9c)
[  450.462253] [] (alloc_inode+0x24/0x9c) from [] 
(new_inode_pseudo+0x10/0x50)
[  450.486131] [] (new_inode_pseudo+0x10/0x50) from 
[] (new_inode+0x10/0x24)
[  450.509985] [] (new_inode+0x10/0x24) from [] 
(ext4_new_inode+0x94/0xee0)
[  450.533711] [] (ext4_new_inode+0x94/0xee0) from 
[] (ext4_create+0xb0/0x150)
[  450.557750] [] (ext4_create+0xb0/0x150) from [] 
(vfs_create+0x98/0x11c)
[  450.581516] [] (vfs_create+0x98/0x11c) from [] 
(do_last+0x418/0x7e8)
[  450.605109] [] (do_last+0x418/0x7e8) from [] 
(path_openat+0xc4/0x39c)
[  450.628904] [] (path_openat+0xc4/0x39c) from [] 
(do_filp_open+0x34/0x80)
[  450.653058] [] (do_filp_open+0x34/0x80) from [] 
(do_sys_open+0xf0/0x17c)
[  450.677183] [] (do_sys_open+0xf0/0x17c) from [] 
(ret_fast_syscall+0x0/0x30)

[  450.701580] Code: c065f53a c065f587 e92d4007 e1a03000 (e896)
inux-sunxi/arch/um/drivers/pcap_kern.c
linux-sunxi/arch/um/drivers/xterm_kern.c
linux-sunxi/arch/um/drivers/cow_sys.h
linux-sunxi/arch/um/drivers/random.c
l[  450.736543] ---[ end trace 6f1dba53c1a6e6be ]---
inux-sunxi/a

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

2014-03-30 Thread Olliver Schinagl


On 03/30/2014 12:33 PM, Olliver Schinagl wrote:

On 03/30/2014 12:25 PM, Olliver Schinagl wrote:

Status update:

d2a8c8d Merge tag 'v2014.04-rc2' into sunxi

seems stable and was able to compile u-boot on itself ;)
linux-sunxi kept failing due to remote hung endpoints while fetching the
full git tree, nothing unexpected there.


4362605 Merge remote-tracking branch
'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi

So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz
causes no issues yet. I'll keep using that rev for a few hours then go
onto the next one.


I shouted too early :(

[  508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0)
[  508.901743] Stack: (0xee5f9e78 to 0xee5fa000)
[  508.910451] 9e60:
 01f9 c006bab0
[  508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c
c0782b28 d1015788 ee5f9f10
[  508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010
 c051a038 c012bc38
[  508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921 
ee639800 ee63989c 
[  508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007
c05442e4 c0292504 c077f97c
[  508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000
ee5f8028 ee5f8000 
[  508.986932] 9f20: 0005 c02935c0 ee825a40  0001
ee5f8000 c000e108 c003d5b8
[  508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18 
ee4f9880 ee5038f0 c023b764
[  509.012692] 9f60: ee4f98b8 eeb9d080  ee5f8000 00f8
c000e108 ee5f8000 
[  509.025742] 9f80: 0005 c003db38  0006efae b6f4
b6f4 00f8 c003dbc4
[  509.038900] 9fa0:  c000df00 0006efae b6f4 
0006ef9a b6fbc4c0 
[  509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898
008513f8 000171d8 0005
[  509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030
  
[  509.078413] [] (tty_ldisc_hangup+0x3c/0x2a4) from
[] (__tty_hangup+0x124/0x378)
[  509.097651] [] (__tty_hangup+0x124/0x378) from []
(disassociate_ctty+0x7c/0x240)
[  509.117536] [] (disassociate_ctty+0x7c/0x240) from
[] (do_exit+0x294/0x784)
[  509.131797] [] (do_exit+0x294/0x784) from []
(do_group_exit+0x54/0xc8)
[  509.145622] [] (do_group_exit+0x54/0xc8) from []
(__wake_up_parent+0x0/0x20)
[  509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018)
[  509.171733] ---[ end trace 0b4cd254dfcafc0c ]---
[  509.181906] Fixing recursive fault but reboot is needed!

Going back to the parent rev,
d3686aa sunxi: use a 4MB malloc pool
and report then :)

Right, this one doesn't seem to crash; but I cant extract the .xz either...

linux-sunxi/.git/objects/pack/pack-06962d550c8aab83282655647120ce3552ca5b0e.idx
xz: (stdin): Compressed data is corrupt
tar: Unexpected EOF in archive
tar: Unexpected EOF in archive
tar: Error is not recoverable: exiting now

and that constantly, sometimes it gets to go 1 file further ...

ironically the sha1 calculation worked fine

I'll go back to pre-merge and double check that.




olliver


On 03/30/2014 11:05 AM, Olliver Schinagl wrote:

On 03/29/2014 05:37 PM, Ian Campbell wrote:

On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote:

Hey all,

I was using current head on my Cubietruck; and it kept crashing. I first
tried to revert the density/width only, but that made no difference what
so ever.


Oh dear.

Aye!

Using the merge tag seems to be fine however, d2a8c8da1.

So it is one of the newer patches, will slowly progress the line, as
time permits, to find the culprit.



The first crash I had on cloning git during 3.4.79+; i first reverted to
Hans's 3.4 series from fedora 19, but then a big huge oops happened even
during boot. And consistently during boot. It doesn't seem to be power
relate either.

I have since reverted to d9aa5dd3d and that seems to be stable again.


Which branch are you running? u-boot-sunxi/sunxi I guess but you mention
Hans' series so maybe jwrdegoede/sunxi-next?

for u-boot, the linux-sunxi u-boot variant.
for the kernel, hans's 3.4 that comes with fedora 19; but I initially
experienced these problems with one the sunxi nightlies, a 3.4.79+



I will cook dinner now, and keep the board running using the d9 hash and
checkout a few newer revisions then. Stable for 10 minutes now though ;)


The obvious first one to try would be d2a8c8da1c6 "Merge tag
'v2014.04-rc2' into sunxi". Its immediate parent on the sunxi side is
d9aa5dd3d which you've already found to be stable. If you can rule that
out then the rest should be fairly tractable to bisect... Looking at
"gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master" most of them
are supposed to be "no semantic change" type cleanups or things which
don't touch cubietruck...

If it does turn out to be the merge then I think it will be time to take
a fine toothed comb to the merge...

Luckily, this does not seem the case. I will keep you all posted.

Olliver


Ian.










--
You received this message because you are subscribed to the Google Gr

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

2014-03-30 Thread Olliver Schinagl


On 03/30/2014 12:25 PM, Olliver Schinagl wrote:

Status update:

d2a8c8d Merge tag 'v2014.04-rc2' into sunxi

seems stable and was able to compile u-boot on itself ;)
linux-sunxi kept failing due to remote hung endpoints while fetching the
full git tree, nothing unexpected there.


4362605 Merge remote-tracking branch
'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi

So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz
causes no issues yet. I'll keep using that rev for a few hours then go
onto the next one.


I shouted too early :(

[  508.891546] Process login (pid: 2265, stack limit = 0xee5f82f0)
[  508.901743] Stack: (0xee5f9e78 to 0xee5fa000)
[  508.910451] 9e60: 
   01f9 c006bab0
[  508.923123] 9e80: d1015788 ee825a78 b7caf08b 0003 ee825a8c 
c0782b28 d1015788 ee5f9f10
[  508.935835] 9ea0: 0001 c00d5498 ee5f9f10 0001 ee5f8010 
 c051a038 c012bc38
[  508.948540] 9ec0: ee6398b8 ee639800 ee58cb40 271ae921  
ee639800 ee63989c 
[  508.961336] 9ee0: 0001 ee63990c ee58cb40 c0292cbc 0007 
c05442e4 c0292504 c077f97c
[  508.974074] 9f00: ee5f8000 ee5c72c0 0001 ee639800 ee5f8000 
ee5f8028 ee5f8000 
[  508.986932] 9f20: 0005 c02935c0 ee825a40  0001 
ee5f8000 c000e108 c003d5b8
[  508.999755] 9f40: b6d3c000 ee5038fc ee4f9884 c0101d18  
ee4f9880 ee5038f0 c023b764
[  509.012692] 9f60: ee4f98b8 eeb9d080  ee5f8000 00f8 
c000e108 ee5f8000 
[  509.025742] 9f80: 0005 c003db38  0006efae b6f4 
b6f4 00f8 c003dbc4
[  509.038900] 9fa0:  c000df00 0006efae b6f4  
0006ef9a b6fbc4c0 
[  509.052039] 9fc0: 0006efae b6f4 b6f4 00f8 00857898 
008513f8 000171d8 0005
[  509.065171] 9fe0: 00f8 be9a7834 b6f0a0f3 b6eaef96 6030 
  
[  509.078413] [] (tty_ldisc_hangup+0x3c/0x2a4) from 
[] (__tty_hangup+0x124/0x378)
[  509.097651] [] (__tty_hangup+0x124/0x378) from [] 
(disassociate_ctty+0x7c/0x240)
[  509.117536] [] (disassociate_ctty+0x7c/0x240) from 
[] (do_exit+0x294/0x784)
[  509.131797] [] (do_exit+0x294/0x784) from [] 
(do_group_exit+0x54/0xc8)
[  509.145622] [] (do_group_exit+0x54/0xc8) from [] 
(__wake_up_parent+0x0/0x20)

[  509.159980] Code: e2066002 e2505000 0a18 e5953000 (e5933018)
[  509.171733] ---[ end trace 0b4cd254dfcafc0c ]---
[  509.181906] Fixing recursive fault but reboot is needed!

Going back to the parent rev,
d3686aa sunxi: use a 4MB malloc pool
and report then :)



olliver


On 03/30/2014 11:05 AM, Olliver Schinagl wrote:

On 03/29/2014 05:37 PM, Ian Campbell wrote:

On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote:

Hey all,

I was using current head on my Cubietruck; and it kept crashing. I first
tried to revert the density/width only, but that made no difference what
so ever.


Oh dear.

Aye!

Using the merge tag seems to be fine however, d2a8c8da1.

So it is one of the newer patches, will slowly progress the line, as
time permits, to find the culprit.



The first crash I had on cloning git during 3.4.79+; i first reverted to
Hans's 3.4 series from fedora 19, but then a big huge oops happened even
during boot. And consistently during boot. It doesn't seem to be power
relate either.

I have since reverted to d9aa5dd3d and that seems to be stable again.


Which branch are you running? u-boot-sunxi/sunxi I guess but you mention
Hans' series so maybe jwrdegoede/sunxi-next?

for u-boot, the linux-sunxi u-boot variant.
for the kernel, hans's 3.4 that comes with fedora 19; but I initially
experienced these problems with one the sunxi nightlies, a 3.4.79+



I will cook dinner now, and keep the board running using the d9 hash and
checkout a few newer revisions then. Stable for 10 minutes now though ;)


The obvious first one to try would be d2a8c8da1c6 "Merge tag
'v2014.04-rc2' into sunxi". Its immediate parent on the sunxi side is
d9aa5dd3d which you've already found to be stable. If you can rule that
out then the rest should be fairly tractable to bisect... Looking at
"gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master" most of them
are supposed to be "no semantic change" type cleanups or things which
don't touch cubietruck...

If it does turn out to be the merge then I think it will be time to take
a fine toothed comb to the merge...

Luckily, this does not seem the case. I will keep you all posted.

Olliver


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] Current u-boot crashes my cubietruck!

2014-03-30 Thread Olliver Schinagl


Status update:

d2a8c8d Merge tag 'v2014.04-rc2' into sunxi

seems stable and was able to compile u-boot on itself ;)
linux-sunxi kept failing due to remote hung endpoints while fetching the 
full git tree, nothing unexpected there.



4362605 Merge remote-tracking branch 
'remotes/ijc/sunxi-merge-v2014.04-rc2' into sunxi


So far, that looks good; running a tar xJvf on the linux-sunxi tar.xz 
causes no issues yet. I'll keep using that rev for a few hours then go 
onto the next one.


olliver


On 03/30/2014 11:05 AM, Olliver Schinagl wrote:

On 03/29/2014 05:37 PM, Ian Campbell wrote:

On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote:

Hey all,

I was using current head on my Cubietruck; and it kept crashing. I first
tried to revert the density/width only, but that made no difference what
so ever.


Oh dear.

Aye!

Using the merge tag seems to be fine however, d2a8c8da1.

So it is one of the newer patches, will slowly progress the line, as
time permits, to find the culprit.



The first crash I had on cloning git during 3.4.79+; i first reverted to
Hans's 3.4 series from fedora 19, but then a big huge oops happened even
during boot. And consistently during boot. It doesn't seem to be power
relate either.

I have since reverted to d9aa5dd3d and that seems to be stable again.


Which branch are you running? u-boot-sunxi/sunxi I guess but you mention
Hans' series so maybe jwrdegoede/sunxi-next?

for u-boot, the linux-sunxi u-boot variant.
for the kernel, hans's 3.4 that comes with fedora 19; but I initially
experienced these problems with one the sunxi nightlies, a 3.4.79+



I will cook dinner now, and keep the board running using the d9 hash and
checkout a few newer revisions then. Stable for 10 minutes now though ;)


The obvious first one to try would be d2a8c8da1c6 "Merge tag
'v2014.04-rc2' into sunxi". Its immediate parent on the sunxi side is
d9aa5dd3d which you've already found to be stable. If you can rule that
out then the rest should be fairly tractable to bisect... Looking at
"gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master" most of them
are supposed to be "no semantic change" type cleanups or things which
don't touch cubietruck...

If it does turn out to be the merge then I think it will be time to take
a fine toothed comb to the merge...

Luckily, this does not seem the case. I will keep you all posted.

Olliver


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] Current u-boot crashes my cubietruck!

2014-03-30 Thread Olliver Schinagl


On 03/29/2014 05:37 PM, Ian Campbell wrote:

On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote:

Hey all,

I was using current head on my Cubietruck; and it kept crashing. I first
tried to revert the density/width only, but that made no difference what
so ever.


Oh dear.

Aye!

Using the merge tag seems to be fine however, d2a8c8da1.

So it is one of the newer patches, will slowly progress the line, as 
time permits, to find the culprit.



The first crash I had on cloning git during 3.4.79+; i first reverted to
Hans's 3.4 series from fedora 19, but then a big huge oops happened even
during boot. And consistently during boot. It doesn't seem to be power
relate either.

I have since reverted to d9aa5dd3d and that seems to be stable again.


Which branch are you running? u-boot-sunxi/sunxi I guess but you mention
Hans' series so maybe jwrdegoede/sunxi-next?

for u-boot, the linux-sunxi u-boot variant.
for the kernel, hans's 3.4 that comes with fedora 19; but I initially 
experienced these problems with one the sunxi nightlies, a 3.4.79+



I will cook dinner now, and keep the board running using the d9 hash and
checkout a few newer revisions then. Stable for 10 minutes now though ;)


The obvious first one to try would be d2a8c8da1c6 "Merge tag
'v2014.04-rc2' into sunxi". Its immediate parent on the sunxi side is
d9aa5dd3d which you've already found to be stable. If you can rule that
out then the rest should be fairly tractable to bisect... Looking at
"gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master" most of them
are supposed to be "no semantic change" type cleanups or things which
don't touch cubietruck...

If it does turn out to be the merge then I think it will be time to take
a fine toothed comb to the merge...

Luckily, this does not seem the case. I will keep you all posted.

Olliver


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] Re: [PATCH] Add Full Duplex support to SPI (v2)

2014-03-30 Thread ocheretianko . m

понедельник, 17 февраля 2014 г., 22:27:29 UTC+2 пользователь 
darius...@gmail.com написал:
> If you are interested I can send some working code for nrf24l01. I just mixed 
> all information above with my previous problems with SPI and i have got a 
> nrf24l01 connected to CB successfully communicating with RPi through the same 
> library. Unfortunately, it needs some changes in kernel GPIO module too.
> 
> See a working example:
> http://www.pl.image-share.com/upload/260/31.png

Hi! I have working spi on cubietruck and bunch of nRF24l01 transceivers.
I'm the one who's interested in your code =)

-- 
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] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] sun6i SPL support status update

RE: [linux-sunxi] Issue - [cpu_freq] ERR:try to get regulator failed, core vdd will not changed!

Re: [linux-sunxi] Issue - [cpu_freq] ERR:try to get regulator failed, core vdd will not changed!

Re: [linux-sunxi] Issue - [cpu_freq] ERR:try to get regulator failed, core vdd will not changed!

Re: [linux-sunxi] Re: New u-boot sunxi-next available for testing

Re: [linux-sunxi] Azpen A727 / A23 chip

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Issue - [cpu_freq] ERR:try to get regulator failed, core vdd will not changed!

Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

Re: [linux-sunxi] Azpen A727 / A23 chip

Re: [linux-sunxi] [PATCH 3.4] sun7i: enable performance counters

Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

[linux-sunxi] Azpen A727 / A23 chip

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Re: A20 + OV5640 (parallel) issues

[linux-sunxi] Issue - [cpu_freq] ERR:try to get regulator failed, core vdd will not changed!

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

[linux-sunxi] How do I add I2C RTC driver to platform?

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code

[linux-sunxi] sun6i SPL support status update

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Current u-boot crashes my cubietruck!

Re: [linux-sunxi] Re: [PATCH] Add Full Duplex support to SPI (v2)

34 matches

Site Navigation

Mail list logo

Footer information