Hi,
I have a project that will involve using a HX8340 display with a BeagleBone A5 board, and obviously I thought the best place to start with this would be the ST7735 driver written by Matt Porter, since the changes to this should be quite trivial…
I checked out the latest Angstrom sources from github, & after a good 12 hours of building toolchains etc I am able to build a uImage kernel for my Beagebone.
The SD card image I am using is the stock Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.05-beaglebone-2012.04.22.img.xz on beaglebone.org
I am able to replace the uImage in /boot, and confirm through the addition of a debug message to my kernel my version is being run ok.
Since the st7735fb support driver is already built into the kernel 3.2.14, I believed all I should need to do is apply the two patches included to get some SPI going. (plus add bone_spi1_init to beaglebone_dev_cfg, to support board rev A5)
Unfortunately on applying these patches, my kernel hangs at the call to register_framebuffer() in st7735fb_probe() - I confirmed this through adding some pr_err() calls.
I wondered if anyone else could confirm whether they can initialise the st7735 driver or not on a beagleboard A5 using the Angstrom kernel sources? You don’t actually need a display, just check the kernel boots & look at the SPI on a scope if you’re adventurous I guess!
Any ideas / tips much appreciated, as this was suppossed to be the simple bit of my project!!
Thanks
Paul
0002-beaglebone-hack-in-support-for-the-WIP-st7735fb-driv.patch (2.01 KB)
0003-st7735fb-Make-FB-native-endian-on-little-endian-plat.patch (2.93 KB)
Try disabling CONFIG_FRAMEBUFFER_CONSOLE. If that works then it's the
same deadlock issue in the core FB code I have seen. It's a known issue
that's coming close to the top of my list. If somebody else doesn't
verify first I'll probably be able to set things back up in the next
few days to take a look.
-Matt
Hi Matt,
Thanks for taking the time out to get back on this - i’ll try it out first thing when I get back to the office…
Paul
Hi Matt,
I managed to remote into my work PC & try this out quicky.
It doesn’t hang like previously now, so there definitely was some sort of race with FRAMEBUFFER_CONSOLE - however now the kernel gets into an endless loop of kernel paging requests…
I can’t really do much more remotely now my beaglebones hung, so will look in more detail tomorrow - just thought I’d post the log in case it rings any bells for anyone!
.
Thanks,
Paul
[ 29.700225] Fixing recursive fault but reboot is needed!
[ 29.705780] Unable to handle kernel paging request at virtual address fffffffc
[ 29.713317] pgd = c0004000
[ 29.716156] [fffffffc] *pgd=8fffe821, *pte=00000000, *ppte=00000000
[ 29.722686] Internal error: Oops: 17 [#18]
[ 29.726989] Modules linked in: bufferclass_ti(O) omaplfb(O) pvrsrvkm(O) ip_tables x_tables g_mass_storage rfcomm ircomm_tty ircomm irda hidp bluetooth rfkill ipv6
[ 29.742218] CPU: 0 Tainted: G D O (3.2.14 #16)
[ 29.747955] PC is at kthread_data+0x4/0xa
[ 29.752136] LR is at wq_worker_sleeping+0x9/0x54
[ 29.756958] pc : [] lr : [] psr: 200001b3
[ 29.756988] sp : cf94efd0 ip : 00000020 fp : c03824a9
[ 29.768951] r10: cf94efd8 r9 : cf9437ac r8 : c047e0c8
[ 29.774414] r7 : cf94efe8 r6 : c047e0c8 r5 : 0000000b r4 : 00000000
[ 29.781250] r3 : 00000000 r2 : cf801640 r1 : 00000000 r0 : cf943540
[ 29.788055] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA Thumb Segment user
[ 29.795776] Control: 50c5387d Table: 8fb7c019 DAC: 00000015
[ 29.801788] Process khungtaskd (pid: 19, stack limit = 0xcf94e2f0)
[ 29.808227] Stack: (0xcf94efd0 to 0xcf950000)
[ 29.812805] efc0: cf943540 c028ef9b c04adffc 00000113
[ 29.821350] efe0: 0000003a 205b0003 39322020 3030372e 5d353232 c002c581 c047e6c8 c002ac3d
[ 29.829895] f000: e9fbe814 00000006 cf94f060 0000000f c04adffc 40000113 00000001 005b933c
[ 29.838439] f020: 39322020 cf943a40 0000000b cf94f0db 00000020 c003933c 00000000 c03824b1
[ 29.846984] f040: c03824a9 cf943a40 0000000b cf94f0db 00000020 c003933c 00000000 c03824b1
etc…
[ 30.898803] ffa0: 34357830 00000000 00000000 31360020 00000000 00000001 00000001 00000000
[ 30.907348] ffc0: 1b478423 c01346b3 4f9423d2 ca000000 00003b9a c00270ea 000001b3 00000000
[ 30.915893] ffe0: cf95001c c000bfb5 00000000 00010000 00000001 00000001 cf950000 00000000
[ 30.924468] [] (kthread_data+0x4/0xa) from [] (wq_worker_sleeping+0x9/0x54)
[ 30.933563] [] (wq_worker_sleeping+0x9/0x54) from [] (__schedule+0xb3/0x380)
[ 30.942749] Code: 3714 c029 f8d0 3240 (f853) 0c04
[ 30.947906] —[ end trace cb816ec25bb89820 ]—
[ 30.952728] Fixing recursive fault but reboot is needed!
[ 30.958312] Unable to handle kernel paging request at virtual address fffffffc
[ 30.965850] pgd = c0004000
[ 30.968658] [fffffffc] *pgd=8fffe821, *pte=00000000, *ppte=00000000
[ 30.975219] Internal error: Oops: 17 [#19]
[ 30.979492] Modules linked in: bufferclass_ti(O) omaplfb(O) pvrsrvkm(O) ip_tables x_tables g_mass_storage rfcomm ircomm_tty ircomm irda hidp bluetooth rfkill ipv6
[ 30.994720] CPU: 0 Tainted: G D O (3.2.14 #16)
[ 31.000457] PC is at kthread_data+0x4/0xa
[ 31.004669] LR is at wq_worker_sleeping+0x9/0x54
[ 31.009490] pc : [] lr : [] psr: 200001b3
[ 31.009490] sp : cf94ed10 ip : 00000020 fp : c03824a9
[ 31.021484] r10: cf94ed18 r9 : cf9437ac r8 : c047e0c8
[ 31.026947] r7 : cf94ed28 r6 : c047e0c8 r5 : 0000000b r4 : 00000000
[ 31.033752] r3 : 00000000 r2 : cf801640 r1 : 00000000 r0 : cf943540
[ 31.040588] Flags: nzCv IRQs off FIQs on Mode SVC_32 ISA Thumb Segment user
[ 31.048309] Control: 50c5387d Table: 8fb7c019 DAC: 00000015
[ 31.054290] Process khungtaskd (pid: 19, stack limit = 0xcf94e2f0)
[ 31.060760] Stack: (0xcf94ed10 to 0xcf950000)
[ 31.065307] ed00: cf943540 c028ef9b c04adffc 00000113
[ 31.073852] ed20: 0000003a 205b0003 30332020 3235392e 5d383237 c002c581 c047e6c8 c002ac3d
[ 31.082427] ed40: 34a393be 00000007 cf94eda0 0000000f c04adffc 40000113 00000001 005b933c
[ 31.090972] ed60: 30332020 cf943a40 0000000b cf94ee1b 00000020 c003933c 00000000 c03824b1
[ 31.099517] ed80: c03824a9 cf943a40 0000000b cf94ee1b 00000020 c003933c 00000000 c03824b1
[ 31.108062] eda0: c03824a9 c002c581 00000020 c003933c 00000000 c03824b1 c03824a9 c047e6e4
[ 31.116607] edc0: c038e6f3 00000002 c0039340 cf94ee1b 00000020 c003933c 00000000 c03824b1
[ 31.125183] ede0: c03824a9 c000ea95 cf94e2f0 0000000b 00000000 bf000000 33000004 20343137
[ 31.133728] ee00: 39323063 64386620 32332030 28203034 33353866 63302029 00203430 00000000
[ 31.142272] ee20: 00000000 cf94ef88 00000017 cf94efd8 c03824a9 fffffffc 00000017 00000000
[ 31.150817] ee40: 00000000 cf94ef88 00000017 cf94efd8 c03824a9 c0011163 00000017 cf94ef88
[ 31.159362] ee60: fffffffc cf943a40 00000000 c001131b c04ae3f8 c04ae036 ffffffff ffffffff
[ 31.167938] ee80: 00000000 c01351a3 ffffffff ffffffff 735f5f06 64656863 2b656c75 33627830
[ 31.176483] eea0: 3378302f 2f003038 34357830 00000000 00000000 00000007 00000007 00000000
[ 31.185028] eec0: 1b478423 c01346b3 00000017 c0462760 fffffffc cf94ef88 c047e0c8 cf9437ac
[ 31.193572] eee0: cf94efd8 c00083f1 cf94ef06 c0135301 00000000 00000000 1b478423 c01346b3
[ 31.202117] ef00: cf94ef3e 3235f025 37303032 00000006 cf867608 c016e3
Hi,
I’ve confirmed that setting CONFIG_FRAMBUFFER_CONSOLE=n in .config removes the race condition that was causing my kernel to hang.
The problem I’ve got now is that the call to spi_write() of 40960 bytes of data via spi_write() in the function st7735fb_update_display() causes my kernel to panic (see attached)
If I split the 40K transfer into 128 bytes blocks, it works fine (but is very slow!!). Any transfer much biggger than this causes the exception to fire (on the first instance of this transfer - & i verified with a scope that the transfer never actually gets sent)
I’m at a bit of a loss to explain this - is there some problem with DMA transfers to the SPI peripheral perhaps??
Thanks
Paul
stack_trace.log (3.2 KB)
Hi,
I've confirmed that setting CONFIG_FRAMBUFFER_CONSOLE=n in .config removes
the race condition that was causing my kernel to hang.
Ok, great.
The problem I've got now is that the call to spi_write() of 40960 bytes of
data via *spi_write()* in the function* **st7735fb_update_display()* causes
my kernel to panic (see attached)
If I split the 40K transfer into 128 bytes blocks, it works fine (but is
very slow!!). Any transfer much biggger than this causes the exception to
fire (on the first instance of this transfer - & i verified with a scope
that the transfer never actually gets sent)
I'm at a bit of a loss to explain this - is there some problem with DMA
transfers to the SPI peripheral perhaps??
Yes, Koen's kernel doesn't yet have my driver updates to make it DMA safe.
I have to rebase to his latest branch and test and then I'll send a pull
request to him to include these.
In the meantime, the latest working code is at:
-Matt