Re: [linux-sunxi] sun6i SPL support status update
Hi Hans, On Sun, Mar 30, 2014 at 8:04 PM, Hans de Goede hdego...@redhat.com wrote: Hi, After wens pointed me to: http://git.rhombus-tech.net/?p=u-boot.git;a=blob;f=arch/arm/cpu/armv7/sunxi/dram_sun6i.c;h=9275ca21ac99592c7d520a41c0914b359c27b913;hb=refs/heads/lichee/jb-4.2.2-a31 I've tried to get a full SPL going on sun6i. No luck sofar, dropping in dram_sun6i.[c,h] +pll5 config seems to get the dram going, at least get_ram_size() likes it. But I cannot get the mmc to work in the SPL. I've narrowed this down to 2 problems, which I believe are related: 1) The mmc controller will simply not work with pll6 as source, after adding a test for the pll6 lock bit I believe this is caused by pll6 never locking. 2) When switching the mmc controller clocksource to OSC24M, then it does work, but gets stuck reading the first sector from the card. I believe this happens because the card is only being supplied 3.0V' rather then 3.3V. Note that the same code works fine in the no SPL u-boot when loaded through boot0 + boot1. Likely wrong power supply voltages are the culprit in both cases (the A31 also has a vdd-pll power pin. So it looks like the next step is to first get the pmic going in u-boot (which will be useful even if booted through boot0 + 1, to enable the nic-phy if nothing else). The A23 lichee u-boot has drivers for P2WI (used in sun6i) and RSB (reduced serial bus, used on A23): https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/p2wi https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/rsb And also PMIC drivers: https://github.com/wens/u-boot-sunxi/tree/lichee-dev-a23/drivers/power Judging from the code, my guess is AXP221 and AXP223 or differ in the type of interface supported. Hope this helps. :) And then see from there. Maybe I'll take a shot at this tonight, for now I'm going to spend some time with my family. Cheers, ChenYu -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
Hi, On 03/30/2014 02:40 PM, Olliver Schinagl wrote: On 03/30/2014 02:25 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. Looking forward to the result, but I'm sure it'll be fine ;) So i changed to the u-boot that comes with fedora 19 from hans, as I did all my previous work with that, and untarring of the extracted tarball works now. I have to make a deadline for my book (building the BSP, hence i bumped into this) and will do more compile/extraction tests in the next few days as time permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various things. If this is all deemed stable; then it can only be u-boot that somehow broke. The only thing I can imagine is tolerances or power usage somehow. Speaking of, during the extraction power jumped from just under 0.5 amps @ 4.85V = idle; to about 0.85 amps @ 4.75V. Hmm, this might be caused by the FAST_MBUS stuff we've for A20 now a days. You could try removing FAST_MBUS from the boards.cfg config options for the cubietruck, and see how a recent u-boot build that way works. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
Hi, On 03/31/2014 08:49 AM, Hans de Goede wrote: Hi, On 03/30/2014 02:40 PM, Olliver Schinagl wrote: On 03/30/2014 02:25 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. Looking forward to the result, but I'm sure it'll be fine ;) So i changed to the u-boot that comes with fedora 19 from hans, as I did all my previous work with that, and untarring of the extracted tarball works now. I have to make a deadline for my book (building the BSP, hence i bumped into this) and will do more compile/extraction tests in the next few days as time permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various things. If this is all deemed stable; then it can only be u-boot that somehow broke. The only thing I can imagine is tolerances or power usage somehow. Speaking of, during the extraction power jumped from just under 0.5 amps @ 4.85V = idle; to about 0.85 amps @ 4.75V. Hmm, this might be caused by the FAST_MBUS stuff we've for A20 now a days. You could try removing FAST_MBUS from the boards.cfg config options for the cubietruck, and see how a recent u-boot build that way works. Oh and another thing to test is to try replacing your powersupply, if is dropping that far below 5V then likely it is also outputting quite a bit of noise and spikes on the powerline. Your battery won't help you there since the power likely is not far enough below 5V to make it switch, so the board keeps using the bad powersupply taking in all the noise and power spikes. Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] Re: How do I add I2C RTC driver to platform?
I got it working by changing the name as below.
static struct i2c_board_info __initdata ds1307_i2c_board_info[] = {
{
.type = ds1307,
.addr = 0x68,
},
};
The bit that got this working was the change of the name to ds1307 instead
of rtc-ds1307 which was the name of the driver. Once I did this, the code
to probe the driver was called and the device was initialised.
Just thought I'd leave it here for others searching for something similar.
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Re: New u-boot sunxi-next available for testing
Am Montag, 31. März 2014 09:04:23 UTC+2 schrieb Hans de Goede: Hi, On 03/30/2014 11:37 PM, markus.roppelt wrote: Am Donnerstag, 27. März 2014 19:50:32 UTC+1 schrieb Ezaul Zillmer: Ok Muito Obrigado! ;) Em quinta-feira, 27 de março de 2014 15h19min58s UTC-3, Hans de Goede escreveu:Hi, To build this you should do: make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- Cubieboard2_config make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- Regards, Hans On 03/27/2014 06:33 PM, Ezaul Zillmer wrote: Good Afternoon Doctor Hans Updated my u-boot I wonder how was the logic I tried to compile it like this: ./mkconfig ARCH=arm CPU=armv7 SOC=sunxi BOARD=Cubieboard2 make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- No dick: (could correct me where I am going wrong! Hug Since Thank you much longer Hi Hans, I tested the new u-boot with your newest kernel (3.14.0-rc8+) on the cubietruck. I found two issues so far. It seems that only one CPU is initialized correctly: [0.049402] /cpus/cpu@0 missing clock-frequency property [0.049433] /cpus/cpu@1 missing clock-frequency property [0.049447] CPU0: thread -1, cpu 0, socket 0, mpidr 8000 [0.049479] Setting up static identity map for 0x4073f2d0 - 0x4073f368 [0.058595] CPU1: failed to boot: -38 [0.058647] Brought up 1 CPUs [0.058655] SMP: Total of 1 processors activated. [0.058662] CPU: All CPU(s) started in SVC mode. [0.059721] devtmpfs: initialized [0.064475] VFP support v0.3: implementor 41 architecture 2 part 30 variant 7 rev 4 Also kvm does not work and there is no /dev/kvm device. [0.176760] kvm [1]: HYP mode not available Here is the full dmesg output: http://pastebin.com/V72FAzmp Did you use the sunxi-next branch ? What you're seeing is typical behavior from using the regular sunxi branch of u-boot-sunxi. Regards, Hans Hi Hans, you're right. I rebuilt u-boot with the following commands (under Fedora 20) and now it works as excepted: git clone --depth=1 https://github.com/jwrdegoede/u-boot-sunxi.git -b sunxi-next make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnu- Cubietruck_config make ARCH=arm CROSS_COMPILE=/usr/bin/arm-linux-gnu- I was somehow on the wrong branch. The following is still printed, but I don't know if this is a bug, as the board runs without problems. [0.049038] /cpus/cpu@0 missing clock-frequency property [0.049066] /cpus/cpu@1 missing clock-frequency property Here is the full dmesg: http://pastebin.com/myei59hG Greetings Markus -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [linux-sunxi] Azpen A727 / A23 chip
On Monday 31 Mar 2014 19:53:31 Luc Verhaegen wrote: On Mon, Mar 31, 2014 at 07:46:18PM +0530, jtd wrote: another A23 board H978 V2.1 20131202 Is there any reason why you thought you would just throw this onto the mailing list in an existing thread? Is there any reason why you also failed to pick up on the countless mentions of http://linux-sunxi.org/New_Device_howto in that thread? Yikes. I thought that the op was about A23. The reason I posted was mention of the serial port in the op. I thought that the attached pic and serial dump might be useful. I guess I will just lurk until a I get more clued in on the community. Apologies. -- 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] [A20] sunxi framebuffer overlay help needed
Hi Luc, Found out why disp driver has choppy overlay - for me overlay comes through DMA from memory. Funny thing - disp_malloc is fetching cached memory, so choppiness or trailing is due to caching framebuffer protected memory. Very silly - I found this out by changing caching method of ARM from WRITEALLOC to WRITETHROUGH, also waited 10 minutes for system to boot up :) The matter is solved by adding the following line to disp_mmap() function: vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); Solved. Just wondering how people were using this before... 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] Azpen A727 / A23 chip
On Mon, Mar 31, 2014 at 08:15:02PM +0530, jtd wrote: On Monday 31 Mar 2014 19:53:31 Luc Verhaegen wrote: On Mon, Mar 31, 2014 at 07:46:18PM +0530, jtd wrote: another A23 board H978 V2.1 20131202 Is there any reason why you thought you would just throw this onto the mailing list in an existing thread? Is there any reason why you also failed to pick up on the countless mentions of http://linux-sunxi.org/New_Device_howto in that thread? Yikes. I thought that the op was about A23. The reason I posted was mention of the serial port in the op. I thought that the attached pic and serial dump might be useful. I guess I will just lurk until a I get more clued in on the community. Apologies. Don't just lurk. Just diligently work through the http://linux-sunxi.org/New_Device_howto and try to get your device at least documented. If you do that, then the last thing you need to do is apologise. 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] [A20] sunxi framebuffer overlay help needed
On Mon, 31 Mar 2014 08:33:29 -0700 (PDT) Ivan Kozic jimmy...@gmail.com wrote: Hi Luc, Found out why disp driver has choppy overlay - for me overlay comes through DMA from memory. Funny thing - disp_malloc is fetching cached memory, so choppiness or trailing is due to caching framebuffer protected memory. Very silly - I found this out by changing caching method of ARM from WRITEALLOC to WRITETHROUGH, also waited 10 minutes for system to boot up :) The matter is solved by adding the following line to disp_mmap() function: vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); Solved. Just wondering how people were using this before... As far as I know, nobody is using these bug ridden memory allocators that Allwinner has implemented in disp and g2d drivers. Except for maybe Allwinner itself in their Android code. -- 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] Azpen A727 / A23 chip
On Mon, Mar 31, 2014 at 09:47:26PM +0530, jtd wrote: On Monday 31 Mar 2014 21:10:49 Luc Verhaegen wrote: On Mon, Mar 31, 2014 at 08:15:02PM +0530, jtd wrote: On Monday 31 Mar 2014 19:53:31 Luc Verhaegen wrote: On Mon, Mar 31, 2014 at 07:46:18PM +0530, jtd wrote: another A23 board H978 V2.1 20131202 Is there any reason why you thought you would just throw this onto the mailing list in an existing thread? Is there any reason why you also failed to pick up on the countless mentions of http://linux-sunxi.org/New_Device_howto in that thread? Yikes. I thought that the op was about A23. The reason I posted was mention of the serial port in the op. I thought that the attached pic and serial dump might be useful. I guess I will just lurk until a I get more clued in on the community. Apologies. Don't just lurk. Just diligently work through the http://linux-sunxi.org/New_Device_howto and try to get your device at least documented. If you do that, then the last thing you need to do is apologise. Got to fel mode fel -v AWUSBFEX soc=00165000(unknown) 0001 ver=0001 44 08 scratchpad=7e00 fel read 0x4240 0x82d0 boot1.header libusb usb_bulk_send error -7 Work in progress. Stop posting in this thread. Create a wiki account http://linux-sunxi.org/Special:UserLogin and start doing work there, by first following the http://linux-sunxi.org/New_Device_howto 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] control USB Power from linux
Hello people, I've disabled these lines in script.bin: usb_drv_vbus_gpio = port:PH0610default0 usb_drv_vbus_gpio = port:PH0310default0 in order to use them as standard GPIO, enabling to switch on and off the usb port. The results is that I receive a super-kernel-panic at boot: 6ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [2.156913] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver 6ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver [2.168608] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver WRN:L104(drivers/usb/host/sw_hci_sunxi.c):[2.178486] WRN:L104(drivers/usb/host/sw_hci_sunxi.c):ERR: get usbc1(usbc1) id failed ERR: get usbc1(usbc1) id failed WRN:L430(drivers/usb/host/sw_hci_sunxi.c):[2.192860] WRN:L430(drivers/usb/host/sw_hci_sunxi.c):ERR: gpio_request failed ERR: gpio_request failed WRN:L816(drivers/usb/host/sw_hci_sunxi.c):[2.206014] WRN:L816(drivers/usb/host/sw_hci_sunxi.c):ERR: alloc_pin failed ERR: alloc_pin failed WRN:L104(drivers/usb/host/sw_hci_sunxi.c):[2.218657] WRN:L104(drivers/usb/host/sw_hci_sunxi.c):ERR: get usbc1(usbc1) id failed ERR: get usbc1(usbc1) id failed WRN:L430(drivers/usb/host/sw_hci_sunxi.c):[2.233026] WRN:L430(drivers/usb/host/sw_hci_sunxi.c):ERR: gpio_request failed ERR: gpio_request failed WRN:L816(drivers/usb/host/sw_hci_sunxi.c):[2.246177] WRN:L816(drivers/usb/host/sw_hci_sunxi.c):ERR: alloc_pin failed ERR: alloc_pin failed WRN:L104(drivers/usb/host/sw_hci_sunxi.c):[2.258821] WRN:L104(drivers/usb/host/sw_hci_sunxi.c):ERR: get usbc2(usbc2) id failed ERR: get usbc2(usbc2) id failed WRN:L430(drivers/usb/host/sw_hci_sunxi.c):[2.273189] WRN:L430(drivers/usb/host/sw_hci_sunxi.c):ERR: gpio_request failed ERR: gpio_request failed WRN:L816(drivers/usb/host/sw_hci_sunxi.c):[2.286342] WRN:L816(drivers/usb/host/sw_hci_sunxi.c):ERR: alloc_pin failed ERR: alloc_pin failed WRN:L104(drivers/usb/host/sw_hci_sunxi.c):[2.298985] WRN:L104(drivers/usb/host/sw_hci_sunxi.c):ERR: get usbc2(usbc2) id failed ERR: get usbc2(usbc2) id failed WRN:L430(drivers/usb/host/sw_hci_sunxi.c):[2.313354] WRN:L430(drivers/usb/host/sw_hci_sunxi.c):ERR: gpio_request failed ERR: gpio_request failed WRN:L816(drivers/usb/host/sw_hci_sunxi.c):[2.326507] WRN:L816(drivers/usb/host/sw_hci_sunxi.c):ERR: alloc_pin failed ERR: alloc_pin failed 1Unable to handle kernel NULL pointer dereference at virtual address [2.342599] Unable to handle kernel NULL pointer dereference at virtual address 1pgd = c0004000 [2.352363] pgd = c0004000 1[] *pgd=[2.357427] [] *pgd= It does look clear that the kernel tries to take control of the gpio used to switch on the TCS9708 IC (which powers the USB as you can see from Cubiebooard schematic) but it fails. I'm thinking I should edit something in kernel sources, but I'd like to ask you if I'm doing somehow wrong and/or there are other ways, Thanks in advance. Vincenzo Il giorno venerdì 4 ottobre 2013 21:54:23 UTC+2, Patrick Wood ha scritto: On Tuesday, September 24, 2013 8:34:52 AM UTC-4, Jon Smirl wrote: On Tue, Sep 24, 2013 at 8:28 AM, Arokux X aro...@gmail.com wrote: On Tue, Sep 24, 2013 at 2:27 PM, jons...@gmail.com jons...@gmail.com wrote: On Tue, Sep 24, 2013 at 8:16 AM, Arokux X aro...@gmail.com wrote: Hi, On Tue, Sep 24, 2013 at 7:59 AM, stu@gmail.com wrote: I want to control the power off my Usb Device conected to cubieboard (power off - power on the device by usb1-drv or usb2-drv ) what is usb1-drv and usb2-drv? I googled a lot and find this article http://e2e.ti.com/support/arm/sitara_arm/f/791/t/270060.aspx but it is not for cubie can anybody help me for this issue? according to attached image it must be a way to control USB1-DRV from Linux. I have checked the usb power at startup and i see the power goes on when in terminal report [sw-ehci1]: Set USB Power ON , but i dont know how it works. 6hub 2-0:1.0: USB hub found [1.894384] hub 2-0:1.0: USB hub found 6hub 2-0:1.0: 1 port detected [1.901073] hub 2-0:1.0: 1 port detected [sw-ehci2]: open clock [1.907602] [sw-ehci2]: open clock [sw-ehci2]: Set USB Power ON [1.923679] [sw-ehci2]: Set USB Power ON The power to USB devices is turned on by setting a certain GPIO pin (likely PH06 or PH03 - check your fex config in sections usbc) to output one. If you figure out a way how to poke at that pins from user space just set them to output 0 to switch off the power and to output 1 to turn off the power. Now, I do not know how to poke at GPIO pins from user space, So tell me if you find out. sysfs interface... http://squidge.sourceforge.net/gpio/ Well yes, but will it
Re: [linux-sunxi] Current u-boot crashes my cubietruck!
On 03/31/2014 08:04 PM, Olliver Schinagl wrote: On 03/31/2014 08:59 AM, Hans de Goede wrote: Hi, On 03/31/2014 08:49 AM, Hans de Goede wrote: Hi, On 03/30/2014 02:40 PM, Olliver Schinagl wrote: On 03/30/2014 02:25 PM, Ian Campbell wrote: On Sun, 2014-03-30 at 12:26 +0100, Ian Campbell wrote: I've just FEL booted with 2014.04-rc2-00665-g96510e1 (i.e. current u-boot-sunxi.git#sunxi) onto a SATA installation and have started a git clone of the kernel, after which I'll run a build and see what happens. So, I did the git clone, checkout, config and make all -j4 has been running for quite a while now (10 minutes) with no errors. While the make was running I've messed around with git archive to produce a tar.xz, got bored waiting for that, used wget to download a tar.xz from kernel.org and unpacked it. All with no errors. IOW I'm afraid it all looks OK to me. This is all running from a SATA disk with a 2A power supply. I'm about to go out for lunch, if it crashes etc while I'm out I'll let you know after I get back. Looking forward to the result, but I'm sure it'll be fine ;) So i changed to the u-boot that comes with fedora 19 from hans, as I did all my previous work with that, and untarring of the extracted tarball works now. I have to make a deadline for my book (building the BSP, hence i bumped into this) and will do more compile/extraction tests in the next few days as time permits on hans's u-boot. I'll run some of ssvb's benchmarks to test various things. If this is all deemed stable; then it can only be u-boot that somehow broke. The only thing I can imagine is tolerances or power usage somehow. Speaking of, during the extraction power jumped from just under 0.5 amps @ 4.85V = idle; to about 0.85 amps @ 4.75V. Hmm, this might be caused by the FAST_MBUS stuff we've for A20 now a days. You could try removing FAST_MBUS from the boards.cfg config options for the cubietruck, and see how a recent u-boot build that way works. Oh and another thing to test is to try replacing your powersupply, if is dropping that far below 5V then likely it is also outputting quite a bit of noise and spikes on the powerline. Your battery won't help you there since the power likely is not far enough below 5V to make it switch, so the board keeps using the bad powersupply taking in all the noise and power spikes. While sensible, I doubt it, it's a high-end samsung charger; I could hook it up to my oscope and see how noise the line is. But the FAST_MBUS thing, yes I will tripple check that. A small update however, I ran a unpack, compile, rm -rf run and while it only managed to complete 37 loops in 24 hours, it completed them appearantly error free (I didn't check the entire log, just the last entry). So this u-boot runs fine and is stable. I will do the loop again (with less itterations) using fast-less u-boot. So far so good, it has run through a few loops which seem to work fine. So the Fast MBUS may not always work too well on all boards ... I'll let it run a bit longer, I'll get back to this tomorrow ... Olliver Olliver Regards, Hans -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3.4 0/4] Use AXP209 for the power consumption measurements
These patches allow reasonably accurate voltage, current and power consumption measurements on at least some of the Allwinner A10/A20 based development boards using lm-sensors or by directly reading from sysfs. So that some basic power consumption measurements can be done even by ordinary users. Without access to lab power supplies, multimeters, cutting wires and/or soldering :-) Example of a Cubietruck running under heavy load: $ sensors Adapter: sunxi-i2c.0 ACIN voltage:+5.03 V (avg = +5.01 V) AXP20X temperature: +57.6 C (low = -144.7 C, high = +264.8 C) ACIN power: 3.02 W (avg = 3.50 W) ACIN current:+0.60 A (avg = +0.70 A) For best accuracy we need to look at the 'avg' results. The momentary values are rather volatile. Siarhei Siamashka (4): sunxi: axp20x: Fix misuse of the lowest 4-bits of temperature ADC sunxi: axp20x: Human readable label for the temperature sensor sunxi: axp20x: Report voltage, current and power for ACIN connector sunxi: axp20x: Calculate moving average for ACIN voltage/current/power drivers/power/axp_power/axp-mfd.c | 4 + drivers/power/axp_power/axp20-mfd.h | 166 +--- include/linux/mfd/axp-mfd.h | 6 ++ 3 files changed, 163 insertions(+), 13 deletions(-) -- 1.8.3.2 -- You received this message because you are subscribed to the Google Groups linux-sunxi group. To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[linux-sunxi] [PATCH 3.4 2/4] sunxi: axp20x: Human readable label for the temperature sensor
Signed-off-by: Siarhei Siamashka siarhei.siamas...@gmail.com
---
drivers/power/axp_power/axp20-mfd.h | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/power/axp_power/axp20-mfd.h
b/drivers/power/axp_power/axp20-mfd.h
index 0021fb5..6ec26f6 100644
--- a/drivers/power/axp_power/axp20-mfd.h
+++ b/drivers/power/axp_power/axp20-mfd.h
@@ -39,6 +39,8 @@ show_temp(struct device *dev, struct device_attribute
*devattr, char *buf)
return sprintf(buf, 264800\n);
if (attr-index == 2)
return sprintf(buf, -144700\n);
+ if (attr-index == 3)
+ return sprintf(buf, AXP20X temperature\n);
return sprintf(buf, %d\n, data-temperature * 100);
}
@@ -46,11 +48,13 @@ show_temp(struct device *dev, struct device_attribute
*devattr, char *buf)
static SENSOR_DEVICE_ATTR(temp1_input, S_IRUGO, show_temp, NULL, 0);
static SENSOR_DEVICE_ATTR(temp1_max, S_IRUGO, show_temp, NULL, 1);
static SENSOR_DEVICE_ATTR(temp1_min, S_IRUGO, show_temp, NULL, 2);
+static SENSOR_DEVICE_ATTR(temp1_label, S_IRUGO, show_temp, NULL, 3);
static struct attribute *axp20_attributes[] = {
sensor_dev_attr_temp1_input.dev_attr.attr,
sensor_dev_attr_temp1_min.dev_attr.attr,
sensor_dev_attr_temp1_max.dev_attr.attr,
+ sensor_dev_attr_temp1_label.dev_attr.attr,
NULL
};
--
1.8.3.2
--
You received this message because you are subscribed to the Google Groups
linux-sunxi group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
