[linux-sunxi] U-boot for SOCHIP S3
Can someone please point me to a u-boot that works on the Sochip S3? V3S is DDR2, S3 is DDR3. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAKON4OzpJD7MqHLDNQbpnO4-yz8mOfcAPCvT5UxjHYTim8UOsA%40mail.gmail.com.
[linux-sunxi] Re: Allwinner R11, updated V3S?
Widora has made a dev board for it https://item.taobao.com/item.htm?spm=a230r.1.14.1.164f3c8blfHq8u=587925184119=1=15#detail On Fri, Sep 13, 2019 at 12:38 PM jonsm...@gmail.com wrote: > > Any know what is up with the Allwinner R11? Are they bringing back the V3S? > http://www.allwinnertech.com/uploads/pdf/201903071018226c.pdf > > All I have is the brief, does anyone have any more docs? > > It looks like they have exposed the I2S lines and added another microphone > ADC. > > Dual-mic middle-near field intelligent voice interaction >The R11 integrates ADC,DAC, and I2S/TDM interface, supports FPU and > NEON, which meets requirements in dual-mic noise reduction, AEC, > wake-up, local command word algorithm and cloud ASR，IOT interaction > functions. The R11 is an ideal choice of middle-near field voice > interaction solution. > > -- > Jon Smirl > jonsm...@gmail.com -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAKON4Owfc3nY90mk-xSbcykG4b8ufu0S4GitjNvPdZ4ZrB%3D%3D%3Dg%40mail.gmail.com.
[linux-sunxi] Allwinner R11, updated V3S?
Any know what is up with the Allwinner R11? Are they bringing back the V3S? http://www.allwinnertech.com/uploads/pdf/201903071018226c.pdf All I have is the brief, does anyone have any more docs? It looks like they have exposed the I2S lines and added another microphone ADC. Dual-mic middle-near field intelligent voice interaction The R11 integrates ADC,DAC, and I2S/TDM interface, supports FPU and NEON, which meets requirements in dual-mic noise reduction, AEC, wake-up, local command word algorithm and cloud ASR，IOT interaction functions. The R11 is an ideal choice of middle-near field voice interaction solution. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/linux-sunxi/CAKON4Oz-w-3vqdwTMioxNLjFLH5ejnLzcOeOcmdot5gyy%3DVpyg%40mail.gmail.com.
Re: [linux-sunxi] Re: Help with V3s
hich should correspond >>>> >> to: >>>> >>> >>>> >>> # write u-boot >>>> >>> dd if=u-boot.fex of=/dev/sdX bs=1k seek=16400 >>>> >> >>>> >> >>>> >> However it doesn't work. >>>> >> >>>> >> I've also tried booting with Icenowys mainline u-boot branch >>>> >> https://github.com/Icenowy/u-boot-1/tree/v3s. >>>> >> I've modified the LichePieZero DTS file to correspond to the board >>>> >> pinout. >>>> >> However I get no message on the console whatsoever. Tried booting >>>> >> both >>>> >> from USB and SDcard. >>>> >> >>>> >> Digging through the commit messages for v3s mainline u-boot support >>>> >> I've >>>> >> noticed that SPL is disabled. Maybe that is the problem ? >>>> >> >>>> >> Does anyone have any idea on how to proceed ? I'd like to get this >>>> >> board >>>> >> up and running with mainline kernel so that I could port some stuff >>>> >> over >>>> >> from lichee. >>>> >> >>>> >> Any help is appreciated. >>>> >> >>>> >> Best, >>>> >> Petar >>>> > >>>> > >>>> > Yes and then it restarts SPL. However I can't yet figure out why it is >>>> > happening. >>>> > u-boot-sunxi-with-spl.bin builds just fine. Can't understand why it >>>> > fails to >>>> > load. >>>> > >>>> > Clear the head first and then back to debugging I guess :) >>>> >>>> If the image does not have the correct header, the ROM restarts the >>>> boot process and trys again to find an image with the correct header. >>>> >>>> >>>> > >>>> > -- >>>> > You received this message because you are subscribed to the Google >>>> > Groups >>>> > "linux-sunxi" group. >>>> > To unsubscribe from this group and stop receiving emails from it, send >>>> > an >>>> > email to linux-sunxi...@googlegroups.com. >>>> > For more options, visit https://groups.google.com/d/optout. >>>> >>>> >>>> >>>> -- >>>> Jon Smirl >>>> jons...@gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] h.264 encoder on V3
The V3 datasheet is unclear on how the h.264 encoder works. All of the other security camera chips on the market can make two or three simultaneous h.264 streams from their encoders. The secondary streams are just scaled down versions of the high resolution stream. This supports letting a DVR/desktop access the full resolution stream and cell phones can check the lower resolution stream. Another use is tiled display on a security monitor, the tiles are the low res streams, when you zoom onto a specific camera it switches to the high res stream. Does the V3 h.264 encoder support this? I can't determine one way or the other if it does. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] CedarX on V3
Is CedarX on the V3 the same CedarX that is on other AW processors? Or is it enhanced? For example the h.264 encoders on Grain camera SOCs can compress 1080P down to 500Kb/s and it is still decent to look at. When I did experiments on A20 the most highest compression I was able to achieve was 2Mb/s. The stream looked decent, but no combination of options would push it down below 2Mb/s. Another good feature of the Grain encoder is support for multiple simultaneous output streams. For example I can tell it to make h.264 streams at 1080P, 640P, 320P simultaneously. Does the V3 encoder support multiple output streams? >From what I can tell from the non-existent information in the datasheet, this is the same old Allwinner CedarX unit. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Help with V3s
On Thu, Mar 23, 2017 at 2:00 PM, Petar Dimitrijevic <petar.dimitrije...@gmail.com> wrote: > > > On Tuesday, March 21, 2017 at 4:06:56 PM UTC+1, Petar Dimitrijevic wrote: >> >> Hi, >> >> I've received a V3s development board few days ago. It has an android FW >> with Camdroid installed booting from SPI NOR flash. >> Picture of the board as well as the fex file are attached to this message. >> >> >> The SDK generates android image which can be programmed to the NOR flash. >> >> However I'm unable to boot Linux. Currently I'm stuck at making u-boot >> work. The SDK ships with 2011.09 Allwinner u-boot. >> >> I'm following http://linux-sunxi.org/H3_Manual_build_howto#Building_u-boot >> and http://linux-sunxi.org/SDK_build_howto. >> When I copy the uboot images to the sdcard I get the following output in >> the serial console: >> >>> HELLO! BOOT0 is starting! >>> get_ifm reg_val=7 >>> ===i2c gpio === 2222 >>> PMU: axp version ok >>> after set, dcdc2 =1100mv >>> axp20 set dcdc2 success >>> DRAM DRIVE INFO: V0.7 >>> DRAM Type = 2 (2:DDR2,3:DDR3,6:LPDDR2,7:LPDDR3) >>> DRAM CLK = 408 MHz >>> DRAM zq value: 39bb >>> DRAM size = 64 MB >>> card boot number = 0 >>> card no is 0 >>> sdcard 0 line count 0 >>> [mmc]: mmc driver ver 2014-8-11 15:06:39 >>> [mmc]: ***Try SD card 0*** >>> [mmc]: SD/MMC Card: 4bit, capacity: 3768MB >>> [mmc]: vendor: Man 0002544d Snr 21ab4a86 >>> [mmc]: product: SA04G >>> [mmc]: revision: 1.3 >>> [mmc]: ***SD/MMC 0 init OK!!!*** >>> sdcard 0 init ok >>> ERROR! NOT find the head of uboot. >>> Jump to Fel. >> >> >> I presume that u-boot0 can't find u-boot1 header. I've checked the source >> code and UBOOT_START_SECTOR_IN_SDMMC is 32800 which should correspond to: >>> >>> # write u-boot >>> dd if=u-boot.fex of=/dev/sdX bs=1k seek=16400 >> >> >> However it doesn't work. >> >> I've also tried booting with Icenowys mainline u-boot branch >> https://github.com/Icenowy/u-boot-1/tree/v3s. >> I've modified the LichePieZero DTS file to correspond to the board pinout. >> However I get no message on the console whatsoever. Tried booting both >> from USB and SDcard. >> >> Digging through the commit messages for v3s mainline u-boot support I've >> noticed that SPL is disabled. Maybe that is the problem ? >> >> Does anyone have any idea on how to proceed ? I'd like to get this board >> up and running with mainline kernel so that I could port some stuff over >> from lichee. >> >> Any help is appreciated. >> >> Best, >> Petar > > > Yes and then it restarts SPL. However I can't yet figure out why it is > happening. > u-boot-sunxi-with-spl.bin builds just fine. Can't understand why it fails to > load. > > Clear the head first and then back to debugging I guess :) If the image does not have the correct header, the ROM restarts the boot process and trys again to find an image with the correct header. > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Help with V3s
t;> >> one I have. Thanks. >> >> >> >> On Tuesday, March 21, 2017 at 7:45:31 PM UTC+1, Benjamin Henrion wrote: >> >>> On Tue, Mar 21, 2017 at 4:06 PM, Petar Dimitrijevic >> >>> <petar.dim...@gmail.com> wrote: >> >>>> Hi, >> >>>> >> >>>> I've received a V3s development board few days ago. It has an android >> >>>> FW >> >>>> with Camdroid installed booting from SPI NOR flash. >> >>>> Picture of the board as well as the fex file are attached to this >> >>>> message. >> >>> >> >>> Where have you bought it? >> >>> >> >>>> The SDK generates android image which can be programmed to the NOR >> >>>> flash. >> >>> >> >>> I just made a mirror of V3S SDK here: >> >>> >> >>> http://filez.zoobab.com/allwinner/v3s/ >> >>> >> >>> Good luck, >> >>> >> >>> -- >> >>> Benjamin Henrion >> >>> FFII Brussels - +32-484-566109 - +32-2-3500762 >> >>> "In July 2005, after several failed attempts to legalise software >> >>> patents in Europe, the patent establishment changed its strategy. >> >>> Instead of explicitly seeking to sanction the patentability of >> >>> software, they are now seeking to create a central European patent >> >>> court, which would establish and enforce patentability rules in their >> >>> favor, without any possibility of correction by competing courts or >> >>> democratically elected legislators." >> > >> > I finally managed to boot mainline u-boot at least initially. More >> > precisely I was able to see u-boot output. It was booting previously as >> > well. >> > >> > Beside changing the DTS file with UART2 additional change in >> > include/configs/sunxi-common.h is required. >> > >> >> diff --git a/include/configs/sunxi-common.h >> >> b/include/configs/sunxi-common.h >> >> index 6bcb9e692c..cc329daf8d 100644 >> >> --- a/include/configs/sunxi-common.h >> >> +++ b/include/configs/sunxi-common.h >> >> @@ -261,7 +261,7 @@ extern int soft_i2c_gpio_scl; >> >> #endif >> >> >> >> #ifndef CONFIG_CONS_INDEX >> >> -#define CONFIG_CONS_INDEX 1 /* UART0 */ >> >> +#define CONFIG_CONS_INDEX 3 /* UART2 */ >> >> #endif >> > >> > After this change I get the following console output: >> >> U-Boot SPL 2017.01-rc2-01115-g252ef38050-dirty (Mar 22 2017 - 16:58:12) >> >> DRAM: 64 MiB >> >> Trying to boot from MMC1 >> > >> > I tried setting up primary boot partition. However nothing works so far. >> > Just to be clear I'm booting from MMC0. >> > >> > However the card removal is detected: >> > >> >> Trying to boot from MMC1Card did not respond to voltage select! >> >> spl: mmc init failed with error: -95 >> >> SPL: failed to boot from all boot devices >> >> ### ERROR ### Please RESET the board ### >> > >> > So I guess I'm missing something. My head is not really clear atm. >> > >> > I'v also tried booting from USB for easier development. >> > >> >> sudo ../sunxi-tools/sunxi-fel -v -p uboot u-boot-sunxi-with-spl.bin >> >> write 0x4100 >> >> Stack pointers: sp_irq=0x2000, sp=0x5E08 >> >> MMU is not enabled by BROM >> >> Generating the new MMU translation table at 0x8000 >> >> => Executing the SPL... done. >> >> Setting write-combine mapping for DRAM. >> >> Setting cached mapping for BROM. >> >> Writing back the MMU translation table. >> >> Enabling I-cache, MMU and branch prediction... done. >> >> Writing image "U-Boot 2017.01-rc2-01115-g252ef3", 338273 bytes @ >> >> 0x42E0. >> >> Invalid command write >> > >> > However as it is seen on the output above it fails. Console output says: >> > >> >> U-Boot SPL 2017.01-rc2-01115-g252ef38050-dirty (Mar 22 2017 - 16:58:12) >> >> DRAM: 64 MiB >> >> Trying to boot from FEL >> > >> > And its stuck. >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "linux-sunxi" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an email to linux-sunxi...@googlegroups.com. >> > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] working A64 DDR eMMC support
On Sat, Jan 14, 2017 at 2:53 PM, André Przywara <andre.przyw...@arm.com> wrote: > On 14/01/17 16:20, jonsm...@gmail.com wrote: >> The Allwinner kernel referenced in this thread has source for working >> DDR eMMC mode on the A64. >> >> http://forum.banana-pi.org/t/bpi-m64-android-6-0-1-source-code/2748 >> >> DDR eMMC support is needed to get the newer eMMC chip used on the BPI >> M64 board working. >> >> Of course this info will need to be extracted and applied to mainlining >> efforts. > > That works already for weeks, the MMC patches are on their way into the > mainline kernel: > http://lists.infradead.org/pipermail/linux-arm-kernel/2017-January/478107.html I see a DTD change for DDR MMC support on the list. Is that enough to achieve the shift into DDR mode for the eMMC chip? I thought we were missing needed bits of code for the MMC driver. > > Cheers, > Andre. > -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] working A64 DDR eMMC support
The Allwinner kernel referenced in this thread has source for working DDR eMMC mode on the A64. http://forum.banana-pi.org/t/bpi-m64-android-6-0-1-source-code/2748 DDR eMMC support is needed to get the newer eMMC chip used on the BPI M64 board working. Of course this info will need to be extracted and applied to mainlining efforts. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: A64 Ethernet interfaces
On Sat, Jan 14, 2017 at 10:42 AM, André Przywara <andre.przyw...@arm.com> wrote:
> On 14/01/17 14:42, jonsm...@gmail.com wrote:
>
> Hi Jon,
>
> (dropping the U-Boot ML, since this is not all related to to OpiZero or
> to U-Boot. Next time please send a separate email (opening a new
> thread). And I recommend just the linux-sunxi list for those kind of
> questions or join the #linux-sunxi IRC channel on Freenode).
>
>> Can you simultaneously use both Ethernet interfaces on the A64? I've
>> received conflicting answers to this question.
>
> Which "both" interfaces? I only know about one interface on the A64.
> Are you talking about WiFi and Ethernet?
I always thought there was a single Ethernet controller on the A64 for
EMAC and GMAC and it is the PHY that is switchable. But several people
have told me that it is possible to run two simultaneous Ethernet net
connections on the A64 - one with the internal 100Mb PHY and one with
an external Gb PHY. So are these people confused or am I wrong and
there is a way to get two simultaneous interfaces on the A64?
> Or about another SoC? The A20 and R40 have two separate, even different
> Ethernet MACs, which appear to be usable simultaneously (from looking at
> the documentation). But I don't know of any board doing that or anyone
> ever tried that.
I believe someone got simultaneous MACs going in the A20 about five
years ago. There was a blog talking about it, but the website is gone
now. It was a hobbyist trying to make a router based on the A20.
>
> Cheers,
> Andre.
>
>> On Fri, Jan 13, 2017 at 9:06 PM, Andre Przywara <andre.przyw...@arm.com>
>> wrote:
>>> The OrangePi Zero can happily use the EMAC along with its integrated
>>> PHY to use Ethernet (for TFTP booting, for instance).
>>> Add the emac node to the board .dts by copying it from the OrangePi One
>>> DT.
>>>
>>> Signed-off-by: Andre Przywara <andre.przyw...@arm.com>
>>> ---
>>> arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 11 +++
>>> 1 file changed, 11 insertions(+)
>>>
>>> diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
>>> b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
>>> index 0989434..20d489c 100644
>>> --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
>>> +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
>>> @@ -99,6 +99,17 @@
>>> status = "okay";
>>> };
>>>
>>> + {
>>> + phy = <>;
>>> + phy-mode = "mii";
>>> + allwinner,use-internal-phy;
>>> + allwinner,leds-active-low;
>>> + status = "okay";
>>> + phy1: ethernet-phy@1 {
>>> + reg = <1>;
>>> + };
>>> +};
>>> +
>>> {
>>> pinctrl-names = "default";
>>> pinctrl-0 = <_pins_a>;
>>> --
>>> 2.8.2
>>>
>>> --
>
--
Jon Smirl
jonsm...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH 1/2] sunxi: dts: OrangePi Zero: add Ethernet node
Can you simultaneously use both Ethernet interfaces on the A64? I've
received conflicting answers to this question.
On Fri, Jan 13, 2017 at 9:06 PM, Andre Przywara <andre.przyw...@arm.com> wrote:
> The OrangePi Zero can happily use the EMAC along with its integrated
> PHY to use Ethernet (for TFTP booting, for instance).
> Add the emac node to the board .dts by copying it from the OrangePi One
> DT.
>
> Signed-off-by: Andre Przywara <andre.przyw...@arm.com>
> ---
> arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> index 0989434..20d489c 100644
> --- a/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> +++ b/arch/arm/dts/sun8i-h2-plus-orangepi-zero.dts
> @@ -99,6 +99,17 @@
> status = "okay";
> };
>
> + {
> + phy = <>;
> + phy-mode = "mii";
> + allwinner,use-internal-phy;
> + allwinner,leds-active-low;
> + status = "okay";
> + phy1: ethernet-phy@1 {
> + reg = <1>;
> + };
> +};
> +
> {
> pinctrl-names = "default";
> pinctrl-0 = <_pins_a>;
> --
> 2.8.2
>
> --
> 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.
--
Jon Smirl
jonsm...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support
On Wed, Jan 4, 2017 at 5:36 PM, André Przywara <andre.przyw...@arm.com> wrote: > On 04/01/17 19:00, jonsm...@gmail.com wrote: >> On Wed, Jan 4, 2017 at 12:29 PM, André Przywara <andre.przyw...@arm.com> >> wrote: >>> On 04/01/17 16:40, jonsm...@gmail.com wrote: >>>> On Wed, Jan 4, 2017 at 8:36 AM, André Przywara <andre.przyw...@arm.com> >>>> wrote: >>>>> >>>>> On 04/01/17 11:25, Chen-Yu Tsai wrote: >>>>>> On Wed, Jan 4, 2017 at 6:28 PM, Jagan Teki <ja...@openedev.com> wrote: >>>>>>> On Tue, Jan 3, 2017 at 2:52 PM, jonsm...@gmail.com <jonsm...@gmail.com> >>>>>>> wrote: >>>>>>>> On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki <jagannadh.t...@gmail.com> >>>>>>>> wrote: >>>>>>>>> On Tue, Jan 3, 2017 at 3:38 AM, jonsm...@gmail.com >>>>>>>>> <jonsm...@gmail.com> wrote: >>>>>>>>>> I recently ran into a probably with the UARTs on the A64. Many >>>>>>>>>> Bluetooth modules (like Ampak) use the UART. The data rate of EDR BT >>>>>>>>>> is 3Mb/s with about 2.1Mb/s though put. To handle this most systems >>>>>>>>>> set the speed of the BT UART to 3Mb/s. >>>>>>>>>> >>>>>>>>>> By default the Allwinner UART clock input is OSC24. When using OSC24 >>>>>>>>>> the maximum speed the UART can be set to is 1.5Mb/s. The clock input >>>>>>>>>> (apb2) can be changed over to PERIPH0x2 (1.2ghz) via the device tree >>>>>>>>>> and 3Mb/s is then supported. >>>>>>>>>> >>>>>>>>>> But... there's a problem, UART0 (the console) is using the same >>>>>>>>>> master >>>>>>>>>> clock source. So when you change the clock input over to PERIPH0x2 >>>>>>>>>> the >>>>>>>>>> console stops working. There is no mechanism in Linux to handle this >>>>>>>>>> clock source change and adjust the dividers on active uarts. So it >>>>>>>>>> would be best if this master clock was set very early in u-boot and >>>>>>>>>> then the console is adjusted to use it. >>>>>>>>>> >>>>>>>>>> Are there any downsides to making this change in u-boot? >>>>>>>>> >>>>>>>>> I don't understand, did you find this behaviour with these SPL changes >>>>>>>>> or general sunxi u-boot? >>>>>>> >>>>>>> I think, this issue need to resolve, Andre any comments? >>>>>> >>>>>> This is a completely different issue unrelated to A64 SPL support. >>>>> >>>>> I agree that's a completely orthogonal issue. Someone needs to bake a >>>>> patch (easy?) and post it. This doesn't depend in any way on this >>>>> series, in fact would affect many sunxi boards. >>>>> >>>>>> What Jon is saying is that for the UART to go faster than 1.5 Mb/s, >>>>>> The APB2 clock has to be reparented to the peripheral PLL. When do >>>>>> we do this is the question. This is a generic sunxi issue. >>>>> >>>>> On the first glance this approach sounds a bit hackish, since we use >>>>> firmware to setup the clocks in a way to solves a particular issue. >>>>> >>>>> On the other hand using PERIPH0(2x) as a base for APB2 seems like a >>>>> completely proper setup, even somewhat recommended by Allwinner (after >>>>> all the UARTs are based on this special clock for a reason). >>>>> >>>>>> Now, I think doing this as soon as possible (with regards to the >>>>>> running system) would be best. Reparenting the clk on the fly >>>>>> would change the baud rate, and result in the uart glitching. >>>>> >>>>> Can't we change it when observing the proper order: turning TX/RX off, >>>>> programming new divisors, changing the clock source, turning TX/RX back >>>>> on? >>>> >>>> You would expect to be able to achieve this reparenting by simply >>>> changing the device tree in Linux. >>> >>> Why would this be done in
Re: [U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support
On Wed, Jan 4, 2017 at 12:29 PM, André Przywara <andre.przyw...@arm.com> wrote: > On 04/01/17 16:40, jonsm...@gmail.com wrote: >> On Wed, Jan 4, 2017 at 8:36 AM, André Przywara <andre.przyw...@arm.com> >> wrote: >>> >>> On 04/01/17 11:25, Chen-Yu Tsai wrote: >>>> On Wed, Jan 4, 2017 at 6:28 PM, Jagan Teki <ja...@openedev.com> wrote: >>>>> On Tue, Jan 3, 2017 at 2:52 PM, jonsm...@gmail.com <jonsm...@gmail.com> >>>>> wrote: >>>>>> On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki <jagannadh.t...@gmail.com> >>>>>> wrote: >>>>>>> On Tue, Jan 3, 2017 at 3:38 AM, jonsm...@gmail.com <jonsm...@gmail.com> >>>>>>> wrote: >>>>>>>> I recently ran into a probably with the UARTs on the A64. Many >>>>>>>> Bluetooth modules (like Ampak) use the UART. The data rate of EDR BT >>>>>>>> is 3Mb/s with about 2.1Mb/s though put. To handle this most systems >>>>>>>> set the speed of the BT UART to 3Mb/s. >>>>>>>> >>>>>>>> By default the Allwinner UART clock input is OSC24. When using OSC24 >>>>>>>> the maximum speed the UART can be set to is 1.5Mb/s. The clock input >>>>>>>> (apb2) can be changed over to PERIPH0x2 (1.2ghz) via the device tree >>>>>>>> and 3Mb/s is then supported. >>>>>>>> >>>>>>>> But... there's a problem, UART0 (the console) is using the same master >>>>>>>> clock source. So when you change the clock input over to PERIPH0x2 the >>>>>>>> console stops working. There is no mechanism in Linux to handle this >>>>>>>> clock source change and adjust the dividers on active uarts. So it >>>>>>>> would be best if this master clock was set very early in u-boot and >>>>>>>> then the console is adjusted to use it. >>>>>>>> >>>>>>>> Are there any downsides to making this change in u-boot? >>>>>>> >>>>>>> I don't understand, did you find this behaviour with these SPL changes >>>>>>> or general sunxi u-boot? >>>>> >>>>> I think, this issue need to resolve, Andre any comments? >>>> >>>> This is a completely different issue unrelated to A64 SPL support. >>> >>> I agree that's a completely orthogonal issue. Someone needs to bake a >>> patch (easy?) and post it. This doesn't depend in any way on this >>> series, in fact would affect many sunxi boards. >>> >>>> What Jon is saying is that for the UART to go faster than 1.5 Mb/s, >>>> The APB2 clock has to be reparented to the peripheral PLL. When do >>>> we do this is the question. This is a generic sunxi issue. >>> >>> On the first glance this approach sounds a bit hackish, since we use >>> firmware to setup the clocks in a way to solves a particular issue. >>> >>> On the other hand using PERIPH0(2x) as a base for APB2 seems like a >>> completely proper setup, even somewhat recommended by Allwinner (after >>> all the UARTs are based on this special clock for a reason). >>> >>>> Now, I think doing this as soon as possible (with regards to the >>>> running system) would be best. Reparenting the clk on the fly >>>> would change the baud rate, and result in the uart glitching. >>> >>> Can't we change it when observing the proper order: turning TX/RX off, >>> programming new divisors, changing the clock source, turning TX/RX back on? >> >> You would expect to be able to achieve this reparenting by simply >> changing the device tree in Linux. > > Why would this be done in DT? The APB2 clock is capable of being driven > by 32KHz, 24 MHz or PERIPH0(2x), the DT should express this. The old > Allwinner binding certainly did, the new hides this in the driver. But > as the hardware allows it, the DT shouldn't have a say in the parenting > decision - apart from listing the alternatives. This is actually a > driver or clock system decision. > >> I tried that on the Allwinner 3.10 > > > >> kernel and it actually works. But... it causes the console to quit >> working. >> >> Do Linux clk_notifiers work soon enough to handle reparenting the >> console in the device tree? It is not clear to me that they do. Plus >> the 8250_dw driver doesn't support it. > > I
Re: [U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support
On Wed, Jan 4, 2017 at 12:29 PM, André Przywara <andre.przyw...@arm.com> wrote: > On 04/01/17 16:40, jonsm...@gmail.com wrote: >> On Wed, Jan 4, 2017 at 8:36 AM, André Przywara <andre.przyw...@arm.com> >> wrote: >>> >>> On 04/01/17 11:25, Chen-Yu Tsai wrote: >>>> On Wed, Jan 4, 2017 at 6:28 PM, Jagan Teki <ja...@openedev.com> wrote: >>>>> On Tue, Jan 3, 2017 at 2:52 PM, jonsm...@gmail.com <jonsm...@gmail.com> >>>>> wrote: >>>>>> On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki <jagannadh.t...@gmail.com> >>>>>> wrote: >>>>>>> On Tue, Jan 3, 2017 at 3:38 AM, jonsm...@gmail.com <jonsm...@gmail.com> >>>>>>> wrote: >>>>>>>> I recently ran into a probably with the UARTs on the A64. Many >>>>>>>> Bluetooth modules (like Ampak) use the UART. The data rate of EDR BT >>>>>>>> is 3Mb/s with about 2.1Mb/s though put. To handle this most systems >>>>>>>> set the speed of the BT UART to 3Mb/s. >>>>>>>> >>>>>>>> By default the Allwinner UART clock input is OSC24. When using OSC24 >>>>>>>> the maximum speed the UART can be set to is 1.5Mb/s. The clock input >>>>>>>> (apb2) can be changed over to PERIPH0x2 (1.2ghz) via the device tree >>>>>>>> and 3Mb/s is then supported. >>>>>>>> >>>>>>>> But... there's a problem, UART0 (the console) is using the same master >>>>>>>> clock source. So when you change the clock input over to PERIPH0x2 the >>>>>>>> console stops working. There is no mechanism in Linux to handle this >>>>>>>> clock source change and adjust the dividers on active uarts. So it >>>>>>>> would be best if this master clock was set very early in u-boot and >>>>>>>> then the console is adjusted to use it. >>>>>>>> >>>>>>>> Are there any downsides to making this change in u-boot? >>>>>>> >>>>>>> I don't understand, did you find this behaviour with these SPL changes >>>>>>> or general sunxi u-boot? >>>>> >>>>> I think, this issue need to resolve, Andre any comments? >>>> >>>> This is a completely different issue unrelated to A64 SPL support. >>> >>> I agree that's a completely orthogonal issue. Someone needs to bake a >>> patch (easy?) and post it. This doesn't depend in any way on this >>> series, in fact would affect many sunxi boards. >>> >>>> What Jon is saying is that for the UART to go faster than 1.5 Mb/s, >>>> The APB2 clock has to be reparented to the peripheral PLL. When do >>>> we do this is the question. This is a generic sunxi issue. >>> >>> On the first glance this approach sounds a bit hackish, since we use >>> firmware to setup the clocks in a way to solves a particular issue. >>> >>> On the other hand using PERIPH0(2x) as a base for APB2 seems like a >>> completely proper setup, even somewhat recommended by Allwinner (after >>> all the UARTs are based on this special clock for a reason). >>> >>>> Now, I think doing this as soon as possible (with regards to the >>>> running system) would be best. Reparenting the clk on the fly >>>> would change the baud rate, and result in the uart glitching. >>> >>> Can't we change it when observing the proper order: turning TX/RX off, >>> programming new divisors, changing the clock source, turning TX/RX back on? >> >> You would expect to be able to achieve this reparenting by simply >> changing the device tree in Linux. > > Why would this be done in DT? The APB2 clock is capable of being driven > by 32KHz, 24 MHz or PERIPH0(2x), the DT should express this. The old > Allwinner binding certainly did, the new hides this in the driver. But > as the hardware allows it, the DT shouldn't have a say in the parenting > decision - apart from listing the alternatives. This is actually a > driver or clock system decision. > >> I tried that on the Allwinner 3.10 > > > >> kernel and it actually works. But... it causes the console to quit >> working. >> >> Do Linux clk_notifiers work soon enough to handle reparenting the >> console in the device tree? It is not clear to me that they do. Plus >> the 8250_dw driver doesn't support it. > > I
Re: [U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support
On Wed, Jan 4, 2017 at 8:36 AM, André Przywara <andre.przyw...@arm.com> wrote: > > On 04/01/17 11:25, Chen-Yu Tsai wrote: > > On Wed, Jan 4, 2017 at 6:28 PM, Jagan Teki <ja...@openedev.com> wrote: > >> On Tue, Jan 3, 2017 at 2:52 PM, jonsm...@gmail.com <jonsm...@gmail.com> > >> wrote: > >>> On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki <jagannadh.t...@gmail.com> > >>> wrote: > >>>> On Tue, Jan 3, 2017 at 3:38 AM, jonsm...@gmail.com <jonsm...@gmail.com> > >>>> wrote: > >>>>> I recently ran into a probably with the UARTs on the A64. Many > >>>>> Bluetooth modules (like Ampak) use the UART. The data rate of EDR BT > >>>>> is 3Mb/s with about 2.1Mb/s though put. To handle this most systems > >>>>> set the speed of the BT UART to 3Mb/s. > >>>>> > >>>>> By default the Allwinner UART clock input is OSC24. When using OSC24 > >>>>> the maximum speed the UART can be set to is 1.5Mb/s. The clock input > >>>>> (apb2) can be changed over to PERIPH0x2 (1.2ghz) via the device tree > >>>>> and 3Mb/s is then supported. > >>>>> > >>>>> But... there's a problem, UART0 (the console) is using the same master > >>>>> clock source. So when you change the clock input over to PERIPH0x2 the > >>>>> console stops working. There is no mechanism in Linux to handle this > >>>>> clock source change and adjust the dividers on active uarts. So it > >>>>> would be best if this master clock was set very early in u-boot and > >>>>> then the console is adjusted to use it. > >>>>> > >>>>> Are there any downsides to making this change in u-boot? > >>>> > >>>> I don't understand, did you find this behaviour with these SPL changes > >>>> or general sunxi u-boot? > >> > >> I think, this issue need to resolve, Andre any comments? > > > > This is a completely different issue unrelated to A64 SPL support. > > I agree that's a completely orthogonal issue. Someone needs to bake a > patch (easy?) and post it. This doesn't depend in any way on this > series, in fact would affect many sunxi boards. > > > What Jon is saying is that for the UART to go faster than 1.5 Mb/s, > > The APB2 clock has to be reparented to the peripheral PLL. When do > > we do this is the question. This is a generic sunxi issue. > > On the first glance this approach sounds a bit hackish, since we use > firmware to setup the clocks in a way to solves a particular issue. > > On the other hand using PERIPH0(2x) as a base for APB2 seems like a > completely proper setup, even somewhat recommended by Allwinner (after > all the UARTs are based on this special clock for a reason). > > > Now, I think doing this as soon as possible (with regards to the > > running system) would be best. Reparenting the clk on the fly > > would change the baud rate, and result in the uart glitching. > > Can't we change it when observing the proper order: turning TX/RX off, > programming new divisors, changing the clock source, turning TX/RX back on? You would expect to be able to achieve this reparenting by simply changing the device tree in Linux. I tried that on the Allwinner 3.10 kernel and it actually works. But... it causes the console to quit working. Do Linux clk_notifiers work soon enough to handle reparenting the console in the device tree? It is not clear to me that they do. Plus the 8250_dw driver doesn't support it. Next I considered changing it in the u-boot device tree. But again, console is set up before u-boot loads that device tree. In Allwinner uboot console is set up in the SPL code before the device tree is loaded. Is the PERIPH0(2x) clock always running? Maybe defaulting UARTs/I2C to OSC24 was done to save power? After investigating this I now understand why Allwinner modified the standard Broadcom Bluetooth driver in AOSP. They fixed it to run with a 1.5Mb UART. Everyone else in AOSP uses it with a 3Mb/s UART. All of this started because we were unaware of the changes Allwinner had made to the Broadcom AOSP code and we couldn't get AOSP Bluetooth to work. Who knows why Allwinner didn't just adjust the UART to run at 3Mb/s. Probably two different programmer groups. > > Nevertheless it seems worthwhile to give this rather simple U-Boot > approach a go. But I would like to see some testing, since this will > affect many sunxi boards. > > > Also, as Jon mentioned, the 8250_dw driver in the kernel doesn't > > support clk notifiers. And it won't work with earlycon an
Re: [U-Boot] [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support
On Tue, Jan 3, 2017 at 5:41 AM, Jagan Teki <jagannadh.t...@gmail.com> wrote: > On Tue, Jan 3, 2017 at 3:38 AM, jonsm...@gmail.com <jonsm...@gmail.com> wrote: >> I recently ran into a probably with the UARTs on the A64. Many >> Bluetooth modules (like Ampak) use the UART. The data rate of EDR BT >> is 3Mb/s with about 2.1Mb/s though put. To handle this most systems >> set the speed of the BT UART to 3Mb/s. >> >> By default the Allwinner UART clock input is OSC24. When using OSC24 >> the maximum speed the UART can be set to is 1.5Mb/s. The clock input >> (apb2) can be changed over to PERIPH0x2 (1.2ghz) via the device tree >> and 3Mb/s is then supported. >> >> But... there's a problem, UART0 (the console) is using the same master >> clock source. So when you change the clock input over to PERIPH0x2 the >> console stops working. There is no mechanism in Linux to handle this >> clock source change and adjust the dividers on active uarts. So it >> would be best if this master clock was set very early in u-boot and >> then the console is adjusted to use it. >> >> Are there any downsides to making this change in u-boot? > > I don't understand, did you find this behaviour with these SPL changes > or general sunxi u-boot? Previously the boot console uart0 was getting setup in the SPL code. I have not been closely following these changes, is that still true? Changing the clock parent needs to be done before uart0 is initialized. Changing this parent should have no other impact on u-boot other than changing the clock divisor uart0 is using. Once Linux is up, the Linux uart code will see the changed clock parent and allow higher baud rates to be set. This clock parent also impacts the I2C clocks, but I don't believe I2C is enabled in A64 uboot. > > thanks! > -- > Jagan Teki > Free Software Engineer | www.openedev.com > U-Boot, Linux | Upstream Maintainer > Hyderabad, India. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH v4 00/26] sunxi: Allwinner A64: SPL support
ay values in single bit delay support patch > - removing stray semicolons from boot0.h header > > Changelog v2 .. v3: > - add various Reviewed-by: and Acked-by: tags > - split tiny-printf fix to handle "-" separately > - add various comments and extend commit messages > - add assembly file to re-create the embedded RMR switch code > - add patch 14/26 to explain the MBUS priority setup > - move DRAM r/w delay values into #defines to simplify re-usablity > - replace #ifdef'ed addition of A64 support to the H3 DRAM driver with an > approach using static parameters > > Changelog v1 .. v2: > - drop SPI build fix (already merged) > - confine A31 register init change to H3 and A64 > - use IS_ENABLED() instead of #idef to guard MBUS2 clock init > - fix tiny-printf (proper sign extension for 32-bit integers) > - add "size" output in commit msg to document tiny-printf size impact > - fix sdelay(): use only one register, add "cc" clobber > - update RMR switch code to provide easy access to RVBAR register address > - drop redundant DRAM frequency setting from Pine64 defconfig > - minor changes as requested by reviewers > > Andre Przywara (21): > sun6i: Restrict some register initialization to Allwinner A31 SoC > armv8: prevent using THUMB > armv8: add lowlevel_init.S > SPL: tiny-printf: add "l" modifier > SPL: tiny-printf: ignore "-" modifier > move UL() macro from armv8/mmu.h into common.h > SPL: make struct spl_image 64-bit safe > armv8: add simple sdelay implementation > armv8: move reset branch into boot hook > ARM: boot0 hook: remove macro, include whole header file > sunxi: introduce extra config option for boot0 header > sunxi: A64: do an RMR switch if started in AArch32 mode > sunxi: provide default DRAM config for sun50i in Kconfig > sunxi: H3/A64: fix non-ODT setting > sunxi: DRAM: fix H3 DRAM size display on aarch64 > sunxi: A64: enable SPL > SPL: read and store arch property from U-Boot image > Makefile: use "arm64" architecture for U-Boot image files > ARM: SPL/FIT: differentiate between arm and arm64 arch properties > sunxi: introduce RMR switch to enter payloads in 64-bit mode > sunxi: A64: add 32-bit SPL support > > Jens Kuske (3): > sunxi: H3: add and rename some DRAM contoller registers > sunxi: H3: add DRAM controller single bit delay support > sunxi: A64: use H3 DRAM initialization code for A64 as well > > Philipp Tomsich (2): > sunxi: H3: Rework MBUS priority setup > sunxi: clocks: Use the correct pattern register for PLL11 > > Makefile| 9 +- > arch/arm/cpu/armv8/Makefile | 1 + > arch/arm/cpu/armv8/cpu.c| 14 + > arch/arm/cpu/armv8/lowlevel_init.S | 44 +++ > arch/arm/cpu/armv8/start.S | 5 +- > arch/arm/include/asm/arch-bcm235xx/boot0.h | 8 +- > arch/arm/include/asm/arch-bcm281xx/boot0.h | 8 +- > arch/arm/include/asm/arch-sunxi/boot0.h | 37 ++- > arch/arm/include/asm/arch-sunxi/clock_sun6i.h | 1 + > arch/arm/include/asm/arch-sunxi/cpu.h | 3 + > arch/arm/include/asm/arch-sunxi/dram.h | 2 +- > arch/arm/include/asm/arch-sunxi/dram_sun8i_h3.h | 53 ++-- > arch/arm/include/asm/armv8/mmu.h| 8 - > arch/arm/lib/Makefile | 2 + > arch/arm/lib/spl.c | 15 + > arch/arm/lib/vectors.S | 1 - > arch/arm/mach-omap2/boot-common.c | 2 +- > arch/arm/mach-sunxi/Makefile| 2 + > arch/arm/mach-sunxi/board.c | 2 +- > arch/arm/mach-sunxi/clock_sun6i.c | 10 +- > arch/arm/mach-sunxi/dram_sun8i_h3.c | 400 > +--- > arch/arm/mach-sunxi/rmr_switch.S| 41 +++ > arch/arm/mach-sunxi/spl_switch.c| 81 + > arch/arm/mach-tegra/spl.c | 2 +- > board/sunxi/Kconfig | 41 ++- > common/spl/spl.c| 9 +- > common/spl/spl_fit.c| 8 + > common/spl/spl_mmc.c| 2 +- > configs/pine64_plus_defconfig | 7 +- > configs/sun50i_spl32_defconfig | 10 + > include/common.h| 13 +- > include/configs/sunxi-common.h | 4 +- > include/spl.h | 19 +- > lib/tiny-printf.c | 50 ++- > 34 files changed, 713 insertions(+), 201 deletions(-) > c
[linux-sunxi] Bluetooth overruns on A64 with longsleep
I've hit this on the A64 but it is likely present on other Allwinner chips.
I'm been digging around in Pine64 Bluetooth as to why it keeps
failing. One reason is that it is constantly getting overruns. I
believe the Pine64 Realtek code is only running on the UART at 115,200
and our Broadcom hardware is running at 921,600. The problem here is
that BT runs at 3Mb wire speed with an effective throughput rate of
2.1Mb/s. All of the other platforms in AOSP set the UART speed to
3Mb/s.
The A64 hardware supports running the UART at 3Mb/s. This device tree
change will do that:
apb2 {
#clock-cells = <0x00>;
compatible = "allwinner,sunxi-periph-clock";
clock-output-names = "apb2";
assigned-clock-parents = <0x7b>; -- change the parent to
periph0x2 instead of OSC24
linux,phandle = <0x7e>;
phandle = <0x7e>;
};
But... doing that kills the console. The console's UART clock was
calculated for a 24Mhz input clock. When you change the clock parent
over to 1.2Ghz the console dies. So this parent switch needs to be
done in uboot, not Linux.
Can anyone help out with a uboot that changes this clock parent over
to periph0x2?
--
Jon Smirl
jonsm...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Kernel CEC driver.
On Mon, Oct 17, 2016 at 3:07 PM, Jarosław Nieć <zuljin...@gmail.com> wrote: >> >> https://groups.google.com/forum/#!topic/linux-sunxi/l5jhSY8PDFA >> >> This thread does seem to suggest there is (some) CEC hardware... >> >> Also some code here ; >> https://groups.google.com/forum/#!msg/linux-sunxi/cNbMiwzgGJ0/tK-KvXkn-pQJ >> >> Not sure if you missed it or i'm blind, just ignore if nonsense ;) >> > > I saw this code and my implementation use it as a reference how to use > HDMI-CEC register. Unfortunately this implementation is unfinished and AFAIK > is using very ineffective busy-wait loop. > CEC hardware in A10 is very very simple and basically is just mapping of CEC > line state to register in memory. It isn't similar to other CEC cores that > can transmit/receive whole messages on its own. > Thats why we need to use bit banging in kernel to use it at all. I believe there is a bitbanging I2C implementation already in the kernel. Might make a good place to start from. > > Regards, Jarek > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Dual voltage SDMMC/eMMC on A64
On Tue, Sep 20, 2016 at 11:50 AM, Andre Przywara <andre.przyw...@arm.com> wrote: > Hi, > > On 20/09/16 15:49, jonsm...@gmail.com wrote: >> On Tue, Sep 20, 2016 at 10:45 AM, jonsm...@gmail.com <jonsm...@gmail.com> >> wrote: >>> On Tue, Sep 20, 2016 at 10:10 AM, TsvetanUsunov <tsvetanusu...@gmail.com> >>> wrote: >>>> >>>> >>>> понеделник, 19 септември 2016 г., 20:06:13 UTC+3, Hans de Goede написа: >>>>> >>>>> Hi, >>>>> >>>>> On 19-09-16 18:07, TsvetanUsunov wrote: >>>>>> Hi, >>>>>> >>>>>> We make our final touch of A64-OLinuXino PCB and there we add option >>>>>> eMMC Flash to work on dual voltages 1.8V and 3.3V. >>>>>> The eMMC is connected to AXP803 pin.34 GPIO1/LDO. The problem is that >>>>>> when A64 boots and AXP803 is not initialized it outputs default 0.8V then >>>>>> after initialization driver takes care to drive it 1.8V or 3.3V. >>>>>> This makes impossible to boot from eMMC which is not good. We now think >>>>>> for solution which to drive eMMC at 3.3V initially when AXP803 output is >>>>>> below 1.8V but this adds unnecessary hardware complexity. >>>>>> For hardware point of view it will be much more simplier if dedigated >>>>>> A64 GPIO is used and initially is pulled down and after AXP803 is >>>>>> initialized is pulled up. >>>>> >>>>> Ok, so what your suggesting is: >>>>> >>>>> axp803-ldo-io1 -\ >>>>>[mux]---> mmc-supply >>>>> Fixed-3.3v --/ | >>>>> | >>>>> |mux-control >>>>> A64 gpio out/ >>>>> >>>>> Note the above ascii-art requires a fixed-width font. >>>>> >>>>> With a pull-down (or pull-up) to fix the mux in a certain position when >>>>> the gpio is in tri-state ? >>>>> >>>>> As long as we pin the axp803-ldo-io1 at 1.8v then the Linux regulator >>>>> framework should be able to deal with, and in u-boot we can just >>>>> keep things at 3.3v. >>>>> >>>>>> How would you suggest us to implement it? Will this additional GPIO >>>>>> create troubles in eMMC driver philosophy? >>>>> >>>>> For the Linux mmc driver the mmc-supply is abstracted as a regulator, >>>>> and the regulator framework should be able to deal with any setup >>>>> you can come up with. >>>>> >>>>>> For the SDMMC we are still hesitating what to do as we don't know if the >>>>>> card which will be inserted will support low voltage and higher speeds at >>>>>> all. >>>>> >>>>> As long as you default to 3.3v then the kernel's sd subsystem can >>>>> dynamically switch voltage (through e.g. the gpio) if the card >>>>> advertises it supports low voltage. Note that you're planning >>>>> the first board to implement this that I know off, so the sunxi-mmc >>>>> kernel driver will need some work to support voltage switching, >>>>> but in the mean time things should work fine at 3.3v. >>>>> >>>>>> Also eMMC Flash and SDMMC card should be driven by separate voltages, as >>>>>> they may work in any combinations. >>>>> >>>>> Ack, right, as said both cards should come up with 3.3v and then >>>>> a new voltage will be negotiated before switching, so this definitely >>>>> needs to be per card. >>>>> >>>>>> This means we need another AXP803 LDO and another GPIO for the SDMMC >>>>>> card. >>>>> >>>>> Right >>>> >>>> >>>> Micron eMMC chips we use do not support higher clock at lower voltage, so >>>> the way we wired the schematic right now makes no much sense. >>>> I check for other vendors but also can't find such eMMC chip, if someone >>>> knows please let us know to investigate more? >>>> >>>> So in this case makes sense to move the dual voltage supply to the SD-MMC >>>> card only but this rise some more issues :) >>>> >>>> The card is currently wired to port F which Vcc is internally connected >>>> together w
Re: [linux-sunxi] Dual voltage SDMMC/eMMC on A64
On Tue, Sep 20, 2016 at 10:45 AM, jonsm...@gmail.com <jonsm...@gmail.com> wrote: > On Tue, Sep 20, 2016 at 10:10 AM, TsvetanUsunov <tsvetanusu...@gmail.com> > wrote: >> >> >> понеделник, 19 септември 2016 г., 20:06:13 UTC+3, Hans de Goede написа: >>> >>> Hi, >>> >>> On 19-09-16 18:07, TsvetanUsunov wrote: >>> > Hi, >>> > >>> > We make our final touch of A64-OLinuXino PCB and there we add option >>> > eMMC Flash to work on dual voltages 1.8V and 3.3V. >>> > The eMMC is connected to AXP803 pin.34 GPIO1/LDO. The problem is that >>> > when A64 boots and AXP803 is not initialized it outputs default 0.8V then >>> > after initialization driver takes care to drive it 1.8V or 3.3V. >>> > This makes impossible to boot from eMMC which is not good. We now think >>> > for solution which to drive eMMC at 3.3V initially when AXP803 output is >>> > below 1.8V but this adds unnecessary hardware complexity. >>> > For hardware point of view it will be much more simplier if dedigated >>> > A64 GPIO is used and initially is pulled down and after AXP803 is >>> > initialized is pulled up. >>> >>> Ok, so what your suggesting is: >>> >>> axp803-ldo-io1 -\ >>>[mux]---> mmc-supply >>> Fixed-3.3v --/ | >>> | >>> |mux-control >>> A64 gpio out/ >>> >>> Note the above ascii-art requires a fixed-width font. >>> >>> With a pull-down (or pull-up) to fix the mux in a certain position when >>> the gpio is in tri-state ? >>> >>> As long as we pin the axp803-ldo-io1 at 1.8v then the Linux regulator >>> framework should be able to deal with, and in u-boot we can just >>> keep things at 3.3v. >>> >>> > How would you suggest us to implement it? Will this additional GPIO >>> > create troubles in eMMC driver philosophy? >>> >>> For the Linux mmc driver the mmc-supply is abstracted as a regulator, >>> and the regulator framework should be able to deal with any setup >>> you can come up with. >>> >>> > For the SDMMC we are still hesitating what to do as we don't know if the >>> > card which will be inserted will support low voltage and higher speeds at >>> > all. >>> >>> As long as you default to 3.3v then the kernel's sd subsystem can >>> dynamically switch voltage (through e.g. the gpio) if the card >>> advertises it supports low voltage. Note that you're planning >>> the first board to implement this that I know off, so the sunxi-mmc >>> kernel driver will need some work to support voltage switching, >>> but in the mean time things should work fine at 3.3v. >>> >>> > Also eMMC Flash and SDMMC card should be driven by separate voltages, as >>> > they may work in any combinations. >>> >>> Ack, right, as said both cards should come up with 3.3v and then >>> a new voltage will be negotiated before switching, so this definitely >>> needs to be per card. >>> >>> > This means we need another AXP803 LDO and another GPIO for the SDMMC >>> > card. >>> >>> Right >> >> >> Micron eMMC chips we use do not support higher clock at lower voltage, so >> the way we wired the schematic right now makes no much sense. >> I check for other vendors but also can't find such eMMC chip, if someone >> knows please let us know to investigate more? >> >> So in this case makes sense to move the dual voltage supply to the SD-MMC >> card only but this rise some more issues :) >> >> The card is currently wired to port F which Vcc is internally connected >> together with port B and H where is WiFi SIDO , I2C UARTs etc which will be >> lost if we power with 1.8V, so no go. >> >> We can swap the SD-MMC and eMMC ports, port F and port C, but in this case >> we will lose the NAND Flash option i.e. the possibility to run Android. >> >> I still can't find SD-MMC card which to work on 1.8 and 3.3V can you point >> me to some model so we perform test and see if this is really good to have >> feature, or we will cut this and wire 3.3V permanently :) > > I have not tried low voltage SD Cards but... > > Here is a chart of the UHS modes > http://panasonic.net/avc/sdcard/industrial_sd/performance.html > > Here are UHS SD Cards for sale: > http://www.lexar.com/products.html > > I
Re: [linux-sunxi] Dual voltage SDMMC/eMMC on A64
On Tue, Sep 20, 2016 at 10:10 AM, TsvetanUsunov <tsvetanusu...@gmail.com> wrote: > > > понеделник, 19 септември 2016 г., 20:06:13 UTC+3, Hans de Goede написа: >> >> Hi, >> >> On 19-09-16 18:07, TsvetanUsunov wrote: >> > Hi, >> > >> > We make our final touch of A64-OLinuXino PCB and there we add option >> > eMMC Flash to work on dual voltages 1.8V and 3.3V. >> > The eMMC is connected to AXP803 pin.34 GPIO1/LDO. The problem is that >> > when A64 boots and AXP803 is not initialized it outputs default 0.8V then >> > after initialization driver takes care to drive it 1.8V or 3.3V. >> > This makes impossible to boot from eMMC which is not good. We now think >> > for solution which to drive eMMC at 3.3V initially when AXP803 output is >> > below 1.8V but this adds unnecessary hardware complexity. >> > For hardware point of view it will be much more simplier if dedigated >> > A64 GPIO is used and initially is pulled down and after AXP803 is >> > initialized is pulled up. >> >> Ok, so what your suggesting is: >> >> axp803-ldo-io1 -\ >>[mux]---> mmc-supply >> Fixed-3.3v --/ | >> | >> |mux-control >> A64 gpio out/ >> >> Note the above ascii-art requires a fixed-width font. >> >> With a pull-down (or pull-up) to fix the mux in a certain position when >> the gpio is in tri-state ? >> >> As long as we pin the axp803-ldo-io1 at 1.8v then the Linux regulator >> framework should be able to deal with, and in u-boot we can just >> keep things at 3.3v. >> >> > How would you suggest us to implement it? Will this additional GPIO >> > create troubles in eMMC driver philosophy? >> >> For the Linux mmc driver the mmc-supply is abstracted as a regulator, >> and the regulator framework should be able to deal with any setup >> you can come up with. >> >> > For the SDMMC we are still hesitating what to do as we don't know if the >> > card which will be inserted will support low voltage and higher speeds at >> > all. >> >> As long as you default to 3.3v then the kernel's sd subsystem can >> dynamically switch voltage (through e.g. the gpio) if the card >> advertises it supports low voltage. Note that you're planning >> the first board to implement this that I know off, so the sunxi-mmc >> kernel driver will need some work to support voltage switching, >> but in the mean time things should work fine at 3.3v. >> >> > Also eMMC Flash and SDMMC card should be driven by separate voltages, as >> > they may work in any combinations. >> >> Ack, right, as said both cards should come up with 3.3v and then >> a new voltage will be negotiated before switching, so this definitely >> needs to be per card. >> >> > This means we need another AXP803 LDO and another GPIO for the SDMMC >> > card. >> >> Right > > > Micron eMMC chips we use do not support higher clock at lower voltage, so > the way we wired the schematic right now makes no much sense. > I check for other vendors but also can't find such eMMC chip, if someone > knows please let us know to investigate more? > > So in this case makes sense to move the dual voltage supply to the SD-MMC > card only but this rise some more issues :) > > The card is currently wired to port F which Vcc is internally connected > together with port B and H where is WiFi SIDO , I2C UARTs etc which will be > lost if we power with 1.8V, so no go. > > We can swap the SD-MMC and eMMC ports, port F and port C, but in this case > we will lose the NAND Flash option i.e. the possibility to run Android. > > I still can't find SD-MMC card which to work on 1.8 and 3.3V can you point > me to some model so we perform test and see if this is really good to have > feature, or we will cut this and wire 3.3V permanently :) I have not tried low voltage SD Cards but... Here is a chart of the UHS modes http://panasonic.net/avc/sdcard/industrial_sd/performance.html Here are UHS SD Cards for sale: http://www.lexar.com/products.html I was unaware of 0.4V UHS-II, but Lexar is selling UHS-II cards. Don't know what supply voltage they need. --- For eMMC I believe you are looking for: eMMC 4.5 HS200 eMMC 5.0 HS400 Kingston sells these, I think Samsung does too. http://www.kingston.com/us/embedded/emmc They come in wide temp https://media.kingston.com/pdfs/emmc/i_temp_eMMC_Product_Flyer.pdf About $5 for 4GB from US distributors, so probably $3 from Chinese one. Random check of simil
Re: [linux-sunxi] Dual voltage SDMMC/eMMC on A64
On Mon, Sep 19, 2016 at 12:07 PM, TsvetanUsunov <tsvetanusu...@gmail.com> wrote: > Hi, > > We make our final touch of A64-OLinuXino PCB and there we add option eMMC > Flash to work on dual voltages 1.8V and 3.3V. > The eMMC is connected to AXP803 pin.34 GPIO1/LDO. The problem is that when > A64 boots and AXP803 is not initialized it outputs default 0.8V then after > initialization driver takes care to drive it 1.8V or 3.3V. > This makes impossible to boot from eMMC which is not good. We now think for > solution which to drive eMMC at 3.3V initially when AXP803 output is below > 1.8V but this adds unnecessary hardware complexity. > For hardware point of view it will be much more simplier if dedigated A64 > GPIO is used and initially is pulled down and after AXP803 is initialized is > pulled up. > How would you suggest us to implement it? Will this additional GPIO create > troubles in eMMC driver philosophy? > For the SDMMC we are still hesitating what to do as we don't know if the > card which will be inserted will support low voltage and higher speeds at > all. Also eMMC Flash and SDMMC card should be driven by separate voltages, > as they may work in any combinations. > This means we need another AXP803 LDO and another GPIO for the SDMMC card. > > By the way the current eMMC from Micron we use has 11MB Write speed no > matter what is the voltage and this is written in the datasheet, so maybe we > should switch and add this dual voltage to the SD MMC where someone could > use SD MMC card supporting higher clocks? Does eMMC exist with the higher speed 1.8V option? I know some SD Cards support it. > > I would love to hear your opinion. > > Tsvetan > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Some problem about develop the audio codec driver for A64
On Fri, Sep 9, 2016 at 11:36 AM, Chen-Yu Tsai <w...@csie.org> wrote: > Hi, > > On Fri, Sep 9, 2016 at 11:28 PM, Hao Zhang <hao5781...@gmail.com> wrote: >> hello, >> I want to pick up some tasks list in this web page >> (http://linux-sunxi.org/Linux_mainlining_effort)which is base on A64 >> and i has some problem on it. if i develop the audio codec driver for >> A64, which respository should i use ? I test the function on my pine64 >> board(about pine64 : https://linux-sunxi.org/Pine64), just review and >> looking for some support in the respository which is belong to linus >> or linux-sunxi-next, it seem it doesn't support the board ,such as >> device tree and so on right ? :) So how to deal with it befor the >> task? > > Pine64 or A64 in general doesn't have a lot of support at the moment. > Hopefully we'll start to get the basics in for the next release. > > Until then you'll have to pick whatever patches you can find to have > something working. As for the codec, it looks similar to what we have > on the A33, which is an I2S/PCM interface coupled with a codec inside > the SoC. It might even be exactly the same. Someone previously expressed > interest for the A33 codec. I suggest you pop in to our IRC channel > and ask around. There is an Allwinner written A64 I2S driver in their kernel. It is just named daudio instead of I2S. It is device tree enabled. Follow the lichee part of the instructions here, https://gitlab.com/pine64-android/manifest/wikis/home Source is here, the daudio stuff. https://gitlab.com/pine64-android/linux-3.10/tree/master/sound/soc/sunxi > > Regards > ChenYu > >> >> regards :) >> Zhang Hao > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Converting script.bin to device tree file
I think there is a tool from Allwinner in their more recent releases for mapping fex to device tree. In here somewhere... https://gitlab.com/pine64-android/tools/tree/master when you go through the pack step it prints out a bunch of messages on how it is doing the mapping. I have not looked at the tool, I just noticed the messages it was printing. Complete build instructions for A64 Android https://gitlab.com/pine64-android/manifest/wikis/home On Sun, Sep 4, 2016 at 1:35 PM, Saurabh Jain <saurabh.j...@gmail.com> wrote: >> > Is there a straightforward way to convert a script.bin file to a device >> > tree file? Any HOWTO that maps the various options? > > > We at least need a HOWTO mapping script.bin options to device tree > constructs. I am going to start one... because an unanswered question is an > opportunity to do something. > >> >> > Should I first be experimenting with the sunxi Uboot instead of >> > Mainline? > > > u-boot-sunxi worked. It was almost annoyingly easy. I just needed gcc > gnueabihf 4.x installed first. > >> >> > My device has an AXP152 paired with an A20. Looking at Mainline U-boot, >> > this is an unexpected combination. >> >> This is the first time I've heard of this weird pairing yes, but it should >> work with mainline u-boot, >> just add CONFIG_AXP152_POWER=y to your defconfig. > > > AXP_152 worked in mainline u-boot rather easily. It was the SD card that I > couldn't get working. Strange, because that must obviously work for > _everyone_ else for mainline u-boot to be of any use to anyone. > > SD card worked quite smoothly in u-boot-sunxi. Will try and make nand work > now. > >> >> > What is a good defconfig and dts file to begin work with, with this >> > combination? >> >> None, you're the first... > > > Copied the Cubietruck board.cfg entry and made some changes. Modified the > cubietruck dram file. And done! > >> >> > I've been using the CubieTruck defconfig and dts file so far. I copied >> > over and created a new dts file, which I've been mucking around with (and >> > only making things worse). >> >> Cubietruck is likely as good a start as any, and sorry no fex -> dts tool, >> it is usually just a matter of manually copy and pasting the right >> bits together to get a dts. > > > As mentioned above, we still need a guide that maps between script.bin and > the rather confusing dts file format. > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Fastboot in A64 u-boot
Been looking at the code for a couple hours now. https://github.com/longsleep/u-boot-pine64/blob/pine64-hacks/usb_sunxi/usb_base_sun50iw1p1.c sunxi_usb_init() is getting called. It appears to be enabling interrupts, but I never get anything on sunxi_usb_irq(). On Fri, Aug 12, 2016 at 2:16 PM, jonsm...@gmail.com <jonsm...@gmail.com> wrote: > There is code from Allwinner in their u-boot implementation for > implementing fastboot. So far I have been unsuccessful in getting it > to work. Has anyone succeeded in getting it to work before I dive in > and try fixing it? > > https://gitlab.com/pine64-android/brandy/blob/master/u-boot-2014.07/usb_sunxi/usb_fastboot.c > > -- > Jon Smirl > jonsm...@gmail.com -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Fastboot in A64 u-boot
There is code from Allwinner in their u-boot implementation for implementing fastboot. So far I have been unsuccessful in getting it to work. Has anyone succeeded in getting it to work before I dive in and try fixing it? https://gitlab.com/pine64-android/brandy/blob/master/u-boot-2014.07/usb_sunxi/usb_fastboot.c -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Procedure to build Android/lichee for Pine64
I've taken a recent Allwinner Android dump and converted it to use Google's repo tool. This wasn't too hard to do since Allwinner uses repo internally and just restricts access to their git server (which is an utterly stupid thing to do. A smart company would mirror those repositories on github. Even secretive Qualcomm's Android is public) So I took an 18GB tarball and converted it back to repo form. Build instructions here: https://gitlab.com/pine64-android/manifest/wikis/home What this achieves is getting Allwinner Android under public source code control. Now it is possible for outside developers to coordinate working on it..It is also interesting to note that Allwinner hasn't modified AOSP very much, maybe 1-2% is changed. You can look at the diffs on github. Main repositories only have 5-10 lines of changes. There are two main pieces - the AOSP overlay repos at github. And the lichee repo at gitlab. Files in the lichee repo are too large for github. A wonderful next step would be to get rid of lichee/brandy and convert over to mainline linux/uboot. Let me know if there are any problem with the build, it is not well tested yet. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] hwc force flip disp[1]:1145
I'm using the longsleep kernel on a Pine64. What does this mean? My HDMI display is not starting [ 230.998215] [DISP] disp_device_attached_and_enable,line:159:attched ok, mgr1<-->device1, type=4, mode=10 [ 231.122119] hwc force flip disp[1]:1 [ 231.138696] hwc force flip disp[1]:2 [ 231.188725] hwc force flip disp[1]:3 [ 231.238830] hwc force flip disp[1]:4 [ 231.288817] hwc force flip disp[1]:5 [ 231.338851] hwc force flip disp[1]:6 [ 231.389410] hwc force flip disp[1]:7 [ 231.439546] hwc force flip disp[1]:8 [ 231.489431] hwc force flip disp[1]:9 [ 231.539406] hwc force flip disp[1]:10 [ 231.589240] hwc force flip disp[1]:11 [ 231.639312] hwc force flip disp[1]:12 [ 231.672785] hwc force flip disp[1]:13 [ 231.723057] hwc force flip disp[1]:14 [ 231.772585] hwc force flip disp[1]:15 [ 231.822498] hwc force flip disp[1]:16 [ 231.872469] hwc force flip disp[1]:17 [ 231.922517] hwc force flip disp[1]:18 [ 231.972551] hwc force flip disp[1]:19 [ 232.022577] hwc force flip disp[1]:20 [ 232.072615] hwc force flip disp[1]:21 [ 232.122645] hwc force flip disp[1]:22 -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Forcing device mode on USB OTG, Pine64
Thanks, it is /sys/devices/soc.0/usbc0.5 on this Allwinner 3.10 Android kernel. I turned it on, but still no Android adb. Host machine is unable to USB reset the Android device. So more poking around to see what else I need to turn on. On Mon, Jul 25, 2016 at 3:38 PM, Thomas Kaiser <thomas.kai...@phg-online.de> wrote: > Jon Smirl wrote: >> >> Is there some way to manually poke the kernel and force the port to >> switch modes? > > > In case /sys/bus/platform/devices/sunxi_usb_udc/otg_role exists, setting it > to 2 should switch to OTG role (assumption based on similarities in > Allwinner's BSP legacy kernel for H3, A83T and A64) > > Best regards, > > Thomas > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Forcing device mode on USB OTG, Pine64
The Pine64 has the OTG controller attached to the top normal USB jack. So there is no OTG detection pin to tell the OTG controller when to switch between host and device mode. Is there some way to manually poke the kernel and force the port to switch modes? -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Broadcom 5Ghz and new FCC rules
Does anyone have any info on how Broadcom 5Ghz chipsets work with the new FCC rules about locked down firmware? Is it possible to get FCC certification at 5Ghz without being forced to lock down the whole kernel? http://arstechnica.com/information-technology/2015/09/fcc-open-source-router-software-is-still-legal-under-certain-conditions/ Or do these new rules only apply to routers and not end devices? -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] A64 boot sequence
On Fri, Apr 22, 2016 at 1:36 AM, Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: > On Thu, 21 Apr 2016 19:56:10 -0400 > "jonsm...@gmail.com" <jonsm...@gmail.com> wrote: > >> On Thu, Apr 21, 2016 at 7:45 PM, jonsm...@gmail.com <jonsm...@gmail.com> >> wrote: >> > On Thu, Apr 21, 2016 at 6:01 PM, Siarhei Siamashka >> > <siarhei.siamas...@gmail.com> wrote: >> >> As for designing an A64 board, unless you really want a 64-bit >> >> processor, something like Allwinner H3 might be a better choice >> >> right now. At least it is currently better supported in software >> >> and has more USB ports. ARM Cortex-A53 is faster than ARM Cortex-A7 >> >> per MHz, but it is also more power hungry. >> >> >> >> Do you have any contacts at Allwinner? Probably not, because otherwise >> >> you would not be asking the A64 boot sequence questions here. >> > >> > We require Android 5.1, not an option on H3. >> >> I am interested in getting AW Android running on mainline. System is >> headless so there is no messing with video. > > Does the ordinary GNU/Linux not work good enough for this particular > headless use case? Why Android? And even why specifically Android 5.1? We are running apps that we don't have the source code to. > > I'm not trying to criticize your design, but you got me intrigued. > > Again, if you want a usable mainline kernel on A64 (let alone usable > in Android), then it may take a while. I guess, Olimex and Xunlong > probably have their A64 based boards ready by now, but are simply > waiting for better software support before flooding the market with > their hardware. > > -- > Best regards, > Siarhei Siamashka -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] A64 boot sequence
On Thu, Apr 21, 2016 at 7:45 PM, jonsm...@gmail.com <jonsm...@gmail.com> wrote: > On Thu, Apr 21, 2016 at 6:01 PM, Siarhei Siamashka > <siarhei.siamas...@gmail.com> wrote: >> On Thu, 21 Apr 2016 16:14:13 -0400 >> "jonsm...@gmail.com" <jonsm...@gmail.com> wrote: >> >>> On Thu, Apr 21, 2016 at 4:09 PM, Siarhei Siamashka >>> <siarhei.siamas...@gmail.com> wrote: >>> > On Thu, 21 Apr 2016 13:38:19 -0400 >>> > "jonsm...@gmail.com" <jonsm...@gmail.com> wrote: >>> > >>> >> On Thu, Apr 21, 2016 at 1:17 PM, Siarhei Siamashka >>> >> <siarhei.siamas...@gmail.com> wrote: >>> >> > Hello, >>> >> > >>> >> > On Thu, 21 Apr 2016 11:24:56 -0400 >>> >> > "jonsm...@gmail.com" <jonsm...@gmail.com> wrote: >>> >> > >>> >> >> The manual is very sparse on this subject. Does anyone know what order >>> >> >> it looks at the MMC options? >>> >> >> >>> >> >> For example - MMC flash and an SD Card socket. For brick recovery it >>> >> >> should be possible to put in an SD Card with a proper boot sector >>> >> >> (right signature) and then boot from the SD Card overriding the MMC >>> >> >> flash. >>> >> >>> >> Thanks for info. >>> >> >>> >> > >>> >> > We don't have full details yet, but it looks like the boot order >>> >> > on Allwinner A64 is somewhat similar to >>> >> > https://linux-sunxi.org/Boot#A31 >>> >> > >>> >> > For example, the Jide Remix Mini device boots from the internal >>> >> > eMMC by default, but the user can override the boot order by >>> >> > pressing the FEL button: >>> >> > https://linux-sunxi.org/Jide_Remix_Mini#FEL_mode >>> >> > >>> >> > And if I understand it correctly, most of the Allwinner based devices >>> >> > (at least the ones which do not deviate from the reference schematics) >>> >> > are perfectly unbrickable: >>> >> > >>> >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380686.html >>> >> > >>> >> > When somebody gets an A64 tablet, I strongly suspect that one of the >>> >> > volume control buttons is going to be connected to the FEL pin too. >>> >> > But we can't be 100% sure until somebody confirms this. >>> >> > >>> >> > Why are you asking this question? >>> >> >>> >> We are designing A64 board for an embedded system. >>> >> >>> >> I don't see any boot A64 jumpers for picking one of the four modes -- >>> >> sel[0:1] >>> > >>> > You are right. There are no UBOOT_SEL pins in the A64 datasheet. This >>> > probably means that there is some hardcoded boot order in the case if >>> > the FEL button is not pressed. But we haven't seen anything other than >>> > the SD card and the eMMC as a bootable media yet >>> > >>> > BTW, did you reply off-list on purpose? >>> >>> no, i just must have touched wrong reply key >> >> OK, adding the linux-sunxi mailing list back to CC :-) >> >> I have also tried to experiment a bit and added the actual A64 boot >> sequence information to the wiki: >> >> https://linux-sunxi.org/BROM#A64 >> >> As for designing an A64 board, unless you really want a 64-bit >> processor, something like Allwinner H3 might be a better choice >> right now. At least it is currently better supported in software >> and has more USB ports. ARM Cortex-A53 is faster than ARM Cortex-A7 >> per MHz, but it is also more power hungry. >> >> Do you have any contacts at Allwinner? Probably not, because otherwise >> you would not be asking the A64 boot sequence questions here. > > We require Android 5.1, not an option on H3. I am interested in getting AW Android running on mainline. System is headless so there is no messing with video. > > >> >> -- >> Best regards, >> Siarhei Siamashka > > > > -- > Jon Smirl > jonsm...@gmail.com -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] A64 boot sequence
On Thu, Apr 21, 2016 at 6:01 PM, Siarhei Siamashka <siarhei.siamas...@gmail.com> wrote: > On Thu, 21 Apr 2016 16:14:13 -0400 > "jonsm...@gmail.com" <jonsm...@gmail.com> wrote: > >> On Thu, Apr 21, 2016 at 4:09 PM, Siarhei Siamashka >> <siarhei.siamas...@gmail.com> wrote: >> > On Thu, 21 Apr 2016 13:38:19 -0400 >> > "jonsm...@gmail.com" <jonsm...@gmail.com> wrote: >> > >> >> On Thu, Apr 21, 2016 at 1:17 PM, Siarhei Siamashka >> >> <siarhei.siamas...@gmail.com> wrote: >> >> > Hello, >> >> > >> >> > On Thu, 21 Apr 2016 11:24:56 -0400 >> >> > "jonsm...@gmail.com" <jonsm...@gmail.com> wrote: >> >> > >> >> >> The manual is very sparse on this subject. Does anyone know what order >> >> >> it looks at the MMC options? >> >> >> >> >> >> For example - MMC flash and an SD Card socket. For brick recovery it >> >> >> should be possible to put in an SD Card with a proper boot sector >> >> >> (right signature) and then boot from the SD Card overriding the MMC >> >> >> flash. >> >> >> >> Thanks for info. >> >> >> >> > >> >> > We don't have full details yet, but it looks like the boot order >> >> > on Allwinner A64 is somewhat similar to >> >> > https://linux-sunxi.org/Boot#A31 >> >> > >> >> > For example, the Jide Remix Mini device boots from the internal >> >> > eMMC by default, but the user can override the boot order by >> >> > pressing the FEL button: >> >> > https://linux-sunxi.org/Jide_Remix_Mini#FEL_mode >> >> > >> >> > And if I understand it correctly, most of the Allwinner based devices >> >> > (at least the ones which do not deviate from the reference schematics) >> >> > are perfectly unbrickable: >> >> > >> >> > http://lists.infradead.org/pipermail/linux-arm-kernel/2015-October/380686.html >> >> > >> >> > When somebody gets an A64 tablet, I strongly suspect that one of the >> >> > volume control buttons is going to be connected to the FEL pin too. >> >> > But we can't be 100% sure until somebody confirms this. >> >> > >> >> > Why are you asking this question? >> >> >> >> We are designing A64 board for an embedded system. >> >> >> >> I don't see any boot A64 jumpers for picking one of the four modes -- >> >> sel[0:1] >> > >> > You are right. There are no UBOOT_SEL pins in the A64 datasheet. This >> > probably means that there is some hardcoded boot order in the case if >> > the FEL button is not pressed. But we haven't seen anything other than >> > the SD card and the eMMC as a bootable media yet >> > >> > BTW, did you reply off-list on purpose? >> >> no, i just must have touched wrong reply key > > OK, adding the linux-sunxi mailing list back to CC :-) > > I have also tried to experiment a bit and added the actual A64 boot > sequence information to the wiki: > > https://linux-sunxi.org/BROM#A64 > > As for designing an A64 board, unless you really want a 64-bit > processor, something like Allwinner H3 might be a better choice > right now. At least it is currently better supported in software > and has more USB ports. ARM Cortex-A53 is faster than ARM Cortex-A7 > per MHz, but it is also more power hungry. > > Do you have any contacts at Allwinner? Probably not, because otherwise > you would not be asking the A64 boot sequence questions here. We require Android 5.1, not an option on H3. > > -- > Best regards, > Siarhei Siamashka -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] A64 boot sequence
The manual is very sparse on this subject. Does anyone know what order it looks at the MMC options? For example - MMC flash and an SD Card socket. For brick recovery it should be possible to put in an SD Card with a proper boot sector (right signature) and then boot from the SD Card overriding the MMC flash. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Allwinner dev board code names
Pine 64 has an android/lichee Allwinner code drop from 1/13/16. http://wiki.pine64.org/index.php/Pine_A64_Software_Release Is these anything interesting in it? Looks likes there is only H3 support in their 3.4 kernel, not the 3.10 one. Don't see Android 5.1 for H3 either. On Sat, Apr 2, 2016 at 10:33 AM, Thomas Kaiser <thomas.kai...@phg-online.de> wrote: > Jon Smirl wrote: >> >> I was looking for H3. > > > What about dolphin then? > > https://github.com/friendlyarm/h3_lichee/tree/master/tools/pack/chips/sun8iw7p1/configs > > Thomas > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: Allwinner dev board code names
On Fri, Apr 1, 2016 at 6:50 PM, jonsm...@gmail.com <jonsm...@gmail.com> wrote: > What CPUs do these Allwinner dev boards correspond to? > > 15. octopus_f1-user A83 > 17. astar_h7-user A33 > 19. jasmine_perf-user can't find this one > 29. kylin_p2-user A80 > 33. tulip_p1-user A64 I was looking for H3. > > > -- > Jon Smirl > jonsm...@gmail.com -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Allwinner dev board code names
What CPUs do these Allwinner dev boards correspond to? 15. octopus_f1-user 17. astar_h7-user 19. jasmine_perf-user 29. kylin_p2-user 33. tulip_p1-user -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] H3 Android and mainline kernel
Does Allwinner H3 Android 4.4 run on the mainline H3 kernel? -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: allwinner-zh/media-codec demo
On Mon, Mar 14, 2016 at 2:22 PM, Manuel Braga <mul.br...@gmail.com> wrote: > On Sun, 13 Mar 2016 18:00:17 -0400 "jonsm...@gmail.com" > <jonsm...@gmail.com> wrote: >> On Sun, Mar 13, 2016 at 5:16 PM, Manuel Braga <mul.br...@gmail.com> >> wrote: >> > On Sun, 13 Mar 2016 13:28:22 -0500 Rosimildo DaSilva >> > <rosimi...@gmail.com> wrote: >> >> >> >> If we implement some Cedrus that works with relatively new H3/A64 >> > >> > The encoding side, you mean. >> > That is easy, just what is need is for someone to do the need work. >> > There isn't any technical difficulty, only is need time to do it. >> > Please help us(the cedrus people), so that we can arrange the time >> > to do it. >> >> We abandoned the Allwinner encoder hardware after discovering the >> limitations of the hardware. The Allwinner encoder hardware is a >> medium quality encoder that is not capable of making highly compressed >> streams. But having said that, it is fine for use on a LAN, it just >> isn't much good if you want to send a quality stream to a cell phone. >> Another issue is that most of the Allwinner SOC don't have an ISP >> (image signal processor) unit (some do, but most don't). > > > Right, this is one thing that most be made aware about this video > engine, to avoid be disappointed about the expected quality. > > The h264 encoder can only do baseline profile (from what was found) > When setting low QP values, there are a point in which the bitstream > size stop decreasing, instead size get bigger, and with even lower > values the images get trashed beyond recognition. > > And this is a hardware limitation. > > > About ISP, well it depends what one whats to do. > To encode in this video engine, the raw frames are feed to a called > isp subengine, which acts as a source for the subengine that does the > encoding. This "isp subengine" can do cropping, scaling, and take as > source some different formats, no much else. I want ISPs with denoising capability. Back to back frames can have a lot of least significant bit jitter in them. The denoising detects this and suppresses a lot of it. If you don't do this all of that noise gets h.264 encoded and it can add 30-40% to the stream bandwidth with useless noise. > > And as you said, there is also in some socs a hardware block that > functions as an ISP, but i know nothing about it. > > > -- > Manuel Braga -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: allwinner-zh/media-codec demo
nse-issues. >> > >> > >> > The "valid reason" that was asked some time ago, is just this. >> > >> > A valid reason, is to respect the license of the software used, >> > which implicits, to choose the solution with no-license-issues. >> > >> > And what we see here, you choose to work around with the >> > binary-blobs-with-random-license-issues. >> > I am sorry, but i can't help. >> > >> > If you are doing this because cedrus(the project for libre and open >> > source for the video engine) *still* don't supports encoding in H3. >> > (And, i must say that this will be very simples to add.) >> > >> > Is because, we can't do everything in the few free time that >> > we(cedrus people) have to spend in this. WE are forced to make >> > decisions and define priorities. Because everyone knows, we all >> > have lifes beyond sunxi. >> > >> > Why are you wasting your time with blobs-with-random-license-issues, >> > when you could be helping cedrus moving forward. >> > >> > Isn't this what "open source" means, working together for mutual >> > benefit. >> > >> > Everyone is more than welcome to join and be part of cedrus. >> > And is up to everyone to make their choice. >> > >> > >> > >> > >> > On Sun, 13 Mar 2016 10:16:01 -0500 Rosimildo DaSilva >> > <rosimi...@gmail.com> wrote: >> > > I will try in a few weeks. >> > > >> > > I am going on a business trip for 2 wks, and when I get back I >> > > will try it. The way it is now, it is very easy to use ffmpeg, >> > > but you have to use scripts to pipe FFMPEG preprocessing to the >> > > encoder, and use the "H264" stream with FFMPEG to mux it, and >> > > transport it. >> > > >> > > R >> > > >> > > >> > > >> > > On Sun, Mar 13, 2016 at 9:27 AM, @lex <alex.mob...@gmail.com> >> > > wrote: >> > > >> > > > Rosimildo, >> > > > >> > > > Do you think you can do a rework on this ffmpeg tree and glue a >> > > > C version of what you have achieved so far? >> > > > >> > > > >> > > > On Saturday, March 12, 2016 at 9:40:16 PM UTC-3, Jon Smirl >> > > > wrote: >> > > >> >> > > >> On Sat, Mar 12, 2016 at 7:38 PM, jons...@gmail.com >> > > >> <jons...@gmail.com> wrote: >> > > >> > On Sat, Mar 12, 2016 at 7:37 PM, @lex <alex@gmail.com> >> > > >> > wrote: >> > > >> >> You are right, i changed the input format to NV12 on >> > > >> >> GuvcView and got >> > > >> lower >> > > >> >> CPU usage (250%) and Temp ~75C. >> > > >> >> I does not help much overall. >> > > >> > >> > > >> > You need an ffmpeg that has been taught how to use the >> > > >> > hardware decode features on your SOC. >> > > >> > >> > > >> > Don't know if one exists for H3. >> > > >> >> > > >> Maybe this will work?... >> > > >> >> > > >> https://github.com/stulluk/FFmpeg-Cedrus >> > > >> >> > >> > -- >> > Manuel Braga >> > > > -- > Manuel Braga > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: allwinner-zh/media-codec demo
On Sat, Mar 12, 2016 at 7:38 PM, jonsm...@gmail.com <jonsm...@gmail.com> wrote: > On Sat, Mar 12, 2016 at 7:37 PM, @lex <alex.mob...@gmail.com> wrote: >> You are right, i changed the input format to NV12 on GuvcView and got lower >> CPU usage (250%) and Temp ~75C. >> I does not help much overall. > > You need an ffmpeg that has been taught how to use the hardware decode > features on your SOC. > > Don't know if one exists for H3. Maybe this will work?... https://github.com/stulluk/FFmpeg-Cedrus > > >> >> >> On Saturday, March 12, 2016 at 8:47:38 PM UTC-3, Rosimildo DaSilva wrote: >>> >>> I have this camera, and if you change the "start_video.sh" script to >>> something like this >>> you can see... the results... the CPU usage is much lower... >>> >>> echo "Starting H264 Encoder..." >>> $FFMPEG -f v4l2 -input_format yuyv422 -r 10 -s 1280x720 -i >>> $SRC_VIDEO -pix_fmt yuv420p -an -r 25 -f rawvideo - | \ >>>$ROOT_DIR/videoenc -i - -k 2 -r 25 -b 1024 -s 1280x720 -o >>> /tmp/out1.h264 >>> ;; >>> >>> R >>> >>> On Saturday, March 12, 2016 at 4:55:57 PM UTC-6, @lex wrote: >>>> >>>> Inspired by so many good arguments on USB uvc cameras i decided to test >>>> one, a 720P HD used in ODROID, so you can take a look and see how good it >>>> is >>>> for Orange Pi PC (Allwinner H3) and decide if having Encode/Decode by HW >>>> worth the effort or we throw in the towel, it is up to you. >>>> >>>> This is simple test, done with Orange Pi PC, with a tuned 3.4.39 kernel >>>> and with ssvb fex (TKaiser advice) to solve the so known temperature issues >>>> this board faces when running at high speed. >>>> >>>> The uvc camera is ODROID 720 HD: >>>> [ 196.199875] ehci_irq: highspeed device connect >>>> [ 196.460139] usb 4-1: new high-speed USB device number 2 using >>>> sunxi-ehci >>>> [ 196.890710] 2:3:1: cannot get freq at ep 0x84 >>>> [ 196.892434] usbcore: registered new interface driver snd-usb-audio >>>> [ 196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (1b71:0056) >>>> [ 196.938300] is_otg_flag: 0x0, >>>> [ 196.938479] usbcore: registered new interface driver uvcvideo >>>> [ 196.938489] USB Video Class driver (v1.1.1) >>>> [ 196.976118] 2:3:1: cannot get freq at ep 0x84 >>>> >>>> >>>> As Jon said, you don't need to do anything, just plug it in and start >>>> using the UVC camera compliant. No need to worry about drivers, etc.. >>>> This camera has MPJEG mode and YUV mode: >>>> ioctl: VIDIOC_ENUM_FMT >>>> Index : 0 >>>> Type: Video Capture >>>> Pixel Format: 'MJPG' (compressed) >>>> Name: MJPEG >>>> Size: Discrete 1280x720 >>>> Interval: Discrete 0.033s (30.000 fps) >>>> Interval: Discrete 0.040s (25.000 fps) >>>> Interval: Discrete 0.050s (20.000 fps) >>>> Interval: Discrete 0.067s (15.000 fps) >>>> Interval: Discrete 0.100s (10.000 fps) >>>> Interval: Discrete 0.200s (5.000 fps) >>>> Size: Discrete 640x480 >>>> Interval: Discrete 0.033s (30.000 fps) >>>> Interval: Discrete 0.040s (25.000 fps) >>>> Interval: Discrete 0.050s (20.000 fps) >>>> Interval: Discrete 0.067s (15.000 fps) >>>> Interval: Discrete 0.100s (10.000 fps) >>>> Interval: Discrete 0.200s (5.000 fps) >>>> Size: Discrete 640x360 >>>> Interval: Discrete 0.033s (30.000 fps) >>>> Interval: Discrete 0.040s (25.000 fps) >>>> Interval: Discrete 0.050s (20.000 fps) >>>> Interval: Discrete 0.067s (15.000 fps) >>>> Interval: Discrete 0.100s (10.000 fps) >>>> Interval: Discrete 0.200s (5.000 fps) >>>> Size: Discrete 544x288 >>>> Interval: Discrete 0.033s (30.000 fps) >>>> Interval: Discrete 0.040s (25.000 fps) >>>> Interval: Discrete 0.050s (20.000 fps) >>>> Interval: Discrete 0.067s (15.000 fps) >>>> Interval: Discrete 0.100s (10.000 fps) >>>> Interval: Discrete 0.200s (5.000 fps) >>>> Size: Discrete 432x240 >>>> Interval: Discrete 0.017s (60.000 fps) >>>> Interval: Discrete 0.033s (30.000 fps) >>>> Interval: Discrete 0.040s (25.000 fps) >>>> Interval: Discrete 0.050s (20.000 f
Re: [linux-sunxi] Re: allwinner-zh/media-codec demo
;> [33719.121687] usb 2-5.1: New USB device found, idVendor=18e3, >> >> >> >> idProduct=5100 >> >> >> >> [33719.121692] usb 2-5.1: New USB device strings: Mfr=2, >> >> >> >> Product=1, >> >> >> >> SerialNumber=3 >> >> >> >> [33719.121696] usb 2-5.1: Product: USB 2.0 Camera >> >> >> >> [33719.121698] usb 2-5.1: Manufacturer: Sonix Technology Co., >> >> >> >> Ltd. >> >> >> >> [33719.121701] usb 2-5.1: SerialNumber: SN0001 >> >> >> >> [33719.122631] uvcvideo: Found UVC 1.00 device USB 2.0 Camera >> >> >> >> (18e3:5100) >> >> >> >> [33719.146885] uvcvideo: Unable to create debugfs 2-13 directory. >> >> >> >> [33719.147213] input: USB 2.0 Camera as >> >> >> >> >> >> >> >> >> >> >> >> /devices/pci:00/:00:1d.7/usb2/2-5/2-5.1/2-5.1:1.0/input/input15 >> >> >> >> jonsmirl@terra:/work/gm/linux-3.3-fa$ >> >> >> >> >> >> >> >> On Fri, Mar 11, 2016 at 6:26 PM, @lex <alex@gmail.com> wrote: >> >> >> >> > Can you please tell me the idVendor and idProduct for this >> >> >> >> > camera? >> >> >> >> > >> >> >> >> > >> >> >> >> > On Friday, March 11, 2016 at 8:08:21 PM UTC-3, @lex wrote: >> >> >> >> >> >> >> >> >> >> Err... That was new to me. Without researching how do you grab >> >> >> >> >> video >> >> >> >> >> from >> >> >> >> >> this generic driver how good this camera performs? >> >> >> >> >> >> >> >> >> >> On Friday, March 11, 2016 at 7:52:17 PM UTC-3, Jon Smirl >> >> >> >> >> wrote: >> >> >> >> >>> >> >> >> >> >>> On Fri, Mar 11, 2016 at 4:42 PM, @lex <alex@gmail.com> >> >> >> >> >>> wrote: >> >> >> >> >>> > Seems to be a nice camera, but that depends on your kernel >> >> >> >> >>> > version. >> >> >> >> >>> > There is no support for SN9C291 OV9712 on kernel v3.4.39. >> >> >> >> >>> > And no support on odroid-3.8.30 on my U3 also. >> >> >> >> >>> > Don't know about armbian legacy kernel version, but i don't >> >> >> >> >>> > expect >> >> >> >> >>> > there >> >> >> >> >>> > will be support also. >> >> >> >> >>> >> >> >> >> >>> The camera does not need a specific driver, it uses the >> >> >> >> >>> generic >> >> >> >> >>> USB >> >> >> >> >>> Video driver. >> >> >> >> >>> It is like a USB mouse or keyboard, you don't need a specific >> >> >> >> >>> driver >> >> >> >> >>> for every different one. >> >> >> >> >>> >> >> >> >> >>> Drivers/Multimedia/Media USB/USB Video Class (UVC) >> >> >> >> >>> >> >> >> >> >>> Kconfig USB_VIDEO_CLASS >> >> >> >> >>> >> >> >> >> >>> This support dates way back to around 2.4 or so. Almost every >> >> >> >> >>> desktop >> >> >> >> >>> web cam works using this driver. >> >> >> >> >>> >> >> >> >> >>> > >> >> >> >> >>> > On Friday, March 11, 2016 at 4:41:59 PM UTC-3, Jon Smirl >> >> >> >> >>> > wrote: >> >> >> >> >>> >> >> >> >> >> >>> >> On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga >> >> >> >> >>> >> <mul@gmail.com> >> >> >> >> >>> >> wrote: >> >> >> >> >>> >> > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo >> >> >> >> >>> >> > DaSilva >> >> >> >> >>> >> > <rosi...@gmail.com> wrote: >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> I did not mention, but I founf two issues withe blobs: >> >> >> >> >>> >> >> >> >> >> >> >>> >> >> a) Motion Detection causes segmentation fault, whenever >> >> >> >> >>> >> >> enabled. >> >> >> >> >>> >> >> b) FFMPEG complains that timestamp ( PTS/DTS ) are >> >> >> >> >>> >> >> missing >> >> >> >> >>> >> >> on >> >> >> >> >>> >> >> the >> >> >> >> >>> >> >> H264 stream generated by the encoder... I've tried many >> >> >> >> >>> >> >> things ( >> >> >> >> >>> >> >> code >> >> >> >> >>> >> >> is commented out ), but nothing worked. >> >> >> >> >>> >> > >> >> >> >> >>> >> > There is another issue, that i believe to be important. >> >> >> >> >>> >> > But for whatever reasons, it has to be constantly >> >> >> >> >>> >> > remembered >> >> >> >> >>> >> > about >> >> >> >> >>> >> > its >> >> >> >> >>> >> > existence. >> >> >> >> >>> >> > >> >> >> >> >>> >> > And that issue is: >> >> >> >> >>> >> > >> >> >> >> >>> >> > c) The proprietaries binary blobs don't have a clear >> >> >> >> >>> >> > license >> >> >> >> >>> >> > attached. >> >> >> >> >>> >> > >> >> >> >> >>> >> > And in the copyright law, any "things" with "no license" >> >> >> >> >>> >> > by >> >> >> >> >>> >> > default >> >> >> >> >>> >> > fell >> >> >> >> >>> >> > in the "all rights reserved". >> >> >> >> >>> >> >> >> >> >> >>> >> I gave up fighting with Allwinner's encoder long ago. It >> >> >> >> >>> >> is >> >> >> >> >>> >> far >> >> >> >> >>> >> easier >> >> >> >> >>> >> to just plug in a USB based h.264 camera. You can easily >> >> >> >> >>> >> buy >> >> >> >> >>> >> ones >> >> >> >> >>> >> from >> >> >> >> >>> >> Logitech for $50. >> >> >> >> >>> >> >> >> >> >> >>> >> If you want it at the hardware level, look at chips from >> >> >> >> >>> >> Sonix. >> >> >> >> >>> >> Here >> >> >> >> >>> >> is a board based on the SN9C291 for $8.50. The bare chips >> >> >> >> >>> >> are >> >> >> >> >>> >> about >> >> >> >> >>> >> $4. >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail >> >> >> >> >>> >> >> >> >> >> >>> >> Note that this PCBA is the same price as most bare image >> >> >> >> >>> >> sensors >> >> >> >> >>> >> mounted on a flex cable. Plus I find it much easier to >> >> >> >> >>> >> wire >> >> >> >> >>> >> things >> >> >> >> >>> >> with a simple USB cable instead of an FFC. >> >> >> >> >>> >> >> >> >> >> >>> >> The Sonix chips will appear as USB UVC devices when >> >> >> >> >>> >> plugged >> >> >> >> >>> >> into >> >> >> >> >>> >> Linux >> >> >> >> >>> >> and they will need no special drivers. They also work on >> >> >> >> >>> >> Windows. >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> > >> >> >> >> >>> >> > -- >> >> >> >> >>> >> > Manuel Braga >> >> >> >> >>> >> > >> >> >> >> >>> >> > -- >> >> >> >> >>> >> > You received this message because you are subscribed to >> >> >> >> >>> >> > the >> >> >> >> >>> >> > Google >> >> >> >> >>> >> > Groups "linux-sunxi" group. >> >> >> >> >>> >> > To unsubscribe from this group and stop receiving emails >> >> >> >> >>> >> > from >> >> >> >> >>> >> > it, >> >> >> >> >>> >> > send >> >> >> >> >>> >> > an email to linux-sunxi...@googlegroups.com. >> >> >> >> >>> >> > For more options, visit >> >> >> >> >>> >> > https://groups.google.com/d/optout. >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> >> >> >> >> >>> >> -- >> >> >> >> >>> >> Jon Smirl >> >> >> >> >>> >> jons...@gmail.com >> >> >> >> >>> > >> >> >> >> >>> > -- >> >> >> >> >>> > You received this message because you are subscribed to the >> >> >> >> >>> > Google >> >> >> >> >>> > Groups >> >> >> >> >>> > "linux-sunxi" group. >> >> >> >> >>> > To unsubscribe from this group and stop receiving emails >> >> >> >> >>> > from >> >> >> >> >>> > it, >> >> >> >> >>> > send >> >> >> >> >>> > an >> >> >> >> >>> > email to linux-sunxi...@googlegroups.com. >> >> >> >> >>> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> -- >> >> >> >> >>> Jon Smirl >> >> >> >> >>> jons...@gmail.com >> >> >> >> > >> >> >> >> > -- >> >> >> >> > You received this message because you are subscribed to the >> >> >> >> > Google >> >> >> >> > Groups >> >> >> >> > "linux-sunxi" group. >> >> >> >> > To unsubscribe from this group and stop receiving emails from >> >> >> >> > it, >> >> >> >> > send >> >> >> >> > an >> >> >> >> > email to linux-sunxi...@googlegroups.com. >> >> >> >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Jon Smirl >> >> >> >> jons...@gmail.com >> >> >> > >> >> >> > -- >> >> >> > You received this message because you are subscribed to the Google >> >> >> > Groups >> >> >> > "linux-sunxi" group. >> >> >> > To unsubscribe from this group and stop receiving emails from it, >> >> >> > send >> >> >> > an >> >> >> > email to linux-sunxi...@googlegroups.com. >> >> >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Jon Smirl >> >> >> jons...@gmail.com >> >> > >> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups >> >> > "linux-sunxi" group. >> >> > To unsubscribe from this group and stop receiving emails from it, >> >> > send >> >> > an >> >> > email to linux-sunxi...@googlegroups.com. >> >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> >> >> -- >> >> Jon Smirl >> >> jons...@gmail.com >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "linux-sunxi" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an >> > email to linux-sunxi...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Jon Smirl >> jons...@gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: allwinner-zh/media-codec demo
My examples are running on Ubuntu with kernel 4.2. jonsmirl@terra:/work/gm/linux-3.3-fa$ uname -a Linux terra 4.2.0-33-generic #38-Ubuntu SMP Tue Mar 8 22:42:18 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux jonsmirl@terra:/work/gm/linux-3.3-fa$ The linux-3.3-fa prompt is because I am painfully working on an ARM9 vendor kernel when the vendor does not update their code. I am porting features from the current kernel back to their old system. I don't have the source for everything to forward port their code. On Sat, Mar 12, 2016 at 6:10 PM, jonsm...@gmail.com <jonsm...@gmail.com> wrote: > Look carefully at my sonix video parameters... > notice that there are two /dev/videoX devices > > This is done so that the screen display app can use the the > uncompressed stream while forwarding on the h.264 stream without > decompressing it. The uncompressed stream does not need much CPU to > display. > > jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video1 > --list-formats-ext > ioctl: VIDIOC_ENUM_FMT > Index : 0 > Type: Video Capture > Pixel Format: 'YUYV' > Name: YUYV 4:2:2 > Size: Discrete 1280x720 > Interval: Discrete 0.200s (5.000 fps) > Size: Discrete 640x480 > Interval: Discrete 0.033s (30.000 fps) > Interval: Discrete 0.050s (20.000 fps) > Interval: Discrete 0.067s (15.000 fps) > Interval: Discrete 0.100s (10.000 fps) > Interval: Discrete 0.200s (5.000 fps) > Size: Discrete 320x240 > Interval: Discrete 0.033s (30.000 fps) > Interval: Discrete 0.050s (20.000 fps) > Interval: Discrete 0.067s (15.000 fps) > Interval: Discrete 0.100s (10.000 fps) > Interval: Discrete 0.200s (5.000 fps) > > Both MJPG and h.264 work at 720P30. > Index : 1 > Type: Video Capture > Pixel Format: 'MJPG' (compressed) > Name: Motion-JPEG > Size: Discrete 1280x720 > Interval: Discrete 0.033s (30.000 fps) > Interval: Discrete 0.050s (20.000 fps) > Interval: Discrete 0.067s (15.000 fps) > Interval: Discrete 0.100s (10.000 fps) > Interval: Discrete 0.200s (5.000 fps) > Size: Discrete 640x480 > Interval: Discrete 0.033s (30.000 fps) > Interval: Discrete 0.050s (20.000 fps) > Interval: Discrete 0.067s (15.000 fps) > Interval: Discrete 0.100s (10.000 fps) > Interval: Discrete 0.200s (5.000 fps) > Size: Discrete 320x240 > Interval: Discrete 0.033s (30.000 fps) > Interval: Discrete 0.050s (20.000 fps) > Interval: Discrete 0.067s (15.000 fps) > Interval: Discrete 0.100s (10.000 fps) > Interval: Discrete 0.200s (5.000 fps) > > jonsmirl@terra:/work/gm/linux-3.3-fa$ v4l2-ctl -d /dev/video2 > --list-formats-ext > ioctl: VIDIOC_ENUM_FMT > Index : 0 > Type: Video Capture > Pixel Format: 'H264' (compressed) > Name: H.264 > Size: Discrete 1280x720 > Interval: Discrete 0.033s (30.000 fps) > Interval: Discrete 0.050s (20.000 fps) > Interval: Discrete 0.067s (15.000 fps) > Interval: Discrete 0.100s (10.000 fps) > Interval: Discrete 0.200s (5.000 fps) > Size: Discrete 640x480 > Interval: Discrete 0.033s (30.000 fps) > Interval: Discrete 0.050s (20.000 fps) > Interval: Discrete 0.067s (15.000 fps) > Interval: Discrete 0.100s (10.000 fps) > Interval: Discrete 0.200s (5.000 fps) > Size: Discrete 320x240 > Interval: Discrete 0.033s (30.000 fps) > Interval: Discrete 0.050s (20.000 fps) > Interval: Discrete 0.067s (15.000 fps) > Interval: Discrete 0.100s (10.000 fps) > Interval: Discrete 0.200s (5.000 fps) > > On Sat, Mar 12, 2016 at 5:55 PM, @lex <alex.mob...@gmail.com> wrote: >> Inspired by so many good arguments on USB uvc cameras i decided to test one, >> a 720P HD used in ODROID, so you can take a look and see how good it is for >> Orange Pi PC (Allwinner H3) and decide if having Encode/Decode by HW worth >> the effort or we throw in the towel, it is up to you. >> >> This is simple test, done with Orange Pi PC, with a tuned 3.4.39 kernel and >> with ssvb fex (TKaiser advice) to solve the so known temperature issues this >> board faces when running at high speed. >> >> The uvc camera is ODROID 720 HD: >> [ 196.199875] ehci_irq: highspeed device connect >> [ 196.460139] usb 4-1: new high-speed USB device number 2 using sunxi-ehci >> [ 196.890710] 2:3:1: cannot get freq at ep 0x84 >> [ 196.892434] usbcore: registered new interface driver snd-usb-audio >> [ 196.923986] uvcvideo: Found UVC 1.00 device USB 2.0 Camera (1b71:0056) >> [ 196.938300] is_otg_flag: 0x0, >> [ 196.938479] usbcore: registered new interface driver uvcvideo >> [ 196.938489] USB Video Class driver (v1.1.1) >> [ 196.976118] 2:3:1: cannot get freq at ep 0x84 >> >> >> As Jon said, you don't need to do anything, just plug it in and star
Re: [linux-sunxi] Re: allwinner-zh/media-codec demo
..@gmail.com> wrote: >> >> >> > Can you please tell me the idVendor and idProduct for this camera? >> >> >> > >> >> >> > >> >> >> > On Friday, March 11, 2016 at 8:08:21 PM UTC-3, @lex wrote: >> >> >> >> >> >> >> >> Err... That was new to me. Without researching how do you grab >> >> >> >> video >> >> >> >> from >> >> >> >> this generic driver how good this camera performs? >> >> >> >> >> >> >> >> On Friday, March 11, 2016 at 7:52:17 PM UTC-3, Jon Smirl wrote: >> >> >> >>> >> >> >> >>> On Fri, Mar 11, 2016 at 4:42 PM, @lex <alex@gmail.com> >> >> >> >>> wrote: >> >> >> >>> > Seems to be a nice camera, but that depends on your kernel >> >> >> >>> > version. >> >> >> >>> > There is no support for SN9C291 OV9712 on kernel v3.4.39. >> >> >> >>> > And no support on odroid-3.8.30 on my U3 also. >> >> >> >>> > Don't know about armbian legacy kernel version, but i don't >> >> >> >>> > expect >> >> >> >>> > there >> >> >> >>> > will be support also. >> >> >> >>> >> >> >> >>> The camera does not need a specific driver, it uses the generic >> >> >> >>> USB >> >> >> >>> Video driver. >> >> >> >>> It is like a USB mouse or keyboard, you don't need a specific >> >> >> >>> driver >> >> >> >>> for every different one. >> >> >> >>> >> >> >> >>> Drivers/Multimedia/Media USB/USB Video Class (UVC) >> >> >> >>> >> >> >> >>> Kconfig USB_VIDEO_CLASS >> >> >> >>> >> >> >> >>> This support dates way back to around 2.4 or so. Almost every >> >> >> >>> desktop >> >> >> >>> web cam works using this driver. >> >> >> >>> >> >> >> >>> > >> >> >> >>> > On Friday, March 11, 2016 at 4:41:59 PM UTC-3, Jon Smirl >> >> >> >>> > wrote: >> >> >> >>> >> >> >> >> >>> >> On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga >> >> >> >>> >> <mul@gmail.com> >> >> >> >>> >> wrote: >> >> >> >>> >> > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva >> >> >> >>> >> > <rosi...@gmail.com> wrote: >> >> >> >>> >> >> >> >> >> >>> >> >> I did not mention, but I founf two issues withe blobs: >> >> >> >>> >> >> >> >> >> >>> >> >> a) Motion Detection causes segmentation fault, whenever >> >> >> >>> >> >> enabled. >> >> >> >>> >> >> b) FFMPEG complains that timestamp ( PTS/DTS ) are missing >> >> >> >>> >> >> on >> >> >> >>> >> >> the >> >> >> >>> >> >> H264 stream generated by the encoder... I've tried many >> >> >> >>> >> >> things ( >> >> >> >>> >> >> code >> >> >> >>> >> >> is commented out ), but nothing worked. >> >> >> >>> >> > >> >> >> >>> >> > There is another issue, that i believe to be important. >> >> >> >>> >> > But for whatever reasons, it has to be constantly >> >> >> >>> >> > remembered >> >> >> >>> >> > about >> >> >> >>> >> > its >> >> >> >>> >> > existence. >> >> >> >>> >> > >> >> >> >>> >> > And that issue is: >> >> >> >>> >> > >> >> >> >>> >> > c) The proprietaries binary blobs don't have a clear >> >> >> >>> >> > license >> >> >> >>> >> > attached. >> >> >> >>> >> > >> >> >> >>> >> > And in the copyright law, any "things" with "no license" by >> >> >> >>> >> > default >> >> >> >>> >> > fell >> >> >> >>> >> > in the "all rights reserved". >> >> >> >>> >> >> >> >> >>> >> I gave up fighting with Allwinner's encoder long ago. It is >> >> >> >>> >> far >> >> >> >>> >> easier >> >> >> >>> >> to just plug in a USB based h.264 camera. You can easily buy >> >> >> >>> >> ones >> >> >> >>> >> from >> >> >> >>> >> Logitech for $50. >> >> >> >>> >> >> >> >> >>> >> If you want it at the hardware level, look at chips from >> >> >> >>> >> Sonix. >> >> >> >>> >> Here >> >> >> >>> >> is a board based on the SN9C291 for $8.50. The bare chips are >> >> >> >>> >> about >> >> >> >>> >> $4. >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail >> >> >> >>> >> >> >> >> >>> >> Note that this PCBA is the same price as most bare image >> >> >> >>> >> sensors >> >> >> >>> >> mounted on a flex cable. Plus I find it much easier to wire >> >> >> >>> >> things >> >> >> >>> >> with a simple USB cable instead of an FFC. >> >> >> >>> >> >> >> >> >>> >> The Sonix chips will appear as USB UVC devices when plugged >> >> >> >>> >> into >> >> >> >>> >> Linux >> >> >> >>> >> and they will need no special drivers. They also work on >> >> >> >>> >> Windows. >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> > >> >> >> >>> >> > -- >> >> >> >>> >> > Manuel Braga >> >> >> >>> >> > >> >> >> >>> >> > -- >> >> >> >>> >> > You received this message because you are subscribed to the >> >> >> >>> >> > Google >> >> >> >>> >> > Groups "linux-sunxi" group. >> >> >> >>> >> > To unsubscribe from this group and stop receiving emails >> >> >> >>> >> > from >> >> >> >>> >> > it, >> >> >> >>> >> > send >> >> >> >>> >> > an email to linux-sunxi...@googlegroups.com. >> >> >> >>> >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> >> >> >> >>> >> -- >> >> >> >>> >> Jon Smirl >> >> >> >>> >> jons...@gmail.com >> >> >> >>> > >> >> >> >>> > -- >> >> >> >>> > You received this message because you are subscribed to the >> >> >> >>> > Google >> >> >> >>> > Groups >> >> >> >>> > "linux-sunxi" group. >> >> >> >>> > To unsubscribe from this group and stop receiving emails from >> >> >> >>> > it, >> >> >> >>> > send >> >> >> >>> > an >> >> >> >>> > email to linux-sunxi...@googlegroups.com. >> >> >> >>> > For more options, visit https://groups.google.com/d/optout. >> >> >> >>> >> >> >> >>> >> >> >> >>> >> >> >> >>> -- >> >> >> >>> Jon Smirl >> >> >> >>> jons...@gmail.com >> >> >> > >> >> >> > -- >> >> >> > You received this message because you are subscribed to the Google >> >> >> > Groups >> >> >> > "linux-sunxi" group. >> >> >> > To unsubscribe from this group and stop receiving emails from it, >> >> >> > send >> >> >> > an >> >> >> > email to linux-sunxi...@googlegroups.com. >> >> >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Jon Smirl >> >> >> jons...@gmail.com >> >> > >> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups >> >> > "linux-sunxi" group. >> >> > To unsubscribe from this group and stop receiving emails from it, >> >> > send >> >> > an >> >> > email to linux-sunxi...@googlegroups.com. >> >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> >> >> -- >> >> Jon Smirl >> >> jons...@gmail.com >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "linux-sunxi" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an >> > email to linux-sunxi...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Jon Smirl >> jons...@gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: allwinner-zh/media-codec demo
t;> >>> >> >> >>> >> If you want it at the hardware level, look at chips from Sonix. >> >>> >> Here >> >>> >> is a board based on the SN9C291 for $8.50. The bare chips are about >> >>> >> $4. >> >>> >> >> >>> >> >> >>> >> >> >>> >> https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail >> >>> >> >> >>> >> Note that this PCBA is the same price as most bare image sensors >> >>> >> mounted on a flex cable. Plus I find it much easier to wire things >> >>> >> with a simple USB cable instead of an FFC. >> >>> >> >> >>> >> The Sonix chips will appear as USB UVC devices when plugged into >> >>> >> Linux >> >>> >> and they will need no special drivers. They also work on Windows. >> >>> >> >> >>> >> >> >>> >> >> >>> >> > >> >>> >> > -- >> >>> >> > Manuel Braga >> >>> >> > >> >>> >> > -- >> >>> >> > You received this message because you are subscribed to the >> >>> >> > Google >> >>> >> > Groups "linux-sunxi" group. >> >>> >> > To unsubscribe from this group and stop receiving emails from it, >> >>> >> > send >> >>> >> > an email to linux-sunxi...@googlegroups.com. >> >>> >> > For more options, visit https://groups.google.com/d/optout. >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> Jon Smirl >> >>> >> jons...@gmail.com >> >>> > >> >>> > -- >> >>> > You received this message because you are subscribed to the Google >> >>> > Groups >> >>> > "linux-sunxi" group. >> >>> > To unsubscribe from this group and stop receiving emails from it, >> >>> > send >> >>> > an >> >>> > email to linux-sunxi...@googlegroups.com. >> >>> > For more options, visit https://groups.google.com/d/optout. >> >>> >> >>> >> >>> >> >>> -- >> >>> Jon Smirl >> >>> jons...@gmail.com >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "linux-sunxi" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an >> > email to linux-sunxi...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Jon Smirl >> jons...@gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] GSoC 2014 #1 status report - Improving Allwinner SoC support
So a long later I think I might have stumbled onto the explanation for
this in the Freescale ASOC driver (fsl_dma.c).
/**
* fsl_dma_hw_params: continue initializing the DMA links
*
* This function obtains hardware parameters about the opened stream and
* programs the DMA controller accordingly.
*
* One drawback of big-endian is that when copying integers of different
* sizes to a fixed-sized register, the address to which the integer must be
* copied is dependent on the size of the integer.
*
* For example, if P is the address of a 32-bit register, and X is a 32-bit
* integer, then X should be copied to address P. However, if X is a 16-bit
* integer, then it should be copied to P+2. If X is an 8-bit register,
* then it should be copied to P+3.
*
* So for playback of 8-bit samples, the DMA controller must transfer single
* bytes from the DMA buffer to the last byte of the STX0 register, i.e.
* offset by 3 bytes. For 16-bit samples, the offset is two bytes.
*
* For 24-bit samples, the offset is 1 byte. However, the DMA controller
* does not support 3-byte copies (the DAHTS register supports only 1, 2, 4,
* and 8 bytes at a time). So we do not support packed 24-bit samples.
* 24-bit data must be padded to 32 bits.
*/
/* Due to a quirk of the SSI's STX register, the target address
* for the DMA operations depends on the sample size. So we calculate
* that offset here. While we're at it, also tell the DMA controller
* how much data to transfer per sample.
*/
switch (sample_bits) {
case 8:
mr |= CCSR_DMA_MR_DAHTS_1 | CCSR_DMA_MR_SAHTS_1;
ssi_sxx_phys += 3;
break;
case 16:
mr |= CCSR_DMA_MR_DAHTS_2 | CCSR_DMA_MR_SAHTS_2;
ssi_sxx_phys += 2;
break;
case 32:
mr |= CCSR_DMA_MR_DAHTS_4 | CCSR_DMA_MR_SAHTS_4;
break;
default:
/* We should never get here */
dev_err(dev, "unsupported sample size %u\n", sample_bits);
return -EINVAL;
}
On Wed, Jul 23, 2014 at 1:19 AM, Chen-Yu Tsai <w...@csie.org> wrote:
> On Wed, Jul 23, 2014 at 1:15 PM, Chris Moore <mo...@free.fr> wrote:
>> Le 22/07/2014 12:22, Chen-Yu Tsai a écrit :
>>
>>> So the user manual says that 24 bit samples should be right justified,
>>> or in the most significant bytes.
>>
>> I understand "right justified" to mean "in the *least* significant bits".
>
> Ah yes. Pardon me. Sticking to "most significant bits" is better. :)
>
>
> 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.
--
Jon Smirl
jonsm...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: allwinner-zh/media-codec demo
The 291 chip is 720P30, the 292 chip is 1080P30. They do decent h.264 compression. Some chips are better, a lot are worse. Both chips are fine for web cam use. There is desktop app called cheese that will take snaphots. You can look at the source to see how it works. Note that these chips operate in a lot of different modes. streaming h.264 streaming mpeg JPEG stills uncompressed streaming uncompressed stills And all of this works without writing any more drivers. While you wait three weeks for things to come from China I have seen the Logitech HD Pro Webcam C920 recently on sale for $50. It is very similar. On Fri, Mar 11, 2016 at 6:08 PM, @lex <alex.mob...@gmail.com> wrote: > Err... That was new to me. Without researching how do you grab video from > this generic driver how good this camera performs? > > On Friday, March 11, 2016 at 7:52:17 PM UTC-3, Jon Smirl wrote: >> >> On Fri, Mar 11, 2016 at 4:42 PM, @lex <alex@gmail.com> wrote: >> > Seems to be a nice camera, but that depends on your kernel version. >> > There is no support for SN9C291 OV9712 on kernel v3.4.39. >> > And no support on odroid-3.8.30 on my U3 also. >> > Don't know about armbian legacy kernel version, but i don't expect there >> > will be support also. >> >> The camera does not need a specific driver, it uses the generic USB >> Video driver. >> It is like a USB mouse or keyboard, you don't need a specific driver >> for every different one. >> >> Drivers/Multimedia/Media USB/USB Video Class (UVC) >> >> Kconfig USB_VIDEO_CLASS >> >> This support dates way back to around 2.4 or so. Almost every desktop >> web cam works using this driver. >> >> > >> > On Friday, March 11, 2016 at 4:41:59 PM UTC-3, Jon Smirl wrote: >> >> >> >> On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga <mul@gmail.com> >> >> wrote: >> >> > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva >> >> > <rosi...@gmail.com> wrote: >> >> >> >> >> >> I did not mention, but I founf two issues withe blobs: >> >> >> >> >> >> a) Motion Detection causes segmentation fault, whenever enabled. >> >> >> b) FFMPEG complains that timestamp ( PTS/DTS ) are missing on the >> >> >> H264 stream generated by the encoder... I've tried many things ( >> >> >> code >> >> >> is commented out ), but nothing worked. >> >> > >> >> > There is another issue, that i believe to be important. >> >> > But for whatever reasons, it has to be constantly remembered about >> >> > its >> >> > existence. >> >> > >> >> > And that issue is: >> >> > >> >> > c) The proprietaries binary blobs don't have a clear license >> >> > attached. >> >> > >> >> > And in the copyright law, any "things" with "no license" by default >> >> > fell >> >> > in the "all rights reserved". >> >> >> >> I gave up fighting with Allwinner's encoder long ago. It is far easier >> >> to just plug in a USB based h.264 camera. You can easily buy ones from >> >> Logitech for $50. >> >> >> >> If you want it at the hardware level, look at chips from Sonix. Here >> >> is a board based on the SN9C291 for $8.50. The bare chips are about >> >> $4. >> >> >> >> >> >> https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail >> >> >> >> Note that this PCBA is the same price as most bare image sensors >> >> mounted on a flex cable. Plus I find it much easier to wire things >> >> with a simple USB cable instead of an FFC. >> >> >> >> The Sonix chips will appear as USB UVC devices when plugged into Linux >> >> and they will need no special drivers. They also work on Windows. >> >> >> >> >> >> >> >> > >> >> > -- >> >> > Manuel Braga >> >> > >> >> > -- >> >> > You received this message because you are subscribed to the Google >> >> > Groups "linux-sunxi" group. >> >> > To unsubscribe from this group and stop receiving emails from it, >> >> > send >> >> > an email to linux-sunxi...@googlegroups.com. >> >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> >> >> >> -- >> >> Jon Smirl >> >> jons...@gmail.com >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "linux-sunxi" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an >> > email to linux-sunxi...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Jon Smirl >> jons...@gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: allwinner-zh/media-codec demo
gt;>> >> >>> >> >>> >> >>> >> > >>> >> > -- >>> >> > Manuel Braga >>> >> > >>> >> > -- >>> >> > You received this message because you are subscribed to the Google >>> >> > Groups "linux-sunxi" group. >>> >> > To unsubscribe from this group and stop receiving emails from it, >>> >> > send >>> >> > an email to linux-sunxi...@googlegroups.com. >>> >> > For more options, visit https://groups.google.com/d/optout. >>> >> >>> >> >>> >> >>> >> -- >>> >> Jon Smirl >>> >> jons...@gmail.com >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups >>> > "linux-sunxi" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> > an >>> > email to linux-sunxi...@googlegroups.com. >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> Jon Smirl >>> jons...@gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: allwinner-zh/media-codec demo
On Fri, Mar 11, 2016 at 4:42 PM, @lex <alex.mob...@gmail.com> wrote: > Seems to be a nice camera, but that depends on your kernel version. > There is no support for SN9C291 OV9712 on kernel v3.4.39. > And no support on odroid-3.8.30 on my U3 also. > Don't know about armbian legacy kernel version, but i don't expect there > will be support also. The camera does not need a specific driver, it uses the generic USB Video driver. It is like a USB mouse or keyboard, you don't need a specific driver for every different one. Drivers/Multimedia/Media USB/USB Video Class (UVC) Kconfig USB_VIDEO_CLASS This support dates way back to around 2.4 or so. Almost every desktop web cam works using this driver. > > On Friday, March 11, 2016 at 4:41:59 PM UTC-3, Jon Smirl wrote: >> >> On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga <mul@gmail.com> wrote: >> > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva >> > <rosi...@gmail.com> wrote: >> >> >> >> I did not mention, but I founf two issues withe blobs: >> >> >> >> a) Motion Detection causes segmentation fault, whenever enabled. >> >> b) FFMPEG complains that timestamp ( PTS/DTS ) are missing on the >> >> H264 stream generated by the encoder... I've tried many things ( code >> >> is commented out ), but nothing worked. >> > >> > There is another issue, that i believe to be important. >> > But for whatever reasons, it has to be constantly remembered about its >> > existence. >> > >> > And that issue is: >> > >> > c) The proprietaries binary blobs don't have a clear license attached. >> > >> > And in the copyright law, any "things" with "no license" by default fell >> > in the "all rights reserved". >> >> I gave up fighting with Allwinner's encoder long ago. It is far easier >> to just plug in a USB based h.264 camera. You can easily buy ones from >> Logitech for $50. >> >> If you want it at the hardware level, look at chips from Sonix. Here >> is a board based on the SN9C291 for $8.50. The bare chips are about >> $4. >> >> https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail >> >> Note that this PCBA is the same price as most bare image sensors >> mounted on a flex cable. Plus I find it much easier to wire things >> with a simple USB cable instead of an FFC. >> >> The Sonix chips will appear as USB UVC devices when plugged into Linux >> and they will need no special drivers. They also work on Windows. >> >> >> >> > >> > -- >> > Manuel Braga >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "linux-sunxi" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an email to linux-sunxi...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Jon Smirl >> jons...@gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: allwinner-zh/media-codec demo
On Fri, Mar 11, 2016 at 2:18 PM, Manuel Braga <mul.br...@gmail.com> wrote: > On Fri, 11 Mar 2016 05:53:36 -0800 (PST) Rosimildo DaSilva > <rosimi...@gmail.com> wrote: >> >> I did not mention, but I founf two issues withe blobs: >> >> a) Motion Detection causes segmentation fault, whenever enabled. >> b) FFMPEG complains that timestamp ( PTS/DTS ) are missing on the >> H264 stream generated by the encoder... I've tried many things ( code >> is commented out ), but nothing worked. > > There is another issue, that i believe to be important. > But for whatever reasons, it has to be constantly remembered about its > existence. > > And that issue is: > > c) The proprietaries binary blobs don't have a clear license attached. > > And in the copyright law, any "things" with "no license" by default fell > in the "all rights reserved". I gave up fighting with Allwinner's encoder long ago. It is far easier to just plug in a USB based h.264 camera. You can easily buy ones from Logitech for $50. If you want it at the hardware level, look at chips from Sonix. Here is a board based on the SN9C291 for $8.50. The bare chips are about $4. https://world.taobao.com/item/40004211822.htm?spm=a312a.7700714.0.0.zGiipg#detail Note that this PCBA is the same price as most bare image sensors mounted on a flex cable. Plus I find it much easier to wire things with a simple USB cable instead of an FFC. The Sonix chips will appear as USB UVC devices when plugged into Linux and they will need no special drivers. They also work on Windows. > > -- > Manuel Braga > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] GPIO interface for GPIOs in AXP209
Has anyone written a kernel GPIO driver for accessing the GPIOs in the AXP209? I don't see one in mainline. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Hardware question, FPC connectors.
I have some 24pin flex cable CIF cameras here. They are labeled with pin 1 and pin 24. But some of them have the metal lands on the top side of the FPC cable and some of them have the metal on the bottom side of the cable. The matching connector on the PCB is also labeled for pin 1 and pin 24. So when I plug these cables into the PCB connector, does that FPC connector make contact with metal lands on either side, or just one side? I can't get these camera to show up on I2C and I am wondering if the connector is simply not making contact when the lands are on the wrong side. There is no simple way to put a scope on it since the flex cable has a coating on it. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: OV2643 Camera on A20
On Wed, Oct 7, 2015 at 6:19 AM, <nskabr...@gmail.com> wrote: > On Sunday, 5 January 2014 11:02:07 UTC+5:30, Jon Smirl wrote: >> I have an A20 system here that has a lot of noise in the camera. Does anyone >> have experience with noise like this? Is this something that software can >> impact or is it a problem in PCB? It is OV2643 image sensor. >> >> >> >> Looks like it is using this driver. >> http://files.virt2real.ru/docs/ >> >> >> >> P1050011_1.JPG >> >> >> >> P1050013_1.JPG >> >> >> -- >> Jon Smirl >> jons...@gmail.com > > I am not able to establish SCCB communication with OV2643 (my 2MP sensor on > board). I was not able to use the existing I2C controller to communicate over > SCCB. Please note I2C needs an ACK from Slave -- in SCCB there is no ACK > concept. Also there is one don't care or NA bit in described in SCCB that is > not there in I2C. I tossed this system about a year ago since I never could get it working correctly. The Android A20 source has the semi-working OV2643 driver in it. AFAIK it has never been ported over to mainline. I am having much more success with external camera boards based on the Hi3518e and then hooking them up to the main CPU via USB. You can buy nice camera PCBA for under $10. For these chips the camera is the main line of business and they do a much better job of making it work. Plus it is way easy to attach multiple cameras. > > Hence I wrote my own APB to SCCB controller and started the HW validation. > > But I am still not getting the correct data from if I read a register over > SCCB. > > Requesting for help -- if there is any know issue etc and how they are > resolved. > if someone used the I2C to communicate over SCCB, what you did for ACK and > Don't care / NA bit. > > Please give me some information -- I am ok to use i2c or SCCB controller > whatever it works. > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Is it possible to boot the A13 chip without DDR3 RAM?
On Tue, Oct 6, 2015 at 3:09 AM, Alexis Jeandet <alexis.jean...@gmail.com> wrote: > Hi Jon, > > On Monday, October 5, 2015 at 12:19:50 AM UTC+2, Jon Smirl wrote: >> >> On Sun, Oct 4, 2015 at 6:14 PM, jons...@gmail.com <jons...@gmail.com> >> wrote: >> > On Sun, Oct 4, 2015 at 4:26 AM, Alexis Jeandet <alexis@gmail.com> >> > wrote: >> >> >> >> Hi, >> >> On Saturday, October 3, 2015 at 1:39:55 PM UTC+2, Jon Smirl wrote: >> >>> >> >>> On Sat, Oct 3, 2015 at 3:53 AM, Rock Slate <rocks...@gmail.com> wrote: >> >>> > Wow, that's a really detailed response. Thanks a lot for the >> >>> > pointers. I >> >>> > will definitely look into this and will let you know as I proceed. >> >>> >> >>> On other processors I have seen people attach SRAM to the LCD >> >>> interface. That technique may be possible on Allwinner but it will >> >>> need some investigation. >> >>> >> >> I've seen the opposite, I'm interested if you have some links, it >> >> would be >> >> a good point to link FPGA to allwinner devices. >> > >> > I believe it works by putting the LCD controller into 8080 mode, then >> > the LCD interface looks like an ISA bus. Normal SRAM has no problem >> > attaching to the ISA bus. But I don't know if the Allwinner LCD >> > controller supports 8080 mode on LCD panels. >> > >> >> The A10 says it supports 8080 mode for LCD panels. The display >> controller section is missing from the A13 manual. >> > > In my understanding, the 8080 mode with LCD just uses a data bus and a > CMD/DATA bit but no address bus. When we connect LCD to a memory controller > in 8080 mode we connect the CMD/DATA bit to an address bit in order to > automatically switch between DATA and CMD. It also allow to copy pixel > buffers directly from RAM to LCD GRAM with DMA. > > In this case I don't understand how to handle the SRAM address bus without > additional logic. I should have missed something. I am software person so we are out of my area and it has been a long time since I saw this. If I recall correctly there were latches to demultiplex the address and data. This was on an NXP microcontroller. What I don't know is if any 8080 LCD interface can do this, or if the NXP chip had extended their interface somehow to make it more flexible. This board had both SRAM and the 8080 LCD hooked to the same interface. The remote framebuffer was memory mapped into the address space, you didn't need to use the DMA controller to access it. > > Alexis. > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Is it possible to boot the A13 chip without DDR3 RAM?
le for toggling a few pins. Moreover, if your DRAM >> >> happens to be broken, guess how the U-Boot bootloader is able to print >> >> an error message about this mishap on the UART serial console? >> >> >> >> As for the L2 cache, it has a much larger size than SRAM, but it is not >> >> normally designed to be used instead of SRAM and DRAM. There might be a >> >> way to configure it like this (I did not rule out this possibility >> >> yet), >> >> but the documentation needs to be checked (ARM Architecture Reference >> >> Manual ARMv7-A and ARMv7-R edition): >> >> >> >> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index.html >> >> >> >> -- >> >> Best regards, >> >> Siarhei Siamashka >> > >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups >> > "linux-sunxi" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an >> > email to linux-sunxi...@googlegroups.com. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> -- >> Jon Smirl >> jons...@gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "linux-sunxi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to linux-sunxi+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Is it possible to boot the A13 chip without DDR3 RAM?
On Sun, Oct 4, 2015 at 6:14 PM, jonsm...@gmail.com <jonsm...@gmail.com> wrote: > On Sun, Oct 4, 2015 at 4:26 AM, Alexis Jeandet <alexis.jean...@gmail.com> > wrote: >> >> Hi, >> On Saturday, October 3, 2015 at 1:39:55 PM UTC+2, Jon Smirl wrote: >>> >>> On Sat, Oct 3, 2015 at 3:53 AM, Rock Slate <rocks...@gmail.com> wrote: >>> > Wow, that's a really detailed response. Thanks a lot for the pointers. I >>> > will definitely look into this and will let you know as I proceed. >>> >>> On other processors I have seen people attach SRAM to the LCD >>> interface. That technique may be possible on Allwinner but it will >>> need some investigation. >>> >> I've seen the opposite, I'm interested if you have some links, it would be >> a good point to link FPGA to allwinner devices. > > I believe it works by putting the LCD controller into 8080 mode, then > the LCD interface looks like an ISA bus. Normal SRAM has no problem > attaching to the ISA bus. But I don't know if the Allwinner LCD > controller supports 8080 mode on LCD panels. > The A10 says it supports 8080 mode for LCD panels. The display controller section is missing from the A13 manual. >>> >>> >>> > >>> > On Sat, Oct 3, 2015 at 1:16 PM, Siarhei Siamashka >>> > <siarhei@gmail.com> wrote: >>> >> >>> >> > On Sat, Oct 3, 2015 at 12:32 PM, Rock Slate <rocks...@gmail.com> >>> >> > wrote: >>> >> > >>> >> > > Hi, >>> >> > > >>> >> > > Thanks for the reply. Both yes and no. The A13 comes in a nice >>> >> > > friendly >>> >> > > package which is easy to solder. However the FBGA on the DDR3 is >>> >> > > really a >>> >> > > nightmare. If not placed correctly, I would have to reball the chip >>> >> > > and >>> >> > > this is a little tough to do since I am not sure if I have the >>> >> > > right >>> >> > > experience for achieving this. >>> >> > > >>> >> > > However , I have some dedicated code which is really >>> >> > > small(something >>> >> > > like >>> >> > > toggling a few pins) to control another interface which I would >>> >> > > like >>> >> > > to do >>> >> > > even if the DDR does not work(signal integrity is also a problem , >>> >> > > even if >>> >> > > ODT is present). >>> >> >>> >> The DDR3 signal integrity also depends on the DRAM controller >>> >> configuration. And this configuration is done by software on >>> >> Allwinner A13: http://linux-sunxi.org/DDR_Calibration >>> >> >>> >> > > I dont want to put in another MCU just for this purpose. >>> >> > > >>> >> > > I was wondering if its possible to run the A13 without the DDRAM >>> >> > > being >>> >> > > configured. >>> >> >>> >> I have already answered this particular question. Yes, it is possible. >>> >> Your code and data can use a small amount of the on-chip SRAM (48KiB). >>> >> Moreover, that's how the bootloaders normally work. The boot ROM does >>> >> not normally initialize the DRAM on ARM devices, because there are no >>> >> DIMM modules with a nice standardized way to retrieve all the necessary >>> >> DRAM settings (from SPD). Instead the bootloader code does all this >>> >> board-specific configuration job on ARM devices. And bootloaders are >>> >> running in SRAM memory, or at least start executing there. >>> >> >>> >> > > Although I havent read the cortex A8 manual , I am assuming >>> >> > > that UBOOT at some level should be able to achieve what I want. >>> >> >>> >> Just take a look at the SPL part of U-Boot. It gets loaded into the >>> >> SRAM, runs from there, takes care of initializing the DRAM and then >>> >> loads the main part of U-Boot into the DRAM memory. >>> >> >>> >> > > It is also an interesting topic since I dont find many papers >>> >> > > detailing >>> >> > > how to use the ARM without external RAM apart from >>> >> > > htt
Re: [linux-sunxi] Is it possible to boot the A13 chip without DDR3 RAM?
On Sat, Oct 3, 2015 at 3:53 AM, Rock Slate <rockslat...@gmail.com> wrote: > Wow, that's a really detailed response. Thanks a lot for the pointers. I > will definitely look into this and will let you know as I proceed. On other processors I have seen people attach SRAM to the LCD interface. That technique may be possible on Allwinner but it will need some investigation. > > On Sat, Oct 3, 2015 at 1:16 PM, Siarhei Siamashka > <siarhei.siamas...@gmail.com> wrote: >> >> > On Sat, Oct 3, 2015 at 12:32 PM, Rock Slate <rockslat...@gmail.com> >> > wrote: >> > >> > > Hi, >> > > >> > > Thanks for the reply. Both yes and no. The A13 comes in a nice >> > > friendly >> > > package which is easy to solder. However the FBGA on the DDR3 is >> > > really a >> > > nightmare. If not placed correctly, I would have to reball the chip >> > > and >> > > this is a little tough to do since I am not sure if I have the right >> > > experience for achieving this. >> > > >> > > However , I have some dedicated code which is really small(something >> > > like >> > > toggling a few pins) to control another interface which I would like >> > > to do >> > > even if the DDR does not work(signal integrity is also a problem , >> > > even if >> > > ODT is present). >> >> The DDR3 signal integrity also depends on the DRAM controller >> configuration. And this configuration is done by software on >> Allwinner A13: http://linux-sunxi.org/DDR_Calibration >> >> > > I dont want to put in another MCU just for this purpose. >> > > >> > > I was wondering if its possible to run the A13 without the DDRAM being >> > > configured. >> >> I have already answered this particular question. Yes, it is possible. >> Your code and data can use a small amount of the on-chip SRAM (48KiB). >> Moreover, that's how the bootloaders normally work. The boot ROM does >> not normally initialize the DRAM on ARM devices, because there are no >> DIMM modules with a nice standardized way to retrieve all the necessary >> DRAM settings (from SPD). Instead the bootloader code does all this >> board-specific configuration job on ARM devices. And bootloaders are >> running in SRAM memory, or at least start executing there. >> >> > > Although I havent read the cortex A8 manual , I am assuming >> > > that UBOOT at some level should be able to achieve what I want. >> >> Just take a look at the SPL part of U-Boot. It gets loaded into the >> SRAM, runs from there, takes care of initializing the DRAM and then >> loads the main part of U-Boot into the DRAM memory. >> >> > > It is also an interesting topic since I dont find many papers >> > > detailing >> > > how to use the ARM without external RAM apart from >> > > http://www.coreboot.org/images/6/6c/LBCar.pdf so that I can use it as >> > > a >> > > microcontroller in the initial stages of development. >> >> Is this paper really about ARM? It looks very much x86 to me. >> >> Please don't confuse the SRAM memory and CPU L1/L2 caches. You can >> already use SRAM easily. It is more than enough for storing your code, >> which is responsible for toggling a few pins. Moreover, if your DRAM >> happens to be broken, guess how the U-Boot bootloader is able to print >> an error message about this mishap on the UART serial console? >> >> As for the L2 cache, it has a much larger size than SRAM, but it is not >> normally designed to be used instead of SRAM and DRAM. There might be a >> way to configure it like this (I did not rule out this possibility yet), >> but the documentation needs to be checked (ARM Architecture Reference >> Manual ARMv7-A and ARMv7-R edition): >> http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406c/index.html >> >> -- >> Best regards, >> Siarhei Siamashka > > > -- > 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Your outrageous wiki edits.
On Wed, Jul 8, 2015 at 5:36 PM, Luc Verhaegen l...@skynet.be wrote: Hi Kevin, I just noticed your edits to our GPL violations page. It seems that you and Allwinnwer still have not fully comprehended just how you went wrong and what can be done to fix it. The most remarkable changes (which i have undone) were: a) that since you aren't really using some parts of the code (dram scaling) anymore these days, Allwinner isn't really violating the gpl all that much anymore and then the fact that it once violated the GPL can be totally brushed under the carpet. Allwinner needs to clarify if they own the code in question. If they don't own it, it should be sufficient to state that they have tried and failed to secure a source release. Since getting the source was not possible, rewriting it and releasing it under the GPL should be ok. If you really want to pursue this, then Allwinner can identify the company that won't release the original code and someone can spend the money to take them to court. It is also possible that Allwinner has simply lost the original source. Their version control practices are not very good. I'm still waiting for them to start keeping everything on public git servers. b) the fact that allwinner was not the original violator on some touchscreen drivers, the fact that it was not allwinner that produced those binaries, makes it all totally ok that allwinner shipped those binaries, which in turn makes allwinner definitely not a repeat violator of the gpl, and this bit of history should totally be brushed under the carpet as well. I don't think b) is a GPL violation by Allwinner. Since Allwinner does not possess the source code to these binaries they are unable to determine if they are a derived work or not. This is NVidia's defense in shipping binaries. NVidia claims the binaries are not derived works of the kernel (that they are developed on Windows and then ported with a wrapper layer). Reshipping a non-derived binary is not a GPL violation. That doesn't imply that we have to like this. And I also don't believe that the touchscreen driver is a non-derived work. But that is not Allwinner's problem, it is the developer of the touchscreen driver's problem. Allwinner should exercise its rights under the GPL and request source from the vendor of the touchscreen driver and see what they claim. If they refuse to deliver source maybe Allwinner might want to file a court action to compel its release. But the GPL does not require you to take action. Allwinner should also consider not doing business in the future with vendors that won't supply source. This is parallel to the Mali problem. Mali is clearly in violation of the GPL and there is nothing Allwinner can do except make a GPL request that source code be delivered. The violator is ARM, Inc. WTF? Have you not learned anything, or are you actively playing with us? How many months now have you and the rest of your company had to get up to speed on this topic? What is it that is so difficult here, or why are you trying to play these games still? Also, with changes like this, it would not be wrong for me or others to block your wiki account. Be very careful what future steps you take. In a case like this, it is also seriously not done to execute such controversial edits yourself. You ask someone from the opposite side (like me) or someone totally independent (as in, not one of your pathetic strawmen) to review the current status and validity of the content of such a controversial wiki page. It seems that you and Allwinner haven't learned anything there either. Are the things that i beat into you and allwinner really the only things that stick? 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Further Allwinner misbehaviour.
On Wed, Jun 24, 2015 at 12:57 PM, andres...@gmail.com wrote: On Monday, June 22, 2015 at 5:45:38 PM UTC+2, Jon Smirl wrote: Personally I'm more of a believer in positive reinforcement than negative. In general I would say that at the top levels Allwinner still does not totally understand the benefits of the open source world. They know the benefits of open source, they are making tons of money thanks to linux, android or gcc. Now that Allwinner went public a few weeks ago, we can see that they are running at break-even to a small loss. That's not making tons of money. The benefit to us is sub-$5 chips when many other vendors charge $25-80 for similar chips. Having said that, they did raise $100M in the IPO so they have enough money now to increase their level of Linaro membership and hire a company or consultants to get their kernel mainlined for all CPUs. Andrés -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [OFFTOPIC] Why use USB over SDIO
On Tue, Jun 23, 2015 at 12:32 PM, Stefan Monnier monn...@iro.umontreal.ca wrote: While comparing the OrangePi Mini and the Banana Pro, I noticed that the Banana Pro connects its wifi chip via SDIO whereas the OrangePi Mini uses a USB connection. My naive understanding is that the BananaPro choice is better since the A20 already provides the SDIO connection, whereas the OrangePi Mini ends up needing a USB hub (an FE1.1s chip, apparently) where only 2 of the 4 outputs is used. Newer wifi is too fast for USB 2.0. For example 5Ghz or 11ac. Several vendors offer modules with the same footprint from 2.4Ghz 11g all the way up to 11ac + BT + GPS + NFC... Those modules use SDIO. If you only care about 2.4Ghz wifi the USB based modules are usually cheaper. Also, http://www.orangepi.org/orangepimini/index.html states: USB | 2 USB 2.0 host, 1 USB 2.0 OTG (all direct from A20 chip) but if I understand the schematics, that's not true since one of the two USB host ports of the A20 gets fed to the FE1.1s hub. Am I missing something? One more thing: I couldn't find schematics for the BananaPro. Did I just not look at the right place, or does LeMaker really fail to distribute that info (which would suck)? Stefan -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [OFFTOPIC] Why use USB over SDIO
On Tue, Jun 23, 2015 at 3:42 PM, Stefan Monnier monn...@iro.umontreal.ca wrote: Newer wifi is too fast for USB 2.0. For example 5Ghz or 11ac. Hard to believe. I never managed to go any further than 5MB/s over wifi (in real-life usage), so in my world 30MB/s is still a long way ahead. Top end 11AC will do 175MB/s = 1.4Gb/s But in any case, this argues in favor of SDIO, which again makes me wonder why the OrangePi guys went with USB. If you only care about 2.4Ghz wifi the USB based modules are usually cheaper. But cheaper enough to pay for the extra USB hub? That hub chip is about $0.30. Stefan -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [OFFTOPIC] Why use USB over SDIO
On Tue, Jun 23, 2015 at 5:11 PM, Stefan Monnier monn...@iro.umontreal.ca wrote: Top end 11AC will do 175MB/s = 1.4Gb/s Right, but has anyone actually seen anywhere near that bandwidth in real life? E.g. I haven't even been able to get past 3MB/s with 11n at home. 3MB/s is about the limit of 2.4Ghz 11n. The 11ac is dual band (2.4/5Ghz) and multiple streams. My laptop gets about 60MB/s to my home routers over dual channel 11ac. I have one router that can do 1.4Gb.s but I don't have any clients that will do that. Instead I can use two clients at about 700Mb/s with it. This said, the SDIO info I found seem to say that it only reaches 200Mb/s. But cheaper enough to pay for the extra USB hub? That hub chip is about $0.30. So is a USB wifi chip really more then $0.30 cheaper than an SDIO wifi chip? Prices for this stuff is all over the map. 700Mb/s 11ac modules are over $10. Cheapest 2.4Ghz 11n I have seen is $0.80. Stefan -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [OFFTOPIC] Why use USB over SDIO
BTW, the real problem with 2.4Ghz is that it can be terribly over crowded in urban areas. There is one place downtown where I can see 120 routers. There are also only three real channels at 2.4Ghz 1, 7, 11. The rest is marketing BS. When you set 11n to wide mode it uses two of the three channels. Add all of this up and it is easy to end up with 1Mb/s throughput from 2.4Ghz wifi. 5Ghz is hardly used and it has 50 available channels. You will rarely encounter any crowding. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Further Allwinner misbehaviour.
On Mon, Jun 22, 2015 at 11:54 AM, Rodrigo Pereira rodrigo2kpere...@gmail.com wrote: I don't understand any advantages of put a device driver code in secret. Someone can explain the advantage of a secret device driver? Maybe is about money. They want to license the code to some company and charge money for that. In case I want to buy the source code, how much this will cost? There are many reasons for keeping device drivers code secret... 1) You believe you have an innovative hardware implementation and are protecting it via trade secret. Releasing the driver source code will provide register definitions and an understanding of how the hardware works. Competitors will see this and copy your hardware. 2) Your hardware implementation is violating patents or you are afraid that people will sue you for patent infringement even when you aren't. Closed source makes it much hard for trolls to launch a patent suit. 3) You have licensed third party code for use in your device driver and you don't have the ability to open source. The third party that wrote this code wants to sell it multiple times so they refuse to open source. Common example -- lighting or physic engines in GPU drivers. 4) You are afraid competitors with similar hardware will take the source you have worked hard to write, modify a few lines, and have a free driver for their hardware. 5) Your hardware is really messed up and almost broken. These warts are embarrassing and you hide the work arounds in closed source. 6) You licensed the IP for the hardware. As part of the IP licensing agreement you are required to keep the register definitions closed. 7) Your secret driver code is violating someone's copyright. and so on. Em segunda-feira, 22 de junho de 2015 09:19:54 UTC-3, Luc Verhaegen escreveu: Hi, It's been a month since Allwinners big open source release, where they tried to shut up the big (and very justified) GPL violations noise by releasing some code which moves decoder codecs into modules, and by releasing some codecs as open source as well. As i predicted then, Allwinner now has taken the next step: They produced a binary for the decoder, which is loaded in: https://github.com/allwinner-zh/media-codec/blob/72f2b8537/sunxi-cedarx/SOURCE/vencoder/venc_device.c Note the Proprietary license notice on top of this and other new files. Even if we ignore the past, all of this is built together with LGPLed code, and the binary is being dlopened into this LGPLed code. Quite illegally so. This is further deliberate avoidance of responsibility by Allwinner. One can only assume that Allwinner is incorrigible at this point. They have been told time and time again what is wrong and they have time and time again been given possible ways out, in great detail. All we get though, is microsteps to take off the heat, followed by further deliberate breaking/bending of the rules. This also sheds a further shadow on the C.H.I.P. project. Clearly the Next Thing Co. guys were very gullible when they went into business with Allwinner (and believed the statements made by allwinner). Later during the run of the kickstarter campaign, after all the noise had been made on the internet about GPL Violations, Next Thing Co. loudly claimed that they are working the Free Electrons and that all promises of open sourceness and such would be kept (all?). While this move in itself was very laudable, it did underline the fact that Next Thing Co. had not done its homework beforehand. Now Allwinner does this, which clearly goes in against everything the Next Thing Co. people have promised us so far... Allwinner has some explaining to do (as does Next Thing Co, to a lesser extent). 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Further Allwinner misbehaviour.
that they are working the Free Electrons and that all promises of open sourceness and such would be kept (all?). While this move in itself was very laudable, it did underline the fact that Next Thing Co. had not done its homework beforehand. Now Allwinner does this, which clearly goes in against everything the Next Thing Co. people have promised us so far... Apparently, this e-mail is meant for those like Phoronix, so that they can rehash without checking and quickly repost. If that's what it takes to get action, then that is what must happen. Phoronix might be one of the worst cases of copy-paste journalism in existence, but it's still one of the better summaries of what's going on in the open source community and, most importantly, people read it. Personally I'm more of a believer in positive reinforcement than negative. In general I would say that at the top levels Allwinner still does not totally understand the benefits of the open source world. They still think that it is more important to keep 'secrets' from competitors than it is to maximize the number of people shipping and using their products. That may have been true in the 1990's but it isn't true now. These competitors obviously know how to make h.264 hardware since they are shipping it too. So my prescription for Allwinner is to take over your own kernel mainlining effort or at least pay someone to do it for you. One way to get help with that is to move to a higher level Linaro membership or hire someone like Free Electrons. The goal you are working towards is the ability to do a single Android release and have it work on all of your CPUs. If you are able to achieve that you will get some huge benefits in reduced effort needed to keep your Android releases up to date. Alternatively, if you continue to do in-house point releases of Android while proliferating a large number of new CPUs, you are going to collapse under the combinatoric workload. Once you realize these benefits, hopefully you'll see the benefits of being open source is all areas. Is there really need for such drama? The A13 has been largely mainlined by members of this community and the R8, being a bit different, needs some extra work. Instead of making it a volunteer effort to linux-sunxi, they are working with Free Electrons in order to fix any issues pertaining to mainline support. There is need for this drama: (L)GPL violations aren't something you can just sweep under the rug. This is a _legal_ issue. This isn't just people moaning about how they don't have all the fancy stuff, this is a company breaking a license they agreed to. Companies have been shut down for less. The person or group that does the mainlining is irrelevant as long as it happens. As for why C.H.I.P. is being dragged into this: quoting from their campaign, they're Fully open source or 100% open source and are going to work with Allwinner to insure that all the necessary documentation and source code for the System on Chip and Power Management Chips used in C.H.I.P. will be available for the community to use and learn from. It could be argued both ways whether the CedarX IP is necessary, but they've talked up their open source-ness so much that any part remaining closed source (with the possible exception of Mali) will be a mark against them and their ability to deliver. The Raspberry Pi copped a _lot_ of flak over the huge chunks of proprietary stuff in it, so I suspect they won't want the same negative press. Also, they're still news, so some copy-paste journalist might just stumble across this from a Google search and post it. At the end of the day, posts like this are about making Allwinner move. We, the community, aren't big enough to push them with any useful force; you (and other people) claim to have some connection to them, but seem to have done nothing, so we have to find other ways to push them. If that means we need to write stuff that can be copied and pasted into a sensationalist Phoronix article, then that's what we must do. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: [linux-sunxi] Discussion about mainlining the A83T
On Mon, Jun 15, 2015 at 4:06 AM, ke...@allwinnertech.com ke...@allwinnertech.com wrote: Hi, ChenYu, Kevin, Shuge, do you know if the 2 chips are actually the same? 請問 A83T 和 H8 是一樣的晶片嗎? 提供給我們的板子上是印 H8， 但告知我們是 A83T 的原型機，讓人不是很有把握。 Yes, I have checked with my hardware colleague. Some chips of H8 is same as A83T, and others are not. The chips on the develop boards are same as the A83T, just different mark. What is the difference between the A83T and H8? We are looking at using the H8 in a product we have under development. I have an Orange Pi 2 on order but it hasn't shipped yet. Does the H8 have the newer h.264 encoder that can compress more? Is Android Lollipop coming for the H8? Best Regards, ke...@allwinnertech.com From: Chen-Yu Tsai Date: 2015-06-15 15:56 To: Simos Xenitellis; Meng Zhang; shuge CC: linux-sunxi Subject: Re: [linux-sunxi] Discussion about mainlining the A83T On Sat, Jun 13, 2015 at 5:05 PM, 'Simos Xenitellis' via linux-sunxi linux-sunxi@googlegroups.com wrote: Hi All! Recently, several people received developer boards with the A83T SoC. I have collected information from a few sources and put them on https://linux-sunxi.org/User:Simos/H8HomletProtoV20_A83T The page includes a comparison of modules of the A83T with other A-line SoCs. There are high-resolution images of the board. In addition, the page has boot messages and also output of commands from the pre-installed BR Linux (kernel version: 3.4). Some facts about the board: Boot0 is V4.0.0. DRAM is 1GB DDR3 @ 672 MHz. eMMC is 8GB (7.32 GiB). AXP818 is a PMIC audio codec combo. AC200 is a audio codec (unused here), TV encoder, ethernet PHY and RTC 4-in-1 chip. USB0 (OTG) and USB1 (EHCI/OHCI) are routed directly to the 2 USB ports. That means no actual OTG, only host mode. The board (and schematics) say this is an H8. However I won't be removing the heatsink to verify. I don't recommend it either. It is quite warm just idling. That said, the A83T has the same packing as the H8 (BGA 345), though I have not compared the actual pin signals. Kevin, Shuge, do you know if the 2 chips are actually the same? 請問 A83T 和 H8 是一樣的晶片嗎? 提供給我們的板子上是印 H8， 但告知我們是 A83T 的原型機，讓人不是很有把握。 The board runs a customized Android system. Not sure if FEL mode or Android fastboot would work on this board. If not, it's going to be hard to mainline without U-boot support. UART0 is the 5 pin-out next to the WiFi module and AXP818. It shares the same pinout as the micro-SD breakout, or the A80 Optimus. Note that the onboard OS muxes UART0 onto mmc0 instead. :| ChenYu I'ld like to start a thread about the planning of the mainlining of the A83T. If there are any other topics not directly related to this thread, please start a new thread. NOTICE: This e-mail and any included attachments are intended only for the sole use of named and intended recipient (s) only. If you are the named and intended recipient, please note that the information contained in this email and its embedded files are confidential and privileged. If you are neither the intended nor named recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. Please reply to the sender and destroy the original message and all your records of this message (whether electronic or otherwise). Furthermore, you should not disclose to any other person, use, copy or disseminate the contents of this e-mail and/or the documents accompanying it. -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: 2015 SBC survey by Linux Foundation/LinuxGizmos
://forum.odroid.com/viewtopic.php?f=111t=8288 but the person working at the forum is there to answer honestly with Because the C1 Kernel had been heavily customized too much by SoC vendor, it is not easy to port the mainline kernel. If you really want to run the mainline Kernel, do NOT buy our C1 board. Sorry about that. With such an honest answer, I would go buy an ODROID-C1. What have been missing from the Allwinner dev boards is good community/support from CubieTech, SinoVoip/LeMaker (their split was really unfortunate, they do terrible promotion on social networks, etc). The person behind Orange Pi looks very active, however there is again the language barrier and the need to better present their products internationally. Allwinner's stock market cap is $2.6B USD now. They just raised over $100M USD from their IPO. Please take some of that cash and hire a company like Free Electrons to get kernel support mainlined for all of your chips. What we don't need is another thirty CPUs with barely functioning software. Concentrate instead on getting excellent support for your top selling chips. Mainline kernel support is the foundation that everything else is built on. I'd also spend some money of making a unified SDK. Instead of having a port and forget SDK for each chip make a single one that supports all of the chips. I suspect you'll find that is easier to support in the long run. I do not have experience with Olimex and what can be improved. People would think that that is the most relevant statement in that whole survey, but not a hint of it can be seen in your email. Stop trying to distort the truth. Similarly, i cannot find any mention of your point 7 in that article. That's my addition and a comment to the GPU stats for the Top 10. The SoC market is quite competitive, and to make it, you need to do things better than the competitors. You would need to put priorities but still, the lack of a fully free GPU driver is not so critical. However, if some SoCs have such a free GPU driver, then the rest need to follow or put much more effort in the other aspects. Simos But thanks for reminding me that that would not have happened if it was not for the fact that i did lima, and that i corrected the Raspberry Pi Foundations big but ultimately statement late 2012. 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. -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: [linux-sunxi] How to adjust bitrate of allwinner's encoder dynamically
I'm still interested in the V3 and the V3S. How much DRAM in the V3S? Is there a datasheet yet? Since me the Chinese one and I will have someone translate. I have a Grain Media dev kit on my desk for the GM8138S and we've built two rounds of prototype PCBs. Our main complaint with the GM8138S has been one SDIO port. But Grain fixed this with the GM8136S which has two SDIO ports. GM8138S does pretty nice 720P h.264 at 500Kb/s which we need. 1080P also works at 500Kb/s but it is not so nice. GM8136S is 720P only, we may drop 1080P since we don't have the bandwidth for it. Our GM8136S dev kit is not here yet. We need two SDIO -- one for SD card, one for SDIO 5Ghz wifi. Right now we have the Ampak AP6330 designed in. But it is 1.8V and Grain is 3.3V so we use level shifters. But AP6330 is cheap since it is old 5Ghz 11N, not 11AC which is 2x the price. We need 5Ghz, 2.4Ghz is too congested in some areas, but we don't need 11ac speed/cost. Any better ideas on how to get 2.4/5Ghz wi-fi plus BLE for under $5? We also require I2S to allow an external codec with built-in amp. We use a 30W PWM digital amp chip. Another Grain complaint - they are on Linux 3.3. That is over two years old. I have been unsuccessful trying to push them onto a more recent kernel. They are made a major mistake in picking 3.3 since it is not a Long-term support kernel. So no security patches for it. We looked at HiSilicon. But they don't have a chip combination with built-in DRAM and the right peripherals we need. On Thu, May 7, 2015 at 7:03 AM, kevin.z.m...@gmail.com kevin.z.m...@gmail.com wrote: On 2015-05-05 at 21:21, jonsm...@gmail.com jonsm...@gmail.com wrote: On Tue, May 5, 2015 at 12:00 AM, kevin.z.m...@gmail.com kevin.z.m...@gmail.com wrote: On 2015-04-29 at 21:20, jonsm...@gmail.com jonsm...@gmail.com wrote: On Tue, Apr 28, 2015 at 10:37 PM, kevin.z.m...@gmail.com kevin.z.m...@gmail.com wrote: Hi, The encoder allows you to set the MaxQp(0~51), MinQp(0~51), and MaxBitrate parameters. MaxQp and MinQp are used to controlpicture quality and MaxBitrate is used to clamp the maximum encoding bit rate within the bitrate statistical time; The default configuration is MinQp = 10; MaxQp = 40. If you could not get it to work for lower bitrates , please try to change MaxQp to a bigger value, The bitrate setting on an h.264 encoder is supposed to take precedence and be a hard limit. So if I set 500Kb/sec the encoder has to adjust everything else until it can hit and hold that limit. Min/MaxQp should not overrule the Bitrate limit. I believe the only exception to that is for VBR where you are allowed to exceed the bandwidth limit by 10% for short periods of time. The encoder is also supposed to be smart on how it adjusts itself when the bandwidth limit is set. These limits are there for streaming video. I needed to set a 500Kb/s hard limit because I only had 500Kb/s of streaming capacity available. I couldn't figure out how to keep the Allwinner encoder at a 500Kb/s limit, it would stay at 500Kb/s for a while but then if there was rapid motion it would jump to 2Mb/s. It should not matter if CBR or VBR is set, the limit should still be enforced. Of course when it jumped to 2Mb/s on my 500Kb/s pipe, the stream dropped. Nowadays, the limits of streaming video can't be controlled accurately with every frame, but an average in a period. On the A20 platform, it can't reach 500kb/s with 720p@30fps, the lowest value should be 1.5Mb/s. That was an important bit of information that should have been in the datasheet. It would have saved me a huge amount of time messing with the A20 if I had known 500Kb was never going to be possible. Check out the the software x86 h.264 implementations - they will output exactly 500Kb/s when told to. You can watch the picture become very clear when the scene is still and then go grainy when there is rapid motion. Also - I had severe problems with noise on A20 cameras. That noise is random from frame to frame. Encoding that noise wastes all of my 500Kb/s bandwidth which makes the image quality terrible. Typical some type of ISP is used to remove this noise before h.264 encoding. There may be 3 main factors causing noise, they are lens, Sensor and ISP. A20 has none local ISP, selecting an external ISP may reduce the noise. Besides ISP, the lens and Sensor is important too, and the NT99141 is recommended. Does the Allwinner V3 support external I2S? I'd just look in the datasheet, but it is too much hassle to get it. Yes, V3 can support external IIS. We will make the documents for v3 ready as soon as possible. Can the V3 hit 500Kb/s for h.264? For static scenes with little noise, V3 and A83T can reach 500kbps for 720p@30pfs or 1080p@15fps. Currently we are using the Grain Media GM8138S. It is very nice with the 128MB of DRAM in the same package. We also looked at the Highsilicon Hi3518e but it gets way too hot. We use GM8138S with 2-channel I2S. What we really need is: 1) 8
Re: [linux-sunxi] [PATCH] ARM: dts: sun8i: Add dts file for the GA10H-A33 tablet
;
+ linux,code = KEY_VOLUMEDOWN;
+ channel = 0;
+ voltage = 40;
+ };
+};
+
+mmc0 {
+ pinctrl-names = default;
+ pinctrl-0 = mmc0_pins_a, mmc0_cd_pin_q8h;
+ vmmc-supply = reg_vcc3v0;
+ bus-width = 4;
+ cd-gpios = pio 1 4 GPIO_ACTIVE_HIGH; /* PB4 */
+ cd-inverted;
+ status = okay;
+};
+
+pio {
+ mmc0_cd_pin_q8h: mmc0_cd_pin@0 {
+ allwinner,pins = PB4;
+ allwinner,function = gpio_in;
+ allwinner,drive = SUN4I_PINCTRL_10_MA;
+ allwinner,pull = SUN4I_PINCTRL_PULL_UP;
+ };
+};
+
+r_uart {
+ pinctrl-names = default;
+ pinctrl-0 = r_uart_pins_a;
+ status = okay;
+};
--
2.3.6
--
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.
--
Jon Smirl
jonsm...@gmail.com
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [PATCH] ARM: dts: sun8i: Add dts file for the GA10H-A33 tablet
On Tue, Jun 2, 2015 at 8:35 PM, Julian Calaby julian.cal...@gmail.com wrote: Hi Jon, On Wed, Jun 3, 2015 at 6:20 AM, jonsm...@gmail.com jonsm...@gmail.com wrote: Resend with plain text for image links I have one of these GA10H-A33 and tore it apart. They used an uncommon wifi/BT chip - RDA5990P. Took mine apart since the wifi didn't work worth two cents. http://www.rdaic.com/sites/default/files/public/RDA5990P_datasheet_V1.4.pdf Is that unpopulated pad next to the RSA5990P an option to use an Ampak module? I am looking for a A33 PCBA where I can mount a 5Ghz wi-fi module. Potential driver: https://github.com/linuxium/3188-SRC-ORIG/tree/master/kernel/drivers/net/wireless/rda5990 (Code implies GPL but is missing copyright / license notices, might be for an older part.) On an unrelated note, is MediaTek buying up every last small manufacturer of WiFi parts? RDA was bought by Spreadtrum Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Lemon Pi on Indiegogo campaign,$35 ARM Quad-core A9 and Imagination PowerVR SGX544 open source board
On Tue, May 26, 2015 at 7:28 PM, Julian Calaby julian.cal...@gmail.com wrote: Hi, Stupid question: isn't this kinda off-topic for this list as the SoC on the LemonPi isn't an Allwinner part? Are there lists for these other Chinese vendors? I haven't found one for Rockchip or AMLogic. Thanks, Julian Calaby On Wed, May 27, 2015 at 7:59 AM, Embed Studio embedstudioi...@gmail.com wrote: The Lemon Pi is a very low-cost open source single-board computer (SBC) equipped with a powerful ARM quad-core Cortex A9 microprocessor integrated with an Imagination PowerVR SGX544 GPU.There are a lot of the same characteristics between Lemon Pi and Raspberry Pi 2，such as the price,the size and the compatible 40 pin interface and so on.But the Lemon Pi has more powerful computing and Imagination GPU hardware acceleration capacity,more IO interface expansion etc.More importantly, Lemon Pi supports many specifictions that Raspberry Pi 2 does not support, such as USB3.0 host, OpenCL that Imagination PowerVR SGX544 supports, android 5.0. S500, which is one of Actions Semi open cource chipset series called ActDuino, is adopted on the Lemon Pi. The specification is as following. Operating systemUbuntu 12.04 + OpenGL ES/OpenCL/GPU acceleration on Kernel 3.10 LTS Android 5.0 on Kernel 3.10 LTS Full source code is accessible via our GithubSoCS500CPUQuad-core Cortex-A9 @28nmGPUImagination PowerVR SGX544 (OpenGL ES2.0/1.1, OpenVG 1.0.1, OpenCL)RAM1GBScreen interfaceMIPI DSIInternal storage interfaceSupport eMMC 4.5 up to 64GBExternal storage interfaceMicro SD/TF card extensible (card socket)Video captureFHD 1080P@30fps H.264TV OutHDMI 1.4 with HDCP and CVBS(integrated in Headphone connector)Audio output/Input3.5 Headphone connector with wire controlUSBUSB2.0 x 2 + USB3.0 (support OTG) CameraMIPI CSI2buttonsOn/Off, Reset, ADFU(Actions Device Firmware Update) keyIR Receiversupport remote controlIO Expansion(40 pin)+3.3V,+5V,GND,I2C,UART,SPI,PCM,UART,I2S,GPIO x16Ethernet10/100 MbpsPMU and Audio CodecATC2603CPower DCIN5V/700mASize85mm x 56mm approxNowadays the Lemon Pi is going on Indiegogo campaign at http://igg.me/at/lemonpi ( https://www.indiegogo.com/projects/lemon-pi-35-arm-quad-core-a9-open-source-board ),you can visit it for more details. Many thanks for your time to read my letter.Don't hesitate to ask any question or give advice to us. We will keep you updated and respond to you as soon as possible. I expect to receive your reply. Thanks. -- 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. -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Lemon Pi on Indiegogo campaign,$35 ARM Quad-core A9 and Imagination PowerVR SGX544 open source board
What is the github link to the mentioned source code for the Android 5.0 port? On Tue, May 26, 2015 at 5:59 PM, Embed Studio embedstudioi...@gmail.com wrote: The Lemon Pi is a very low-cost open source single-board computer (SBC) equipped with a powerful ARM quad-core Cortex A9 microprocessor integrated with an Imagination PowerVR SGX544 GPU.There are a lot of the same characteristics between Lemon Pi and Raspberry Pi 2，such as the price,the size and the compatible 40 pin interface and so on.But the Lemon Pi has more powerful computing and Imagination GPU hardware acceleration capacity,more IO interface expansion etc.More importantly, Lemon Pi supports many specifictions that Raspberry Pi 2 does not support, such as USB3.0 host, OpenCL that Imagination PowerVR SGX544 supports, android 5.0. S500, which is one of Actions Semi open cource chipset series called ActDuino, is adopted on the Lemon Pi. The specification is as following. Operating systemUbuntu 12.04 + OpenGL ES/OpenCL/GPU acceleration on Kernel 3.10 LTS Android 5.0 on Kernel 3.10 LTS Full source code is accessible via our GithubSoCS500CPUQuad-core Cortex-A9 @28nmGPUImagination PowerVR SGX544 (OpenGL ES2.0/1.1, OpenVG 1.0.1, OpenCL)RAM1GBScreen interfaceMIPI DSIInternal storage interfaceSupport eMMC 4.5 up to 64GBExternal storage interfaceMicro SD/TF card extensible (card socket)Video captureFHD 1080P@30fps H.264TV OutHDMI 1.4 with HDCP and CVBS(integrated in Headphone connector)Audio output/Input3.5 Headphone connector with wire controlUSBUSB2.0 x 2 + USB3.0 (support OTG) CameraMIPI CSI2buttonsOn/Off, Reset, ADFU(Actions Device Firmware Update) keyIR Receiversupport remote controlIO Expansion(40 pin)+3.3V,+5V,GND,I2C,UART,SPI,PCM,UART,I2S,GPIO x16Ethernet10/100 MbpsPMU and Audio CodecATC2603CPower DCIN5V/700mASize85mm x 56mm approxNowadays the Lemon Pi is going on Indiegogo campaign at http://igg.me/at/lemonpi ( https://www.indiegogo.com/projects/lemon-pi-35-arm-quad-core-a9-open-source-board ),you can visit it for more details. Many thanks for your time to read my letter.Don't hesitate to ask any question or give advice to us. We will keep you updated and respond to you as soon as possible. I expect to receive your reply. Thanks. -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Request for detaild for GSL1680 driver for porting to Linux x86_64 kernel on baytrail 3735f platform
an email to linux-sunxi...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jons...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Request for detaild for GSL1680 driver for porting to Linux x86_64 kernel on baytrail 3735f platform
Here's the datasheet http://www.buydisplay.com/download/ic/GSL1680.pdf On Fri, May 15, 2015 at 2:32 PM, sergk.ad...@gmail.com wrote: In addition some details from Android Under Android : Linux 3.10.20-263387 i686 I have the following: cat /sys/class/i2c-adapter/i2c-4/ 4-0040/name MSSL1680:00. or the same under other path: cat /sys/bus/i2c/devices/i2c-4/4- 0040/name MSSL1680:00. Also in Windows drivers there is fw Silead. Only base on this I am sure that I have 1680 chip! Also it is resides on 0x40! on i2c channel. Lsmod under undroid shows gslx68x_ts driver that is relative to mentioned above i2c channel. Under any of the Linux kernel - I prefer x86_64 there is the same MSSL1680:00 but on the i2c-3 channel. I2cdetect detects nothing at the same moment. My guessing that probable mentioned here http://linux-sunxi.org/GSL1680 IOCNTL pin is not set to logical 1 and this is a main my problem - I do not know how to detect to which gpio pin on z3735f is connected IOCNTL thats mean that for your driver I could not provide -gpio parameter! To make MSSL1680 communicate via I2c channel I need 1st to set IOCNTL to 1, and do not know how to do this and I do not have /sys/devices/virtual/misc/sun4i-gpio/pin/pb3. At the same moment - It looks strange but under classical linux kernels I have only 3 items inside /sys/class/gpio numbers of them also differ from kernel to kernel. ubuntu 14.10 (3.16.0-29). shows ghpiochip 126, gpiochip154,gpiochip82 - have tried all of them - your driver wrotes (by memory) - that unable to open such device. under Arch 4.0.1 kernel - set of gpios are 338,382,410. actually the same story. Numbers are different but all binded to the same - INT33F:0x. At the same moment cat /sys/kernel/debug/gpio shows about 145 values in the table. Kind regards, Serge Kolotylo On Friday, May 15, 2015 at 2:04:48 PM UTC, sergk...@gmail.com wrote: Dear All, please assist me in porting GSL1680 touchscreen driver to Linux x86/86_64 kernel. As a testing device I have tablet =Chuwi vi8 super. Specs of it http://techtablets.com/chuwi-vi8/ (baytrail based intel z3735f). I have successfully run on it Linux x86 and x86_64 (Arch linux, Ubuntu, Linux mint, sysrescue cd linux distros), the main last problem is - there is NO touch screen driver for Silead GSL1680 which is used in this tablet. I have successfully porting to x86_64 userspace driver https://github.com/rastersoft/gsl1680. BUT the problem is according http://linux-sunxi.org/GSL1680 to communicate with chip controller of this touchscreen you should 1st initialize it via setting IOCNTL line to 1, this line is mapped to GPIO pin. The main problem - how to determine without any documentation, having only device with Android 4.4 and Windows 8.1 with working touch screen which gpio pin serve IOCNTL. Please help to find out gpio pin for IOCNTL touch screen on Chuwi vi8 (baytrail) platform or with porting kernel level drive to Linux vanilla kernel for x86 plaforms. PS: I tend to run user space mentioned above driver because porting from sunxi linux driver into vanilla for x86 platforms is not so easy way due a lot of differences of included platform headers files. Regards, Serge Kolotylo. -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner R8 module
On Mon, May 11, 2015 at 7:44 PM, Julian Calaby julian.cal...@gmail.com wrote: Hi, On Tue, May 12, 2015 at 2:13 AM, Marius Cirsta mfor...@gmail.com wrote: On Monday, May 11, 2015 at 5:24:01 AM UTC+3, Luc Verhaegen wrote: On Sun, May 10, 2015 at 09:49:43PM -0400, jons...@gmail.com wrote: Does anyone have any info on the new Allwinner R8 module being used in the Chip $9 PC Kickstarter? It is A13+flash+RAM on module. I'd like to get a pin out and projected price. That module has to be really low cost if they are able to make a $9 computer out of it. *sigh* I am amazed that people still fall for what i can now only call the kickstarter trap. Yeah, it's a bunch of crap, crowdfunding we're better of letting the corporations and investment funds deciding what to fund and what not. Why are we arguing about whether or not crowdfunding and this particular campaign is viable when the question was only using it to point out that the particular SoC was probably cheap? Like *mumble*% of kickstarter projects, it's probably too good to be true, but who here really cares? And if they do, why are we hijacking Jon's question to make that point? IIRC the actual question was where / when will the R8 SoC be available for other device builders? Allwinner has not officially announced anything yet, but it will be available real soon and it is pretty cheap. I don't have pin outs yet so I am not sure yet if the modules works for me. I have a specific set of peripherals I have to have. Does anyone actually have any useful info on that? Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Allwinner R8 module
On Sun, May 10, 2015 at 10:23 PM, Luc Verhaegen l...@skynet.be wrote: On Sun, May 10, 2015 at 09:49:43PM -0400, jonsm...@gmail.com wrote: Does anyone have any info on the new Allwinner R8 module being used in the Chip $9 PC Kickstarter? It is A13+flash+RAM on module. I'd like to get a pin out and projected price. That module has to be really low cost if they are able to make a $9 computer out of it. *sigh* I am amazed that people still fall for what i can now only call the kickstarter trap. * only 9usd * 1y delivery time * full mainline support * linux-sunxi is not mentioned even once I don't care about their board, I want to know the price/specs of the R8 module from Allwinner. I want to put it on my own board. None of that fits together, and i am amazed that people actually fall for that still. Luc Verhaegen. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Allwinner R8 module
Does anyone have any info on the new Allwinner R8 module being used in the Chip $9 PC Kickstarter? It is A13+flash+RAM on module. I'd like to get a pin out and projected price. That module has to be really low cost if they are able to make a $9 computer out of it. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] 6LowPan Suuport in linux-sunxi kernel
On Thu, May 7, 2015 at 8:10 AM, Puneet B punit...@gmail.com wrote: Hi ALL, I need to test IOT kind of application with A20 board, but to test i need kernel which will support 6LowPan . But only kernel 3.17 and above will support 6LowPan. So is it any branch of this kernel for A20 or is it possible to make 3.4 to support 6LowPan?. Use an 802.15.4 chip that supports 6Lowpan inside of it. Like the TI CC2530 or Freescale MC13224. Some of these chips have UART (SLIP) interfaces and other have USB Ethernet. So now the kernel only sees IPv6 via the USB Ethernet/SLIP and knows nothing about 6Lowpan. Search for 6lowpan border routers. https://github.com/cetic/6lbr/wiki Regards Punith -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: [linux-sunxi] How to adjust bitrate of allwinner's encoder dynamically
On Tue, May 5, 2015 at 12:00 AM, kevin.z.m...@gmail.com kevin.z.m...@gmail.com wrote: On 2015-04-29 at 21:20, jonsm...@gmail.com jonsm...@gmail.com wrote: On Tue, Apr 28, 2015 at 10:37 PM, kevin.z.m...@gmail.com kevin.z.m...@gmail.com wrote: Hi, The encoder allows you to set the MaxQp(0~51), MinQp(0~51), and MaxBitrate parameters. MaxQp and MinQp are used to controlpicture quality and MaxBitrate is used to clamp the maximum encoding bit rate within the bitrate statistical time; The default configuration is MinQp = 10; MaxQp = 40. If you could not get it to work for lower bitrates , please try to change MaxQp to a bigger value, The bitrate setting on an h.264 encoder is supposed to take precedence and be a hard limit. So if I set 500Kb/sec the encoder has to adjust everything else until it can hit and hold that limit. Min/MaxQp should not overrule the Bitrate limit. I believe the only exception to that is for VBR where you are allowed to exceed the bandwidth limit by 10% for short periods of time. The encoder is also supposed to be smart on how it adjusts itself when the bandwidth limit is set. These limits are there for streaming video. I needed to set a 500Kb/s hard limit because I only had 500Kb/s of streaming capacity available. I couldn't figure out how to keep the Allwinner encoder at a 500Kb/s limit, it would stay at 500Kb/s for a while but then if there was rapid motion it would jump to 2Mb/s. It should not matter if CBR or VBR is set, the limit should still be enforced. Of course when it jumped to 2Mb/s on my 500Kb/s pipe, the stream dropped. Nowadays, the limits of streaming video can't be controlled accurately with every frame, but an average in a period. On the A20 platform, it can't reach 500kb/s with 720p@30fps, the lowest value should be 1.5Mb/s. That was an important bit of information that should have been in the datasheet. It would have saved me a huge amount of time messing with the A20 if I had known 500Kb was never going to be possible. Check out the the software x86 h.264 implementations - they will output exactly 500Kb/s when told to. You can watch the picture become very clear when the scene is still and then go grainy when there is rapid motion. Also - I had severe problems with noise on A20 cameras. That noise is random from frame to frame. Encoding that noise wastes all of my 500Kb/s bandwidth which makes the image quality terrible. Typical some type of ISP is used to remove this noise before h.264 encoding. There may be 3 main factors causing noise, they are lens, Sensor and ISP. A20 has none local ISP, selecting an external ISP may reduce the noise. Besides ISP, the lens and Sensor is important too, and the NT99141 is recommended. Does the Allwinner V3 support external I2S? I'd just look in the datasheet, but it is too much hassle to get it. Yes, V3 can support external IIS. We will make the documents for v3 ready as soon as possible. Can the V3 hit 500Kb/s for h.264? Currently we are using the Grain Media GM8138S. It is very nice with the 128MB of DRAM in the same package. We also looked at the Highsilicon Hi3518e but it gets way too hot. We use GM8138S with 2-channel I2S. What we really need is: 1) 8-channel I2S 2) Camera that can do low noise, 720P or 1080P video at 500Kb/s (security video) 3) Runs Android 4) The unit is headless so no display 5) OpenCL on the GPU would be a bonus. I have not found this combination is a low cost chip that works. Best Regards, kevin.z.m -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Inside of Ampak AP6330
If you've ever wondered what was inside an Ampak AP6330. Photo of one we destroyed by accident. https://drive.google.com/file/d/0B-2Z6FDzyIwrQUpYcUZFX25KMG9EQVlFWGx4bDl4R1VadjVZ/view?usp=sharing -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: [linux-sunxi] How to adjust bitrate of allwinner's encoder dynamically
On Tue, Apr 28, 2015 at 10:37 PM, kevin.z.m...@gmail.com kevin.z.m...@gmail.com wrote: Hi, The encoder allows you to set the MaxQp(0~51), MinQp(0~51), and MaxBitrate parameters. MaxQp and MinQp are used to controlpicture quality and MaxBitrate is used to clamp the maximum encoding bit rate within the bitrate statistical time; The default configuration is MinQp = 10; MaxQp = 40. If you could not get it to work for lower bitrates , please try to change MaxQp to a bigger value, The bitrate setting on an h.264 encoder is supposed to take precedence and be a hard limit. So if I set 500Kb/sec the encoder has to adjust everything else until it can hit and hold that limit. Min/MaxQp should not overrule the Bitrate limit. I believe the only exception to that is for VBR where you are allowed to exceed the bandwidth limit by 10% for short periods of time. The encoder is also supposed to be smart on how it adjusts itself when the bandwidth limit is set. These limits are there for streaming video. I needed to set a 500Kb/s hard limit because I only had 500Kb/s of streaming capacity available. I couldn't figure out how to keep the Allwinner encoder at a 500Kb/s limit, it would stay at 500Kb/s for a while but then if there was rapid motion it would jump to 2Mb/s. It should not matter if CBR or VBR is set, the limit should still be enforced. Of course when it jumped to 2Mb/s on my 500Kb/s pipe, the stream dropped. Check out the the software x86 h.264 implementations - they will output exactly 500Kb/s when told to. You can watch the picture become very clear when the scene is still and then go grainy when there is rapid motion. Also - I had severe problems with noise on A20 cameras. That noise is random from frame to frame. Encoding that noise wastes all of my 500Kb/s bandwidth which makes the image quality terrible. Typical some type of ISP is used to remove this noise before h.264 encoding. Does the Allwinner V3 support external I2S? I'd just look in the datasheet, but it is too much hassle to get it. then maybe reduce the qulity of the picture. kevin.z.m...@gmail.com From: jonsm...@gmail.com Date: 2015-04-27 21:22 To: achun liu CC: linux-sunxi Subject: Re: [linux-sunxi] How to adjust bitrate of allwinner's encoder dynamically On Mon, Apr 27, 2015 at 2:45 AM, lyc.ac...@gmail.com wrote: hi,all, How to adjust bitrate of allwinner's encoder dynamically,I tried to change, but did not seem to effect. I could not get it to work for lower bitrates. After about 1.5Mb/s it stopped doing anything. I needed 500Kb/s for my application and was unable to get that. BR, -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] How to adjust bitrate of allwinner's encoder dynamically
On Mon, Apr 27, 2015 at 2:45 AM, lyc.ac...@gmail.com wrote: hi,all, How to adjust bitrate of allwinner's encoder dynamically,I tried to change, but did not seem to effect. I could not get it to work for lower bitrates. After about 1.5Mb/s it stopped doing anything. I needed 500Kb/s for my application and was unable to get that. BR, -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: sunxi-kms driver
You need to insert the copyright notice as a way of saying you own the code in the file. After you claim ownership you can choose a license to release your work under. The important part of kernel development is placing the GPL notice at the top of each kernel source file (copy it from another kernel file). The copyright notice is just a statement saying you have the right to license the code under the GPL. Once you license under the GPL, the GPL allows many more uses of the code than simple copyright does. Some projects require copyright assignment, but the kernel does not. The main reason for copyright assignment is in case the license needs to be changed later. For example Mozilla was originally released under the MPL. The Mozilla organization was forced to track down and get written permission from every copyright holder when they reissued Mozilla under the LGPL. Some of these authors could not be located which required chunks of Mozilla to be rewritten. Now Mozilla gets copyright right assignment from each author in order to allow them to change the license again if necessary. The kernel has long passed having any ability to track down all of the copyright holders since some of them are dead. It will be GPLv2 forever because there is no way to change it. If you want to contribute your code to mainline it has to have at the minimum: a copyright statement and the GPLv2 license. If you want you can also include the MIT license in addition to the GPLv2. Including the MIT license allows the code the be shared with BSD. On Sat, Apr 11, 2015 at 9:30 AM, Stefan Monnier monn...@iro.umontreal.ca wrote: Also copyright like this looks weird: * Copyright (C) 2015-2020 Allwinner Technology Co., Ltd. Living in the future? :) I'm granting all the copyright to my newly written code to Allwinner so no... It's 2015 and the copyright goes 5 years... Am I wrong? ^^' Yes, you're wrong: the copyright statement is about when the copyright starts, basically, so it can't be in the future. The duration of the copyright is then defined based on this information combined with the law (which is not 5 years, but more like 75 years, or maybe even 75 years after the death of the author, and has changed over the time, with the tendency being to extend copyright towards infinity, since those decisions are mostly taken by people who have personal financial incentives to extend the coverage as much as they can get away with (or are close to people who have such)). Stefan -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Regarding the sunxi-cedarx support
onto the LCD pins too. Consider this -- take existing high volume tablet boards with LCD connectors. Now reuse those boards in embedded applications without LCDs. Program the pins on the LCD connector to expose all of the peripherals. I'd buy a bunch of tablet boards right now if the LCD connectors could be reconfigured that way. We'd just run a FPC cable over to another PCB with our application specific hardware on it. On Wed, Mar 4, 2015 at 8:35 AM, Simos Xenitellis simos.li...@googlemail.com wrote: Hi All, As some may say, what is important to look at, is our end-game. That is, how should our relationship with Allwinner be, and what steps to take to get there. Allwinner has made mistakes with regards to free/open-source licenses of software. Some of those mistakes could have been avoidable (that is, still not release the source but distribute in a more appropriate way), while others have no way around (i.e. the source must be released) nor excuse. For the part of libvdecoder.so/libvencoder.so, if there are libraries in there that did not come from Allwinner, then there is a workaround for them by splitting the code in separate libraries. It would make them compliant (in future versions) but then the core issue of software support would be bypassed. I do not know whether libvdecoder.so has non-Allwinner code; perhaps David could investigate and deliver a verdict. There is this tradition for semiconductor companies to try to keep closed as much as possible. Being less exposed should mean less potential problems? And more control over the downstream? Well, that tradition is changing and it's not the important the new trend is to attract as many developers as possible. It is so critical to attract developers to your hardware/software, that companies start to make things free and open-source. For me, the important message from the recent discussion on software support in CedarX, is what Jon Smirl and javqui said. That they have been doing projects and the lack of good support is a huge issue. Also, very expensive to their projects. This is something that Allwinner must note down and rectify. Apart from the developers being affected, it is also Allwinner that loses developers and new customers. There are more and more SoCs from others to choose from, including Intel, who are doing a similar open driver (http://www.phoronix.com/scan.php?page=news_itempx=MTg4Mjg). Even the PR manager at ImgTec showed interest to get things more open at http://www.reddit.com/r/linux/comments/2ps5l3/the_state_of_open_source_drivers_for_mobile_and/ I do not like the aggressive/abusive style that is shown in this list. I do not think that it can deliver a working relationship that can last. While we talk about community, it's still free for all to anyone to lead to different directions. I think the end-game should be towards a long-term working relationship. In the case that Allwinner cannot deliver, so be it. Everyone would loses, including Allwinner. However, I see efforts to adapt, including the hiring of David. It's up to Allwinner to adapt quickly in order to keep attracting developers. Simos -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Allwinner GPL violations: definitive proof.
utterly incapable of or unwilling to change. Luc Verhaegen. NOTICE: This e-mail and any included attachments are intended only for the sole use of named and intended recipient (s) only. If you are the named and intended recipient, please note that the information contained in this email and its embedded files are confidential and privileged. If you are neither the intended nor named recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. Please reply to the sender and destroy the original message and all your records of this message (whether electronic or otherwise). Furthermore, you should not disclose to any other person, use, copy or disseminate the contents of this e-mail and/or the documents accompanying it. -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v4] dma: sun4i: Add support for the DMA engine on sun[457]i SoCs
Did you fix multiple simultaneous DMA transfers in this? And easy test
is to start jack audio. Jack will start simultaneous cyclic transfers
on both the ALSA input and output. Since cyclic transfers never end,
multiple simultaneous transfers has to work. Last time I tried it I
got an immediate GPF when the second cyclic transfer was started.
On Tue, Feb 3, 2015 at 1:43 PM, Emilio López emi...@elopez.com.ar wrote:
Hi,
El 01/02/15 a las 07:03, Priit Laes escibió:
On Sat, 2015-01-31 at 19:58 -0300, Emilio López wrote:
This patch adds support for the DMA engine present on Allwinner A10,
A13, A10S and A20 SoCs. This engine has two kinds of channels:
normal and dedicated. The main difference is in the mode of
operation; while a single normal channel may be operating at any
given time, dedicated channels may operate simultaneously provided
there is no overlap of source or destination.
Hardware documentation can be found on A10 User Manual (section 12),
A13 User Manual (section 14) and A20 User Manual (section 1.12)
Signed-off-by: Emilio López emi...@elopez.com.ar
(...)
diff --git a/Documentation/devicetree/bindings/dma/sun4i-dma.txt
b/Documentation/devicetree/bindings/dma/sun4i-dma.txt
new file mode 100644
index 000..f1634a2
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/sun4i-dma.txt
@@ -0,0 +1,46 @@
+Allwinner A10 DMA Controller
Don't you want to mention A13, A10S and A20 too?
What if a new SoC shows up with this controller? :) I'd rather give a
single name to the IP, like we do with the compatible strings.
(...)
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index 2022b54..675b98f 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -50,3 +50,4 @@ obj-y += xilinx/
obj-$(CONFIG_INTEL_MIC_X100_DMA) += mic_x100_dma.o
obj-$(CONFIG_NBPFAXI_DMA) += nbpfaxi.o
obj-$(CONFIG_DMA_SUN6I) += sun6i-dma.o
+obj-$(CONFIG_SUN4I_DMA) += sun4i-dma.o
diff --git a/drivers/dma/sun4i-dma.c b/drivers/dma/sun4i-dma.c new file
mode 100644
index 000..a025405
--- /dev/null
+++ b/drivers/dma/sun4i-dma.c
@@ -0,0 +1,1264 @@
+/*
+ * Copyright (C) 2014 Emilio López
2014, 2015 ?
I guess so :)
(...)
+static int convert_burst(u32 maxburst)
+{
+ if (maxburst 8)
+ return -EINVAL;
Would it make sense to add check for maxburst = 0 too?
I can add one if you feel it's needed.
+
+ /* 1 - 0, 4 - 1, 8 - 2 */
+ return (maxburst 2);
+}
+
+static int convert_buswidth(enum dma_slave_buswidth addr_width)
+{
+ if (addr_width DMA_SLAVE_BUSWIDTH_4_BYTES)
+ return -EINVAL;
+
+ /* 8 (1 byte) - 0, 16 (2 bytes) - 1, 32 (4 bytes) - 2 */
+ return (addr_width 1);
+}
+
+static int choose_optimal_buswidth(dma_addr_t addr)
+{
+ /* On 32 bit aligned addresses, we can use a 32 bit bus width */
+ if (addr % 4 == 0)
Not sure, whether it makes sense to optimize or not, but this can be
calculated like this:
(addr (4 - 1)) == 0
It looks like IS_ALIGNED() in linux/kernel.h is what we need here.
+static struct sun4i_dma_promise *
+generate_ddma_promise(struct dma_chan *chan, dma_addr_t src, dma_addr_t
dest,
+ size_t
len, struct dma_slave_config *sconfig)
+{
+ struct sun4i_dma_promise *promise;
+ int ret;
+
+ promise = kzalloc(sizeof(*promise), GFP_NOWAIT);
+ if (!promise)
+ return NULL;
+
+ promise-src = src;
+ promise-dst = dest;
+ promise-len = len;
+
No timing parameters or this is just a quirk required for SPI?
They're filled together with the endpoints, in case we need different
ones for some other device. There's a big comment block explaining the
situation on top of their assignment.
promise-cfg = DDMA_CFG_LOADING |
DDMA_CFG_BYTE_COUNT_MODE_REMAIN;
+
+ /* Source burst */
+ ret = convert_burst(sconfig-src_maxburst);
+ if (IS_ERR_VALUE(ret))
+ goto fail;
+ promise-cfg |= DDMA_CFG_SRC_BURST_LENGTH(ret);
+
Thanks for reviewing this! :)
Emilio
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an
email to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
--
Jon Smirl
jonsm...@gmail.com
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: DMAEngine and audio support on A20
On Thu, Jan 29, 2015 at 3:45 PM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Thu, Jan 29, 2015 at 09:37:25AM -0500, Stefan Monnier wrote: You may also need some DMA changes. I've got a patch for this but have never tested it. I really would like to keep using my little server for another 5 years or more, and I don't see that happening if it doesn't get merged into mainline. You absolutely need DMA for a server? Really? Home jukebox server, yes: the audio out is rather handy when playing music ;-) Buying a USB DAC is also an option for now then. IIUC the main first step is to fix the DMA code so as to allow concurrent DMA. Where in the code is this limitation to only one DMA at a time? It's not really a limitation of the number of clients, but the number of concurrent transfers, and it actually works like that in hardware, it's just re-emulated in software too. I thought that the hardware did support multiple (8?) concurrent transfers (and that the code does not make use of it because of a misunderstanding of the docs). IIRC, the hardware a 8 channels, and follows a round-robin between the 8. So you can program 8 in parallel, but only one will be actually transfering at the same time. Allwinner corrected the translation error on this. All DMA on any common CPU only does one transfer at a time -- there's only one bus. This hardware does a bus memory burst (8 or 16 bytes) and then round robins to the next ready DMA. All common DMA hardware works like that. What Sugar said what that this is standard DMA hardware with no special sauce. It is the normal burst round-robin DMA found on all ARM CPUs. This single transfer thing was a translation error in the documentation. And what Emilio did was always use a single channel (still IIRC), effectively implementing some kind of scheduler in software. In any case, if someone could help me get started on fixing this would be very welcome. I'm not a kernel hacker, but I'm willing to try and learn. I'd start looking what the issue_pending function does. It's the function that's supposed to push the transfer descriptor to the hardware. PS: Looking at recent coding activity, it seems there's more interest in adding basic support for new SoCs than for improving support for old ones. So we end up with basic support for lots of devices but good support for none :-( These days, we're three of us doing some work, including fixing existing bugs, maintaining the code, etc. I'm sorry I sounded like the usual whiner. I really do appreciate all the work people put into this (especially since the 3.4 kernel was unstable on my machine, whereas the mainline is pretty solid) and I'm well aware of the usual lack of manpower. That, and I'm not sure that focusing on a five years old SoCs while ignoring any new SoC is the right policy. linux-sunxi did that with the A31, look at where it is now. I don't know for sure what is the right policy either, of course. But I don't find it obvious that, given the lack of resources, trying to expand the breadth of support rather than the depth of support is necessarily a good idea either, if the result is more boards that can barely boot. I wouldn't describe it as barely boot. But there's also two things to consider: - People with A31/A23/A80 have no other alternative than the Allwinner kernel. Do we really want to leave these users out in the cold? I don't. - Adding a new SoC support is pretty cheap Maybe the best policy should aim at bringing more people on board. If you have a good strategy for that, I'm all ears. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Infrared Remote Control (sunxi-ir)
IR remotes use different protocols. These protocols are supported by different kernel modules like NEC, RC5, etc. You also need keymaps for mapping the remote protocols into standard key events. Look in the kernel source at drivers/media/rc/.. If you get things set up right Linux can decode every IR remote on the market. On Thu, Dec 4, 2014 at 8:42 AM, Simo Xefil xe...@xefil.com wrote: Hello to all! I'm trying to debug IR signals on a A20 based board with Arch Linux. I'm trying to test if I'm able to read values from a remote IR control. During boot I can recognise the ir as follow: [2.478959] input: sunxi-ir as /devices/virtual/input/input0 Looking on the devices I get: # cat /proc/bus/input/devices I: Bus=0019 Vendor=0001 Product=0001 Version=0100 N: Name=sunxi-ir P: Phys=RemoteIR/input1 S: Sysfs=/devices/virtual/input/input0 U: Uniq= H: Handlers=sysrq rfkill kbd event0 B: PROP=0 B: EV=3 B: KEY= fffe (...) Then, using this command I expect to see some signals: # evtest /dev/input/event0 Input driver version is 1.0.1 Input device ID: bus 0x19 vendor 0x1 product 0x1 version 0x100 Input device name: sunxi-ir Supported events: Event type 0 (EV_SYN) Event type 1 (EV_KEY) Event code 1 (KEY_ESC) Event code 2 (KEY_1) Event code 3 (KEY_2) (...) Event code 247 (KEY_RFKILL) Event code 248 (?) Event code 249 (?) Event code 250 (?) Event code 251 (?) Event code 252 (?) Event code 253 (?) Event code 254 (?) Event code 255 (?) Properties: Testing ... (interrupt to exit) I've tested a PHILIPS remote, no signal, and a SAMSUNG remote. On the samsung remote I get values. Event: time 1417698487.436218, type 1 (EV_KEY), code 2 (KEY_1), value 1 Event: time 1417698487.436227, -- EV_SYN Event: time 1417698487.959104, type 1 (EV_KEY), code 2 (KEY_1), value 0 Event: time 1417698487.959113, -- EV_SYN Event: time 1417698489.688749, type 1 (EV_KEY), code 2 (KEY_1), value 1 Event: time 1417698489.688757, -- EV_SYN Event: time 1417698489.989063, type 1 (EV_KEY), code 2 (KEY_1), value 0 Event: time 1417698489.989070, -- EV_SYN Event: time 1417698490.761935, type 1 (EV_KEY), code 2 (KEY_1), value 1 Event: time 1417698490.761947, -- EV_SYN Event: time 1417698491.069059, type 1 (EV_KEY), code 2 (KEY_1), value 0 Event: time 1417698491.069065, -- EV_SYN Event: time 1417698491.961707, type 1 (EV_KEY), code 2 (KEY_1), value 1 Event: time 1417698491.961715, -- EV_SYN Event: time 1417698492.269065, type 1 (EV_KEY), code 2 (KEY_1), value 0 Event: time 1417698492.269072, -- EV_SYN Also the device works. All remote are working used on their own devices. My goal is to remplicate the signal of a remote command of an automatic pellet stove. I would like to clone the signal. The remote works on the stove, also it's not a remote issue. Is there a way to debug or to know if the remote is incompatible? Reading the instructions it's defined as Infra Red. Are there different IR signals? I've read that in some cases, values sent above 255 are ignored. Could be the case? How in case to solve? Thanks! Simon -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Infrared Remote Control (sunxi-ir)
On Thu, Dec 4, 2014 at 9:23 AM, Simo Xefil xe...@xefil.com wrote: Il giorno giovedì 4 dicembre 2014 14:51:57 UTC+1, Jon Smirl ha scritto: IR remotes use different protocols. These protocols are supported by different kernel modules like NEC, RC5, etc. You also need keymaps for mapping the remote protocols into standard key events. Look in the kernel source at drivers/media/rc/.. If you get things set up right Linux can decode every IR remote on the market. Ok, good to know there are different protocols. The content of my folder is: #pwd /usr/lib/modules/3.4.90/kernel/drivers/media/rc # ls ati_remote.ko ir-jvc-decoder.ko ir-mce_kbd-decoder.ko ir-rc5-decoder.ko ir-rc6-decoder.koir-sony-decoder.ko lirc_dev.ko rc-core.ko streamzap.koimon.koir-lirc-codec.ko ir-nec-decoder.ko ir-rc5-sz-decoder.ko ir-sanyo-decoder.ko keymaps mceusb.ko redrat3.ko I was expecting to be able get a kind of raw string to simply resend if needed, even if not recognized. Is there a way to get raw values and simply resend them? Like using an arduino, with a sketch I got the raw data and then I use them to resend the signal. i.e.: http://www.instructables.com/id/Arduino-Infrared-Remote-tutorial/#step5 I would then an IR led to send out signals, if the build in receiver cannot send as well. I've no idea if the build in ir sensor can only receive. It is unlikely that your built-in IR can also transmit. Your box would need to have a jack labeled IR out. You will probably need an external USB box like this one: http://www.hauppauge.com/site/webstore2/webstore_remote-mckit.asp That bundle of wire on the left is the transmitter. Or if you are a hacker you can build your own IR transmitter for a couple of dollars. Thanks Simon -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Infrared Remote Control (sunxi-ir)
I have not tried this... but I think if you load the kernel lirc device driver the raw data will be available on /dev/lirc. It may also be available in sysfs as part of the base IR system. Google around, someone else must have tried getting to it. http://www.lirc.org/ On Thu, Dec 4, 2014 at 10:40 AM, Simo Xefil xe...@xefil.com wrote: Il giorno giovedì 4 dicembre 2014 16:24:23 UTC+1, Jon Smirl ha scritto: It is unlikely that your built-in IR can also transmit. Your box would need to have a jack labeled IR out. You will probably need an external USB box like this one: http://www.hauppauge.com/site/webstore2/webstore_remote-mckit.asp That bundle of wire on the left is the transmitter. Or if you are a hacker you can build your own IR transmitter for a couple of dollars. Uh, I'll try to build my own IR sender. I already have some IR leds. I'll try to use it on the GPIO pins of my board. Aside this, which is a point I'll start to deal with later, I need to get the values from the remote IR to clone the signal. Also I'm again on the original issue. Is there a way to capture the raw data? I'll think how to send it out later :) Simon -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Is it possible to encode multi(csi0, csi1) h.264 using the CedarX(Video Engine)?
CedarX doesn't do very good video. These Hi3518E camera boards are much more effective - $11 http://www.aliexpress.com/item/Pre-order-2-0MP-IP-Camera-Module-1080P-HD-Support-Intelligent-Video-Analytics-Hi3516C-1-2/1838582703.html Those boards run Linux and support ONVIF. You can use a cheap Ethernet switch and hook up a bunch of them to your Allwinner system. On Fri, Nov 21, 2014 at 6:26 AM, JongHo Kim furmu...@gmail.com wrote: Dear members. I have questions for CedarX(Video Engine). Is it possible situation? (at same runtime) +-+ | CSI0(NV21) --++- test0.mp4 | | +-- (CedarX)VE --+ | | CSI1(NV21) --++- test1.mp4 | +-+ Is the CedarX(Video Engine) supported to encode multiple instance? If it is not support, What should I do to encode multiple input? Thanks! -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v4 0/5] simplefb: add clock handling code
to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Buffer size limitations in sound device?
There is no hardware limit. The audio buffer is in main memory. If the driver is properly written you should be able to use ALSA to allocate a larger buffer. Try emilio's kernel. It has 192/24 working and I believe it should work to allocate arbitrary buffers but I haven't tried. On Thu, Oct 16, 2014 at 5:31 AM, Rob r.jans...@xs4all.nl wrote: I am trying to use the on-board analog sound output on a CubieBoard2 (A20) with a program that I developed on the PC platform. It uses 16bit 48000 samples/s stereo audio output, and tries to set a 16384 frame buffer (16 periods of 1024 frames). The driver on the CubieBoard2 (from the current version of Cubian) refuses this setting and limits the number of periods to 8 and the buffer size to 8192 frames. I can find the 8-period limit in the driver source that I retrieved using git clone -b sunxi-3.4 --depth 1 https://github.com/linux-sunxi/linux-sunxi.git (I'm not completely certain that this is the source of the kernel I am running). Is it a hardware-determined limitation? However, when I change my program to use 2048-frame periods, it still limits the buffer to 8192 periods, now 4. I wonder if there is some way to get around this, or if this is a hardware limitation that can not be fixed in the driver (and so I will have to change my program to work around having the smaller buffer)? Rob -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s
On Sat, Oct 11, 2014 at 10:31 AM, jacky lau i900...@gmail.com wrote: A big client will buy thousands of chips once. Are there any relation between big client and user manual publishing? No. So they don't think it's necessary to open their private property. When you are a big client, you are VIP, all document and source code is open to you. And if publish all technical documentation, competitors will know some technical secret (e.g. bug;) they don't want them to know. Open world is beautiful, but they will not actively participate if there is no return. Why some China soc company publish some documents and source code now? I think this is mainly for marketing. But no matter how, VIP priority. Right now Allwinner is only good for tablets and STBs because Allwinner supplies turnkey solutions. If documentation were more open other applications could be developed. If customer can't get software working for these other applications, they won't buy thousands of chips. So if Allwinner wants to survive past the end of the tablet fad they have to start developing these other markets. Otherwise when the tablet fad is over it will be the end of Allwinner. You also over estimate the value of technical secrets. What is the point of putting a secret h.264 encode/decode unit on the chip if half of your customers can't get it working? Obviously Rockchip knows how to make h.264 encode/decode since they have a similar unit on their chip. And so does Freescale, TI, ST, etc. -- there is no big secret in making h.264 hardware for people familiar with how to do it (hint, it is an ISO standard). So by keeping the documentation secret you hide nothing significant from your competitors and much, much worse -- you keep your own customers from using the hardware they bought. Think about it --- which is more important - hiding something form a competitor that they probably already know, or getting your customers to ship and buy more chips? Bottom line - which one brings cash in the door - secret documentation or getting as many customers as possible to ship? 在 2014年10月6日星期一UTC+8下午8时55分30秒，RFat写道： Hi Kevin, Publishing the user manuals will certainly increase Allwinner's chips popularity. I was wondering if there is a rough estimate as to when the A80's manual will be made available? Thanks! Raanan On Monday, September 29, 2014 12:46:53 PM UTC+3, ke...@allwinnertech.com wrote: Hi All, I have put the documents on github, and the url is https://github.com/allwinner-zh/documents.git Thanks Simos, Henrik and Luc's suggestion. And other documents will be upated to here when released. Best Regards, kevin.z.m From: HenrikNordström Date: 2014-09-29 08:46 To: linux...@googlegroups.com CC: sh...@allwinnertech.com; Meng Zhang Subject: Re: [linux-sunxi] Allwinner documentation (hardware datasheet, user manual) for A10, A10s, A13, A20, A31, A31s sön 2014-09-28 klockan 02:18 +0200 skrev Luc Verhaegen: Why didn't someone from Allwinner send these documents in him/herself? The current person discussion the matter with Allwiner was Simos, who is part of the linux-sunxi community. Allwinner sent current versions of the documents to Simos for distribution in the community. What is wrong? Mailing the full set of documents as attachments directly to the mailinglist is not appropriate. And for some strange and unknown reason Allwinner do not appear to have a public document archive for this kind of documents themselves, and seems to only distribute them via email to their customers when requested. The real question is why AW do not make the documents available in public themselves, and likewise why they do not have a public git repository for SDK sources etc (github or elsewhere). Regards Henrik NOTICE: This e-mail and any included attachments are intended only for the sole use of named and intended recipient (s) only. If you are the named and intended recipient, please note that the information contained in this email and its embedded files are confidential and privileged. If you are neither the intended nor named recipient, you are hereby notified that any unauthorized review, use, disclosure, dissemination, distribution, or copying of this communication, or any of its contents, is strictly prohibited. Please reply to the sender and destroy the original message and all your records of this message (whether electronic or otherwise). Furthermore, you should not disclose to any other person, use, copy or disseminate the contents of this e-mail and/or the documents accompanying it. -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because
[linux-sunxi] A20 USB gadget mode
Has anyone tried USB gadget mode on the A20? Any success? Which kernels does it work on? I tried it on mainline and the OTG device is not in the device tree, I'm poking around and trying to figure out how to get it going. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: A20 USB gadget mode
On Thu, Oct 9, 2014 at 3:27 PM, Stefan Monnier monn...@iro.umontreal.ca wrote: Has anyone tried USB gadget mode on the A20? I used it successfully (using the Ethernet driver so as to use the OTG as a second NIC) on the Cubietruck with the sunxi-3.4 kernel. That's what I want it for, I want to run the gadget CDC Ethernet driver. By doing that I can hook up the second CPU on the board via USB and they can all share the network. I'd be really happy to see it supported on mainline (and FWIW, I don't really need the dynamic detection/switch between the two modes, as long as I can decide at boot whether to use the OTG port in host mode or not). Stefan -- 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. -- Jon Smirl jonsm...@gmail.com -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: Report on recently added audio support
On Tue, Oct 7, 2014 at 10:07 AM, Stefan Monnier monn...@iro.umontreal.ca
wrote:
pll2: clk@01c20008 {
#clock-cells = 1;
compatible = allwinner,sun4i-a10-b-pll2-clk;
^^
Apparently, this -b shouldn't have been there. At least it isn't
there in the sun7i-a20.dtsi and when I removed it, the initialization
went a bit further.
-b is there because these is code in arch/arm/sunxi that is supposed detect
an A10 version A vs a version B. The codec drivers for those two versions
are not the same.
So something is wrong in that version detection code.
Now it fails on the DMA setup (so apparently the clock setup succeeded):
[3.143406] sunxi-codec 1c22c00.codec: ASoC: Failed to create
platform debugfs directory
[3.151636] sunxi-codec 1c22c00.codec: Missing dma channel for
stream: 0
[3.158428] sunxi-codec 1c22c00.codec: ASoC: pcm constructor failed:
-22
[3.165157] sunxi-codec 1c22c00.codec: ASoC: can't create pcm CDC
PCM :-22
[3.172056] sunxi-codec 1c22c00.codec: ASoC: failed to instantiate
card -22
[3.179203] sunxi-codec 1c22c00.codec: snd_soc_register_card failed
(-22)
[3.186098] sunxi-codec: probe of 1c22c00.codec failed with error -22
I assume the debugfs failure is of no serious consequence. But w.r.t
the missing DMA channel, I'm at a loss. Does that refer to the first
dma (i.e. the rx) of:
It is not going to work without the DMA channels. There is a sunxi DMA
driver on in drivers/dma/sunxi
It must not be loading right on the A10.
codec: codec@01c22c00 {
...
dmas = dma 0 19, dma 0 19;
dma-names = rx, tx;
...
}
The printfs told me that in
if (!pcm-chan[i]
(pcm-flags
SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME)) {
pcm-chan[i] = dma_request_slave_channel(dev,
dma_data-chan_name);
}
if (!pcm-chan[i] (pcm-flags
SND_DMAENGINE_PCM_FLAG_COMPAT)) {
pcm-chan[i] =
dmaengine_pcm_compat_request_channel(rtd,
substream);
}
we don't enter any of the two ifs, so it seems that pcm-flags is
not set properly. Commenting out the pcm-flags tests to force
execution of the then branch of any of the two ifs above makes no
difference, so the calls to dma_request_slave_channel or
dmaengine_pcm_compat_request_channel return NULL anyway.
FWIW, dma_data-chan_name is NULL, and I'm not sure.
Stefan
reg = 0x01c20008 0x4;
clocks = osc24M;
clock-output-names = pll2, pll2x2, pll2x4,
pll2x8;
};
pll4: clk@01c20018 {
#clock-cells = 0;
compatible = allwinner,sun4i-a10-pll1-clk;
reg = 0x01c20018 0x4;
--
};
codec_clk: clk@01c20140 {
#clock-cells = 0;
compatible = allwinner,sun4i-a10-codec-clk;
reg = 0x01c20140 0x4;
clocks = pll2 0;
clock-output-names = codec;
};
};
soc@01c0 {
--
codec: codec@01c22c00 {
#sound-dai-cells = 0;
compatible = allwinner,sun4i-a10-codec;
reg = 0x01c22c00 0x40;
interrupts = 0 30 4;
clocks = pll2 0, apb0_gates 0,
codec_clk;
clock-names = pll, apb, codec;
dmas = dma 0 19, dma 0 19;
dma-names = rx, tx;
routing =
MIC_IN, Microphone Jack,
Microphone Jack, Mic Bias,
boot/dts%
--
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.
--
Jon Smirl
jonsm...@gmail.com
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
