Re: [linux-sunxi] Login to wiki not possible

[Luc Verhaegen]

On Fri, Sep 04, 2015 at 01:11:10AM -0700, m.silentcr...@gmail.com wrote:
> Hi,
> 
> the login to the wiki isn't possible at the moment. It throws the following 
> error:
> 
> > Warning: Unknown: write failed: No space left on device (28) in Unknown on 
> > line 0
> >
> > Warning: Unknown: Failed to write session data (files). Please verify that 
> > the current setting of session.save_path is correct (/var/lib/php5) in 
> > Unknown on line 0
> 
> If it's not just me who sees this message, then maybe somebody can take care 
> of it?
> 
> Thanks and regards,
> 
> Timo

Fixed now. Thanks for reporting this!

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] Allwinner pack tools adventures

[Ivan Kozic]

Hi all,

Quick progress update:

LiveSuit:
I have fixed the error regarding Linux LiveSuit, there were some fex tool 
files missing in the image, now it behaves the same like PhoenixSuit in 
Windows (trying to update SD-Card instead of NAND), but at least images are 
not invalid anymore.

Second issue stays for now - the way I see it, most of download/flashing 
stuff is actually in these card folders where fex tools are. So far I have 
tried several different versions of these tools:
- original SDK versions (both from /boot/pack/chips/sun7i/eFex and 
/tools/pack/chips/sun7i/eFex; yes, they are different (?!?)) - these are 
Fes version 097.5,
- extracted from Olimex Android image for Olinuxino Micro A20 - these are 
Fes version 098,
- "new" SDK A20  versions (not really sure if really new, but newer than 
original) - these are again the same 097.5.

I have also tried cardscript and cardtool from both versions and all of 
these attempts were unsuccessful - LiveSuit/PhoenixSuit is always trying to 
update SD Card instead of NAND... ("Hello SDCARD register" instead of 
"Hello NAND register" in FES UART output). Getting a bit frustrating 
honestly...

I'd like to try out images that do work (extract and use their tools), so:
@Piotr:
Can you give me a link to a known working cubie image that you were using 
(original one)? The one which worked for NAND out of the box. Also, please 
tell me how exactly did you extract it (image_repacker?). Thanks!

Cheers!

-- 
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] Allwinner pack tools adventures

[Ivan Kozic]

Hi Piotr,

Well, I'm officially ashamed :) Of course, culprit was something stupid
that I took for granted from the start - I've accidentally took
sys_config.fex for SD-Card... So basically, these binary utilities for
download/burn (all those fel/fes fex files) actually first read script.bin
(or sys_config.fex in binary format) - [target] section has the following
item:

storage_type = 0

This was set to '1' in my sys_config (0=NAND, 1=SD)... Now my image works
as it should in LiveSuit :) I've just flashed it by using LiveSuit in
Linux. But...

