This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Vanilla 3.8 on dm8148..?

Other Parts Discussed in Thread: BEAGLEBOARD-X15

I've just taken over a design using a dm8148, and I'm fairly annoyed to see that the latest kernel from TI is 2.6.37, aka 2 or even 3 years old.

By doing some digging, I noticed that there seems to be support for 'ti81xx' in the vanilla kernel, as the ARM core is common to a lot of the other OMAP parts (despite the davinci name, amongst other confusing aliases and variations).

I can build a kernel with support for TI8148EVM, however it fails to boot, it breaks pretty early on by trying to access the "iva2_pwrdm" registers, using (strangely) a /negative/ offset relative to the IO base address. 

Strangely, that code seems to run fine on plenty of other hardware using that omap core, so I'm starting to suspect that u-boot (I'm still using the TI one) might be somehow protecting that IO range spuriously.

Has anyone have a play with these? I'd also like to yank the TI bootloader, as it's (also) ancient, and there's seems to have some sort of generic support for OMAP3(et al) in the vanilla upstream u-boot. As a bonus, it uses a proper streamlined first stage bootloader instead of the 'mini' one from TI.

Michael

  • Michael,

    As of now, according to my understanding TI has not plans to support 3.x kernel on DM81xx platforms. I'm not sure about the particular 3.8 kernel that you are looking at. 

    Are you really particular about using 3.8 kernel? Will 37 kernel be sufficient for your application?

  • Oh I'm sure TI doesn't support 3.x kernels. And, no, starting a new project with new drivers on a kernel that is not '37' but '2.6.37' doesn't amuse me at all, a LOT of stuff has happened since 2010 in the kernel.

    Thats why I am interested in a kernel that is not provided by TI, so I'm not suffering from the same code sclerosis as they do. Likewise, for the bootloader.

    IMO, the reason they dropped of the mobile market is partly due to the fact they haven't followed up, ignored more modern kernels, android etc. If you look at samsung, freescale, qualcomm etc, they all have tip top, mainstream support in vanilla kernel.

  • Michael,

    I guess the efforts required for porting the drivers to a newer kernel would be quite high. This is most common problem with Linux on Embedded platforms. If you migrate the kernel alone, it won't be sufficient as you'll have to migrate all the user space components and multimedia subsystem along with it. May be that's the reason why migration to newer platforms happens slowly.

  • Well, the dm8148 is an omap at the core (as far as the ARM bits are concerned, and despite what TI says) and that is pretty well supported in mainline. The only bits that stick out are the DSP bridge, but that also has some sort of mainline driver (in fact, 2 if I'm not mistaken) and the PowerVR graphics -- and that is also mainline since it works on the other omap range.

    So AFAIK, there's nothing really missing from the mainline, and from what I see, it actually /should/ work, or at least boot, with very little tweaking...

    That's why I tried it really, I /hoped/ someone here would have, too. I guess I'm back at trying to debug it myself.

  • Michael,

    The major difference between OMAP4 and DM814x are as follows.

    1. OMAP4 has DSS for display and ISS for camera, DM814x has HDVPSS for display and capture and an extra ISS for capture.

    2. DM814x has GPU SGX530 and OMAP4 has SGX540 cores

    3. Both has dual-cortex-M3 subsystem but software running on DM814x and OMAP4 is different. On one of the M3 in OMAP4 camera driver runs, where as in DM814x HDVPSS driver runs.

    This makes the software architecture for both Centaurus and OMAP4 completely different. Most of the smaller IP block remains same but the bigger IPs are totally different. Also the software architecture is also different.

    I guess you are getting the major differences involved. The major work involved will be to migrate the HDPVSS drivers to the newer kernel.

    What is your final application? Does it involve extensive multimedia operations?

  • Well the DM8148 looks a lot closer to an OMAP3 than an OMAP4 tho, in fact all the bits I find in the kernel about it seems to be shared with 3430 and so on, thats why I'm attempting to get that working.

    With further digging, it seems modern kernels requires a more recent u-boot that the TI that is on the board, so I've been attempting to build a vanilla u-boot for omap3 and get that to boot of the SD card, without much success so far.

    My application only requires OGLES for the moment as far as 'multimedia' goes. There is a fat FPGA attached that can/will do anything else, and if I only that /that/ ES working I'd be quite satisfied. I'm not quite fond of being reliant on 'fancy non standard binary blobed' peripherals in any case, it's a nigthmare to support later on, when the silicon manufacturer has moved on to greener, fancier and marketed stuff.

  • Michael,

    If its is just about OGLES then it makes sense to port newer kernel. 

  • Hi Michael,

    Good to see your porting work on 3.8 Kernel for DM8148. I also beginning to do the same porting. Before I begin, would like to hear from you, if you have succeeded in porting the 3.8 kernel to DM8148.

    Thanks

    Ashok

  • Hello Michael and Ashok,

    I'd be interested to know if you've managed to make any progress on the 3.x kernel for the DM814x. We've tried using Aida Mynzhasova's patches (http://www.kernelhub.org/?msg=271207&p=2) and can now get past the power init stage, but now we see a clock init crash (see below).

    U-Boot# setenv bootargs 'console=ttyO0,115200n8 rootwait root=/dev/mmcblk0p2 rw mem=256M earlyprintk noinitrd loglevel=8'
    U-Boot# fatload mmc 0 0x80009000 uImage
    reading uImage
    2346472 bytes read in 293 ms (7.6 MiB/s)
    U-Boot# bootm 0x80009000
    ## Booting kernel from Legacy Image at 80009000 ...
    Image Name: Linux-3.10.25-aufs-rt23-tl4+
    Image Type: ARM Linux Kernel Image (uncompressed)
    Data Size: 2346408 Bytes = 2.2 MiB
    Load Address: 80008000
    Entry Point: 80008000
    Verifying Checksum ... OK
    Loading Kernel Image ... OK

    Starting kernel ...

    [ 0.000000] Booting Linux on physical CPU 0x0
    [ 0.000000] Linux version 3.10.25-aufs-rt23-tl4+ (root@TMDX8148-LINUXVM) (gcc version 4.7.3 (Gentoo 4.7.3-r1 p1.4, pie-0.5.5) ) #5 PREEMPT RT Thu Oct 23 09s
    [ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7d
    [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
    [ 0.000000] Machine: dm814x_evm
    [ 0.000000] bootconsole [earlycon0] enabled
    [ 0.000000] Memory policy: ECC disabled, Data cache writeback
    [ 0.000000] On node 0 totalpages: 65536
    [ 0.000000] free_area_init_node: node 0, pgdat c046a230, node_mem_map c04b1000
    [ 0.000000] Normal zone: 512 pages used for memmap
    [ 0.000000] Normal zone: 0 pages reserved
    [ 0.000000] Normal zone: 65536 pages, LIFO batch:15
    [ 0.000000] CPU: All CPU(s) started in SVC mode.
    [ 0.000000] DM814X ES2.1 (neon )
    [ 0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
    [ 0.000000] pcpu-alloc: [0] 0
    [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 65024
    [ 0.000000] Kernel command line: console=ttyO0,115200n8 rootwait root=/dev/mmcblk0p2 rw mem=256M earlyprintk noinitrd loglevel=8
    [ 0.000000] PID hash table entries: 1024 (order: 0, 4096 bytes)
    [ 0.000000] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
    [ 0.000000] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
    [ 0.000000] Memory: 256MB = 256MB total
    [ 0.000000] Memory: 255040k/255040k available, 7104k reserved, 0K highmem
    [ 0.000000] Virtual kernel memory layout:
    [ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
    [ 0.000000] fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
    [ 0.000000] vmalloc : 0xd0800000 - 0xff000000 ( 744 MB)
    [ 0.000000] lowmem : 0xc0000000 - 0xd0000000 ( 256 MB)
    [ 0.000000] pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
    [ 0.000000] modules : 0xbf000000 - 0xbfe00000 ( 14 MB)
    [ 0.000000] .text : 0xc0008000 - 0xc03fe854 (4059 kB)
    [ 0.000000] .init : 0xc03ff000 - 0xc0429134 ( 169 kB)
    [ 0.000000] .data : 0xc042a000 - 0xc046ada0 ( 260 kB)
    [ 0.000000] .bss : 0xc046ada0 - 0xc04b0924 ( 279 kB)
    [ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
    [ 0.000000] Preemptible hierarchical RCU implementation.
    [ 0.000000] NR_IRQS:16 nr_irqs:16 16
    [ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrupts
    [ 0.000000] Total of 128 interrupts on 1 active controller
    [ 0.000000] GFGFGF : sdrc_ick
    [ 0.000000] GFGFGF : init_clk = -2
    [ 0.000000] Unable to handle kernel NULL pointer dereference at virtual address 0000002a
    [ 0.000000] pgd = c0004000
    [ 0.000000] [0000002a] *pgd=00000000
    [ 0.000000] Internal error: Oops: 5 [#1] PREEMPT ARM
    [ 0.000000] Modules linked in:
    [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 3.10.25-aufs-rt23-tl4+ #5
    [ 0.000000] task: c0434548 ti: c042a000 task.ti: c042a000
    [ 0.000000] PC is at __clk_prepare+0xc/0x7c
    [ 0.000000] LR is at clk_prepare+0x14/0x24
    [ 0.000000] pc : [<c024cfbc>] lr : [<c024d304>] psr: a0000193
    [ 0.000000] sp : c042bf68 ip : 00000001 fp : 00000000
    [ 0.000000] r10: 00000000 r9 : 413fc082 r8 : c06b2f40
    [ 0.000000] r7 : c043c724 r6 : 00000001 r5 : fffffffe r4 : fffffffe
    [ 0.000000] r3 : c0434548 r2 : 00000001 r1 : c0465204 r0 : fffffffe
    [ 0.000000] Flags: NzCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment kernel
    [ 0.000000] Control: 10c5387d Table: 80004019 DAC: 00000015
    [ 0.000000] Process swapper (pid: 0, stack limit = 0xc042a230)
    [ 0.000000] Stack: (0xc042bf68 to 0xc042c000)
    [ 0.000000] bf60: c0434548 fffffffe fffffffe c024d304 00000003 c0027fbc
    [ 0.000000] bf80: c046bb58 00000001 c046adc0 c0421260 ffffffff c040b574 00000000 00000000
    [ 0.000000] bfa0: 00000000 00000001 c046adc0 c0421260 ffffffff c040792c c0407914 c0402184
    [ 0.000000] bfc0: 00000000 c03ff8bc ffffffff ffffffff c03ff4f0 00000000 00000000 c0421260
    [ 0.000000] bfe0: 10c53c7d c0432028 c042125c c043540c 80004059 80008070 00000000 00000000
    [ 0.000000] [<c024cfbc>] (__clk_prepare+0xc/0x7c) from [<c024d304>] (clk_prepare+0x14/0x24)
    [ 0.000000] [<c024d304>] (clk_prepare+0x14/0x24) from [<c0027fbc>] (omap2_clk_enable_init_clocks+0x48/0x80)
    [ 0.000000] [<c0027fbc>] (omap2_clk_enable_init_clocks+0x48/0x80) from [<c040b574>] (omap3xxx_clk_init+0x214/0x39c)
    [ 0.000000] [<c040b574>] (omap3xxx_clk_init+0x214/0x39c) from [<c040792c>] (omap3_sync32k_timer_init+0x18/0x64)
    [ 0.000000] [<c040792c>] (omap3_sync32k_timer_init+0x18/0x64) from [<c0402184>] (time_init+0x1c/0x28)
    [ 0.000000] [<c0402184>] (time_init+0x1c/0x28) from [<c03ff8bc>] (start_kernel+0x1a4/0x2f0)
    [ 0.000000] [<c03ff8bc>] (start_kernel+0x1a4/0x2f0) from [<80008070>] (0x80008070)
    [ 0.000000] Code: eafffd4c e92d4038 e2504000 0a000015 (e594302c)
    [ 0.000000] ---[ end trace 0000000000000001 ]---
    [ 0.000000] Kernel panic - not syncing: Attempted to kill the idle task!

    Any help or pointers would be appreciated.

    Thanks,

    Grant

     

     

  • Luckily, I changed job since I worked on the DM814x. I can't tell you the relief I felt not having to deal with that piece of t cr*p anymore :-)

    No, I never managed to get a vanilla working -- I know some people have managed to get /something/ working, but without the st*pid binary blob that TI uses for the cortex M3, and other piece of completely antiquated code you have to work with just to get that idiocy to boot. So if you don't need the video bits, you probably can manage to get something fairly recent.

    Otherwise, you are still stuck with a 2.6.37 from 2009, and a binary compiler that is also from 2009, becuase the kernel won't even boot with something more recent.

    I will never, EVER take on a project with a TI processor, and will encourage /any/ other solution but TI. I think they are a bit of a disgrace of a company, and the support for these 'top of the range' processor is a complete joke. When you see the level of the answers people get from people who have a "Ti employee" tag (like the previous one, who obviously hasnt even read the topic and just cut+paste some sort of canned answer), you can't help but have to giggle in despair.

    I wish you all good luck :-)

  • Hi Michael,

    Thanks for responding to my query - much appreciated. Not the answer I really wanted to hear, but to be honest, probably the answer I expected :(. I fully agree with you regarding TI's support of this processor - just not good enough. Luckily we've not yet made any hardware so we'll probably ditch this part and use a two chip solution, i.MX6 + C674x (don't think I'll be touching a TI ARM SoC again very soon...). Already been burned by the Stellaris EOL fiasco so my trust in TI is not really very high right now...

    Thanks again for your post.

    Regards,

    Grant

  • Renjith Thomas said:

    The major work involved will be to migrate the HDPVSS drivers to the newer kernel.

    And if TI isn't willing to do that (which is clear by now), perhaps they might consider releasing actual documentation on HDVPSS and HDVICP2 (IVA-HD) to give the open source community a chance?  Black boxes and binary blobs are no fun to work with, especially w.r.t. debugging.

     

    Michael Po said:
    Well the DM8148 looks a lot closer to an OMAP3 than an OMAP4 tho,

    No, it really isn't.  It may seem that way if you look superficially at the cpu and 3d cores, but look deeper and the 81xx family is definitely OMAP4-derived.  Same interconnect technology, same PRCM style (but greatly simplified in the 81xx since power management isn't such a big concern there).  Whole subsystems have been copied over (ISS, IVA-HD (aka HDVICP2), Ducati (aka media controller), the DMM/TILER/EMIF4 memory subsystem, face detect).  The standard "small" peripherals are also OMAP4-versions rather than OMAP3-versions (when this differs).

    BTW, focussing purely on core architecture (which is essential to booting a kernel) and ignoring the big video/dsp subsystems (which are not strictly needed to get a working kernel), the closest relative with mainline support is actually the AM335x ("Subarctic").  This is particularly evident if you compare memory maps.  They also have the same control module, and the peripherals they have in common also have the same IRQ numbers.  The biggest difference is in PRCM, which is relatively sane in the DM814x (although with some ugly hacks due to the understandable desire to retain as much of Netra's clock tree as possible while tossing out its FAPLLs), while on the AM335x it seems they shuffled the registers like a deck of cards.

    Oh, and the little detail that centaurus and subarctic have virtually identical ethernet switch subsystems, both located at the same address, but all the register subblocks have different offsets and some bitfields moved from one register to another...

     

    Michael Po said:

    Luckily, I changed job since I worked on the DM814x. I can't tell you the relief I felt not having to deal with that piece of t cr*p anymore :-)

    Actually that's not fair: so far the processor seems pretty nice, after a bit of learning curve of doing baremetal programming on it (since the software offering available... well, this thread seems to have some consensus on that so no need to add comments to it).  Luckily I have no need for video, so that simplifies things greatly of course (something like the C6A811x would have been a better match for us, but the whole C6-Integra line seems to have gone up in smoke).

    It's also funny how evident it made to me how bizarrely bloated software has gotten... I'm running a Forth system (compiler/interpreter) on the cortex-a8, which includes things like MMU/cache setup, NAND flash code, etc.  It loads a DSP application doing audio processing and an application which includes basic IPv6 networking onto one of the cortex-M3s (and I'm planning on putting the other two to work also soon -- yes, I got the cortex-M3 in the security subsystem operational too).  So far the main application is small enough to be loaded directly as "MLO" by the rom code, and while I have external RAM working I haven't found any use for it so far due to the plentitude of on-chip SRAM.

    ... yet u-boot needs to be loaded in two stages (with the first stage initializing external RAM) because it's too big to be loaded directly by ROM.  ... ... wat?

     

    Michael Po said:
    I will never, EVER take on a project with a TI processor, and will encourage /any/ other solution but TI.

    I'm not convinced the grass is greener elsewhere.  I do plenty of complaining about TI docs, but when people I know speak of "TI-quality" documentation, they mean that as a compliment.  For comparison, have you seen the "manual" of that broadcom thing that's on the raspberry pi?  Oh, and its chip errata are maintained by volunteers on a wiki because broadcom doesn't publish any official ones.

     

    Michael Po said:
    When you see the level of the answers people get

    It seems optimized for the typical level of questions ;-P  Ok to be fair I've also had cases here where the support guy clearly didn't read my post, but I've seen the same guy also put in real effort.  I think they may simply be a bit understaffed and the skim-post-and-paste-canned-answer procedure is the result of coping with the sheer volume of support questions.

  • Hi all,

    I would urge TI's management to read this thread very carefully. By skimping on engineering resources (some of whom are very good, but probably oversubscribed), you're shooting yourselves in the foot. This is not how you sell good silicon, or motivate good employees, or build good relationships with customers.

    First, there's a sizeable community of knowledgeable users who would very happily migrate to a modern kernel. This is a huge opportunity for you to gain goodwill and "free" engineering; as you can see, a few of us are willing to do a lot of the work ourselves. An explicit statement of support from TI could very quickly snowball into a usable, modern kernel release.

    Second, your repeated statement that "we support 2.6.37" is disingenuous. Your 2.6.37 tree is barely supported. Support interactions are occasionally very good, but mostly they just demonstrate a lack of dedication from TI. It's telling that you won't even integrate patches that fix obvious bugs.

    Both of these situations are working against you right now. Resolving either of them (obviously I'd prefer the first) would turn a really frustrating situation into a tolerable one, or even a great one.

    sincerely,
    Graeme

  • Michael Po said:

    and a binary compiler that is also from 2009, becuase the kernel won't even boot with something more recent.

    I just remembered I ran into that one when playing a bit with linux on the EVM quite some time ago (may have been the DM816x instead of DM814x but I doubt it matters):  the problem was that using a newer compiler exposed a kernel bug that had been known and fixed in mainline ages ago already. Googling some relevant keywords from the kernel panic easily led to the commit that fixed it, and it cleanly applied to the ti81xx tree and allowed compilation with the latest compiler release.

    Unfortunately I don't think I have that tree anywhere anymore, so I can't easily check which commit it was.  Hopefully the info above is sufficient to locate it if anyone cares.

  • Graeme Smecher said:

    First, there's a sizeable community of knowledgeable users who would very happily migrate to a modern kernel. This is a huge opportunity for you to gain goodwill and "free" engineering; as you can see, a few of us are willing to do a lot of the work ourselves. An explicit statement of support from TI could very quickly snowball into a usable, modern kernel release.

    Amen.  This doesn't only apply to code, but documentation as well:  I regularly spot mistakes in the TRM, and I've reported a few of them. Perhaps the corrections will be integrated into some future TRM (if and when one shows up), but so far it feels like I might as well have submitted my feedback into a black hole.  Ditto with errata I have reported. Needless to say, this is deeply unmotivating for me to invest any more of my time in trying to improve your documentation for the benefit of your other customers.  A process with clear feedback and fast integration would be highly valuable here (note that nowadays you can even fork the C++ standard on github).

    Releasing documentation that exists would also be a nice start.  If you don't want to officially support stuff that's in there then just clearly mark it as such just like you did with the unofficial release of PRUSSv2 docs of the AM335x (before it finally got re-added to the TRM anyway).  But, for example, it's completely silly that the TRM pretends the security subsystem doesn't exist and marks its memory as "reserved", while at the same time you guys released linux drivers for a large part of its functionality.

  • Dear All,

    Fortunately or unfortunately i have read this thread ...in spite of  strong discourage from Michale i have to do almost same thing  infect few  steps ahead i have to make HDVPSS and gstreeamer 1.0 also running on DM8148.

    so the idea is as below .

    1: Cross compile the Latest kernel 3.17.xx

    2:  Fix the bug apply our custom patches and make it run on our custom board.

    3: start porting Multi-media driver HDVSS and all

    4: compile Media component (first omx then gstream 0.10

    5: then move it to gstreamer 1.0

    6: put Intel based network card on PICe and enable AVB stack (qav/qat )

    any one can give me  in defth on changes specially first on driver porting of HDVPSS and second on gstreamer 1.0 AVB we can leave for moment.

    BR,

    KP

  • Robert C Nelson, beagleboard forum said:
    Check on linux-omap, Tony's been adding DM81xx support

    Woo!

    Of course basic booting won't get the video-related subsystems up and running, but it should help that:

    • IVA-HD (aka HDVICP2) is afaik identical across many devices (omap4/5, dm81xx, vayu)
    • ditto with the ("Ducati"/"Benelli") dual cortex M3/M4 subsystem (differing only in the core used), aka Media Controller (M3) / IPU (M4)
    • DM814x ISS is almost identical to that of omap4 (and the differences no bigger than those between omap4 and omap5)
    • DM814x and DM816x HDVPSS seem to consist of components quite similar to those of the VIP/VPE/DSS subsystems of Vayu (dra7xx / am57xx), albeit a different selection and arrangement. There's at least some support in mainline, and it also has (omg!) actual documentation in its public TRM.  Together with some DM814x-specifics one can gather from the basic boot-splash framebuffer support in the EZSDK u-boot (and by just peeking and poking around) it may actually be possible to get HDVPSS working without an NDA getting it the way of mainlining it.

    so although I'm not really familiar with how well supported those subsystems currently are, any efforts that are made for them in the name other SoCs (especially Vayu seems to be getting real attention, and will get even more when the beagleboard-x15 is released) will also benefit DM81xx once its basic mainline linux support is functioning.

    There may be some light at the end of the tunnel after all...