[linux-sunxi] Compiling android kernel using android source files
I have downloaded android source files for pcduino3 and I am trying to compile android kernel using these source files. I am following the steps given at the following link. http://learn.linksprite.com/pcduino/and ... -pcduino3/ But while compiling I am getting the following error at ./build.sh -p sun7i_android mkscript current setting: Chip: sun7i Platform: android Board: Output Dir: /home/embed/android4.2/lichee/out/android/common INFO: build lichee ... INFO: build buildroot ... external toolchain has been installed INFO: build buildroot OK. INFO: build kernel ... INFO: prepare toolchain ... Building kernel build standby make: Entering directory `/home/embed/android4.2/lichee/linux-3.4/arch/arm/mach-sun7i/pm/dram-freq' arm-linux-gnueabi-gcc -I. -I/home/embed/android4.2/lichee/linux-3.4/include -I/home/embed/android4.2/lichee/linux-3.4/arch/arm/mach-sun7i/include -g -c -nostdlib -march=armv7-a -marm -D__STANDBY_MODULE__ -fno-unwind-tables -fno-asynchronous-unwind-tables -mlittle-endian -O2 --min_array_alignment=4 --no_unaligned_access -e dram_freq_main dram_freq_entry.c-o dram_freq_entry.o as: unrecognized option '-EL' make: *** [all] Error 1 make: Leaving directory `/home/embed/android4.2/lichee/linux-3.4/arch/arm/mach-sun7i/pm/dram-freq' ERROR: build kernel Failed Also I removed -EL flag from the file ./android4.2/lichee/linux-3.4/arch/arm/mach-sun7i/pm/dram-freq/Makefile and tried but again it is giving the same error. Also I have downloaded the tool chain for arm-linux-gnueabi-gcc and set the path in the ~/.profile file like this export PATH=$PATH:/usr/bin/gcc/arm-linux-gnueabi/bin Is their any way to install arm-linux-gnueabi-gcc ? I am using ubuntu 12.04 64 bit os for cross compile. Thanks pirpi -- You received this message because you are subscribed 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] Compiling android kernel using android source files
Hi Pirpi, On Thu, Jul 24, 2014 at 4:06 PM, pirpi.12...@gmail.com wrote: I have downloaded android source files for pcduino3 and I am trying to compile android kernel using these source files. I am following the steps given at the following link. Just a warning: This mailing list is for discussion and support of the upstream linux-sunxi kernel, not Android or the Lichee kernel. You should take your questions to the pcduino community as we might not be able to help you. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ -- You received this message because you are subscribed 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] Compiling android kernel using android source files
On Thu, Jul 24, 2014 at 9:39 AM, Code Kipper codekip...@gmail.com wrote: Just a warning: This mailing list is for discussion and support of the upstream linux-sunxi kernel, not Android or the Lichee kernel. I'd say linux is general, not only upstream but I agree that Android is OT. Is this really the case?according to the wiki http://linux-sunxi.org/Mailing_list this mailing list is for technical discussion pertaining to sunxi. It's not the first time that I feel someone has asked a relevant question only be get a reply like this from you. Are you aware that this ml is called linux-sunxi right? -- Carlo Caione -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Compiling android kernel using android source files
On Thu, Jul 24, 2014 at 11:02 AM, Code Kipper codekip...@gmail.com wrote: Are you aware that this ml is called linux-sunxi right? Yes and so is the website where a lot of this information is stored. Is Android really OT?, it's described here http://linux-sunxi.org/Android. So what? This is a ml not a wiki, on the wiki you can find a lot of related stuff. I would say that anything sunxi related is relevant here. If this was a purely kernel hangout, I would miss a lots of quite interesting information. It's not like this ml is flooded with questions. The fact that there aren't that many questions doesn't allow people to be OT and, please, consider also that the you can find something OT interesting but a lot of other people are annoyed by it. See, the problem is that often the posts in this ml are definitely OT (see the Puneet B posts) so Julian is welcome to try to keep things on topic. FWIW I already proposed in the irc channel to create a ml specifically for kernel development (on vger maybe?) Aaas usual IMHO, Ciao :) -- Carlo Caione -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Compiling android kernel using android source files
So what? This is a ml not a wiki, on the wiki you can find a lot of related stuff. I never said that it wasbut it was put together by the community working with sunxi to avoid flooding the arm-netbook ml. I'm not much of an irc'er but I'd like to think that I can post something here without getting a knock back. I would say that anything sunxi related is relevant here. If this was a purely kernel hangout, I would miss a lots of quite interesting information. It's not like this ml is flooded with questions. The fact that there aren't that many questions doesn't allow people to be OT and, please, consider also that the you can find something OT interesting but a lot of other people are annoyed by it. Then surely this is your problem...if I didn't filter out or plainly ignore things that I wasn't interested in especially in modern life then I'll probably end up killing myself. See, the problem is that often the posts in this ml are definitely OT (see the Puneet B posts) so Julian is welcome to try to keep things on topic. And this is probably why I got annoyed at Julian in the first place and wanted to reply to this. I saw that Puneet had posted a question about wifi BT devices supported by the linux sunxi driver. John answered his question and supplied him with some more information. At no stage did I feel that these exchanges were OT. FWIW I already proposed in the irc channel to create a ml specifically for kernel development (on vger maybe?) Aaas usual IMHO, To quote the late Bill Hicks (OTI know!) “It takes more energy to frown than it does to smile.” Yeah, you know it takes more energy to point that out than it does to leave me alone? Ciao :) Bye D Bye.I'll get back to some kernel hacking. CK -- You received this message because you are subscribed 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] conflict gt811_ts with gpio-suinxi
hello I am using goodix-gt811 ctp 7 inch and i have not problem to use this module but when i modprobe gpio-sunxi , the interrupt of my ctp disable 1- when gt811_ts is intalled and i modprobe gpio-sunxi ,this message shown on Putty the message is : 6sunxi_gpio driver init ver 1.3 3IRQ handler type mismatch for IRQ 60 3current handler: Goodix-TS [c0015340] (unwind_backtrace+0x0/0x134) from [c0094b80] (__setup_irq+0x3b8/0 x404) [c0094b80] (__setup_irq+0x3b8/0x404) from [c0094d04] (request_threaded_irq+0 xb0/0x138) [c0094d04] (request_threaded_irq+0xb0/0x138) from [bf0d4ca8] (sunxi_gpio_pro be+0x3e4/0x490 [gpio_sunxi]) [bf0d4ca8] (sunxi_gpio_probe+0x3e4/0x490 [gpio_sunxi]) from [c04bba50] (driv er_probe_device+0xb4/0x354) [c04bba50] (driver_probe_device+0xb4/0x354) from [c04bbdc0] (__driver_attach +0x8c/0x90) [c04bbdc0] (__driver_attach+0x8c/0x90) from [c04b9dd0] (bus_for_each_dev+0x6 0/0x94) [c04b9dd0] (bus_for_each_dev+0x60/0x94) from [c04bb000] (bus_add_driver+0xd0 /0x28c) [c04bb000] (bus_add_driver+0xd0/0x28c) from [c04bc394] (driver_register+0x78 /0x13c) [c04bc394] (driver_register+0x78/0x13c) from [c00086c0] (do_one_initcall+0x1 1c/0x174) [c00086c0] (do_one_initcall+0x11c/0x174) from [c008244c] (sys_init_module+0x 78/0x19c) [c008244c] (sys_init_module+0x78/0x19c) from [c000ec00] (ret_fast_syscall+0x 0/0x30) 3Can't request irq 60 4gpio-sunxi: probe of gpio-sunxi failed with error -16 2- when gpio-sunxi is intalled and i modprobe gt811_ts,this message shown on Putty the message is : ===goodix_ts_init= ctp_fetch_sysconfig_para. ctp_fetch_sysconfig_para: after: ctp_twi_addr is 0x5d, dirty_addr_buf: 0x5d. dirty_addr_buf[1]: 0xfffe ctp_fetch_sysconfig_para: ctp_twi_id is 1. 6ctp_fetch_sysconfig_para: screen_max_x = 800. 6ctp_fetch_sysconfig_para: screen_max_y = 480. 6ctp_fetch_sysconfig_para: revert_x_flag = 0. 6ctp_fetch_sysconfig_para: revert_y_flag = 0. 6ctp_fetch_sysconfig_para: exchange_x_y_flag = 0. goodix_ts_init: after fetch_sysconfig_para: normal_i2c: 0x5d. normal_i2c[1]: 0xfffe 4i2c-core: driver [Goodix-TS] using legacy suspend method 4i2c-core: driver [Goodix-TS] using legacy resume method incomplete xfer (0x48) 6ctp_detect: Detected chip Goodix-TS at adapter 1, address 0x5d 6Goodix-TS 1-005d: Install gt811 driver. 6Goodix-TS 1-005d: Driver Release Date:2012-02-08 ==goodix_gt811 probe== ctp_set_irq_mode: config gpio to int mode. 6ctp_set_irq_mode, 231: gpio_int_info, port = 8, port_num = 15. INTERRUPT CONFIG 6Goodix-TS 1-005d: GT811 init info:X_MAX=4096,Y_MAX=4096,TRIG_MODE=RISING EDGE 6input: gt80x as /devices/virtual/input/input4 3IRQ handler type mismatch for IRQ 60 3current handler: sunxi-gpio [c0015340] (unwind_backtrace+0x0/0x134) from [c0094b80] (__setup_irq+0x3b8/0x404) [c0094b80] (__setup_irq+0x3b8/0x404) from [c0094d04] (request_threaded_irq+0xb0/0x138) [c0094d04] (request_threaded_irq+0xb0/0x138) from [bf0e1388] (goodix_ts_probe+0x480/0x794 [gt811_ts]) [bf0e1388] (goodix_ts_probe+0x480/0x794 [gt811_ts]) from [c05714dc] (i2c_device_probe+0xb8/0x118) [c05714dc] (i2c_device_probe+0xb8/0x118) from [c04bba50] (driver_probe_device+0xb4/0x354) [c04bba50] (driver_probe_device+0xb4/0x354) from [c04b9e70] (bus_for_each_drv+0x58/0x8c) [c04b9e70] (bus_for_each_drv+0x58/0x8c) from [c04bb930] (device_attach+0x90/0xa4) [c04bb930] (device_attach+0x90/0xa4) from [c04badd4] (bus_probe_device+0x84/0xa8) [c04badd4] (bus_probe_device+0x84/0xa8) from [c04b9454] (device_add+0x520/0x60c) [c04b9454] (device_add+0x520/0x60c) from [c0571824] (i2c_new_device+0x128/0x1c0) [c0571824] (i2c_new_device+0x128/0x1c0) from [c0572d40] (i2c_do_add_adapter+0x1ac/0x254) [c0572d40] (i2c_do_add_adapter+0x1ac/0x254) from [c04b9dd0] (bus_for_each_dev+0x60/0x94) [c04b9dd0] (bus_for_each_dev+0x60/0x94) from [c05722fc] (i2c_for_each_dev+0x34/0x48) [c05722fc] (i2c_for_each_dev+0x34/0x48) from [c0573654] (i2c_register_driver+0x84/0xe8) [c0573654] (i2c_register_driver+0x84/0xe8) from [c00086c0] (do_one_initcall+0x11c/0x174) [c00086c0] (do_one_initcall+0x11c/0x174) from [c008244c] (sys_init_module+0x78/0x19c) [c008244c] (sys_init_module+0x78/0x19c) from [c000ec00] (ret_fast_syscall+0x0/0x30) 3Goodix-TS 1-005d: Cannot allocate ts INT!ERRNO:-16 this messages shows both of them use IRQ 60 how can i resolve this problem thanks for your help my board is CB2 A20 cubian SdCard image(debian 7) -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send
[linux-sunxi] Re: [PATCH 1/2] pinctrl: sunxi: use gpiolib API to mark a GPIO used as an IRQ
Hi Chen-Yu, Sorry for the belated reply. On Tue, Jul 15, 2014 at 01:24:36AM +0800, Chen-Yu Tsai wrote: When an IRQ is started on a GPIO line, mark this GPIO as IRQ in the gpiolib so we can keep track of the usage centrally. Signed-off-by: Chen-Yu Tsai w...@csie.org It looks fine: Acked-by: Maxime Ripard maxime.rip...@free-electrons.com Thanks! Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [linux-sunxi] Compiling android kernel using android source files
Hi, On Thu, Jul 24, 2014 at 7:28 PM, Carlo Caione ca...@caione.org wrote: On Thu, Jul 24, 2014 at 11:02 AM, Code Kipper codekip...@gmail.com wrote: Are you aware that this ml is called linux-sunxi right? Yes and so is the website where a lot of this information is stored. Is Android really OT?, it's described here http://linux-sunxi.org/Android. So what? This is a ml not a wiki, on the wiki you can find a lot of related stuff. I would say that anything sunxi related is relevant here. If this was a purely kernel hangout, I would miss a lots of quite interesting information. It's not like this ml is flooded with questions. The fact that there aren't that many questions doesn't allow people to be OT and, please, consider also that the you can find something OT interesting but a lot of other people are annoyed by it. See, the problem is that often the posts in this ml are definitely OT (see the Puneet B posts) so Julian is welcome to try to keep things on topic. Puneet started asking questions about compiling Allwinner's own kernel (Lichee / 3.0.8) which we definitely don't support. He was told this by a couple of people and I took over when he persisted as I'm sure they have better stuff to do. My understanding is that everything and anything related to sunxi hardware, upstream or our development versions of u-boot and the Linux kernel, the linux-sunxi website and the Wiki, related tools, boards, BSP etc. is definitely on topic and that vendor kernels and stuff is definitely off topic. Everything else depends. This looked like it was a question about dealing with the Lichee kernel and some related Android distro, hence, by my understanding, it is probably off topic, hence me pointing out that they may not get much help here and that they'll probably get better answers from the vendor he got the Android tree from or the pcduino community. Admittedly he was asking about toolchains, but I don't know what that Android tree expects from a compiler, so it's probably a question best asked where he got it. Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH v11 0/2] Add support for the Allwinner A31 DMA Controller
Vinod, Dan, On Thu, Jul 17, 2014 at 09:46:14PM +0200, Maxime Ripard wrote: Hi, This patchset adds support for the DMA controller found in the Allwinner A31 and A23 SoCs. This has been tested using the newly introduced SPI driver on an A31 EVK. Support for DMA-driven SPI transfers will be the subject of another patch serie. This has been around for around 5 monthes now, and didn't get any review but nitpicks for three versions, so I feel like it could be merged quite quickly. Ok, so, who should I bribe to get this merged? The first version was posted on the 2/24, we're at v11 already, and I only got a single mail from either one of you. Don't get me wrong, I'd be ok to make any change you deemed necessary, but in order to do so, I at least have to get a sign of life from you, and so far, you've both always been MIA. We're pretty much in the same situation for the other DMA driver Emilio has been sending for over a month now, that he is doing as part as a GSoC for the Linux Foundation, with not a single maintainer review so far. I'm getting quite tired of this honestly, and I'm not sure it sends the right message to the hobbyists and companies that try to get things right by contributing. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 2/2] pinctrl: sunxi: number gpio ranges starting from 0
On Tue, Jul 15, 2014 at 01:24:37AM +0800, Chen-Yu Tsai wrote: The pinctrl-sunxi driver originally used the pin number as the gpio range offset. This resulted in large, bogus gpio numbers for the new sun6i-a31-r pinctrl devices. This patch makes the driver number the gpios ranges starting from an offset of 0, by subtracting the pin_base number from the pin number. This also makes the system-wide gpio number match the pin number. Tested on sun8i with sysfs exported gpios. Signed-off-by: Chen-Yu Tsai w...@csie.org Acked-by: Maxime Ripard maxime.rip...@free-electrons.com Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 0/2] pinctrl: sunxi: misc improvements for gpio
On Tue, Jul 22, 2014 at 06:33:10PM +0200, Linus Walleij wrote: AFAIK pinctrl pin numbers are device specific, so I'm wondering if we should also number them in terms of offsets, rather than absolute pin numbers. It's more of an asthetic change though. Any thoughts? Usually I say these pin numbers should try to match what is in the data sheet so it is easy to understand and debug. Sometimes pins are numbered with letters and stuff so they rather have names than numbers, then some artificial numbering is applied, whatever is helpful. I'm not directly familiar with the sunxi numbering system though... I'd prefer if we had an absolute number that more or less matches the one in the datasheet. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 2/2] pinctrl: sunxi: number gpio ranges starting from 0
Hi Maxime, On Tue, Jul 15, 2014 at 1:24 AM, Chen-Yu Tsai w...@csie.org wrote: The pinctrl-sunxi driver originally used the pin number as the gpio range offset. This resulted in large, bogus gpio numbers for the new sun6i-a31-r pinctrl devices. This patch makes the driver number the gpios ranges starting from an offset of 0, by subtracting the pin_base number from the pin number. This also makes the system-wide gpio number match the pin number. Tested on sun8i with sysfs exported gpios. Signed-off-by: Chen-Yu Tsai w...@csie.org --- This patch also changes the GPIO bindings for R_PIO: gpios = r_pio B N flag; Where B originally was the pinbank label (L or M) counted from A, with this patch it becomes (L or M) counted from its pinbank base (L). Thus gpios = r_pio 10 11 0; /* PL11 */ becomes gpios = r_pio 0 11 0; /* PL11 */ IMO this is correct, as the binding shows the bank offset and pin offset within the bank for the GPIO controller. But I'm worried it might be a bit confusing. I see you Acked this patch, but also in your reply to my cover letter, you mentioned that you want absolute pin numbers matching the datasheets. What about the GPIO DT bindings, as I explained above? Just double checking. Thanks. 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.
[linux-sunxi] sunxi-3.4 display driver dpms bug?
if I do: P=/sys/devices/platform/disp/graphics/fb0/blank echo 4 $P; echo 4 $P sleep 1 echo 0 $P the display is switched off and i can't switch the display on anymore can someone confirm? -- You received this message because you are subscribed 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] sunxi-3.4 display driver dpms bug?
Isn't that expected? The last command turned it off, did you try turning it back on? On Jul 24, 2014 7:04 AM, Jens Thiele ka...@karme.de wrote: if I do: P=/sys/devices/platform/disp/graphics/fb0/blank echo 4 $P; echo 4 $P sleep 1 echo 0 $P the display is switched off and i can't switch the display on anymore can someone confirm? -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] sunxi-3.4 display driver dpms bug?
Neal Peacock kulimandpho...@gmail.com writes:
Isn't that expected?
no
The last command turned it off, did you try turning it back on?
echo 0 turns it on
and to be clear:
echo 4 $P
is not enough to produce the problem
you have to call it twice
echo 4 $P; echo 4 $P
you can also try something like:
/*BINFMTC:
*/
#include stdio.h
#include assert.h
#include linux/fb.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
int main(int argc, char** argv) {
int fd=open(/dev/fb0,O_RDWR);
assert(fd!=-1);
printf(%d\n,ioctl(fd, FBIOBLANK, FB_BLANK_POWERDOWN));
printf(%d\n,ioctl(fd, FBIOBLANK, FB_BLANK_POWERDOWN));
printf(%d\n,ioctl(fd, FBIOBLANK, FB_BLANK_UNBLANK));
return 0;
}
greetings,
karme
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 2/2] pinctrl: sunxi: number gpio ranges starting from 0
On Thu, Jul 24, 2014 at 09:19:18PM +0800, Chen-Yu Tsai wrote: This patch also changes the GPIO bindings for R_PIO: gpios = r_pio B N flag; Where B originally was the pinbank label (L or M) counted from A, with this patch it becomes (L or M) counted from its pinbank base (L). Thus gpios = r_pio 10 11 0; /* PL11 */ becomes gpios = r_pio 0 11 0; /* PL11 */ IMO this is correct, as the binding shows the bank offset and pin offset within the bank for the GPIO controller. But I'm worried it might be a bit confusing. I see you Acked this patch, but also in your reply to my cover letter, you mentioned that you want absolute pin numbers matching the datasheets. What about the GPIO DT bindings, as I explained above? Just double checking. Thanks. I'd like it to have the absolute numbers in sysfs, but the relative one in the DT. But I guess it's already what's happening, right? Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
[linux-sunxi] Re: [PATCH 2/2] pinctrl: sunxi: number gpio ranges starting from 0
On Fri, Jul 25, 2014 at 12:01 AM, Maxime Ripard maxime.rip...@free-electrons.com wrote: On Thu, Jul 24, 2014 at 09:19:18PM +0800, Chen-Yu Tsai wrote: This patch also changes the GPIO bindings for R_PIO: gpios = r_pio B N flag; Where B originally was the pinbank label (L or M) counted from A, with this patch it becomes (L or M) counted from its pinbank base (L). Thus gpios = r_pio 10 11 0; /* PL11 */ becomes gpios = r_pio 0 11 0; /* PL11 */ IMO this is correct, as the binding shows the bank offset and pin offset within the bank for the GPIO controller. But I'm worried it might be a bit confusing. I see you Acked this patch, but also in your reply to my cover letter, you mentioned that you want absolute pin numbers matching the datasheets. What about the GPIO DT bindings, as I explained above? Just double checking. Thanks. I'd like it to have the absolute numbers in sysfs, but the relative one in the DT. But I guess it's already what's happening, right? That's right. Just checking. :) ChenYu -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] sunxi-3.4 display driver dpms bug?
On 24 July 2014 16:04, Jens Thiele ka...@karme.de wrote: if I do: P=/sys/devices/platform/disp/graphics/fb0/blank echo 4 $P; echo 4 $P sleep 1 echo 0 $P the display is switched off and i can't switch the display on anymore can someone confirm? I have exactly opposite problem. When I connect a display to A10 it never turns off. It only shows either console or fully backlit blank screen. I may have quite dated kernel, though. Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] sunxi-3.4 display driver dpms bug?
Michal Suchanek hramr...@gmail.com writes: I have exactly opposite problem. When I connect a display to A10 it never turns off. It only shows either console or fully backlit blank screen. different problem then I may have quite dated kernel, though. sunxi-3.4 branch? consoleblank=0 in /proc/cmdline ? greetings karme -- You received this message because you are subscribed 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] sunxi-3.4 display driver dpms bug?
On 24 July 2014 21:33, Jens Thiele ka...@karme.de wrote: Michal Suchanek hramr...@gmail.com writes: I have exactly opposite problem. When I connect a display to A10 it never turns off. It only shows either console or fully backlit blank screen. different problem then I may have quite dated kernel, though. sunxi-3.4 branch? Linux A10 3.4.79+ #3 PREEMPT Mon Feb 17 21:33:07 CET 2014 armv7l GNU/Linux consoleblank=0 in /proc/cmdline ? Why would I do that !? console=ttyS0,115200 console=tty0 netconsole=@10.11.12.13/usb0,@10.11.12.14/ debug hdmi.audio=EDID:0 disp.screen0_output_mode=EDID:1280x1024p60 root=/dev/mmcblk0p1 rootwait panic=10 Thanks Michal -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] sunxi-3.4 display driver dpms bug?
Michal Suchanek hramr...@gmail.com writes: Linux A10 3.4.79+ #3 PREEMPT Mon Feb 17 21:33:07 CET 2014 armv7l GNU/Linux not that old consoleblank=0 in /proc/cmdline ? Why would I do that !? you shouldn't it was just a wild guess on my side why switching off the display might not work for you at all sorry for the confusion -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v3 3/5] sunxi: add general USB settings
General configuration settings to be set if CONFIG_USB_EHCI is enabled for an Allwinner aka sunxi SoC. Signed-off-by: Roman Byshko rbys...@gmail.com Acked-by: Ian Campbell i...@hellion.org.uk --- include/configs/sunxi-common.h | 6 ++ 1 file changed, 6 insertions(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 845b004..18dbede 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -204,6 +204,12 @@ #define CONFIG_BOOTP_SEND_HOSTNAME #endif +#ifdef CONFIG_USB_EHCI +#define CONFIG_CMD_USB +#define CONFIG_SYS_USB_EHCI_MAX_ROOT_PORTS 1 +#define CONFIG_USB_STORAGE +#endif + #if !defined CONFIG_ENV_IS_IN_MMC \ !defined CONFIG_ENV_IS_IN_NAND \ !defined CONFIG_ENV_IS_IN_FAT \ -- 2.0.0 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v3 5/5] sun7i: cubietruck: enable USB EHCI
Cubietruck has two USB host controllers. This makes them usable by enabling the EHCI driver for them. Signed-off-by: Roman Byshko rbys...@gmail.com Acked-by: Ian Campbell i...@hellion.org.uk --- boards.cfg | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/boards.cfg b/boards.cfg index 035b5c7..ae167c2 100644 --- a/boards.cfg +++ b/boards.cfg @@ -381,7 +381,7 @@ Active arm armv7 sunxi - sunxi Active arm armv7 sunxi - sunxi Cubieboard sun4i:CUBIEBOARD,SPL,AXP209_POWER,SUNXI_EMAC Hans de Goede hdego...@redhat.com Active arm armv7 sunxi - sunxi Cubieboard2 sun7i:CUBIEBOARD2,SPL,SUNXI_GMAC Ian Campbell i...@hellion.org.uk:Hans de Goede hdego...@redhat.com Active arm armv7 sunxi - sunxi Cubieboard2_FEL sun7i:CUBIEBOARD2,SPL_FEL,SUNXI_GMAC Ian Campbell i...@hellion.org.uk:Hans de Goede hdego...@redhat.com -Active arm armv7 sunxi - sunxi Cubietruck sun7i:CUBIETRUCK,SPL,AXP209_POWER,SUNXI_GMAC,RGMII Ian Campbell i...@hellion.org.uk:Hans de Goede hdego...@redhat.com +Active arm armv7 sunxi - sunxi Cubietruck sun7i:CUBIETRUCK,SPL,AXP209_POWER,SUNXI_GMAC,RGMII,USB_EHCI Ian Campbell i...@hellion.org.uk:Hans de Goede hdego...@redhat.com Active arm armv7 sunxi - sunxi Cubietruck_FEL sun7i:CUBIETRUCK,SPL_FEL,AXP209_POWER,SUNXI_GMAC,RGMII Ian Campbell i...@hellion.org.uk:Hans de Goede hdego...@redhat.com Active arm armv7 sunxi - sunxi r7-tv-dongle sun5i:R7DONGLE,SPL,AXP152_POWER Hans de Goede hdego...@redhat.com Active arm armv7 u8500 st-ericsson snowball snowball - Mathieu Poirier mathieu.poir...@linaro.org -- 2.0.0 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v3 4/5] sun7i: add USB EHCI settings
Specific USB EHCI settings to be set for sun7i if CONFIG_USB_EHCI is enabled. Signed-off-by: Roman Byshko rbys...@gmail.com Acked-by: Ian Campbell i...@hellion.org.uk --- include/configs/sun7i.h | 8 1 file changed, 8 insertions(+) diff --git a/include/configs/sun7i.h b/include/configs/sun7i.h index d9be104..0c9bddd 100644 --- a/include/configs/sun7i.h +++ b/include/configs/sun7i.h @@ -17,6 +17,14 @@ #define CONFIG_SYS_PROMPT sun7i# +#ifdef CONFIG_USB_EHCI +#define CONFIG_USB_EHCI_SUNXI + +#define CONFIG_USB_MAX_CONTROLLER_COUNT2 +#define CONFIG_SUNXI_USB_VBUS0_GPIO230 +#define CONFIG_SUNXI_USB_VBUS1_GPIO227 +#endif + /* * Include common sunxi configuration where most the settings are */ -- 2.0.0 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v3 1/5] sunxi: add defines to control USB Host clocks/resets
The commit adds three defines which will be used in
the EHCI driver to enable USB clock and assert
reset controllers of the corresponding PHYs.
Signed-off-by: Roman Byshko rbys...@gmail.com
Acked-by: Ian Campbell i...@hellion.org.uk
---
arch/arm/include/asm/arch-sunxi/clock_sun4i.h | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
index 928f3f2..fe7348a 100644
--- a/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
+++ b/arch/arm/include/asm/arch-sunxi/clock_sun4i.h
@@ -253,4 +253,8 @@ struct sunxi_ccm_reg {
#define CCM_GMAC_CTRL_GPIT_MII (0x0 2)
#define CCM_GMAC_CTRL_GPIT_RGMII (0x1 2)
+#define CCM_USB_CTRL_PHY1_RST (0x1 1)
+#define CCM_USB_CTRL_PHY2_RST (0x1 2)
+#define CCM_USB_CTRL_PHYGATE (0x1 8)
+
#endif /* _SUNXI_CLOCK_SUN4I_H */
--
2.0.0
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH v3 2/5] sunxi: add USB EHCI driver
The Allwinner aka sunxi SoCs have one or more USB host controllers.
This adds a driver for their EHCI.
Signed-off-by: Roman Byshko rbys...@gmail.com
---
drivers/usb/host/Makefile | 1 +
drivers/usb/host/ehci-sunxi.c | 196 ++
2 files changed, 197 insertions(+)
create mode 100644 drivers/usb/host/ehci-sunxi.c
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 04c1a64..c4f5157 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_USB_EHCI_PPC4XX) += ehci-ppc4xx.o
obj-$(CONFIG_USB_EHCI_MARVELL) += ehci-marvell.o
obj-$(CONFIG_USB_EHCI_PCI) += ehci-pci.o
obj-$(CONFIG_USB_EHCI_SPEAR) += ehci-spear.o
+obj-$(CONFIG_USB_EHCI_SUNXI) += ehci-sunxi.o
obj-$(CONFIG_USB_EHCI_TEGRA) += ehci-tegra.o
obj-$(CONFIG_USB_EHCI_VCT) += ehci-vct.o
obj-$(CONFIG_USB_EHCI_RMOBILE) += ehci-rmobile.o
diff --git a/drivers/usb/host/ehci-sunxi.c b/drivers/usb/host/ehci-sunxi.c
new file mode 100644
index 000..dc628ca
--- /dev/null
+++ b/drivers/usb/host/ehci-sunxi.c
@@ -0,0 +1,196 @@
+/*
+ * Copyright (C) 2014 Roman Byshko
+ *
+ * Roman Byshko rbys...@gmail.com
+ *
+ * Based on code from
+ * Allwinner Technology Co., Ltd. www.allwinnertech.com
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#include asm/arch/clock.h
+#include asm/gpio.h
+#include asm/io.h
+#include common.h
+#include ehci.h
+
+#define SUNXI_USB1_IO_BASE 0x01c14000
+#define SUNXI_USB2_IO_BASE 0x01c1c000
+
+#define SUNXI_USB_PMU_IRQ_ENABLE 0x800
+#define SUNXI_USB_CSR 0x01c13404
+#define SUNXI_USB_PASSBY_EN1
+
+#define SUNXI_EHCI_AHB_ICHR8_EN(1 10)
+#define SUNXI_EHCI_AHB_INCR4_BURST_EN (1 9)
+#define SUNXI_EHCI_AHB_INCRX_ALIGN_EN (1 8)
+#define SUNXI_EHCI_ULPI_BYPASS_EN (1 0)
+
+static struct sunxi_ehci_hcd {
+ struct usb_hcd *hcd;
+ int usb_rst_mask;
+ int ahb_clk_mask;
+ int gpio_vbus;
+ void *csr;
+ int irq;
+ int id;
+} sunxi_echi_hcd[] = {
+ {
+ .usb_rst_mask = CCM_USB_CTRL_PHY1_RST,
+ .ahb_clk_mask = 1 AHB_GATE_OFFSET_USB_EHCI0,
+ .gpio_vbus = CONFIG_SUNXI_USB_VBUS0_GPIO,
+ .csr = (void*) SUNXI_USB_CSR,
+ .irq = 39,
+ .id = 1,
+ },
+#if (CONFIG_USB_MAX_CONTROLLER_COUNT 1)
+ {
+ .usb_rst_mask = CCM_USB_CTRL_PHY2_RST,
+ .ahb_clk_mask = 1 AHB_GATE_OFFSET_USB_EHCI1,
+ .gpio_vbus = CONFIG_SUNXI_USB_VBUS1_GPIO,
+ .csr = (void*) SUNXI_USB_CSR,
+ .irq = 40,
+ .id = 2,
+ }
+#endif
+};
+
+static int enabled_hcd_count = 0;
+
+static void* get_io_base(int hcd_id)
+{
+ if (hcd_id == 1)
+ return (void*) SUNXI_USB1_IO_BASE;
+ else if (hcd_id == 2)
+ return (void*) SUNXI_USB2_IO_BASE;
+ else return NULL;
+}
+
+static void usb_phy_write(struct sunxi_ehci_hcd *sunxi_ehci, int addr,
+ int data, int len)
+{
+ int j = 0, usbc_bit = 0;
+ void *dest = sunxi_ehci-csr;
+
+ usbc_bit = 1 (sunxi_ehci-id * 2);
+ for (j = 0; j len; j++) {
+ /* set the bit address to be written */
+ clrbits_le32(dest, 0xff 8);
+ setbits_le32(dest, (addr + j) 8);
+
+ clrbits_le32(dest, usbc_bit);
+ /* set data bit */
+ if (data 0x1)
+ setbits_le32(dest, 1 7);
+ else
+ clrbits_le32(dest, 1 7);
+
+ setbits_le32(dest, usbc_bit);
+
+ clrbits_le32(dest, usbc_bit);
+
+ data = 1;
+ }
+}
+
+static void sunxi_usb_phy_init(struct sunxi_ehci_hcd *sunxi_ehci)
+{
+ /* The following comments are machine
+* translated from Chinese, you have been warned!
+*/
+
+ /* adjust PHY's magnitude and rate */
+ usb_phy_write(sunxi_ehci, 0x20, 0x14, 5);
+
+ /* threshold adjustment disconnect */
+ usb_phy_write(sunxi_ehci, 0x2a, 3, 2);
+
+ return;
+}
+
+static void sunxi_usb_passby(struct sunxi_ehci_hcd *sunxi_ehci, int enable)
+{
+ unsigned long bits = 0;
+ void *addr = get_io_base(sunxi_ehci-id) + SUNXI_USB_PMU_IRQ_ENABLE;
+
+ bits = SUNXI_EHCI_AHB_ICHR8_EN |
+ SUNXI_EHCI_AHB_INCR4_BURST_EN |
+ SUNXI_EHCI_AHB_INCRX_ALIGN_EN |
+ SUNXI_EHCI_ULPI_BYPASS_EN;
+
+ if (enable)
+ setbits_le32(addr, bits);
+ else
+ clrbits_le32(addr, bits);
+
+ return;
+}
+
+static void sunxi_ehci_enable(struct sunxi_ehci_hcd *sunxi_ehci)
+{
+ struct sunxi_ccm_reg *ccm = (struct sunxi_ccm_reg *)SUNXI_CCM_BASE;
+
+ setbits_le32(ccm-usb_clk_cfg, sunxi_ehci-usb_rst_mask);
+ setbits_le32(ccm-ahb_gate0, sunxi_ehci-ahb_clk_mask);
+
+
[linux-sunxi] conflict gpio-sunxi with gt811_ts
hello I am using goodix-gt811 ctp 7 inch and i have not problem to use this module but when i modprobe gpio-sunxi , the interrupt of my ctp disable 1- when gt811_ts is intalled and i modprobe gpio-sunxi ,this message shown on Putty the message is : 6sunxi_gpio driver init ver 1.3 3IRQ handler type mismatch for IRQ 60 3current handler: Goodix-TS [c0015340] (unwind_backtrace+0x0/0x134) from [c0094b80] (__setup_irq+0x3b8/0 x404) [c0094b80] (__setup_irq+0x3b8/0x404) from [c0094d04] (request_threaded_irq+0 xb0/0x138) [c0094d04] (request_threaded_irq+0xb0/0x138) from [bf0d4ca8] (sunxi_gpio_pro be+0x3e4/0x490 [gpio_sunxi]) [bf0d4ca8] (sunxi_gpio_probe+0x3e4/0x490 [gpio_sunxi]) from [c04bba50] (driv er_probe_device+0xb4/0x354) [c04bba50] (driver_probe_device+0xb4/0x354) from [c04bbdc0] (__driver_attach +0x8c/0x90) [c04bbdc0] (__driver_attach+0x8c/0x90) from [c04b9dd0] (bus_for_each_dev+0x6 0/0x94) [c04b9dd0] (bus_for_each_dev+0x60/0x94) from [c04bb000] (bus_add_driver+0xd0 /0x28c) [c04bb000] (bus_add_driver+0xd0/0x28c) from [c04bc394] (driver_register+0x78 /0x13c) [c04bc394] (driver_register+0x78/0x13c) from [c00086c0] (do_one_initcall+0x1 1c/0x174) [c00086c0] (do_one_initcall+0x11c/0x174) from [c008244c] (sys_init_module+0x 78/0x19c) [c008244c] (sys_init_module+0x78/0x19c) from [c000ec00] (ret_fast_syscall+0x 0/0x30) 3Can't request irq 60 4gpio-sunxi: probe of gpio-sunxi failed with error -16 2- when gpio-sunxi is intalled and i modprobe gt811_ts,this message shown on Putty the message is : ===goodix_ts_init= ctp_fetch_sysconfig_para. ctp_fetch_sysconfig_para: after: ctp_twi_addr is 0x5d, dirty_addr_buf: 0x5d. dirty_addr_buf[1]: 0xfffe ctp_fetch_sysconfig_para: ctp_twi_id is 1. 6ctp_fetch_sysconfig_para: screen_max_x = 800. 6ctp_fetch_sysconfig_para: screen_max_y = 480. 6ctp_fetch_sysconfig_para: revert_x_flag = 0. 6ctp_fetch_sysconfig_para: revert_y_flag = 0. 6ctp_fetch_sysconfig_para: exchange_x_y_flag = 0. goodix_ts_init: after fetch_sysconfig_para: normal_i2c: 0x5d. normal_i2c[1]: 0xfffe 4i2c-core: driver [Goodix-TS] using legacy suspend method 4i2c-core: driver [Goodix-TS] using legacy resume method incomplete xfer (0x48) 6ctp_detect: Detected chip Goodix-TS at adapter 1, address 0x5d 6Goodix-TS 1-005d: Install gt811 driver. 6Goodix-TS 1-005d: Driver Release Date:2012-02-08 ==goodix_gt811 probe== ctp_set_irq_mode: config gpio to int mode. 6ctp_set_irq_mode, 231: gpio_int_info, port = 8, port_num = 15. INTERRUPT CONFIG 6Goodix-TS 1-005d: GT811 init info:X_MAX=4096,Y_MAX=4096,TRIG_MODE=RISING EDGE 6input: gt80x as /devices/virtual/input/input4 3IRQ handler type mismatch for IRQ 60 3current handler: sunxi-gpio [c0015340] (unwind_backtrace+0x0/0x134) from [c0094b80] (__setup_irq+0x3b8/0x404) [c0094b80] (__setup_irq+0x3b8/0x404) from [c0094d04] (request_threaded_irq+0xb0/0x138) [c0094d04] (request_threaded_irq+0xb0/0x138) from [bf0e1388] (goodix_ts_probe+0x480/0x794 [gt811_ts]) [bf0e1388] (goodix_ts_probe+0x480/0x794 [gt811_ts]) from [c05714dc] (i2c_device_probe+0xb8/0x118) [c05714dc] (i2c_device_probe+0xb8/0x118) from [c04bba50] (driver_probe_device+0xb4/0x354) [c04bba50] (driver_probe_device+0xb4/0x354) from [c04b9e70] (bus_for_each_drv+0x58/0x8c) [c04b9e70] (bus_for_each_drv+0x58/0x8c) from [c04bb930] (device_attach+0x90/0xa4) [c04bb930] (device_attach+0x90/0xa4) from [c04badd4] (bus_probe_device+0x84/0xa8) [c04badd4] (bus_probe_device+0x84/0xa8) from [c04b9454] (device_add+0x520/0x60c) [c04b9454] (device_add+0x520/0x60c) from [c0571824] (i2c_new_device+0x128/0x1c0) [c0571824] (i2c_new_device+0x128/0x1c0) from [c0572d40] (i2c_do_add_adapter+0x1ac/0x254) [c0572d40] (i2c_do_add_adapter+0x1ac/0x254) from [c04b9dd0] (bus_for_each_dev+0x60/0x94) [c04b9dd0] (bus_for_each_dev+0x60/0x94) from [c05722fc] (i2c_for_each_dev+0x34/0x48) [c05722fc] (i2c_for_each_dev+0x34/0x48) from [c0573654] (i2c_register_driver+0x84/0xe8) [c0573654] (i2c_register_driver+0x84/0xe8) from [c00086c0] (do_one_initcall+0x11c/0x174) [c00086c0] (do_one_initcall+0x11c/0x174) from [c008244c] (sys_init_module+0x78/0x19c) [c008244c] (sys_init_module+0x78/0x19c) from [c000ec00] (ret_fast_syscall+0x0/0x30) 3Goodix-TS 1-005d: Cannot allocate ts INT!ERRNO:-16 this messages shows both of them use IRQ 60 how can i resolve this problem thanks for your help -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to
[linux-sunxi] Re: [PATCH v11 0/2] Add support for the Allwinner A31 DMA Controller
On Thu, 24 Jul 2014 14:13:15 +0200 Maxime Ripard maxime.rip...@free-electrons.com wrote: On Thu, Jul 17, 2014 at 09:46:14PM +0200, Maxime Ripard wrote: Hi, This patchset adds support for the DMA controller found in the Allwinner A31 and A23 SoCs. This has been tested using the newly introduced SPI driver on an A31 EVK. Support for DMA-driven SPI transfers will be the subject of another patch serie. This has been around for around 5 monthes now, and didn't get any review but nitpicks for three versions, so I feel like it could be merged quite quickly. Ok, so, who should I bribe to get this merged? Turns out I'm easily bribed. The code looks pretty clean and simple and is refreshingly free of comments, which only confuse people anyway. I think we could do this as a single patch - is there any benefit to splitting it apart like this? The combinations of spin_lock()/spin_lock_irq() and spin_lock_irqsave() are a bit scary - it's easy to get these optimisations wrong. Has it been thoroughly tested with lockdep enabled? -- You received this message because you are subscribed 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: [U-Boot] [PATCH 2/2] sunxi: Set the AUXCR L2EN bit for sun4i/sun5i in FEL boot mode
On Mon, 21 Jul 2014 21:59:51 +0100 Ian Campbell i...@hellion.org.uk wrote: On Mon, 2014-07-21 at 22:39 +0200, Jeroen Hofstee wrote: Hello Ian, On 21-07-14 22:07, Ian Campbell wrote: On Fri, 2014-07-18 at 20:47 +0200, Jeroen Hofstee wrote: Hello Siarhei, On 18-07-14 19:09, Siarhei Siamashka wrote: This is needed to have feature parity with the normal boot mode, where the L2EN bit in the CP15 Auxiliary Control Register is set by the BROM code right from the start. If this is not done, the Linux system ends up booted with the L2 cache disabled. I don't know a single about the sunxi, but shouldn't linux be patched instead. The commit message seems to indicate it is not an u-boot issue. The ACTLR may not be writeable from NS mode so it has to be setup in the bootloader before dropping to NS mode. mmm, I guess there is something wrong with the boot sequence if the kernel itself can't access raw hw. Do you know what ARM Secure and Non-Secure worlds are? The kernel expects to be launched in NS mode and simply cannot access this register. This is a feature not a bug. Just curious. Is there a modern consensus about how this all is supposed to be done nowadays? The last time I read anything about this subject was the following longish and already old discussion thread (which has probably already lost relevance): http://lists.linaro.org/pipermail/boot-architecture/2011-August/60.html Since the Allwinner BROM does not forcefully drop us to the non-secure mode, we have the absolute freedom of choice and may implement any policy. -- 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.
[linux-sunxi] Re: [PATCH 1/2] sunxi: Use Thumb2 and move stack to gain more SRAM space in FEL mode
On Fri, 18 Jul 2014 20:09:44 +0300
Siarhei Siamashka siarhei.siamas...@gmail.com wrote:
The Allwinner SoCs support a special FEL boot mode, which can be activated
by users via a button press (or other means). In the FEL mode, the BROM
implements a custom FEL protocol over USB, which allows to upload code to
the device and run it. This protocol had been reverse engineered and
documented by Henrik Nordström:
http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-June/004341.html
Because the BROM code is using some parts of the SRAM for itself, only a
few areas are available for use in u-boot. Currently the SPL is loaded
into the 0x2000-0x5cff Free for program use area and the stack pointer
is at the end of this area. This is barely enough to fit just the current
SPL and leaves almost no headroom for the future code.
This patch enables the use of a more compact Thumb2 mode for compiling the
FEL SPL binary. And also relocates the stack to another 0x8000-0xbfff Free
for program use area.
Self review.
Maybe instead of adding the stack relocation hacks, a better idea
would be to just change the usb-boot script to load the SPL to 0x8000
address instead of 0x2000? The relevant usb-boot code is here:
https://github.com/linux-sunxi/sunxi-tools/blob/e2a3f16e36f6/usb-boot#L73
In this case the stack would remain in the 0x2000-0x5cff area, and the
code/data would use 0x8000-0xbfff. However backwards compatibility with
the existing sunxi-tools becomes an issue. Does anyone have any opinion?
Additionally, the BSS segment is cleared.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
---
arch/arm/cpu/armv7/sunxi/Makefile | 1 +
arch/arm/cpu/armv7/sunxi/start_fel.S| 42
+
arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds | 4 +--
include/configs/sunxi-common.h | 2 --
4 files changed, 45 insertions(+), 4 deletions(-)
create mode 100644 arch/arm/cpu/armv7/sunxi/start_fel.S
diff --git a/arch/arm/cpu/armv7/sunxi/Makefile
b/arch/arm/cpu/armv7/sunxi/Makefile
index a64bfa1..b3eff98 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -21,5 +21,6 @@ ifdef CONFIG_SPL_BUILD
obj-$(CONFIG_SUN7I) += dram.o
ifdef CONFIG_SPL_FEL
obj-y+= start.o
+extra-y += start_fel.o
endif
endif
diff --git a/arch/arm/cpu/armv7/sunxi/start_fel.S
b/arch/arm/cpu/armv7/sunxi/start_fel.S
new file mode 100644
index 000..2789fd9
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/start_fel.S
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2014 Siarhei Siamashka siarhei.siamas...@gmail.com
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+.syntax unified
+.text
+.arm
+.arch armv7a
+.p2align 2
+
+.globl _start_fel
+.globl s_init
+.globl __bss_start
+.globl __bss_end
+
+_start_fel:
+ /* Relocate stack to the 0x8000-0xBFFF area */
+ mov r0, #0xC000
+ str sp, [r0, #-4]!
+ str lr, [r0, #-4]!
+ adr lr, _exit_fel /* Return back to '_exit_fel' */
+ mov sp, r0
+
+ /* Erase the BSS segment */
+ ldr r0, =__bss_start
+ ldr r1, =__bss_end
+ mov r2, #0
+0: cmp r0, r1
+ strbne r2, [r0], #1
+ bne 0b
+
+ /* Pass control to the 's_init()' function */
+ b s_init
+
+_exit_fel:
+ /* Relocate stack back and return */
+ mov r0, #0xC000
+ ldr sp, [r0, #-4]!
+ ldr lr, [r0, #-4]!
+ bx lr
diff --git a/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
index 364e35c..418c2fc 100644
--- a/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
+++ b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
@@ -6,7 +6,7 @@
*/
OUTPUT_FORMAT(elf32-littlearm, elf32-littlearm, elf32-littlearm)
OUTPUT_ARCH(arm)
-ENTRY(s_init)
+ENTRY(_start_fel)
SECTIONS
{
. = 0x2000;
@@ -14,7 +14,7 @@ SECTIONS
. = ALIGN(4);
.text :
{
- *(.text.s_init)
+ arch/arm/cpu/armv7/sunxi/start_fel.o(.text)
*(.text*)
}
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 5d72d62..4b980e9 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -18,10 +18,8 @@
*/
#define CONFIG_SUNXI /* sunxi family */
#ifdef CONFIG_SPL_BUILD
-#ifndef CONFIG_SPL_FEL
#define CONFIG_SYS_THUMB_BUILD /* Thumbs mode to save space in SPL */
#endif
-#endif
#include asm/arch/cpu.h/* get chip and board defs */
--
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.
[linux-sunxi] Re: [PATCH 04/14] sunxi: dram: Code cleanup and comments for the CKE delay handling
On Mon, 21 Jul 2014 19:51:50 +0100
Ian Campbell i...@hellion.org.uk wrote:
On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote:
Before driving the CKE pin (Clock Enable) high, the DDR3 spec requires
to wait for additional 500 us after the RESET pin is de-asserted.
The DRAM controller takes care of this delay by itself, using a
configurable counter in the SDR_IDCR register. This works in the same
way on sun4i/sun5i/sun7i hardware (even the default register value
0x00c80064 is identical). Except that the counter is ticking a bit
slower on sun7i (3 DRAM clock cycles instead of 2), resulting in
longer actual delays for the same settings.
This patch keeps the old code and only removes the CONFIG_SUN7I ifdef.
But maybe we should drop all of this and just add 'udelay(500)' after
the DDR3 reset without bothering to play with these undocumented
registers.
I'm happy to go with whichever you think is better.
If the total DRAM initialization time in u-boot is not really critical
(all the delays are only fractions of millisecond), then I would
probably go with the cargo cult approach and actually apply the
delays in both places ('udelay(500)' after the DDR3 reset and keep
the maximum delay in the SDR_IDCR register too).
I just feel uneasy about using only the SDR_IDCR approach, because it
implies the 524MHz DRAM clock speed limit for sun4i/sun5i hardware if
we don't want to violate the DDR3 requirements. And we would prefer to
have at least the 528MHz clock speed option (the Allwinner A13 manual
says that 533MHz is the DRAM clock limit for it).
The changes in the SDR_IDCR delay counter on sun7i hardware (which
permit longer delays) are very interesting. It might be a hint that
the DRAM controller in sun7i had been originally intended to support
higher clock speeds than its predecessors. However the Allwinner A20
manual only advertises the 400MHz DRAM clock. It might be that the
Allwinner engineers could not figure out how to configure the DRAM
parameters to reach really high clock speeds and decided to be modest
about this. However that's just a speculation on my side.
Anyway, if anybody has a logic analyzer (the hardware companies like
Olimex and CubieTech?), then checking and confirming the timings
between the signals on the CKE and RESET pins during the DRAM
initialization would be very interesting to confirm that everything
is alright.
Another interesting observation is that the u-boot-sunxi code (derived
from the Allwinner boot0) did not configure the SDR_IDCR register
for sun4i/sun5i, but performed the DDR3 reset very early. Possibly
resulting in a sufficient time gap between the DDR3 reset and the DDR3
initialization steps.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
Acked-by: Ian Campbell i...@hellion.org.uk
Thanks.
--
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.
[linux-sunxi] Re: [PATCH 06/14] sunxi: dram: Configurable MBUS clock speed (use PLL5 or PLL6)
On Mon, 21 Jul 2014 20:31:30 +0100
Ian Campbell i...@hellion.org.uk wrote:
On Fri, 2014-07-18 at 19:22 +0300, Siarhei Siamashka wrote:
The sun5i hardware (Allwinner A13) introduced configurable MBUS clock speed.
Allwinner A13 uses only 16-bit data bus width to connect the external DRAM,
which is halved compared to the 32-bit data bus of sun4i (Allwinner A10), so
it does not make much sense to clock a wider internal bus at a very high
speed.
The Allwinner A13 manual specifies 300 MHz MBUS clock speed limit and 533
MHz
DRAM clock speed limit. Newer sun7i hardware (Allwinner A20) has a full
width
32-bit external memory interface again, but still keeps the MBUS clock speed
configurable. Clocking MBUS too low inhibits memory performance and one has
to find the optimal MBUS/DRAM clock speed ratio, which may depend on many
factors.
This patch introduces a new 'mbus_clock' parameter for the 'dram_para'
struct
and uses it as a desired MBUS clock speed target. If 'mbus_clock' is not
set,
300 MHz is used by default to match the older hardcoded settings.
Nothing in this series seems to set it for any board -- is that
expected?
Yes. Not touching the board config files avoids any extra dependencies
and merging conflicts. I could explicitly add .mbus_clock = 300 to
the Cubietruck 'dram_para' struct, but this is the default MBUS value
anyway and makes no real difference.
If we wanted to set something other than 300MHz, there are too many
possible options to select from:
http://linux-sunxi.org/A10_DRAM_Controller_Performance
+ if (pll6x_div = 16 pll6x_clk / pll6x_div pll5p_clk / pll5p_div) {
Some brackets or perhaps some temporaries ({pll5p,pll6x}_rate ?) might
help clarity/readability here.
With the brackets we would exceed the 80 characters line limit. This
leaves us with the only choice. I'll add the temporaries.
When pll6 is viable you prefer the faster clock, even if it might happen
to be further from the requested clock, is that right? Or does all the
arithmetic end up with that never being the case?
The 'pll5p_rate' and 'pll6x_rate' values are always equal to or less
than the requested 'mbus_clock'. Selecting the larger of these two will
make it closer to the requested clock.
--
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.
Re: [linux-sunxi] Re: [PATCH 1/2] sunxi: Use Thumb2 and move stack to gain more SRAM space in FEL mode
Hi, On Fri, Jul 25, 2014 at 11:03 AM, Julian Calaby julian.cal...@gmail.com wrote: Hi, On Fri, Jul 25, 2014 at 11:01 AM, Siarhei Siamashka siarhei.siamas...@gmail.com wrote: On Mon, 21 Jul 2014 19:31:45 +0100 Ian Campbell i...@hellion.org.uk wrote: On Fri, 2014-07-18 at 20:09 +0300, Siarhei Siamashka wrote: http://lists.phcomp.co.uk/pipermail/arm-netbook/2012-June/004341.html I think a better reference is https://github.com/hno/Allwinner-Info/blob/master/FEL-usb/USB-protocol.txt Yes, very likely. Except that I'm a little bit concerned about the long term availability of this link (which is a personal repository on github). Stupid question: why isn't this on the wiki? Stupider question: why not add it myself? It's now on the linux-sunxi wiki at: http://linux-sunxi.org/FEL/Protocol Thanks, -- Julian Calaby Email: julian.cal...@gmail.com Profile: http://www.google.com/profiles/julian.calaby/ .Plan: http://sites.google.com/site/juliancalaby/ -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: [PATCH 09/14] sunxi: dram: Add a helper function 'mctl_get_number_of_lanes'
On Mon, 21 Jul 2014 20:41:33 +0100
Ian Campbell i...@hellion.org.uk wrote:
On Fri, 2014-07-18 at 19:23 +0300, Siarhei Siamashka wrote:
It is going to be useful in more than one place.
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
---
arch/arm/cpu/armv7/sunxi/dram.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/sunxi/dram.c
b/arch/arm/cpu/armv7/sunxi/dram.c
index 18a5c3b..49d1770 100644
--- a/arch/arm/cpu/armv7/sunxi/dram.c
+++ b/arch/arm/cpu/armv7/sunxi/dram.c
@@ -115,23 +115,31 @@ static void mctl_enable_dll0(u32 phase)
udelay(22);
}
+/* Get the number of DDR byte lanes */
+static u32 mctl_get_number_of_lanes(void)
+{
+ struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
+ switch (readl(dram-dcr) DRAM_DCR_BUS_WIDTH_MASK) {
+ case DRAM_DCR_BUS_WIDTH(DRAM_DCR_BUS_WIDTH_32BIT):
+ return 4;
+ case DRAM_DCR_BUS_WIDTH(DRAM_DCR_BUS_WIDTH_16BIT):
+ return 2;
+ default:
+ return 1;
+ }
+}
+
/*
* Note: This differs from pm/standby in that it checks the bus width
*/
static void mctl_enable_dllx(u32 phase)
{
struct sunxi_dram_reg *dram = (struct sunxi_dram_reg *)SUNXI_DRAMC_BASE;
- u32 i, n, bus_width;
-
- bus_width = readl(dram-dcr);
+ u32 i, number_of_lanes;
- if ((bus_width DRAM_DCR_BUS_WIDTH_MASK) ==
- DRAM_DCR_BUS_WIDTH(DRAM_DCR_BUS_WIDTH_32BIT))
- n = DRAM_DCR_NR_DLLCR_32BIT;
- else
- n = DRAM_DCR_NR_DLLCR_16BIT;
Either DRAM_DCR_NR_DLLCR_??BIT are obsolete now and should be removed or
they should be be adjusted and used in the new function.
ISTM they don't add much so removing would be fine by me.
Agreed, I also think that they are better to be dropped.
+ number_of_lanes = mctl_get_number_of_lanes();
There is a subtle functional change here since number_of_lanes can be 1
whereas n could never have been 2. Is that intended/ok? Please mention
in the commit message.
I tried to experiment with setting the 8-bit bus width and it is
semi-workable (single byte access is OK, but accessing more than
one byte is broken). This part of the patch looks like a forgotten
leftover of these experiments. But it clearly has no practical
value and we only normally deal with the 16-bit or 32-bit bus width.
The most correct way of handling this unexpected code branch would
be to panic. But that's an unnecessarily increase of the code size.
So I think that the best solution is just to keep the old code
logic (expect only 16-bit or 32-bit bus width and 2 or 4 lanes).
--
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.
[linux-sunxi] Re: [PATCH 12/14] sunxi: dram: Drop DDR2 support and assume only single rank DDR3 memory
On Mon, 21 Jul 2014 20:51:12 +0100 Ian Campbell i...@hellion.org.uk wrote: On Fri, 2014-07-18 at 19:23 +0300, Siarhei Siamashka wrote: All the known Allwinner A10/A13/A20 devices are using just single rank DDR3 memory. So don't pretend that we support DDR2 or more than one rank, because nobody could ever test these configurations for real and they are likely broken. Support for these features can be added back in the case if such hardware actually exists. + if (para-type != DRAM_MEMORY_TYPE_DDR3 || para-rank_num != 1) + return 0; Can we not go further and remove these fields from the para struct too? Right now the DRAM patchset keeps backwards compatibility with the old 'dram_para' settings. This is intended to ensure that it is a drop-in replacement for the old code and make the transition easier. The fields can be removed at any time later as a cosmetic fix. -- 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.