Since the first boot failed, I also remembered how badly I want to remove
'boot' partition with ANDROID! magic (actually a RAW bImage of Android
kernel, no fs whatsoever). This one has to go since I do not want to
download that partition. It is also a bit dangerous, since if something
fails with the bootloader FAT partition, I've seen several times that it
boots this ancient kernel (I've just copied /dev/nandb from Olimex like a
year ago and been using it in this format ever since - maybe not the best
idea I've had ;) ).

In fact I only want to have bootloader and rootfs, maybe one more user
partition. If anyone's interested in removing 'boot' - just comment out the
check in SPL (it's in boot.axf 'app'):

boot/boot1/apps/Boot_Android/BootOS/BootOS.c:
- if (memcmp(fb_hdr->magic, FASTBOOT_BOOT_MAGIC, 8)) {
- __inf("boot1: bad boot image magic, maybe not a boot.img?\n");
- return -1;
- }

That's it. Say byebye to the 'boot' magic.

I still have to prep some stuff before I leave, but I'll try to update the
wiki page or at least give you pointers on how to do it afterwards. This
whole thing along with 'boot' partition removal should go there, since I've
heard tons of complaints about this, no one using Linux really wants it
there.

So, let's continue afterwards - I'll let you know of my progress.

Cheers!


On Fri, Sep 4, 2015 at 2:48 PM, Ivan Kozic  wrote:

> Hi Piotr,
>
> Thanks, I'll try it out straight away.
>
> On Fri, Sep 4, 2015 at 2:45 PM, Piotr Król  wrote:
>
>> On Fri, Sep 04, 2015 at 04:26:09AM -0700, Ivan Kozic wrote:
>> > Hi all,
>> >
>> > Quick progress update:
>> >
>> > LiveSuit:
>> > I have fixed the error regarding Linux LiveSuit, there were some fex
>> tool files
>> > missing in the image, now it behaves the same like PhoenixSuit in
>> Windows
>> > (trying to update SD-Card instead of NAND), but at least images are not
>> invalid
>> > anymore.
>> >
>> > Second issue stays for now - the way I see it, most of
>> download/flashing stuff
>> > is actually in these card folders where fex tools are. So far I have
>> tried
>> > several different versions of these tools:
>> > - original SDK versions (both from /boot/pack/chips/sun7i/eFex and
>> /tools/pack/
>> > chips/sun7i/eFex; yes, they are different (?!?)) - these are Fes
>> version 097.5,
>> > - extracted from Olimex Android image for Olinuxino Micro A20 - these
>> are Fes
>> > version 098,
>> > - "new" SDK A20  versions (not really sure if really new, but newer than
>> > original) - these are again the same 097.5.
>> >
>> > I have also tried cardscript and cardtool from both versions and all of
>> these
>> > attempts were unsuccessful - LiveSuit/PhoenixSuit is always trying to
>> update SD
>> > Card instead of NAND... ("Hello SDCARD register" instead of "Hello NAND
>> > register" in FES UART output). Getting a bit frustrating honestly...
>> >
>> > I'd like to try out images that do work (extract and use their tools),
>> so:
>> > @Piotr:
>> > Can you give me a link to a known working cubie image that you were
>> using
>> > (original one)? The one which worked for NAND out of the box. Also,
>> please tell
>> > me how exactly did you extract it (image_repacker?). Thanks!
>>
>> Hi Ivan,
>> image that works for me is:
>>
>> http://dl.cubieboard.org/software/a20-cubietruck/debian/debieez/ct-debian-nand.img.gz
>>
>> To change it I used:
>> http://forum.xda-developers.com/showpost.php?p=28329544=1
>>
>> Simply:
>> ./imgrepacker ct-debian-nand.img
>> to extract and:
>> ./imgrepacker ct-debian-nand.img.dump
>> to pack.
>>
>> This image contain a lot of fex files. I mainly changed
>> bootloader.fex.iso and rootfs.fex.iso.
>>
>> Thanks,
>> --
>> Piotr Król
>> 3mdeb - Embedded Systems Consulting
>> Burgaska 9D/10
>> 80-287 Gdansk POLAND
>> tel: +48880673344
>> http://3mdeb.com | @3mdeb_com
>>
>> --
>> 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/IoOEbf-X11E/unsubscribe.
>> To unsubscribe from this group and all its topics, 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 

[linux-sunxi] Re: Regression in uboot mmc code causing boot failure.

[Yousong Zhou]

Hi,

On 1 September 2015 at 00:07, Hans de Goede  wrote:
> Hi,
>
> On 30-08-15 10:30, Yousong Zhou wrote:
>>
>> Hi
>>
>> In an OpenWrt ticket [1] I reported two issues encountered by 2 SD
>> cards of mine.
>>
>> One of them failed with `error reading clusters` when reading a uImage
>> file of size about 2MB.  This issue happened after we switch from DMA
>> transfer to `mmc_trans_data_by_cpu()`.  It is caused by fixed 2
>> seconds timeout without considering the transfer size.  A fixed was
>> just posted [2] in OpenWrt-devel list.
>>
>> The other card failed at the SPL stage with `spl: mmc init failed with
>> error: -19`.  That -19 is defined as macro TIMEOUT in U-Boot and it is
>> comparable to -110 in Linux kernel defined as ETIMEOUT.  This problem
>> happened after we switch the clock divider from the
>> controller-internal one to mod0-clock (commit fc3a832 "sunxi: mmc:
>> Properly setup mod-clk and clock sampling phases").  Actually TIMEOUT
>> is not the root cause here.  It is caused by
>> SUNXI_MMC_RINT_RESP_CRC_ERROR when trying to switch the card to
>> highspeed mode.  Unfortunately I am not familiar with sunxi clock
>> system enough to provide a fix for this.
>>
>> More details can be found in the ticket description in link [1]
>>
>> [1] https://dev.openwrt.org/ticket/20387
>> [2] http://patchwork.ozlabs.org/patch/512163/
>
>
> Thanks for the patch I've merged it into my sunxi u-boot tree,
> and send a pullreq for merging it into u-boot master.
>
> As for the other issue I've no idea what is going on there.

I just made a fix for that issue.  It worked both for U-Boot and
Linux.  The approach is that we change the bus frequency to 52MHz
before (instead of after) the access change.  Well, the patch needs to
be applied on the core code.  I am not sure of the possible side
effects on other cards...

Patch attached for both U-Boot and Linux.

Regards

yousong

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


134-mmc-core-Set-clock-before-switching-to-highspeed-mod.patch
Description: Binary data


0001-mmc-add-debug-message-on-failure-of-switching-to-hig.patch
Description: Binary data


0002-mmc-set-clock-speed-before-switching-to-highspeed.patch
Description: Binary data

Re: [linux-sunxi] Allwinner pack tools adventures

[Ivan Kozic]

Hi Piotr,

Thanks, I'll try it out straight away.

On Fri, Sep 4, 2015 at 2:45 PM, Piotr Król  wrote:

> On Fri, Sep 04, 2015 at 04:26:09AM -0700, Ivan Kozic wrote:
> > Hi all,
> >
> > Quick progress update:
> >
> > LiveSuit:
> > I have fixed the error regarding Linux LiveSuit, there were some fex
> tool files
> > missing in the image, now it behaves the same like PhoenixSuit in Windows
> > (trying to update SD-Card instead of NAND), but at least images are not
> invalid
> > anymore.
> >
> > Second issue stays for now - the way I see it, most of download/flashing
> stuff
> > is actually in these card folders where fex tools are. So far I have
> tried
> > several different versions of these tools:
> > - original SDK versions (both from /boot/pack/chips/sun7i/eFex and
> /tools/pack/
> > chips/sun7i/eFex; yes, they are different (?!?)) - these are Fes version
> 097.5,
> > - extracted from Olimex Android image for Olinuxino Micro A20 - these
> are Fes
> > version 098,
> > - "new" SDK A20  versions (not really sure if really new, but newer than
> > original) - these are again the same 097.5.
> >
> > I have also tried cardscript and cardtool from both versions and all of
> these
> > attempts were unsuccessful - LiveSuit/PhoenixSuit is always trying to
> update SD
> > Card instead of NAND... ("Hello SDCARD register" instead of "Hello NAND
> > register" in FES UART output). Getting a bit frustrating honestly...
> >
> > I'd like to try out images that do work (extract and use their tools),
> so:
> > @Piotr:
> > Can you give me a link to a known working cubie image that you were using
> > (original one)? The one which worked for NAND out of the box. Also,
> please tell
> > me how exactly did you extract it (image_repacker?). Thanks!
>
> Hi Ivan,
> image that works for me is:
>
> http://dl.cubieboard.org/software/a20-cubietruck/debian/debieez/ct-debian-nand.img.gz
>
> To change it I used:
> http://forum.xda-developers.com/showpost.php?p=28329544=1
>
> Simply:
> ./imgrepacker ct-debian-nand.img
> to extract and:
> ./imgrepacker ct-debian-nand.img.dump
> to pack.
>
> This image contain a lot of fex files. I mainly changed
> bootloader.fex.iso and rootfs.fex.iso.
>
> Thanks,
> --
> Piotr Król
> 3mdeb - Embedded Systems Consulting
> Burgaska 9D/10
> 80-287 Gdansk POLAND
> tel: +48880673344
> http://3mdeb.com | @3mdeb_com
>
> --
> 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/IoOEbf-X11E/unsubscribe.
> To unsubscribe from this group and all its topics, 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] Allwinner pack tools adventures

[Piotr Król]

On Fri, Sep 04, 2015 at 04:26:09AM -0700, Ivan Kozic wrote:
> Hi all,
> 
> Quick progress update:
> 
> LiveSuit:
> I have fixed the error regarding Linux LiveSuit, there were some fex tool 
> files
> missing in the image, now it behaves the same like PhoenixSuit in Windows
> (trying to update SD-Card instead of NAND), but at least images are not 
> invalid
> anymore.
> 
> Second issue stays for now - the way I see it, most of download/flashing stuff
> is actually in these card folders where fex tools are. So far I have tried
> several different versions of these tools:
> - original SDK versions (both from /boot/pack/chips/sun7i/eFex and 
> /tools/pack/
> chips/sun7i/eFex; yes, they are different (?!?)) - these are Fes version 
> 097.5,
> - extracted from Olimex Android image for Olinuxino Micro A20 - these are Fes
> version 098,
> - "new" SDK A20  versions (not really sure if really new, but newer than
> original) - these are again the same 097.5.
> 
> I have also tried cardscript and cardtool from both versions and all of these
> attempts were unsuccessful - LiveSuit/PhoenixSuit is always trying to update 
> SD
> Card instead of NAND... ("Hello SDCARD register" instead of "Hello NAND
> register" in FES UART output). Getting a bit frustrating honestly...
> 
> I'd like to try out images that do work (extract and use their tools), so:
> @Piotr:
> Can you give me a link to a known working cubie image that you were using
> (original one)? The one which worked for NAND out of the box. Also, please 
> tell
> me how exactly did you extract it (image_repacker?). Thanks!

Hi Ivan,
image that works for me is:
http://dl.cubieboard.org/software/a20-cubietruck/debian/debieez/ct-debian-nand.img.gz

To change it I used:
http://forum.xda-developers.com/showpost.php?p=28329544=1

Simply:
./imgrepacker ct-debian-nand.img
to extract and:
./imgrepacker ct-debian-nand.img.dump
to pack.

This image contain a lot of fex files. I mainly changed
bootloader.fex.iso and rootfs.fex.iso.

Thanks,
-- 
Piotr Król
3mdeb - Embedded Systems Consulting
Burgaska 9D/10
80-287 Gdansk POLAND
tel: +48880673344
http://3mdeb.com | @3mdeb_com

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

[linux-sunxi] Re: [PATCH v2] mtd: nand: sunxi: rely on nand_dt_init initialization

[Brian Norris]

On Wed, Sep 02, 2015 at 10:21:08AM +0200, Boris Brezillon wrote:
> On Tue, 1 Sep 2015 18:16:16 -0700
> Brian Norris  wrote:
> > There's also a subtle change here that affects more than just here: you
> > don't have a good way to tell the difference between "no ECC mode
> > provide" and NAND_ECC_NONE. Perhaps we can modify the nand_ecc_modes_t
> > enum to include a "uninitialized" value? I'm not sure if that'd work
> > best as 0, -1, or something else, in case there are people making
> > assumptions elsewhere...
> 
> It really depends on what we want to do. I see at least two solutions
> for this problem:
> 1/ keep the nand_dt_init() implementation as is and ask
>nand_scan_ident() callers to pre-set their default value in ecc.mode.
>This should work since ecc.mode is only overridden if ecc_mode is >= 0.
> 2/ modify the nand_dt_init function to assign the ecc_mode even if it
>is negative, or create a new value in the enum (NAND_ECC_UNSPECIFIED
>= -1) and assign it to ecc.mode when ecc_mode is negative.
> 
> 1# does not require any change, but if we choose this solution, we
> should make it clear that NAND controller drivers should set their
> default value before calling nand_scan_ident().

I'm OK with your choice of #1. Your v3 patch looks fine.

> And if go for 2#, that's not like we'll have to patch a lot of
> drivers (AFAICT, the only user in 4.2 is the brcmnand driver) ;-).

:) Well, I thought there were others in the pipeline. I've at least
reviewed another addition somewhat recently, but it wasn't quite ready.

Brian

-- 
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: Regression in uboot mmc code causing boot failure.

[Hans de Goede]

Hi,

On 04-09-15 16:24, Yousong Zhou wrote:

Hi,

On 1 September 2015 at 00:07, Hans de Goede  wrote:

Hi,

On 30-08-15 10:30, Yousong Zhou wrote:


Hi

In an OpenWrt ticket [1] I reported two issues encountered by 2 SD
cards of mine.

One of them failed with `error reading clusters` when reading a uImage
file of size about 2MB.  This issue happened after we switch from DMA
transfer to `mmc_trans_data_by_cpu()`.  It is caused by fixed 2
seconds timeout without considering the transfer size.  A fixed was
just posted [2] in OpenWrt-devel list.

The other card failed at the SPL stage with `spl: mmc init failed with
error: -19`.  That -19 is defined as macro TIMEOUT in U-Boot and it is
comparable to -110 in Linux kernel defined as ETIMEOUT.  This problem
happened after we switch the clock divider from the
controller-internal one to mod0-clock (commit fc3a832 "sunxi: mmc:
Properly setup mod-clk and clock sampling phases").  Actually TIMEOUT
is not the root cause here.  It is caused by
SUNXI_MMC_RINT_RESP_CRC_ERROR when trying to switch the card to
highspeed mode.  Unfortunately I am not familiar with sunxi clock
system enough to provide a fix for this.

More details can be found in the ticket description in link [1]

[1] https://dev.openwrt.org/ticket/20387
[2] http://patchwork.ozlabs.org/patch/512163/



Thanks for the patch I've merged it into my sunxi u-boot tree,
and send a pullreq for merging it into u-boot master.

As for the other issue I've no idea what is going on there.


I just made a fix for that issue.  It worked both for U-Boot and
Linux.  The approach is that we change the bus frequency to 52MHz
before (instead of after) the access change.  Well, the patch needs to
be applied on the core code.  I am not sure of the possible side
effects on other cards...

Patch attached for both U-Boot and Linux.


Can you send the linux version upstream please?

Send it to Ulf Hansson  with
linux-...@vger.kernel.org and me in the Cc.

Then we can see what upstream thinks about this, this might
actually be a sunxi-mmc code bug somewhere ...

Once we've figured out what to do on the kernel side, we
can simply apply the same fix to u-boot.

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] Allwinner pack tools adventures

[Thomas Kaiser]

Ivan Kozic wrote:

> I didn't know if anyone would complain about it being not so structured, 
> as I've never updated any public wiki pages
>

You could start summarizing/editing the stuff below 
http://linux-sunxi.org/index.php?title=User_talk:Ikozic=edit=1 
as long as it's early "work in progress" and then move it to where it 
belongs to if you feel you might want feedback/corrections from others.

-- 
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] musb: sunxi: Ignore VBus errors in host-only mode

[Olliver Schinagl]

Hey Hans,

On 07-08-15 10:45, Olliver Schinagl wrote:


If you change the dr_mode to host then you _must_ also remove any 
id_det and vbus_det
gpio settings from the usb_phy node in the dts, as the sun4i phy code 
detects

host vs otg mode by checking for the presence of these.

Yes, this fixes it and makes it work. Thanks.

I've been going back to this and am wondering if this is something I can 
look into to fix properly? E.g. if the dts sets dr_mode = host, can we 
simply ignore the pins and treat them as unset?


Reason why I'm asking, the board we are using, the Lime2 has all the 
stuff required for regular otg mode. The cables however that we connect 
to the miniusb however do not force host only mode via the id pin, which 
would have been the preferred way. We use a 'shield' for our lime with 
various connections and thus have a dts for this shield, which includes 
the lime2 dts. In the lime2 dts you want the otg pins enabled and set in 
the generic usbphy section.


In my overlay, I ideally don't want to unset the pins, but do want to 
set dr_mode (as i can't force it from userspace can I?). The logical 
thing in my mind, would be to then just ignore those pins even when set, 
right?


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.

[linux-sunxi] Login to wiki not possible

[m . silentcreek]

Hi,

the login to the wiki isn't possible at the moment. It throws the following 
error:

> Warning: Unknown: write failed: No space left on device (28) in Unknown on 
> line 0
>
> Warning: Unknown: Failed to write session data (files). Please verify that 
> the current setting of session.save_path is correct (/var/lib/php5) in 
> Unknown on line 0

If it's not just me who sees this message, then maybe somebody can take care of 
it?

Thanks and regards,

Timo

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