[linux-sunxi] sunxi-nfc-mtd modules to access to boot0 partition.
Hi from yuq git
https://github.com/yuq/sunxi-nfc-mtd
i downloaded sunxi-nfc-mtd source code.
i compiled as a module by doing some changes according to my kernel.
once i insert my module , i am getting kernel panic error.
Here i am attaching the log.
i am using A20 board with kernel 3.4.
you help will be greatly appreciable.
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.
audiodump.wav dev homemedia run srv user
binemplayer lib proc sbin sys usr
boot etc lost+found root selinux tmp var
root@localhost:/# modprobe sunxi_nanf
FATAL: Module sunxi_nanf not found.
root@localhost:/# modprobe sunxi_nand
6[MTD][NAND][SUNXI]: nand driver, init.
6[MTD][NAND][SUNXI]: nand driver, ok.
6[MTD][NAND][SUNXI]: hardware ECC is on
6[MTD][NAND][SUNXI]: use flash bad block table
6[MTD][NAND][SUNXI]: random read/write is off
6[MTD][NAND][SUNXI]: cmu_clk is 480
6[MTD][NAND][SUNXI]: nand clk init end
6[MTD][NAND][SUNXI]: offset 0xc: 0x202e95e
6[MTD][NAND][SUNXI]: offset 0x14: 0x820b
6[MTD][NAND][SUNXI]: get nand pio ok
6nand: device found, Manufacturer ID: 0xad, Chip ID: 0xd7
6nand: Hynix NAND 4GiB 3,3V 8-bit
6nand: 4096MiB, MLC, page size: 8192, OOB size: 640
6[MTD][NAND][SUNXI]: nand chip id: 0 0 0 0 0 0 0 0
6[MTD][NAND][SUNXI]: cmu_clk is 480
6[MTD][NAND][SUNXI]: nand clk init end
6[MTD][NAND][SUNXI]: offset 0xc: 0x202e95e
6[MTD][NAND][SUNXI]: offset 0x14: 0x820f
6[MTD][NAND][SUNXI]: set final clock freq to 15MHz
6[MTD][NAND][SUNXI]: flash chip bus width 8
6[MTD][NAND][SUNXI]: OOB size = 640 page size = 8192 block size = 2097152
total size = 4294967296
4nand: 8192 byte HW ECC not possible on 8192 byte page size, fallback to SW
ECC
1Unable to handle kernel paging request at virtual address 3f10ba60
[ 28.832151] Unable to handle kernel paging request at virtual address
3f10ba60
1pgd = eeb3
[ 28.854414] pgd = eeb3
1[3f10ba60] *pgd=[ 28.859488] [3f10ba60] *pgd=
0Internal error: Oops: 805 [#1] PREEMPT SMP ARM
[ 28.877575] Internal error: Oops: 805 [#1] PREEMPT SMP ARM
dModules linked in:[ 28.884898] Modules linked in: sunxi_nand(O+)
sunxi_nand(O+) nand nand nand_ids nand_ids nand_hynix nand_hynix mtd mtd h
CPU: 0Tainted: G O (3.4.61+ #65)
[ 28.907971] CPU: 0Tainted: G O (3.4.61+ #65)
PC is at dma_nand_config_start+0xa8/0x104 [sunxi_nand]
[ 28.918460] PC is at dma_nand_config_start+0xa8/0x104 [sunxi_nand]
LR is at 0x7f077f07
[ 28.926481] LR is at 0x7f077f07
pc : [bf109b34]lr : [7f077f07]psr: 200f0013
sp : ee6b7b48 ip : fp : f1c03000
[ 28.938487] pc : [bf109b34]lr : [7f077f07]psr: 200f0013
[ 28.938500] sp : ee6b7b48 ip : fp : f1c03000
r10: 0001 r9 : r8 : 0008
[ 28.953894] r10: 0001 r9 : r8 : 0008
r7 : edd98000 r6 : 2000 r5 : bf10f6b8 r4 : fff0
[ 28.964338] r7 : edd98000 r6 : 2000 r5 : bf10f6b8 r4 : fff0
r3 : 3f10ba48 r2 : 0002 r1 : ee6b7b4c r0 : fff0
[ 28.976084] r3 : 3f10ba48 r2 : 0002 r1 : ee6b7b4c r0 : fff0
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 28.988439] Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 6eb3006a DAC: 0015
[ 29.15] Control: 10c5387d Table: 6eb3006a DAC: 0015
SP: 0xee6b7ac8:
[ 29.007424]
[ 29.007430] SP: 0xee6b7ac8:
7ac8 [ 29.012156] 7ac8 10624dd3 10624dd3 9a6e09bd 9a6e09bd
0003 0003 000f 000f 0006 0006 3b9aca00 0
7ae8 [ 29.027424] 7ae8 c088a027 c088a027 bf109b34 bf109b34 200f0013 200f0013
ee6b7b34 ee6b7b34 c000e5d8 c000e5d8 fff0 c
7b08 [ 29.042690] 7b08 0002 0002 3f10ba48 3f10ba48 fff0 fff0
bf10f6b8 bf10f6b8 2000 2000 edd98000 edd98000 0008 0
7b28 [ 29.057954] 7b28 0001 0001 f1c03000 f1c03000
ee6b7b48 ee6b7b48 7f077f07 7f077f07 bf109b34 bf109b34 200f0013 f
7b48 [ 29.073220] 7b48 05230002 05230002 0201 0201
01c03030 01c03030 7f077f07 7f077f07 0041 0
7b68 [ 29.088485] 7b68 bf10ce90 bf10ce90 ee8ac000 ee8ac000 850c 850c
bf107914 bf107914 000284d0 000284d0 c0823dc0 c0823dc0 c
7b88 [ 29.103752] 7b88 0007ff00 0007ff00
ee8ac000 ee8ac000 ee8ac250 0
7ba8 [ 29.119018] 7ba8 ee6b7c38 ee6b7c38 0007ff00 0007ff00
05d0 05d0 bf0f61f4 bf0f61f4 0001 0
FP: 0xf1c02f80:
[ 29.135499]
[ 29.135505] FP: 0xf1c02f80:
2f80 [ 29.140231] 2f80
Re: [linux-sunxi] [PATCH u-boot (sc)] Cleanups of various clock macro's
On Thu, 2014-03-27 at 23:42 +0100, Olliver Schinagl wrote: On 03/27/2014 10:06 PM, Ian Campbell wrote: On Tue, 2014-03-25 at 11:00 +0100, oliver+l...@schinagl.nl wrote: From: Olliver Schinagl oli...@schinagl.nl This patch cleans up several macro's to remove magic values etc from clock.c and clock.h. Casualties being dragged in are some macro's from dram.c and the i2c driver. This addresses (some of) Marek's review on the upstreaming series, is that right? Yes, but this is just some of the stuff i had done for some early sunxi review. I since have cleaned it up better, changed it a little; and with you workflow explanation, have to redo it. On top of that, i have to split it out in seperate patches *yay* I will work on that the next few days; but you now know what i'm doing, and I know how to test it :) Thanks! so just diff the output of objdump -d is what you do? I should be able to do that. For straight replace a number with a #define this diffing is what I would do. Unfortunately I suspect that the sr32-clrsetbits transformation will result in too much change in the generated code (a function call turns into some inline bit fiddling) to allow useful diffing of the resulting binary. I think for that patch you'll just have to do a runtime test. Good reason to split all the trivial replacements into separate patches though ;-) Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH] Add Full Duplex support to SPI (v2)
понедельник, 17 февраля 2014 г., 23:40:53 UTC+2 пользователь Marco Montesissa написал: HI Darius, I have a modified version which works in half-duplex mode by modifing just the userspace. If you need any piece of code i can share it. Cheers Marco. 2014-02-17 21:27 GMT+01:00 darius...@gmail.com: If you are interested I can send some working code for nrf24l01. I just mixed all information above with my previous problems with SPI and i have got a nrf24l01 connected to CB successfully communicating with RPi through the same library. Unfortunately, it needs some changes in kernel GPIO module too. See a working example: http://www.pl.image-share.com/upload/260/31.png Hi! I have working spi on cubietruck and bunch of nRF24l01 transceivers. I'm the one who's interested in your code =) -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] [RFC PATCH u-boot 0/2] Try to improve sunxi DRAM setup code
On Fri, 28 Mar 2014 13:29:17 +0100 Olliver Schinagl oli...@schinagl.nl wrote: On 03/28/2014 11:42 AM, Siarhei Siamashka wrote: I understand that setting up binary drivers and then running some 3D accelerated applications while checking for memory corruption bugs at the same time is not something that many people would enjoy (or even try in the first place). And I had plans to try to simplify the test setup since a long time ago. Finally here it is: https://github.com/ssvb/lima-memtester Basically, that's just a single static binary with no dependencies. It combines a memtester tool with a simple spinning textured cube demo from the work-in-progress free open source Mali400 driver project http://limadriver.org/ That's amazing, we should prep a rootfs with all of that in it maybe too? setting up lima + mali + god knows what may be a bit too much for some right now, so having a pre-defined test rootfs might proove usefull... Nah :) The whole point of doing this exercise was exactly that now: 1. The only runtime dependency of this lima-memtester tool is just a linux kernel with a mali kernel module. The users of linux-sunxi defconfigs already have it enabled. Even if some users have disabled mali support in their kernels, they are expected to have enough skills to enable it back. 2. The only build dependency is just a GCC compiler. And lazy or inexperienced users can even skip this step and download a static binary. The choice of rootfs or distro should not matter at all. Just like with a10-meminfo-static, you run this program and it gets the job done without extra efforts and time consuming preparations. The users get a basic smoke test for the 3D hardware (even if they don't give rats about 3D support in general). And in the case if the test fails, they will know that the dram clock/timings are likely not good for their hardware. By the way, this does not bring anything new to the table with regard to mali400 gpu support. I'm using almost a year old public limadriver snapshot. The only purpose for it here is to make mali400 hardware do memory reads and writes for extra pressure on the memory controller. -- 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 v3 04/10] input: misc: Add driver for AXP20x Power Enable Key
On Fri, Mar 28, 2014 at 12:38:03AM -0700, Dmitry Torokhov wrote:
Hi Carlo,
Hi Dmitry,
On Thu, Mar 27, 2014 at 10:29:18PM +0100, Carlo Caione wrote:
[...]
+#include linux/errno.h
+#include linux/irq.h
+#include linux/init.h
+#include linux/input.h
+#include linux/interrupt.h
+#include linux/kernel.h
+#include linux/mfd/axp20x.h
+#include linux/module.h
+#include linux/platform_device.h
+#include linux/regmap.h
+#include linux/slab.h
+
+#define AXP20X_PEK_STARTUP_MASK(0xc0)
+#define AXP20X_PEK_SHUTDOWN_MASK (0x03)
+
+static const char const *startup_time[] = { 128ms, 3s , 1s, 2s };
+static const char const *shutdown_time[] = { 4s, 6s , 8s, 10s };
Why not have everything expressed in milliseconds and have sysfs
attribute apply the closest one possible?
Yep, I agree that could be nice. Fix in v3.
By the way, do you want to plumb these through device tree as well?
Hum, not sure about that. AFAIK device tree is used for hardware
description whereas these are configuration parameters. Moreover you
would have these parameters saved through reboots.
+
+struct axp20x_pek {
+ struct axp20x_dev *axp20x;
+ struct input_dev *input;
+ int irq_dbr;
+ int irq_dbf;
+};
+
+struct axp20x_pek_ext_attr {
+ const char const **str;
+ unsigned int mask;
+};
+
+static struct axp20x_pek_ext_attr axp20x_pek_startup_ext_attr = {
+ .str= startup_time,
+ .mask = AXP20X_PEK_STARTUP_MASK,
+};
+
+static struct axp20x_pek_ext_attr axp20x_pek_shutdown_ext_attr = {
+ .str= shutdown_time,
+ .mask = AXP20X_PEK_SHUTDOWN_MASK,
+};
+
+static struct axp20x_pek_ext_attr *get_axp_ext_attr(struct
device_attribute *attr)
+{
+ return container_of(attr, struct dev_ext_attribute, attr)-var;
+}
+
+static ssize_t axp20x_show_ext_attr(struct device *dev, struct
device_attribute *attr,
+char *buf)
+{
+ struct axp20x_pek *axp20x_pek = dev_get_drvdata(dev);
+ struct axp20x_pek_ext_attr *axp20x_ea = get_axp_ext_attr(attr);
+ unsigned int val;
+ int ret, i;
+ int cnt = 0;
+
+ ret = regmap_read(axp20x_pek-axp20x-regmap, AXP20X_PEK_KEY, val);
+ if (ret != 0)
+ return ret;
+
+ val = axp20x_ea-mask;
+ val = ffs(axp20x_ea-mask) - 1;
+
+ for (i = 0; i 4; i++) {
+ if (val == i)
+ cnt += sprintf(buf + cnt, [%s] , axp20x_ea-str[i]);
+ else
+ cnt += sprintf(buf + cnt, %s , axp20x_ea-str[i]);
Please just return the current value; why do we need pretty-printing?
It was done to have the possibility to look at the accepted values. With
the modification you suggested before this is not necessary anymore.
I'll change it.
+ }
+
+ cnt += sprintf(buf + cnt, \n);
+
+ return cnt;
+}
+
+static ssize_t axp20x_store_ext_attr(struct device *dev, struct
device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct axp20x_pek *axp20x_pek = dev_get_drvdata(dev);
+ struct axp20x_pek_ext_attr *axp20x_ea = get_axp_ext_attr(attr);
+ char val_str[20];
+ int ret, i;
+ size_t len;
+
+ val_str[sizeof(val_str) - 1] = '\0';
+ strncpy(val_str, buf, sizeof(val_str) - 1);
+ len = strlen(val_str);
+
+ if (len val_str[len - 1] == '\n')
+ val_str[len - 1] = '\0';
+
+ for (i = 0; i 4; i++) {
+ if (!strcmp(val_str, axp20x_ea-str[i])) {
+
+ i = ffs(axp20x_ea-mask) - 1;
+ ret = regmap_update_bits(axp20x_pek-axp20x-regmap,
+AXP20X_PEK_KEY,
+axp20x_ea-mask, i);
+ if (ret != 0)
+ return -EINVAL;
+ return count;
+ }
+ }
+
+ return -EINVAL;
+}
+
+static struct dev_ext_attribute axp20x_dev_attr_startup = {
+ .attr = __ATTR(startup, 0644, axp20x_show_ext_attr,
axp20x_store_ext_attr),
+ .var= axp20x_pek_startup_ext_attr
+};
+
+static struct dev_ext_attribute axp20x_dev_attr_shutdown = {
+ __ATTR(shutdown, 0644, axp20x_show_ext_attr, axp20x_store_ext_attr),
+ axp20x_pek_shutdown_ext_attr
+};
+
+static struct attribute *dev_attrs[] = {
+ axp20x_dev_attr_startup.attr.attr,
+ axp20x_dev_attr_shutdown.attr.attr,
+ NULL,
+};
+
+static struct attribute_group dev_attr_group = {
+ .attrs = dev_attrs,
+};
+
+static const struct attribute_group *dev_attr_groups[] = {
+ dev_attr_group,
+ NULL,
+};
+
+static irqreturn_t axp20x_pek_irq(int irq, void *pwr)
+{
+ struct input_dev *idev = pwr;
+ struct axp20x_pek *axp20x_pek = input_get_drvdata(idev);
+
+ if (irq == axp20x_pek-irq_dbr)
+ input_report_key(idev, KEY_POWER, true);
+ else if (irq ==
[linux-sunxi] Current u-boot crashes my cubietruck!
Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) Olliver -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On Sat, 2014-03-29 at 16:52 +0100, Olliver Schinagl wrote: Hey all, I was using current head on my Cubietruck; and it kept crashing. I first tried to revert the density/width only, but that made no difference what so ever. Oh dear. The first crash I had on cloning git during 3.4.79+; i first reverted to Hans's 3.4 series from fedora 19, but then a big huge oops happened even during boot. And consistently during boot. It doesn't seem to be power relate either. I have since reverted to d9aa5dd3d and that seems to be stable again. Which branch are you running? u-boot-sunxi/sunxi I guess but you mention Hans' series so maybe jwrdegoede/sunxi-next? I will cook dinner now, and keep the board running using the d9 hash and checkout a few newer revisions then. Stable for 10 minutes now though ;) The obvious first one to try would be d2a8c8da1c6 Merge tag 'v2014.04-rc2' into sunxi. Its immediate parent on the sunxi side is d9aa5dd3d which you've already found to be stable. If you can rule that out then the rest should be fairly tractable to bisect... Looking at gitk d9aa5dd3d...u-boot-sunxi/sunxi --not origin/master most of them are supposed to be no semantic change type cleanups or things which don't touch cubietruck... If it does turn out to be the merge then I think it will be time to take a fine toothed comb to the merge... Ian. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: [PATCH v3 06/10] regulator: AXP20x: Add support for regulators subsystem
On Fri, Mar 28, 2014 at 01:39:34PM +, Mark Brown wrote:
On Thu, Mar 27, 2014 at 10:29:20PM +0100, Carlo Caione wrote:
+static int axp20x_set_suspend_voltage(struct regulator_dev *rdev, int uV)
+{
+ int sel = regulator_map_voltage_iterate(rdev, uV, uV);
+
+ if (sel 0)
+ return sel;
+
+ return regulator_set_voltage_sel_regmap(rdev, sel);
+}
This is fairly obviously broken - it's overwriting the normal runtime
value, this will disrupt the running system if we want the value we use
on suspend is different to the value we want at runtime.
Ok, silly question: isn't it exactly what we want? Set the voltage for
the regulator when the system is suspended?
Think about it - if this was a sane thing to do the core would just do
it without needing driver specific code, we already know how to set the
voltage for the device.
I thought it was because some regulators can have specific regs for
managing the suspend mode.
BTW, but then what is the difference between my code and (i.e.) the same
routine in da9055-regulator.c?
http://lxr.linux.no/linux+v3.13.5/drivers/regulator/da9055-regulator.c#L276
Thanks,
--
Carlo Caione
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: A20 + OV5640 (parallel) issues
Hey getting closer :) There's still an issue with the LDO (I don't like this debugfs issue) - check if you actually get sensor voltage first. If no, there's still something funny going on with AXP, so triple-check the Fex file for LDO init. Check with a multimeter whether you really get 2V8. Ok, so the I2C stuff is located in the driver itself - just look at the functions in the mt9d112 driver file (something like sensor_read and sensor_write) - there you should see if the sensor address is correct. Also bear in mind which I2C bus is used for sensor in the fex file for your sensor - mine is twi0, but it can easily be that you've connected the sensor to something else (on Olinuxino twi2 was also close to route for instance so I made assembly options on my interface to either use TWI0 or TWI2, as I didn't really know what is implemented in the kernel and what's not at the time...). If you're using level converters for I2C, check them as well, especially OE's. On Fri, Mar 28, 2014 at 11:47 PM, rdv0...@gmail.com wrote: пятница, 28 марта 2014 г., 11:41:49 UTC+2 пользователь Ivan Kozic написал: Hi, You haven't given much info about this - take care with Cubieboard 1 2 - as far as I can remember they don't have PIXCLK routed for CSI0 port, so it's completely unusable. You should use CSI1. Regarding the seg fault - not sure how you connected the power supplies to the sensor, but these regulator_enable are for AXP IC - if you connected the sensor to the AXP, you need to use them I guess. I for instance have just connected the sensor supply to fixed LDO's coming from either 3V3 or 5V, which is always alive, so I don't really need them, but nevertheless they aren't commented out in my driver (WiP, so still dirty) and they are working, so maybe the culprit is something else. You didn't say which test application or given any snippets, but if it's the one coming with the driver (app_test_ok or something similar), by Rockie Cheng (this name always amuses me :) ), then it's full of bugs and issues and you should carefully go through every step and clean the crap code out (a lot of it is crap). Better yet, write a much simpler V4L2 test app yourself. Things that also pop is the old kernel (I'm using 3.4.75 and this is already like couple of months old) and this Linaro rootfs (don't know about this - is it fully supported on Cubies?). You should probably use newer kernel just to be sure that something stupid is not breaking. Also take care with drivers - the one for OV5640 is very badly written and full of bugs and I don't think that the supplied sensor settings are usable for anyone (they are all like 3.75 and 7.5 fps, most of them just wrong). Also sun4i_csi driver is bad (you can read some of the issues on this thread, but there are other threads as well). So mostly for a functional system all this needs to be cleaned and rewritten. On Thursday, March 27, 2014 11:54:08 PM UTC+1, rdv...@gmail.comwrote:Hello guys, I want to get camera module mt9d112 working on cubieboard a10 over CSI. I am using ubuntu linaro with kernel version 3.4.61. Test application crashes with seg fault on (regulator_enable+0x4/0x1f8) from [bf010138] (sensor_power+0x190/0x398 [mt9d112]). Could you please help me to figure out where the issue is? How can I debug kernel module? You are right for testing I using app_test_ok. This test application is full of mistakes but for now I did not even successfuly initialized camera module. I have connected VCC of camera module to CSI1_IO_2V8 pin on the board and other pins to the rest of CSI ports. The CSI1_IO_2V8 is actually LDO4 of AXP20 and I finally found in AllWinner documentation that string axp_hdmi should be used in script.fex instead of axp_p11 as described in tutorial. By the way the tutorial from cubieboard is full of such mistakes. So, when I change settings string to axp_hdmi I get new portion of errors: [ 383.721765] [CSI]Welcome to CSI driver [ 383.723657] [CSI]csi_init [ 383.934525] [CSI]registered sub device,input_num = 0 [ 383.939747] axp20_ldo4: Failed to create debugfs directory [ 384.003476] [CSI]V4L2 device registered as video1 [ 385.171443] incomplete xfer (0x20) [ 385.176430] [CSI_ERR][MT9D112]Error -70 on register write [ 385.181925] [CSI_ERR][MT9D112]sensor_read err at sensor_detect! [ 385.194199] [CSI_ERR][MT9D112]chip found is not an target chip. [ 385.199069] [CSI_ERR]sensor initial error when csi open! As I understand these error means that I2C communication is failed. The I2C address might by incorrect. But what is incomplete xfer (0x20) ? -- You received this message because you are subscribed to a topic in the Google Groups linux-sunxi group. To unsubscribe from this topic, visit https://groups.google.com/d/topic/linux-sunxi/ijitRnbl8c8/unsubscribe. To unsubscribe from this group and all its topics, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more
Re: [linux-sunxi] [A20] sunxi framebuffer overlay help needed
Just posting to say that it can be done with the Disp driver. Basically it is a bit difficult to figure out how to properly use ioctls to do it, but in the end it is not so difficult to actually do it. However, I'm still facing issues :) Right now I have a video overlayed with a Qt window, and even alpha blending is working properly (pipes need to be setup correctly for alpha blender to work), but due to memory allocation issues from kernel, my Qt overlay is very bad, since it looks like either framebuffer is read bad, or written to bad, as when you move the mouse you get something similar to trails, like ghost pixel groups. Quite ugly actually, but I think it's due to memory allocation (same situation with kmalloc) - once I've managed to remove it, but due to all the commenting and still not having a working version control, I forgot what :( There is a tiny mess with this reserved memory in the disp driver - I will check it on Monday and post back if I find the issue. Anyway, while it's possible to use it properly, as you can see everything is quite buggy, and really unconventional because of these ioctls. I also took a look at your KMS driver presentation - it looks quite cool and it seems that you've given quite some effort to it. In fact, the main goal for this driver should have been a much better structure, as it seems that like for CSI, it is only copied from sun4i and a bit patched, which made the whole thing bloated and very error-prone - there are so many stupid bugs in this driver and I can almost make that most of them came from copy-pasting the old code... On Tuesday, March 25, 2014 3:00:07 PM UTC+1, Luc Verhaegen wrote: On Tue, Mar 25, 2014 at 01:55:40AM -0700, Ivan Kozic wrote: Hi Luc and thanks for replying, Not sure I follow - I went deeper into the Qt structure yesterday. Basically, Qt uses just a normal linux fb access (opens /dev/fb0 directly), while my current no-GUI application (only used to display video from CSI) is using more advanced way - it opens /dev/disp first and then requests a layer from it, eventually opening /dev/fb just to execute FBIOGET_LAYER_HDL_0 ioctl and then closes it. Afterwards, I just have an endless loop in the program in which buffers from V4L2 exchange addresses with buffers from display. To my understanding (I'm a bit fresh with all this), Qt should actually also open /dev/disp and request a GUI layer (think it's called YUV layer in the user manual for A20) for it, while my underlying V4L2 library should do the same, but only requesting video layer instead of a GUI layer. This way, underlying lib would do the video and provide controls, while overlay would be in a different layer providing GUI which is linked with the controls. Is this true? If so, there is no easy way to do it, as I would have to implement a different display driver for Qt which would use layers instead of stupidly opening /dev/fb0 (this is quite some work) + update my underlying library to actually use display, again with layering. Just saying - compared to Freescale kernel, this is far from walk in the park. As I said before, Freescale provides a separate /dev/fb for every layer of the screen, which is much easier to work with. But as I said, I might be completely wrong - what did you have in mind? You should use the hw differently, i am not sure whether disp allows that though. Just wait until i finally deliver on my KMS driver, i still am too lethargic atm to make proper progress on it, although i have added some good lcd code in the last week. Luc Verhaegen. -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: A20 + OV5640 (parallel) issues
On Sat, Mar 29, 2014 at 4:34 PM, Ivan Kozic jimmy...@gmail.com wrote: Hey getting closer :) There's still an issue with the LDO (I don't like this debugfs issue) - check if you actually get sensor voltage first. If no, there's still something funny going on with AXP, so triple-check the Fex file for LDO init. Check with a multimeter whether you really get 2V8. Ok, so the I2C stuff is located in the driver itself - just look at the functions in the mt9d112 driver file (something like sensor_read and sensor_write) - there you should see if the sensor address is correct. Also bear in mind which I2C bus is used for sensor in the fex file for your sensor - mine is twi0, but it can easily be that you've connected the sensor to something else (on Olinuxino twi2 was also close to route for instance so I made assembly options on my interface to either use TWI0 or TWI2, as I didn't really know what is implemented in the kernel and what's not at the time...). If you're using level converters for I2C, check them as well, especially OE's. Are you planning on feeding this into the h.264 compression engine? That's where I got stuck with not enough compression being done - output stream is too many MB/s. On Fri, Mar 28, 2014 at 11:47 PM, rdv0...@gmail.com wrote: пятница, 28 марта 2014 г., 11:41:49 UTC+2 пользователь Ivan Kozic написал: Hi, You haven't given much info about this - take care with Cubieboard 1 2 - as far as I can remember they don't have PIXCLK routed for CSI0 port, so it's completely unusable. You should use CSI1. Regarding the seg fault - not sure how you connected the power supplies to the sensor, but these regulator_enable are for AXP IC - if you connected the sensor to the AXP, you need to use them I guess. I for instance have just connected the sensor supply to fixed LDO's coming from either 3V3 or 5V, which is always alive, so I don't really need them, but nevertheless they aren't commented out in my driver (WiP, so still dirty) and they are working, so maybe the culprit is something else. You didn't say which test application or given any snippets, but if it's the one coming with the driver (app_test_ok or something similar), by Rockie Cheng (this name always amuses me :) ), then it's full of bugs and issues and you should carefully go through every step and clean the crap code out (a lot of it is crap). Better yet, write a much simpler V4L2 test app yourself. Things that also pop is the old kernel (I'm using 3.4.75 and this is already like couple of months old) and this Linaro rootfs (don't know about this - is it fully supported on Cubies?). You should probably use newer kernel just to be sure that something stupid is not breaking. Also take care with drivers - the one for OV5640 is very badly written and full of bugs and I don't think that the supplied sensor settings are usable for anyone (they are all like 3.75 and 7.5 fps, most of them just wrong). Also sun4i_csi driver is bad (you can read some of the issues on this thread, but there are other threads as well). So mostly for a functional system all this needs to be cleaned and rewritten. On Thursday, March 27, 2014 11:54:08 PM UTC+1, rdv...@gmail.com wrote:Hello guys, I want to get camera module mt9d112 working on cubieboard a10 over CSI. I am using ubuntu linaro with kernel version 3.4.61. Test application crashes with seg fault on (regulator_enable+0x4/0x1f8) from [bf010138] (sensor_power+0x190/0x398 [mt9d112]). Could you please help me to figure out where the issue is? How can I debug kernel module? You are right for testing I using app_test_ok. This test application is full of mistakes but for now I did not even successfuly initialized camera module. I have connected VCC of camera module to CSI1_IO_2V8 pin on the board and other pins to the rest of CSI ports. The CSI1_IO_2V8 is actually LDO4 of AXP20 and I finally found in AllWinner documentation that string axp_hdmi should be used in script.fex instead of axp_p11 as described in tutorial. By the way the tutorial from cubieboard is full of such mistakes. So, when I change settings string to axp_hdmi I get new portion of errors: [ 383.721765] [CSI]Welcome to CSI driver [ 383.723657] [CSI]csi_init [ 383.934525] [CSI]registered sub device,input_num = 0 [ 383.939747] axp20_ldo4: Failed to create debugfs directory [ 384.003476] [CSI]V4L2 device registered as video1 [ 385.171443] incomplete xfer (0x20) [ 385.176430] [CSI_ERR][MT9D112]Error -70 on register write [ 385.181925] [CSI_ERR][MT9D112]sensor_read err at sensor_detect! [ 385.194199] [CSI_ERR][MT9D112]chip found is not an target chip. [ 385.199069] [CSI_ERR]sensor initial error when csi open! As I understand these error means that I2C communication is failed. The I2C address might by incorrect. But what is incomplete xfer (0x20) ? -- You received this message because you are subscribed to a
