dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_mag -- Pass
dEQP-GLES3.functional.fbo.blit.rect.nearest_consistency_min -- Pass

This one was a fun geometry puzzle.

The problem

Mesa’s u_blitter is the utility that drivers use for framebuffer blits – copying pixel data between surfaces, optionally scaling and filtering. It works by drawing a textured quad: set up the source as a texture, the destination as a render target, and draw a rectangle with the appropriate texture coordinates. Simple.

Except the quad is made of two triangles. And that diagonal seam between them is where the trouble starts.

 v2 -------- v3
  |  \   T2  |
  | T1  \    |
  |       \  |
 v0 -------- v1

For LINEAR filtering, this is fine – the interpolation across the seam is smooth enough that nobody notices. But for NEAREST filtering, a texel is selected based on which texel center is closest to the interpolated texture coordinate. At the diagonal seam, the two triangles can produce slightly different texture coordinates for pixels that sit right on the boundary. Different coordinates mean different nearest-texel selection, and that means an inconsistent stripe of wrong texels running diagonally across the blit.

The dEQP nearest_consistency tests specifically check for this: they blit with NEAREST filtering and verify that every pixel picks the same texel regardless of which triangle it fell into.

What others do

This isn’t a new problem. V3D already has a workaround in u_blitter: it sets use_index_buffer to reorder the triangle indices so that the shared edge of the two triangles is along a different diagonal. This changes which pixels land on the seam and can be enough to pass the tests on some hardware.

On GC7000, that wasn’t sufficient. The floating-point interpolation differences are large enough that the seam remains visible regardless of which diagonal you pick.

What the blob does

Looking at command stream traces from the proprietary Vivante driver, the answer was clear: they don’t draw a quad at all. They draw a single oversized triangle and let the scissor clip it to the destination rectangle.

No seam, no problem.

The single triangle transform

The idea is simple: take a rectangle and find a single triangle that fully covers it. The smallest such triangle is a right triangle with legs twice the width and twice the height of the rectangle:

 v2
  |\
  |  \
  | rect\
  |------+\
  |      |  \
 v0 -----|--- v1

Vertex 0 stays at the rectangle’s top-left corner. Vertex 1 extends to twice the rectangle width. Vertex 2 extends to twice the rectangle height. The original rectangle is fully contained within this triangle.

The math for transforming the blitter’s 4-vertex quad into a 3-vertex triangle is:

for (unsigned a = 0; a < 2; a++) {      /* pos and texcoord */
   for (unsigned c = 0; c < 4; c++) {   /* xyzw components */
      float v0 = ctx->vertices[0][a][c];
      ctx->vertices[1][a][c] = 2.0f * ctx->vertices[1][a][c] - v0;
      ctx->vertices[2][a][c] = 2.0f * ctx->vertices[3][a][c] - v0;
   }
}

This transforms both position and texture coordinates consistently, so the texture mapping across the visible (scissored) region is identical to what the full quad would have produced – minus the seam.

Scissor is essential

The oversized triangle extends beyond the destination rectangle, so we need scissor to clip it. The blitter doesn’t always have a scissor set up, so when use_single_triangle is enabled, we synthesize one from the destination box:

if (ctx->base.use_single_triangle && !scissor) {
   synth_scissor.minx = MAX2(dstbox->x, 0);
   synth_scissor.miny = MAX2(dstbox->y, 0);
   synth_scissor.maxx = dstbox->x + dstbox->width;
   synth_scissor.maxy = dstbox->y + dstbox->height;
   scissor = &synth_scissor;
}

Keeping it scoped

The single-triangle transform should only apply to blit operations, not to clears or other blitter draws. A transient single_triangle_active flag is set around the actual blit draw calls and checked in the vertex emission code. Drivers opt in by setting use_single_triangle on the blitter context at creation time.

For etnaviv, that’s a single line:

ctx->blitter->use_single_triangle = true;

The design

The implementation is split into two commits: the u_blitter.c infrastructure (vertex transform, synthesized scissor, gating flag, 3-vertex draw path) that any driver can opt into, and the one-line etnaviv enablement. Keeping them separate means another driver hitting the same seam can flip the flag without touching u_blitter code.

The work landed upstream in u_blitter: Add single-triangle draw mode for NEAREST blit consistency.

The takeaway

Sometimes the fix for a rendering artifact isn’t better math or tighter tolerances – it’s removing the geometric feature that causes the problem in the first place. Two triangles have a seam. One triangle doesn’t.

The problem

Vivante GPUs have a quirk: the Pixel Engine (PE) always writes pixels in BGRA byte order. When your API says “render to R8G8B8A8_UNORM”, what actually lands in memory is B, G, R, A. Every byte of every pixel, every frame. The hardware just works that way.

The question is: where do you fix it?

The etnaviv driver was doing it in the shader. Before the fragment shader writes its output, a NIR lowering pass swaps the R and B channels:

   alu->src[0].swizzle[0] = 2;   /* .r reads from .b */
   alu->src[0].swizzle[2] = 0;   /* .b reads from .r */

This works, until it doesn’t. The shader key needs a frag_rb_swap bitmask per render target. The blend color needs per-RT R/B swapping to match. And it falls apart entirely for scalar outputs - if a shader writes a single float, there’s no .z component to swizzle into .x. That’s exactly the NIR validation failure we hit:

Test case 'dEQP-GLES3.functional.fragment_out.basic.fixed.rgb8_lowp_float'..
NIR validation failed after etna_lower_io in ../mesa/src/gallium/drivers/etnaviv/etnaviv_compiler_nir.c:1296
1 errors:
shader: MESA_SHADER_FRAGMENT
source_blake3: {0x4d463d73, 0x4b27d742, 0x27a92b64, 0x375c010f, 0xb2ce3767, 0x2adc55cc, 0x6da8105b, 0x5b9fce29}
name: GLSL1
prev_stage: MESA_SHADER_VERTEX
inputs_read: 32
outputs_written: 4
perspective_varyings: 32
max_subgroup_size: 128
min_subgroup_size: 1
api_subgroup_size_draw_uniform: true
first_ubo_is_default_ubo: true
known_interpolation_qualifiers: true
flrp_lowered: true
inputs: 1
outputs: 1
decl_var shader_in INTERP_MODE_SMOOTH none highp float packed:var0 (VARYING_SLOT_VAR0.x, 0, 0)
decl_var shader_out INTERP_MODE_NONE none mediump float out0 (FRAG_RESULT_DATA0.x, 0, 0)
decl_function main () (entrypoint)

impl main {
    block b0:  // preds:
    32    %3 = load_const (0x00000000)
    32    %4 = @load_input (%3 (0x0)) (base=0, range=1, component=0, dest_type=float32, io location=VARYING_SLOT_VAR0 slots=1)  // packed:var0
    32    %2 = deref_var &out0 (shader_out mediump float)
    32    %5 = mov %4.z
error: src->swizzle[i] < num_components (../mesa/src/compiler/nir/nir_validate.c:217)

               @store_deref (%2, %5) (wrmask=x, access=none)
               // succs: b1
    block b1:
}

FATAL ERROR: Test program crashed

What the blob does

Looking at command stream traces from the proprietary driver, the answer is almost disappointingly simple. Instead of this:

  Texture format: A8B8G8R8     (read BGRA as BGRA)
  PE format:      A8B8G8R8     (write BGRA)
  Shader:         swap R <-> B

The blob does this:

  Texture format: A8R8G8B8     (read BGRA as RGBA - hardware swaps on read)
  PE format:      A8B8G8R8     (write BGRA - unchanged)
  Shader:         nothing

That’s it. Tell the texture sampler the data is A8R8G8B8, and it will correctly interpret the BGRA bytes as RGBA channels. The PE keeps writing BGRA because that’s what it does. No shader modification needed.

In our format table, the change is a single field:

  -  VT(R8G8B8A8_UNORM, UNSIGNED_BYTE, A8B8G8R8, A8B8G8R8)
  +  VT(R8G8B8A8_UNORM, UNSIGNED_BYTE, A8R8G8B8, A8B8G8R8)
                                        ^^^^^^^^
                                     texture format

The data flow

To understand why this works, trace a red pixel through the pipeline:

                          BGRA-internal byte order
                         +------------------------+
                         |                        |
  API: glClear(1,0,0,1)  |   Memory: [0,0,255,255]|   CPU: expects [255,0,0,255]
  "red = 1.0"            |   (B=0, G=0, R=255,    |   "RGBA order"
                         |    A=255)              |
                         +------------------------+

  +-----------+     +--------+     +--------+     +---------+
  | Shader    |     | PE     |     | Memory |     | Sampler |
  | out=RGBA  | --> | writes | --> | stores | --> | reads   |
  | (1,0,0,1) |     | BGRA   |     | BGRA   |     | as      |
  |           |     |        |     | bytes  |     | A8R8G8B8|
  +-----------+     +--------+     +--------+     +---------+
       |                |               |              |
    R=1.0            B=0x00          [00 00 FF FF]   R=1.0
    G=0.0            G=0x00                          G=0.0
    B=0.0            R=0xFF                          B=0.0
    A=1.0            A=0xFF                          A=1.0

The shader writes (1,0,0,1). The PE swaps R/B on write, so memory gets [0,0,255,255] in BGRA order. The sampler, told the format is A8R8G8B8, reads those same bytes back as (1,0,0,1). Round-trip complete, no shader involvement.

The CPU boundary problem

GPU-to-GPU is clean. But what happens at the CPU boundary - glReadPixels, glTexSubImage, glBlitFramebuffer to a CPU-mapped buffer? The CPU expects RGBA byte order. Memory has BGRA. Something needs to swap.

This is where the hardware copy/resolve engines come in - RS and BLT. Both can perform R/B swapping during their copy operations. The RS engine has a swap_rb bit. The BLT engine has per-side swizzle fields. We just need to activate this at the right moment.

The key insight: only transfer blits (tiled-to-linear copies for CPU access) need the swap. GPU-internal blits - glBlitFramebuffer between two render targets, TS resolve, mipmap generation - are all operating on data already in BGRA order on both sides. Swapping there would be wrong.

So we gate it with a context flag:

ctx->in_transfer_blit = true;
etna_copy_resource_box(pctx, trans->rsc, &rsc->base, ...);
ctx->in_transfer_blit = false;

And in the RS blit path:

.swap_rb = ctx->in_transfer_blit &&
           translate_pe_format_rb_swap(blit_info->src.format),

The texture shadow trap

With the basic approach working, tests passed on GC7000 (BLT engine). But GC2000 (RS engine) had a regression: fbo-blit showed blue where red should be.

After adding debug prints and tracing the code paths, the culprit was the texture shadow. Some resources can’t be sampled directly by the texture unit - for example, a render target might use a layout the sampler doesn’t understand. For these, the driver allocates a second copy of the resource in a sampler-compatible tiled layout. This is the “texture shadow”.

The shadow is a workaround that hurts performance - it means extra memory and extra copies. Ideally we wouldn’t need it at all. But while it exists, the driver uses it as a shortcut for CPU transfers: read directly from the shadow and detile in software, skipping the blit engine:

Passing probes:  PATH=temp_resource+RS_blit    swap_rb=1   -> correct
Failing probes:  PATH=texture_shadow                       -> R/B swapped

The texture shadow path does a software detile - raw byte copy, no R/B swap. With BGRA-internal byte order, that gives you BGRA bytes on the CPU side. Wrong.

The fix: skip the texture shadow shortcut for formats that need R/B swap, forcing through the blit engine path which handles the conversion:

if (rsc->texture && !etna_resource_newer(rsc, etna_resource(rsc->texture)) &&
    !translate_pe_format_rb_swap(prsc->format)) {
   /* Use texture shadow - safe, no R/B swap needed */
   rsc = etna_resource(rsc->texture);
} else {
   /* Use blit engine - handles R/B swap correctly */
   ...
}

Results

This is a net-negative patch series - 15 files changed, 76 insertions, 113 deletions. The etnaviv: Remove RB swap logic in the fragment shader contains all that’s needed:

1. blt: Use img->swizzle for CONFIG SWIZ fields - preparation for per-image swizzle support
2. Add translate_pe_internal_format helper - maps RGBA pipe formats to BGRA equivalents for clear color packing
3. Use BGRA-internal texture format with BLT/RS R/B swizzle - the main change
4. Compute blend color directly in etna_set_blend_color - simplifies blend color, no deferred update needed

Fixes the NIR validation failure with scalar fragment outputs. And as a nice side effect, removing the shader-based swap means fewer shader variants, fewer instructions and less overhead. glmark2-es2-wayland improves from ~835 to ~874 FPS - a 4.7% performance increase.

Sometimes matching what the hardware vendor does is the right answer. The blob driver figured this out years ago. We just needed to look at the traces.

That’s where I thought the story ended

The texture-format trick has a hidden assumption baked into it: that the GPU both writes and reads every resource. The PE writes BGRA, the sampler is told the format is A8R8G8B8, and the byte order cancels out. It’s a closed loop, and as long as the data never leaves the GPU, nobody outside ever sees the BGRA bytes.

dmabuf breaks the loop.

When a buffer is shared with another process - a Wayland compositor, a video decoder, a camera - the byte order is no longer our private business. It’s mandated by the DRM FourCC. An external producer writes honest RGBA bytes into the buffer. Then our sampler, still convinced the format is A8R8G8B8, reads them as BGRA. Red and blue swap. And on the way out, a transfer blit happily swaps data that was already correct. The optimization that made GPU-internal rendering clean made buffer sharing wrong.

  GPU-internal (closed loop):       dmabuf (loop broken):

  PE writes BGRA                    external producer writes RGBA
       |                                  |
  sampler reads as A8R8G8B8         sampler reads as A8R8G8B8
       |                                  |
  cancels out -> correct            reads RGBA as BGRA -> swapped

Step back out for shared resources

The first fix is the obvious one: when a resource is shared, don’t play the trick. Use the native A8B8G8R8 texture format so the sampler reads RGBA bytes as RGBA, skip the R/B swizzle in the BLT and RS transfer blits, and re-enable the texture shadow shortcut that the swizzle had forced us to disable. Internal resources keep the BGRA-internal optimization untouched.

That handles imports. But there’s a case it doesn’t cover: a resource we rendered into and then export. The PE wrote BGRA, because that’s all the PE knows how to do. The external consumer expects native order.

Here a second kind of shadow shows up. Just as the sampler gets a texture shadow when it can’t read the base layout, the PE gets a render shadow - a render-compatible copy - when it can’t draw into the base layout. (On some GPUs, like GC2000, no single tiling satisfies both the texture engine and the pixel engine, so a resource can end up carrying both shadows.) When an exported resource is flushed, that render shadow is resolved back to the base. So we hook etna_flush_resource() and do the R/B swap during that copy - using the BLT destination swizzle or the RS SWAP_RB bit. The swap rides along on a copy we were doing anyway.

One buffer, two byte orders

Now the same shared buffer can be in one of two states. Just imported, or just flushed for export? Native RGBA. Freshly rendered by the PE, not yet flushed? PE-internal BGRA. A static texture format chosen at sampler-view creation can’t be right for both.

So the format choice becomes dynamic. A shared_native_order flag tracks which order the bytes are currently in, and the sampler-view format follows from it:

Both texture paths - state-based and descriptor-based - pre-compute the native format variant at sampler-view creation, so picking the right one at emit time costs a single branch, not a per-frame format recompute.

The shader swap comes back

Which brings us to LINEAR_PE GPUs, and a twist I didn’t see coming.

On these GPUs, a linear shared resource is render-compatible. There is no render shadow - the PE writes straight into the buffer that gets handed to the compositor. So after a draw, the buffer holds BGRA, and flush_resource() would have to issue a full-surface blit to swap it. That’s real bandwidth, on every frame, that the old shadow-based path never paid.

There’s a cheaper place to do the swap: in the shader, on the way out. Which is exactly the thing this whole series set out to delete.

So it comes back - but only for this one case, and done properly. A per-RT frag_rb_swap bitmask in the shader key drives a NIR lowering pass that swaps channels 0 and 2 on the fragment output. The original shader swap fell over on scalar outputs, because there was no .z to swizzle from. This one widens the output variable to vec4 first, padding the missing components with undef, then applies the swizzle with an adjusted writemask:

   /* Pad source to 4 components (undef for missing) */
   nir_def *padded = nir_pad_vec4(&b, src);

   /* Swap R and B channels */
   unsigned swiz[] = {2, 1, 0, 3};

That’s the scalar rgb8_lowp_float crash from the top of this post - fixed, in the one path that now needs a shader swap at all.

Wiring it up is a check in etna_draw_vbo():

   if (VIV_FEATURE(screen, ETNA_FEATURE_LINEAR_PE)) {
      for (i = 0; i < pfb->nr_cbufs; i++) {
         struct etna_resource *rsc = etna_resource(pfb->cbufs[i].texture);
         if (rsc->shared && rsc->layout == ETNA_LAYOUT_LINEAR &&
             translate_pe_format_rb_swap(pfb->cbufs[i].format))
            key.frag_rb_swap |= (1 << i);
      }
   }

The bitmask is per-RT, so an MRT setup with a mix of shared and private targets does the right thing for each. And because the shader produced native bytes directly, shared_native_order stays true and flush_resource() skips its blit entirely.

The fixes for all of this live in a follow-up series, etnaviv: Fix dmabuf R/B byte order for PE_FORMAT_RB_SWAP formats.

So was removing the shader swap a mistake?

No - but it wasn’t the whole answer either.

The shader swap was wrong as the universal solution. It cost a shader-key dimension, per-RT blend-color fixups, and it crashed on scalar outputs. The texture-format trick is genuinely better for the common case, where a resource lives and dies on the GPU.

What the dmabuf work showed is that there is no single right place to fix R/B order. There’s a place that’s cheapest for each path: the texture format for GPU-internal resources, a transfer-blit swap at the CPU boundary, a flush-time swap for exported render targets, and - for LINEAR_PE, where the PE writes straight into a shared buffer - the shader, after all. The trick isn’t picking one. It’s knowing which boundary you’re standing on, and swapping there.

Spoiler: it was a busy one.

The landscape

PanVK - the Vulkan driver for Arm Mali GPUs (Valhall and newer) - is a collaborative effort. Collabora has been doing incredible work on the compiler backend and the foundational infrastructure. Arm themselves are actively contributing to the open source Mali GPU stack as well, reviewing patches and pushing driver quality forward. On the Igalia side, my focus this cycle was Vulkan extension coverage. The kind of work that doesn’t make for flashy demos but is absolutely critical for real-world application compatibility - especially for things like DXVK.

Why extensions matter

A Vulkan driver without extensions is like a car without wheels - technically complete, practically useless. Applications (and translation layers like DXVK, vkd3d-proton, and Zink) probe for specific extensions and adjust their behavior accordingly. Missing even one can mean falling back to a slower path or refusing to run entirely.

Three different things drove the extension work this cycle:

• The Proton stack - extensions consumed by DXVK and vkd3d-proton, the translation layers that make D3D9–12 games run on Vulkan.
• DDK feature parity - extensions Arm’s binary Mali driver exposes that PanVK didn’t yet, tracked in the DDK feature parity ticket.
• Catching up on mesamatrix.net - closing the visible gap with the other Mesa Vulkan drivers (RADV, ANV, Turnip).

So I set out to close gaps. Lots of them.

The Proton stack essentials

These are extensions DXVK and vkd3d-proton actually require - not just nice-to-haves on a recommendation list. Each one unblocks something concrete in the D3D-to-Vulkan translation path.

VK_EXT_conditional_rendering (!40452) was probably the most involved piece of work. D3D12 has predicated rendering (SetPredication), and vkd3d-proton uses this extension to implement it efficiently. It wasn’t a simple “flip a bit” situation - I had to add the core state tracking, wrap all draw and dispatch calls with conditional checks, handle inherited state in secondary command buffers, and make sure meta operations (like internal clears and resolves) properly disable conditional rendering so they don’t get accidentally skipped. That ended up being five patches touching draw paths, dispatch, and the secondary command buffer inheritance logic.

VK_VALVE_mutable_descriptor_type (!40254) is one of those extensions that exists purely because Valve needed it. In D3D, descriptor types are more fluid than in Vulkan - a descriptor slot might hold a sampler one frame and a storage buffer the next. vkd3d-proton enables this to avoid expensive descriptor set re-creation when types change. It’s a trivial alias of the already-supported VK_EXT_mutable_descriptor_type, so enabling it was a one-liner.

VK_EXT_memory_budget (!40246) lets applications (and both DXVK and vkd3d-proton) query how much GPU memory is actually available versus how much is in use. Without it, apps are flying blind on memory management, which can lead to over-allocation and stuttering. Getting the heap budget reporting right required hooking into the kernel memory accounting.

VK_EXT_attachment_feedback_loop_layout (!40498) - feedback loops let you read from an attachment that you’re simultaneously rendering to (think screen-space effects that sample the current framebuffer). DXVK uses this in its D3D9 hazard layout path to avoid artifacts in certain games.

VK_EXT_shader_stencil_export (!39944) - allows fragment shaders to write stencil values directly, rather than relying on the fixed-function stencil path. DXVK leans on this in its meta-copy and meta-resolve paths, and vkd3d-proton enables it too. The Panfrost stack already supported everything needed; literally a one-line advertisement in physical_device.c.

VK_KHR_shader_untyped_pointers (!40457, v9+) - a newer KHR extension that relaxes pointer type requirements in SPIR-V. DXVK calls this out as a dependency for descriptor heaps. Restricted to v9+ because Bifrost has issues with 8-bit vector loads through untyped pointers combined with 16-bit storage. Also needed to lower memcpy derefs before explicit IO lowering.

Catching up to the DDK

The panfrost keeps a DDK feature parity ticket tracking everything Arm’s binary Mali driver exposes that PanVK doesn’t yet. Four of those got crossed off this cycle:

• VK_ARM_scheduling_controls (!40063, CSF only) - an ARM-specific extension for controlling shader core scheduling on Command Stream Frontend (CSF) hardware. I also fixed the per-queue shader core count so CSF group creation uses the right values.
• VK_EXT_legacy_dithering (!39781) - implements ordered dithering in the blending stage, which some applications expect from legacy APIs. Wired up the existing Panfrost dithering infrastructure (pan_dithered_format_from_pipe_format()) — just plumbing the VK_RENDERING_ENABLE_LEGACY_DITHERING_BIT_EXT flag through the blend descriptor and color attachment internal conversion paths.
• VK_EXT_rgba10x6_formats (!40653) - a last-minute addition that just squeezed in before the branch point. This required adding the PIPE_FORMAT_X6R10X6G10X6B10X6A10_UNORM format to Mesa’s gallium format table first, then wiring it up in PanVK. Used for 10-bit per channel content in video and HDR scenarios.
• VK_EXT_astc_decode_mode (!39799) - controls the format used when decoding ASTC compressed textures, allowing apps to choose lower-precision decoding for performance. The Panfrost hardware already supports controlling ASTC decode precision via the Decode Wide plane descriptor field; just needed to parse VkImageViewASTCDecodeModeEXT from the image view pNext chain and set astc.narrow accordingly. v9+ only because the relevant ASTC plane descriptor fields only exist from Valhall onward.

Catching up on mesamatrix

mesamatrix.net tracks Vulkan extension support across the Mesa drivers. The remaining extensions this cycle were about closing the visible gap with RADV, ANV, and Turnip — extensions that don’t have a single big consumer driving them, but whose absence shows up as red squares on the matrix and as silent fallbacks in apps that probe for them.

• VK_EXT_color_write_enable (!39913) - per-attachment control over which color channels actually get written. The common Vulkan runtime already handled all the pipeline state and dynamic command plumbing, and panvk’s blend descriptor emission was already consuming color_write_enables, so this was effectively an “advertise the feature” change.
• VK_EXT_depth_clamp_control (!39925) - lets applications specify a custom depth clamp range instead of always clamping to the viewport’s minDepth/maxDepth. Mali GPUs have native LOW_DEPTH_CLAMP/HIGH_DEPTH_CLAMP registers, so it was a matter of wiring the existing runtime state through to those.
• VK_EXT_attachment_feedback_loop_dynamic_state (!40498) - the dynamic-state companion to VK_EXT_attachment_feedback_loop_layout above; lets you toggle feedback-loop state per draw call without pipeline rebuilds.
• VK_EXT_map_memory_placed (!40315) - lets applications control where in their virtual address space GPU memory gets mapped. This simplified pan_kmod_bo_mmap() to always map the whole BO, cleaning up the kernel module interface.
• VK_EXT_shader_atomic_float (!40506) - atomic operations on float values in shaders. The existing axchg instruction is type-agnostic, so no compiler changes were needed; image atomics are already lowered to global atomics. Just had to add R32_FLOAT to the storage-image-atomic format flag.
• VK_EXT_nested_command_buffer (!40120, v10+) - allows secondary command buffers to call other secondary command buffers. The CSF backend’s cs_call() is a hardware call/return instruction that nests naturally, and the existing CmdExecuteCommands already does the caller/callee state merging. The 8-level hardware call stack, minus one for the kernel ringbuffer call and two reserved for future driver use, leaves maxCommandBufferNestingLevel at 5.
• VK_EXT_image_view_min_lod (!39938) - allows clamping the minimum LOD at the image view level rather than just the sampler. Mali v6+ has per-texture-descriptor LOD clamp fields independent from the sampler’s, so this just plumbs vk_image_view::min_lod through pan_image_view into the texture descriptor — no shader lowering or descriptor merging needed.
• VK_EXT_zero_initialize_device_memory (!39658) - guarantees that newly allocated device memory is zeroed. The kernel side already does the heavy lifting — panfrost/panthor use drm_gem_shmem, which serves zeroed pages from the shmem subsystem. And since panvk treats layout transitions as no-ops, VK_IMAGE_LAYOUT_ZERO_INITIALIZED_EXT falls out for free. (Did need one format-table fix: dropping STORAGE_IMAGE support from compressed formats to avoid crashes in the new dEQP tests.)

By the numbers

That’s 18 extensions across roughly a dozen merge requests - ranging from single-patch additions to multi-patch series like conditional rendering. Collectively they represent a meaningful shift in what PanVK can claim to support: more of the Proton stack working out of the box, four more checkboxes against the DDK, and fewer red squares on the mesamatrix.

What’s next

The extension sprint isn’t over - there are still gaps to fill, and each one removed makes PanVK more viable for real workloads. But 26.1 was a good milestone. The driver is getting to the point where you can throw a DXVK game at it and have a reasonable expectation that it just works.

Back to it. ⚡

Where We Are

etnaviv has supported GLES2 on Vivante GPUs for a long time. GLES3 support has been progressing steadily, but the remaining dEQP failures are the stubborn ones - the cases where the hardware doesn’t quite do what the spec says, and the driver has to get creative.

These aren’t missing feature bits or unimplemented extensions. These are the problems where you stare at a command stream trace from the proprietary blob driver and realize they’re doing something completely different from what you’d expect, because the hardware has a quirk that nobody documented.

The Approach

My workflow for each fix follows a pattern:

1. Run the failing dEQP test, note the failure mode (wrong pixels, crash, GPU hang)
2. Capture command stream traces from both the blob (proprietary driver) and etnaviv for the same test
3. Compare the traces - what states differ? What draw calls differ? Is the blob doing extra work?
4. Understand why - read the spec, reason about the hardware behavior, figure out what the blob knows that we don’t
5. Implement the fix in Mesa, test, iterate

The blob traces are invaluable. Vivante’s proprietary driver has years of hardware workarounds baked in. When something doesn’t work, the answer is usually hiding in the trace.

The Hardware

The primary test target is a GC7000 rev 6214 (HALTI5 generation). This is a capable GPU found in the NXP i.MX8MQ SoC. It has a BLT engine, texture descriptors, and most of the features needed for GLES3 - but also its own set of rasterization quirks and interpolation behaviors that need workarounds.

In the future, I plan to expand the focus to the broader GC7000 GPU family.

Up Next

The first post will tackle the R/B swap problem - the PE always writes pixels in BGRA byte order, and we’ve been fixing it in the shader. The blob has a simpler answer. Stay tuned.

Following Along

All of this work happens upstream in Mesa.

If you’re interested in GPU driver development, these posts aim to show what the work actually looks like – not just the final patch, but the debugging, the trace analysis, and the reasoning that gets you there.

Why this extension?

A customer needed advanced blending support in lavapipe, so the extension choice was made for me. But it turned out to be a great fit for a first extension - useful, self-contained, and not a multi-month rabbit hole. Standard Vulkan blending is limited to basic operations like add and subtract with blend factors. That’s fine for most rendering, but if you want Photoshop-style effects - multiply, screen, overlay, color dodge, color burn - you’re stuck doing it manually in shaders or with extra render passes.

The extension adds 19 blend operations that handle all of this in the fixed-function pipeline. Useful for UI toolkits, image editors, and anywhere you need creative compositing.

The journey

What started as “just wire up an extension” turned into a proper refactoring adventure. The existing blend infrastructure in Mesa was scattered - OpenGL had its own enum definitions, Vulkan had separate conversions, and the actual NIR blend math lived in glsl-specific code.

So I took a step back and cleaned things up. Moved the blend mode enums into a shared util/blend.h header. Added proper helpers in the Vulkan runtime for converting between API types. Then came the fun part: implementing the actual blend equations in nir/lower_blend.

Each of those 19 blend modes has its own formula from the spec. Some are simple (multiply is just src * dst), others get hairy with conditionals and special cases for luminosity and saturation. About 570 lines of NIR code later, I had a lowering pass that any Mesa driver can use.

For example, here’s how the spec defines advanced blending. Each mode plugs into a general equation:

RGB = f(Cs,Cd) * X * p0 + Cs * Y * p1 + Cd * Z * p2
A   =            X * p0 +      Y * p1 +      Z * p2

Where p0, p1, p2 are weighting factors based on source/destination alpha coverage, and f(Cs,Cd) is the per-mode blend function. For overlay - probably the most recognizable blend mode from Photoshop - the spec defines:

f(Cs,Cd) = 2*Cs*Cd,              if Cd <= 0.5
           1 - 2*(1-Cs)*(1-Cd),  otherwise

And here’s that same formula expressed as NIR - Mesa’s intermediate representation:

static inline nir_def *
blend_overlay(nir_builder *b, nir_def *src, nir_def *dst)
{
   /* f(Cs,Cd) = 2*Cs*Cd, if Cd <= 0.5
    *            1-2*(1-Cs)*(1-Cd), otherwise
    */
   nir_def *rule_1 = nir_fmul(b, nir_fmul(b, src, dst), imm3(b, 2.0));
   nir_def *rule_2 =
      nir_fsub(b, imm3(b, 1.0),
               nir_fmul(b, nir_fmul(b, nir_fsub(b, imm3(b, 1.0), src),
                                        nir_fsub(b, imm3(b, 1.0), dst)),
                         imm3(b, 2.0)));
   return nir_bcsel(b, nir_fge(b, imm3(b, 0.5f), dst), rule_1, rule_2);
}

nir_fmul, nir_fsub, nir_bcsel - multiply, subtract, conditional select. Each call builds a node in the shader’s IR graph. This is what “lowering” looks like: translating a high-level blend mode into operations the GPU’s shader core can execute. The outer framework - the p0/p1/p2 weighting - is handled by the caller; each blend function just implements its f(Cs,Cd).

The Turnip surprise

Everything was working on Honeykrisp, tests were passing, life was good. Then the merge pipeline started failing - on Turnip (the Adreno Vulkan driver). Not my code, not my hardware, but my changes were breaking it.

I reached out for help, and Zan Dobersek stepped up. After some digging, he found the culprit: I was violating a subtle corner of the spec around attachmentCount. Turns out, when certain dynamic states are set and advancedBlendCoherentOperations isn’t enabled, attachmentCount gets ignored entirely. My state tracking code wasn’t accounting for that.

One fixup commit later, Turnip was happy again. This is the part they don’t tell you about Vulkan extensions - you’re not just implementing for your driver, you’re touching shared infrastructure that every driver depends on. And the Mesa CI will absolutely let you know if you break something.

lavapipe landed

One week later, lavapipe has it too. This was the original goal, and the shared infrastructure did exactly what it was supposed to - the lavapipe MR is mostly just flipping the extension on. The lowering pass, the enum plumbing, the runtime helpers - all reused as-is. The full dEQP-VK.pipeline.*.blend_operation_advanced.* test suite passes on both drivers.

Two drivers in two weeks. That’s what building the right abstractions gets you.

What’s next

The shared NIR lowering pass is there for any Mesa Vulkan driver to use. If your hardware doesn’t have native advanced blending support, enabling the extension is now mostly plumbing. I’m curious to see if other drivers pick it up.

For me, this was a good first step into Vulkan - and into working on Honeykrisp. I’m looking forward to what comes next.

The Honeykrisp/NIR MR and the lavapipe MR are both merged if you want to look at the code. Thanks to Alyssa Rosenzweig for the review and guidance, and to Zan Dobersek for debugging the Turnip regression with me.

With the latest release of Mesa 24.03 and the commitment from Igalia, the etnaviv GPU driver now includes support for MRTs. If you’ve ever wondered how MRTs can transform your graphics pipeline or are curious about the challenges of implementing this feature, this blog post is for you.

Understanding Multiple Render Targets (MRTs)

At its core, MRTs allow rendering to multiple images or “render targets” simultaneously during a single rendering pass. These render targets are buffers or textures that store various scene data such as color, depth, or normals. By writing to multiple targets at once, MRTs enable developers to:

• Enhance efficiency by reducing the number of rendering passes.
• Implement sophisticated rendering techniques, such as deferred shading, which decouples geometry processing from lighting and shading.

Here’s a simple OpenGLES shader example demonstrating how to use MRTs:

// Vertex Shader
layout(location = 0) in vec2 inPosition;

void main() {
    gl_Position = vec4(inPosition, 0.0, 1.0);
}

// Fragment Shader
layout(location = 0) out vec4 fragColor1;
layout(location = 1) out vec4 fragColor2;

void main() {
    fragColor1 = vec4(1.0, 0.0, 0.0, 1.0); // Red
    fragColor2 = vec4(0.0, 0.0, 1.0, 1.0); // Blue
}

This code renders two render targets: one red and one blue, by declaring two output locations in the fragment shader and writing different colors to each of them.

How MRTs Are Used

MRTs play an important role in graphics applications. Here are some of their most common use cases:

1. Deferred Rendering

MRTs are the backbone of deferred shading, a technique where scene geometry is rendered to multiple targets, storing data like positions, normals, and albedo. This data is then processed in a second pass to calculate lighting, enabling advanced effects like dynamic shadows and screen-space reflections.

2. Post-Processing Effects

By writing intermediate results to multiple targets, MRTs facilitate a wide range of effects, including bloom, depth of field, and ambient occlusion.

3. Debugging and Visualization

Developers can output different types of scene data simultaneously for debugging or creating visualizations.

Implementing MRTs in etnaviv

Adding MRT support to the etnaviv driver involved significant reverse engineering and experimentation. Here’s a look at some of the challenges and solutions:

Reverse Engineering the GPU

The reverse engineering process begins with examining the limits exposed by the binary blob driver, such as the value returned by GL_MAX_DRAW_BUFFERS. Different Vivante GPU generations (HALTI) support varying numbers of render targets, requiring repeated testing and analysis.

Lay the foundation

I started with Freedreno’s test-mrt-fbo to get a rought idea of what needed to be done. Hours later, I identified most of the necessary bits and GPU states I had seen in the command stream dumps generated by the proprietary driver.

The first goal was to get a very basic piglit MRT test working on the GC7000 (HALTI5) GPU, rendering correctly with etnaviv. In this phase of reverse engineering, I usually hack around in the driver and my git commit history is full of ‘hack/wip’ commits. This helps me keep track of the (breaking) changes I make during the process.

Looking at the changes I had made until here, it was clear that I had touched nearly every part of the gallium driver. It started with compiler changes to handle the extra color outputs and ended with the extra MRT states that needed to be emitted. And, to be honest, at this stage I also had broken some other CTS and piglit tests, but that was something to be taken care of later.

When I tried some more complex piglit tests that used sparse render targets, I saw that they failed and realized, after reverse-engineering the proprietary driver some more, that I needed to work on remapping some information provided by NIR in Mesa about fragment shader outputs into compressed info the driver needed. That didn’t make all relevant Piglit tests pass, but I was getting close.

Will it work on another GPU?

The branch was then tested on older Vivante GPUs, like the GC3000 (HALTI2). None of the tests passed initially, as state emissions differed and the maximum MRT count was lower (4 vs. 8). Updating the state emission logic addressed these issues.

Whats wrong with the Tile Status?

As I always want to provide the best experience for all etnaviv users, I wanted to support this shiny new feature even on a much older Vivante GPU generation - GC2000 (HALT0) found in i.MX6 boards.

My hopes where high that my git branch would just work but, as usual, I was wrong. The traces from the vendor driver showed something interesting. There was no tile status (TS) usage found in the traces and I could confirm piglit was happy when I used ETNA_MESA_DEBUG=no_ts.

You might wonder that the ominous Tile Status might be. Let me give you a quick summary.

A render target is divided in tiles, and every tile has a couple of status flags. An auxiliary buffer - the so called Tile Status buffer - associated with each render surface keeps track of these tile status flags. One of these flags is the clear flag, that signifies that the tile has been cleared. For example, a fast clear happens by setting the clear bit for each tile instead of clearing the actual surface data.

I found a way to fix this problem too and then moved to CI.

CI to test them all

If you’ve followed me until here, you know that I worked on one HALTI and moved to another and never tested if I had broken any of the other HALTI’s. It was time to let etnaviv’s CI do its work and, as expected, I discovered I had broken HALTI5. After a local debugging session I got it into a working state. While I was very close to being ready to submit an MR and incorporate review feedback, there was one last thing I need to take care of…

HALTI5+ Enhancements for MRTs

It turns out that a HALTI5 GPU can support more OpenGL extensions as it has even more GPU states that fall under the MRT umbrella. The MRT ground work that was already in place allowed me to implement the following ones:

1. GL_EXT_draw_buffers2

This extension allows independent blending and write masking for each render target in an MRT setup. Developers can specify unique blending equations and masks for each target, offering unparalleled control over how data is combined.

2. GL_ARB_draw_buffers_blend

This feature extends blending capabilities even further, enabling per-buffer blending equations and functions. It’s especially useful for advanced rendering pipelines, such as deferred shading and post-processing, where different render targets may require entirely distinct blending behaviors.

Conclusion

With the addition of MRT support and the powerful HALTI5+ enhancements like GL_EXT_draw_buffers2 and GL_ARB_draw_buffers_blend, the etnaviv driver has reached a significant milestone.

MRT support is also a key feature for achieving full GLES3 compliance, marking a step forward in modernizing the capabilities of the etnaviv driver.

For detailed reverse engineering results, check out this repository, which uses the rnndb format to describe GPU states and bits. The MRT specific changes can be found in this commit.

What’s next? Stay tuned for more updates on the etnaviv driver as we continue to push more features upstream.

I’m not the first one at Igalia to think this is really important. We already have a large Raspberry Pi board farm available on freedesktop’s GitLab instance that serves as a powerful tool for validating changes before they hit the main branch.

For a while, however, the etnaviv board farm has been offline. The main reason? I needed to clean up the setup: re-house it in a proper rack, redo all the wiring, and add more devices. What initially seemed like a few days’ worth of work spiraled into months of delay, mostly because I wanted to transition to using ci-tron.

Getting Familiar with the Ci-Tron Setup

Before diving into my journey, let’s quickly cover what makes up a ci-tron board farm.

• Ci-Tron Gateway: This component is the central hub that manages devices.
• PDU (Power Delivery Unit): A PDU is a device that manages the electrical power distribution to all the components in the CI farm. It allows you to remotely control the power, including power cycling devices, which is crucial for automating device management.
• DUT (Device Under Test): The heart of the CI farm—these are the devices where the actual testing happens.

The Long Road to a Working Farm

Over the past few months, I’ve been slowly preparing for the big ci-tron transition. The first step was ensuring my PDU was compatible. It wasn’t initially supported, but after some hacking, I got it working and submitted a merge request (MR). After a few rounds of revisions, it was merged, expanding ci-tron’s PDU support significantly.

The next and most critical step was getting a DUT to boot up correctly. Initially, ci-tron only supported iPXE as a boot method, but my devices are using U-Boot. I tried to make it work anyway, but the network initialization failed too often, and I found myself sinking hours into debugging.

Thankfully, rudimentary support for a U-Boot based boot flow was eventually added. After some tweaks, I managed to get my DUTs booting — but not without complications. A major problem was getting the correct Device Tree Blob (DTB) to load, which was needed for ci-tron’s training rounds. A Device Tree Blob (DTB) is a binary representation of the hardware layout of a device. The DTB is used by the Linux kernel to understand the hardware configuration, including components like the CPU, memory, and peripherals. In my case, ensuring that the correct DTB was provided was crucial for the DUT to boot and be correctly managed by ci-tron. While integrating the DTB into U-Boot was suggested, it wasn’t ideal. Updating the bootloader just to change a DTB is cumbersome, especially with multiple devices in the farm.

With the booting issue taking up too much time, I decided to put it on hold and focus on something else: gfxinfo.

Gfxinfo Integration Challenges

gfxinfo is a neat feature that automatically tags a DUT based on the GPU model in the system, avoiding the need for manually assigning tags like gc2000. In theory, it’s very convenient—but in practice, there were hurdles.

gfxinfo tags Vivante GPUs using the device tree node information. However, since Vivante GPUs are quite generic, they don’t have a specific model property that uniquely identifies them. The plan was to pull this information using ioctl() calls to the etnaviv kernel driver. It took a lot of back and forth in review due to the internal gfxinfo API being under-documented, but after a lot of effort, I finally got the necessary code merged. You can find all of it in this MR.

Final Push: Getting Everything to Boot

There was still one major obstacle — getting the DUT to boot reliably. Luckily, mupuf was already working on it and made a significant MR with over 80 patches to address the boot issues. Introducing “boots db,” a feature designed to decouple the boot process, granting full control over DHCP, TFTP, and HTTP servers to each job. This is paired with YAML configurations to flexibly define the boot specifics for each board.

As of a few days ago, the latest official ci-tron gateway image contains everything needed to get an etnaviv DUT up and running successfully.

I have to say, I’m very impressed with the end result. It took a lot longer than I had anticipated, but we finally have a plug-and-play CI farm solution for etnaviv. There are still a few missing features—like Network Block Device (NBD) support and some advanced statistics—but the ci-tron team is doing an excellent job, and I’m optimistic about what’s coming next.

Conclusion: A Long Road, but Worth It

The journey to get the etnaviv board farm back online was longer than expected, full of unexpected challenges and technical hurdles. But it was worth it. The result is a robust, automated solution that makes CI testing easier and more reliable for everyone. With ci-tron, it’s easier to find and fix problems before they ever make it into the code base, which is exactly what a good CI setup should be all about. There is still some work to be done on the GitLab side to switch all etnaviv jobs to the new board farm.

If you’re thinking about setting up your own CI farm or migrating to ci-tron, I hope my experience helps smooth the road for you a bit. It might be a long journey, but the end results are absolutely worth it.

The first time I heard about isaspec, I was blown away by the possibilities it opens. I am really thankful that Igalia made it possible to complete this crucial piece of core infrastructure for the etnaviv GPU stack.

If isaspec is new to you, here is what the Mesa docs have to tell about it:

isaspec provides a mechanism to describe an instruction set in XML, and generate a disassembler and assembler. The intention is to describe the instruction set more formally than hand-coded assembler and disassembler, and better decouple the shader compiler from the underlying instruction encoding to simplify dealing with instruction encoding differences between generations of GPU.

Benefits of a formal ISA description, compared to hand-coded assemblers and disassemblers, include easier detection of new bit combinations that were not seen before in previous generations due to more rigorous description of bits that are expect to be ‘0’ or ‘1’ or ‘x’ (dontcare) and verification that different encodings don’t have conflicting bits (i.e. that the specification cannot result in more than one valid interpretation of any bit pattern).

If you are interested in more details, I highly recommend Rob Clark’s introduction to isaspec presentation.

Target ISA

Vivante uses a fixed-size (128 bits), predictable instruction format with explicit inputs and outputs.

As of today, there are three different encodings seen in the wild:

• Base Instruction Set
• Extended Instruction Set
• Enhanced Vision Instruction Set (EVIS)

Why do I want to switch to isaspec

There are several reasons..

The current state

The current ISA documentation is not very explicit and leaves lot of room for interpretation and speculation. One thing that it provides, are some nice explanations what an instruction does. isaspec does not support <doc> tags yet, but I there is a PoC MR that generates really nice looking and information ISA documentation based on the xml.

I think soon you might find all etnaviv’s isaspec documentation at docs.mesa3d.org.

No unit tests

There are no unit tests based on instructions generated by the blob driver. This might not sound too bad, but it opens the door to generating ‘bad’ encoded instructions that could trigger all sorts of weird and hard-to-debug problems. Such breakages could be caused by some compiler rework, etc.

In an ideal world, there would be a unit test that does the following:

• Disassembles the binary representation of an instruction from the blob to a string representation.
• Verifies that it matches our expectation.
• Assembles the string representation back to 128 bits.
• Verifies that it matches the binary representation from the blob driver.

This is our ultimate goal, which we really must reach. etnaviv will not be the only driver that does such deep unit testing - e.g. freedreno does it too.

Easier to understand code

Do you remember the rusticl OpenCL attempt for etnaviv? It contains lines like:

      if (nir_src_is_const(intr->src[1])) {
         inst.tex.swiz = 128;
      }

      if (rmode == nir_rounding_mode_rtz)
         inst.tex.amode = 0x4 + INST_ROUND_MODE_RTZ;
      else /*if (rmode == nir_rounding_mode_rtne)*/
         inst.tex.amode = 0x4 + INST_ROUND_MODE_RTNE;

Do you clearly see what is going on? Why do we need to set tex.amode for an ALU instruction?

I always found it quite disappointing to see such code snippets. Sure, they mimic what the blob driver is doing, but you might lose all the knowledge about why these bits are used that way days after you worked on it. There must be a cleaner, more understandable, and thus more maintainable way to document the ISA better.

This situation might become even worse if we want to support the other encodings and could end up with more of these bad patterns, resulting in a maintenance nightmare.

Oh, and if you wonder what happened to OpenCL and etnaviv - I promise there will be an update later this year.

Python opens the door to generate lot of code

As isaspec is written in Python, it is really easy to extend it and add support for new functionality.

At its core, we can generate a disassembler and an assembler based on isaspec. This alone saves us from writing a lot of code that needs to be kept in sync with all the ISA reverse engineering findings that happen over time.

As isaspec is just an ordinary XML file, you can use any programming language you like to work with it.

One source of truth

I really fell in love with the idea of having one source of truth that models our target ISA, contains written documentation, and extends each opcode with meta information that can be used in the upper layers of the compiler stack.

Missing Features

I think I have sold you the idea quite well, so it must be a matter of some days to switch to it. Sadly no, as there are some missing features:

• Only max 64 bits width ISAs are supported
• Its home in src/freedreno
• Alignment support is missing
• No <meta> tags are supported

Add support for 128 bit wide instructions

The first big MR I worked on, extended BITSET APIs with features needed for isaspec. Here we are talking about bitwise AND, OR, and NOT, and left shifts.

The next step was to switch isaspec to use the BITSET API to support wider ISAs. This resulted in a lot of commits, as there was a need for some new APIs to support handling this new feature. After these 31 commits, we were able to start looking into isaspec support for etnaviv.

Decode Support

Now it is time to start writing an isaspec XML for etnaviv, and the easiest opcode to start with is the nop. As the name suggests, it does nothing and has no src’s, no dst, or any other modifier.

As I do not have this initial version anymore, I tried to recreate it - it might have looked something like this:

<?xml version="1.0" encoding="UTF-8"?>
<isa>
<bitset name="#instruction">
	<display>
		{NAME} void, void, void, void
	</display>

	<pattern low="6" high="10">00000</pattern>
	<pattern pos="11">0</pattern>

	<pattern pos="12">0</pattern>
	<pattern low="13" high="26">00000000000000</pattern>
	<pattern low="27" high="31">00000</pattern>

	<pattern pos="32">0</pattern>
	<pattern pos="33">0</pattern>
	<pattern pos="34">0</pattern>
	<pattern low="35" high="38">0000</pattern>
	<pattern pos="39">0</pattern>
	<pattern low="40" high="42">000</pattern>

	<!-- SRC0 -->
	<pattern pos="43">0</pattern> <!-- SRC0_USE -->
	<pattern low="44" high="52">000000000</pattern> <!-- SRC0_REG -->
	<pattern pos="53">0</pattern>
	<pattern low="54" high="61">00000000</pattern> <!-- SRC0_SWIZ -->
	<pattern pos="62">0</pattern> <!-- SRC0_NEG -->
	<pattern pos="63">0</pattern> <!-- SRC0_ABS -->
	<pattern low="64" high="66">000</pattern> <!-- SRC0_AMODE -->
	<pattern low="67" high="69">000</pattern> <!-- SRC0_RGROUP -->

	<!-- SRC1 -->
	<pattern pos="70">0</pattern> <!-- SRC1_USE -->
	<pattern low="71" high="79">000000000</pattern> <!-- SRC1_REG -->
	<pattern low="81" high="88">00000000</pattern> <!-- SRC1_SWIZ -->
	<pattern pos="89">0</pattern> <!-- SRC1_NEG -->
	<pattern pos="90">0</pattern> <!-- SRC1_ABS -->
	<pattern low="91" high="93">000</pattern> <!-- SRC1_AMODE -->
	<pattern pos="94">0</pattern>
	<pattern pos="95">0</pattern>
	<pattern low="96" high="98">000</pattern> <!-- SRC1_RGROUP -->

	<!-- SRC2 -->
	<pattern pos="99">0</pattern> <!-- SRC2_USE -->
	<pattern low="100" high="108">000000000</pattern> <!-- SRC2_REG -->
	<pattern low="110" high="117">00000000</pattern> <!-- SRC2_SWIZ -->
	<pattern pos="118">0</pattern> <!-- SRC2_NEG -->
	<pattern pos="119">0</pattern> <!-- SRC2_ABS -->
	<pattern pos="120">0</pattern>
	<pattern low="121" high="123">000</pattern> <!-- SRC2_AMODE -->
	<pattern low="124" high="126">000</pattern> <!-- SRC2_RGROUP -->
	<pattern pos="127">0</pattern>
</bitset>


<!-- opcocdes sorted by opc number -->

<bitset name="nop" extends="#instruction">
	<pattern low="0" high="5">000000</pattern> <!-- OPC -->
	<pattern pos="80">0</pattern> <!-- OPCODE_BIT6 -->
</bitset></isa>

With the knowledge of the old ISA documentation, I went fishing for instructions. I only used instructions from the binary blob for this process. It is quite important for me to have as many unit tests as I can write to not break any decoding with some isaspec XML changes I do. And it was a huge lifesaver at that time.

After I reached almost feature parity with the old disassembler, I thought it was time to land etnaviv.xml and replace the current handwritten disassembler with a generated one - yeah, so I submitted an MR to make the switch.

As this is only a driver internal disassembler used by maybe 2-3 human beings, it would not be a problem if there were some regressions.

Today I would say the isaspec disassembler is superior to the handwritten one.

Encode Support

The next item on my list was to add encoding support. As you can imagine, there was some work needed upfront to support ISAs that are bigger than 64 bits. This time the MR only contains two commits 😄.

With everything ready it is time to add isaspec based encoding support to etnaviv.

The goal is to drop our custom (and too simple) assembler and switch to one that is powered by isaspec.

This opens the door to:

• Modeling special cases for instructions like a branch with no src’s to a new jump instruction.
• Doing the NIR src -> instruction src mapping in isaspec.
• Supporting different instruction encodings.
• Adding meta information to instructions.

Supporting special instructions that are used in compiler unit tests

In the end, all the magic that is needed is shown in the following diff:

diff --git a/src/etnaviv/isa/etnaviv.xml b/src/etnaviv/isa/etnaviv.xml
index eca8241a2238a..c9a3ebe0a40c2 100644
--- a/src/etnaviv/isa/etnaviv.xml
+++ b/src/etnaviv/isa/etnaviv.xml
@@ -125,6 +125,13 @@ SPDX-License-Identifier: MIT
 	<field name="AMODE" low="0" high="2" type="#reg_addressing_mode"/>
 	<field name="REG" low="3" high="9" type="uint"/>
 	<field name="COMPS" low="10" high="13" type="#wrmask"/>
+
+	<encode type="struct etna_inst_dst *">
+		<map name="DST_USE">p->DST_USE</map>
+		<map name="AMODE">src->amode</map>
+		<map name="REG">src->reg</map>
+		<map name="COMPS">p->COMPS</map>
+	</encode>
 </bitset>
 
 <bitset name="#instruction" size="128">
@@ -137,6 +144,46 @@ SPDX-License-Identifier: MIT
 	<derived name="TYPE" type="#type">
 		<expr>{TYPE_BIT2} &lt;&lt; 2 | {TYPE_BIT01}</expr>
 	</derived>
+
+	<encode type="struct etna_inst *" case-prefix="ISA_OPC_">
+		<map name="TYPE_BIT01">src->type &amp; 0x3</map>
+		<map name="TYPE_BIT2">(src->type &amp; 0x4) &gt; 2</map>
+		<map name="LOW_HALF">src->sel_bit0</map>
+		<map name="HIGH_HALF">src->sel_bit1</map>
+		<map name="COND">src->cond</map>
+		<map name="RMODE">src->rounding</map>
+		<map name="SAT">src->sat</map>
+		<map name="DST_USE">src->dst.use</map>
+		<map name="DST">&amp;src->dst</map>
+		<map name="DST_FULL">src->dst_full</map>
+		<map name="COMPS">src->dst.write_mask</map>
+		<map name="SRC0">&amp;src->src[0]</map>
+		<map name="SRC0_USE">src->src[0].use</map>
+		<map name="SRC0_REG">src->src[0].reg</map>
+		<map name="SRC0_RGROUP">src->src[0].rgroup</map>
+		<map name="SRC0_AMODE">src->src[0].amode</map>
+		<map name="SRC1">&amp;src->src[1]</map>
+		<map name="SRC1_USE">src->src[1].use</map>
+		<map name="SRC1_REG">src->src[1].reg</map>
+		<map name="SRC1_RGROUP">src->src[1].rgroup</map>
+		<map name="SRC1_AMODE">src->src[1].amode</map>
+		<map name="SRC2">&amp;src->src[2]</map>
+		<map name="SRC2_USE">rc->src[2].use</map>
+		<map name="SRC2_REG">src->src[2].reg</map>
+		<map name="SRC2_RGROUP">src->src[2].rgroup</map>
+		<map name="SRC2_AMODE">src->src[2].amode</map>
+
+		<map name="TEX_ID">src->tex.id</map>
+		<map name="TEX_SWIZ">src->tex.swiz</map>
+		<map name="TARGET">src->imm</map>
+
+		<!-- sane defaults -->
+		<map name="PMODE">1</map>
+		<map name="SKPHP">0</map>
+		<map name="LOCAL">0</map>
+		<map name="DENORM">0</map>
+		<map name="LEFT_SHIFT">0</map>
+	</encode>
 </bitset>
 
 <bitset name="#src-swizzle" size="8">
@@ -148,6 +195,13 @@ SPDX-License-Identifier: MIT
 	<field name="SWIZ_Y" low="2" high="3" type="#swiz"/>
 	<field name="SWIZ_Z" low="4" high="5" type="#swiz"/>
 	<field name="SWIZ_W" low="6" high="7" type="#swiz"/>
+
+	<encode type="uint8_t">
+		<map name="SWIZ_X">(src &amp; 0x03) &gt;&gt; 0</map>
+		<map name="SWIZ_Y">(src &amp; 0x0c) &gt;&gt; 2</map>
+		<map name="SWIZ_Z">(src &amp; 0x30) &gt;&gt; 4</map>
+		<map name="SWIZ_W">(src &amp; 0xc0) &gt;&gt; 6</map>
+	</encode>
 </bitset>
 
 <enum name="#thread">
@@ -272,6 +326,13 @@ SPDX-License-Identifier: MIT
 			</expr>
 		</derived>
 	</override>
+
+	<encode type="struct etna_inst_src *">
+		<map name="SRC_SWIZ">src->swiz</map>
+		<map name="SRC_NEG">src->neg</map>
+		<map name="SRC_ABS">src->abs</map>
+		<map name="SRC_RGROUP">p->SRC_RGROUP</map>
+	</encode>
 </bitset>
 
 <bitset name="#instruction-alu-no-src" extends="#instruction-alu">

One nice side effect of this work is the removal of isa.xml.h file that has been part of etnaviv since day one. We are able to generate all the file contents with isaspec and some custom python3 scripts. The move of instruction src swizzling from the driver into etnaviv.xml was super easy - less code to maintain!

Summary

I am really happy with the end result, even though it took quite some time from the initial idea to the point when everything was integrated into Mesa’s main git branch.

There is so much more to share - I can’t wait to publish parts II and III.

tl;dr

The etnaviv GPU stack is continuously improving and becoming more robust. This time, a hardware database was incorporated into Mesa, utilizing header files provided by the SoC vendors.

If you are interested in the implementation details, I recommend checking out this Mesa MR.

Are you employed at Versilicon and want to help? You could greatly simplify our work by supplying the community with a comprehensive header that includes all the models you offer.

Last but not least: I deeply appreciate Igalia’s passion for open source GPU driver development, and I am grateful to be a part of the team. Their enthusiasm for open source work not only pushes the boundaries of technology but also builds a strong, collaborative community around it.

The good old days

Years ago, when I began dedicating time to hacking on etnaviv, the kernel driver in use would read a handful of registers and relay the gathered information to the user space blob. This blob driver was then capable of identifying the GPU (including model, revision, etc.), supported features (such as DXT texture compression, seamless cubemaps, etc.), and crucial limits (like the number of registers, number of varyings, and so on).

For reverse engineering purposes, this interface is super useful. Image if you could change one of these feature bits on a target running the binary blob.

With libvivhook it is possible to do exactly this. From time to time, I am running such an old vendor driver stack on an i.MX 6QuadPlus SBC, which features a Vivante GC3000 as its GPU.

Somewhere, I have a collection of scripts that I utilized to acquire additional knowledge about unknown GPU states activated when a specific feature bit was set.

To explore a simple example, let’s consider the case of misrepresenting a GPU’s identity as a GC2000. This involves modifying the information provided by the kernel driver to the user space, making the user space driver believe it is interacting with a GC2000 GPU. This scenario could be used for testing, debugging, or understanding how specific features or optimizations are handled differently across GPU models.

export ETNAVIV_CHIP_MODEL="0x2000"
export ETNAVIV_CHIP_REVISION="0x5108"
export ETNAVIV_FEATURES0_CLEAR="0xFFFFFFFF"
export ETNAVIV_FEATURES1_CLEAR="0xFFFFFFFF"
export ETNAVIV_FEATURES2_CLEAR="0xFFFFFFFF"
export ETNAVIV_FEATURES0_SET="0xe0296cad"
export ETNAVIV_FEATURES1_SET="0xc9799eff"
export ETNAVIV_FEATURES2_SET="0x2efbf2d9"
LD_PRELOAD="/lib/viv_interpose.so" ./test-case

If you capture the generated command stream and compare it with the one produced under the correct identity, you’ll observe many differences. This is super useful - I love it.

Changing Tides: The Shift in ioctl() Interface

At some point in time, Vivante changed their ioctl() interface and modified the gcvHAL_QUERY_CHIP_IDENTITY command. Instead of providing a very detailed chip identity, they reduced the data set to the following values:

• model
• revision
• product id
• eco id
• customer id

This shift could indeed hinder reverse engineering efforts significantly. At a glance, it becomes impossible to alter any feature value, and understanding how the vendor driver processes these values is out of reach. Determining the function or impact of an unknown feature bit now seems unattainable.

However, the kernel driver also requires a mechanism to verify the existing features of the GPU, as it needs to accommodate a wide variety of GPUs. Therefore, there must be some sort of system or method in place to ensure the kernel driver can effectively manage and support the diverse functionalities and capabilities of different GPUs.

A New Approach: The Hardware Database Dilemma

Let’s welcome: gc_feature_database.h, or hwdb for short.

Vivante transitioned to using a database that stores entries for limit values and feature bits. This database is accessed by querying with model, revision, product id, eco id and customer id.

There is some speculation why this move was done. My theory posits that they became frustrated with the recurring cycle of introducing feature bits to indicate the implementation of a feature, subsequently discovering problems with said feature, and then having to introduce additional feature bits to signal that the feature now truly operates as intended. It became far more straightforward to deactivate a malfunctioning feature by modifying information in the hardware database (hwdb). After they began utilizing the hwdb within the driver, updates to the feature registers in the hardware ceased.

Here is a concrete example of such a case that can be found in the etnaviv gallium driver:

screen->specs.tex_astc = VIV_FEATURE(screen, chipMinorFeatures4, TEXTURE_ASTC) &&
                            !VIV_FEATURE(screen, chipMinorFeatures6, NO_ASTC);

Meanwhile, in the etnaviv world there was a hybrid in the making. We stuck with the detailed feature words and found a smart way to convert from Vivante’s hwdb entries to our own in-kernel database. There is even a full blown Vivante -> etnaviv hwdb convert.

At that time, I did not fully understand all the consequences this approach would bring - more on that later. So, I dedicated my free time to reverse engineering and tweaking the user space driver, while letting the kernel developers do their thing.

About a year after the initial hwdb landed in the kernel, I thought it might be a good idea to read out the extra id values, and provide them via sysfs to the user space. At that time, I already had the idea of moving the hardware database to user space in mind. However, I was preoccupied with other priorities that were higher on my to-do list, and I ended up forgetting about it.

Challange accepted

Tomeu Vizoso began to work on teflon and a Neural Processing Unit (NPU) driver within Mesa, leveraging a significant amount of the existing codebase and concepts, including the same kernel driver for the GPU. During this process, he encountered a need for some NPU-specific limit values. To address this, he added an in-kernel hwdb entry and made the limit values accessible to user space.

That’s it — the kernel supplies all the values the NPU driver requires. We’re finished, aren’t we?

It turns out, that there are many more NPU related values that need to be exposed in the same manner, with seemingly no end in sight.

One of the major drawbacks when the hardware database (hwdb) resides in the kernel is the considerable amount of time it takes for hwdb patches to be written, reviewed, and eventually merged into Linus’s git tree. This significantly slows down the development of user space drivers. For end users, this means they must either run a bleeding-edge kernel or backport the necessary changes on their own.

For me personally, the in-kernel hardware database should never have been implemented in its current form. If I could go back in time, I would have voiced my concerns.

As a result, moving the hardware database (hwdb) to user space quickly became a top priority on my to-do list, and I began working on it. However, during the testing phase of my proof of concept (PoC), I had to pause my work due to a kernel issue that made it unreliable for user space to trust the ID values provided by the kernel. Once my fix for this issue began to be incorporated into stable kernel versions, it was time to finalize the user space hwdb.

There is only one little but important detail we have not talked about yet. There are vendor specific versions of gc_feature_database.h based on different versions of the binary blob. For instance, there is one from NXP, ST, Amlogic and some more.

Here is a brief look at the differences:

nxp/gc_feature_database.h (autogenerated at 2023-10-24 16:06:00, 861 struct members, 27 entries)
stm/gc_feature_database.h (autogenerated at 2022-12-29 11:13:00, 833 struct members, 4 entries)
amlogic/gc_feature_database.h (autogenerated at 2021-04-12 17:20:00, 733 struct members, 8 entries)

We understand that these header files are generated and adhere to a specific structure. Therefore, all we need to do is write an intelligent Python script capable of merging the struct members into a single consolidated struct. This script will also convert the old struct entries to the new format and generate a header file that we can use.

I’m consistently amazed by how swiftly and effortlessly Python can be used for such tasks. Ninety-nine percent of the time, there’s a ready-to-use Python module available, complete with examples and some documentation. To address the C header parsing challenge, I opted for pycparser.

The final outcome is a generated hwdb.h file that looks and feels similar to those generated from the binary blob.

Future proof

This header merging approach offers several advantages:

• It simplifies the support for another SoC vendor.
• There’s no need to comprehend the significance of each feature bit.
• The source header files are supplied by Versilicon or the SoC vendor, ensuring accuracy.
• Updating the hwdb is straightforward — simply replace the files and rebuild Mesa.
• It allows for much quicker deployment of new features and hwdb updates since no kernel update is required.
• This method accelerates the development of user space drivers.

While working on this topic I decided to do a bigger refactoring with the end goal to provide a struct etna_core_info that is located outside of the gallium driver.

This makes the code future proof and moves the filling of struct etna_core_info directly into the lowest layer - libetnaviv_drm (src/etnaviv/drm).

We have not yet talked about one important detail.

What happens if there is no entry in the user space hwdb?

The solution is straightforward: we fallback to the previous method and request all feature words from the kernel driver. However, in an ideal scenario, our user space hardware database should supply all necessary entries. If you find that an entry for your GPU/NPU is missing, please get in touch with me.

What about the in-kernel hwdb?

The existing system, despite its limitations, is set to remain indefinitely, with new entries being added to accommodate new GPUs. Although it will never contain as much information as the user space counterpart, this isn’t necessarily a drawback. For the purposes at hand, only a handful of feature bits are required.

I ❤️ it!

This was the best decision to leave my comfort zone of a normal 9-5 job. I am so proud to work on open source GPU drivers and I am able to spend much of my work time on etnaviv.

Driver maintenance

Before adding any new feature I thought it would be great idea to improve the current state of etnaviv’s gallium driver. Therefor I reworked some general driver code to be more consistent and to have a more modern feeling, and made it possible to drop some hand-rolled conversion helpers by switching to already existing solutions (U_FIXED(..), S_FIXED(..), float_to_ubyte(..)).

I worked through the low hanging fruits of crashes seen in CI runs and fixed many of them.

Feature wise, I also looked at some easy to implement extensions like GL_NV_conditional_render and GL_OES_texture_half_float_linear.

Besides the gallium driver I also worked on some NIR and isaspec features that are beneficial for etnaviv.

XDC2023

A personal highlight was to give a talk about etnaviv at XDC2023 in person.

You might wonder what happened since mid October in etnaviv land.

GLES3

I worked on some features that are needed to expose GLES3 and it turned out that an easy to maintain, extend and test compiler backend is needed. Sadly etnaviv’s current backend compiler does not check any of these boxes. It is so fragile that I only added some needed lowerings to pass some of the dEQP-GLES3.functional.shaders.texture_functions.* tests.

Some more fun work regarding some feature emulation is on the horizon and it’s blocked again by the current compiler.

Backend Compiler

etnaviv includes an isaspec powered disassembler now - a small step towards a new backend compiler. Next on the road to success is the etnaviv backend IR with an assembler.

The new backend compiler is able to run OpenCL kernels with the help of rusticl but I want to land the new backend compiler in smaller chunks that are easier to review.

Multiple Render Targets

During my XDC presentation I talked about a feature I got working on GC7000L - Multiple Render Targets (MRT). At this point it was more or less a proof-of-concept regarding the gallium drivers. There were some missing bits and register for full support on more GPU models and therefore more reverse engineering work was needed. Also the gallium driver needed lots of work to add support for MRT.

Some weeks later I had MRT working on a wider range of Vivante GPUs that are supporting this feature. This includes GC2000, GC3000 and GC7000 models among others. As etnaviv makes heavy use of GPU features it should work on even more models.

Looking forward to 2024

I am really confident that we will see GLES3 and OpenCL for etnaviv. As driver testing is quite important for my work I will expand my current board farm and will look into the new star in CI world - ci-tron.

With that, have a happy holiday season and we’ll be back with more improvements in 2024!

The big problem is that the stock boot-chain can not boot a mainline kernel - it simply hangs.

TF-A

Trusted Firmware-A (TF-A) is a reference implementation of secure-world software used on this platform. It implements a secure monitor with various interface standards:

• The power state coordination interface (PSCI)
• Trusted board boot requirements (TBBR)
• SMC calling convention
• System control and management interface

More information can be found at the official website at https://www.trustedfirmware.org/.

On kernel side when you need to access to secure feature (like clocks, resets …) you need to discuss it with this secure monitor using secure APIs. This APIs have not yet been pushed to mainline kernel. So It means that a mainline kernel can’t access to secure resources and it is the reason for the boot hang.

u-boot - the solution

It looks like that we can replace the current secure boot chain with u-boot in non-secure boot mode and call it a day.

This will generate two build artifacts:

• u-boot-spl.stm32
• u-boot.img

Lets copy these artifacts with dd directly to the suitable partition. ST has a quite nice wiki where we can find some more details.

• u-boot-spl.stm32 -> fsbl1
• u-boot.img -> ssbl

Lets boot it …

Connect all your cables and have a look at you serial console:

And from there you can simply boot your mainline kernel:

For years, I was a happy DynDns user and even paid once for a premium plan. But now it is time for a change as I recently switched to Unfi network equipment including a USG. Currently, I am using Cloudflare for CDN, DDOS protection, free SSL certificates and DNS with a free account. Thankfully, Cloudflare has a free API that allows you to automatically update your DNS records.

Preparation of the USG

The installed version of ddclient on the USG is too old to support Cloudflare’s v4 API so we need to update it first.

Configure Cloudflare DDNS on the Controller

With Controller version 5.10.25.0 it is not possible to configure Cloudflare DDNS via the UI, so we need to go another route. Luckily, the config.gateway.json is a file that sits in the UniFi Controller filesystem and allows custom changes to the USG that aren’t available in the web GUI. For more [information visit Unifi documentation here.

After this step was done we are almost ready. Finally, we need to run a “force provision” to the USG in the UniFi Controller Devices > USG > Config > Manage Device > Force provision. That’s it!

Keep in mind that chances are quite high that you might need to reupdate ddclient on the USG after an Firmware update.

This page is a graphical representation of the text file docs/features.txt from the Mesa repository.

So wouldn’t it be sick to get etnaviv mentioned in docs/features.txt and onto the matrix?

First mesamatrix needs to know/support etnaviv. This seems to be quite simple as there is already a pull request to add a bunch of embedded GPU drivers: Add VC4,VC5 and Vivante GPUs

Second we need is to add support for an easy to support extension. After skimming through the list I settled with ARB_seamless_cubemap_per_texture

To be fair I know that there are some UNK bits in the sampler registers and I hope one of them has something to do with seamless cubemaps. I went with a quick try-and-error approach to find the UNK bit which enables seamless cubemaps. And after 20 minutes of hacking the spec@amd_seamless_cubemap_per_texture@amd_seamless_cubemap_per_texture piglit works \o/.

The end result can be found in in this merge request. I hope to merge the changes soon and see something new in mesamatrix.

This does not mean we are done with development at all. There are many interesting topics to work on and some of them like better support for newer IP cores or a reworked GLSL compiler should see the light of day during the next months.

I think 2017 will be a quite interesting one for etnaviv and open source GPU drivers in general.

At this point I want to thank a lot of people who helped out in different areas. The whole mesa community (esp. Rob, Ilia and Emil), SolidRun for provided hardware, Pengutronix - the ‘imx6-company’ - for doing a wonderful job in the kernel space and all the other guys I meet in real life or via irc/mail.

There is a very good (German) tutorial directly from ueberspace for the whole process. Two minutes later everything was done and it worked! There is only one missing part. As the generated certificate is only valid for 90 days I created a little script which gets run every month – thanks to cron.

You may ask why did it so long to get it working? Let me explain it to you.

The Vivnate GPU is a so called render-only GPU which does not have any kind of scanout logic in it. It can only render to physical memory and this only in a tiled memory layout. So we need to use the resolve engine found on the GPU to de-tile the rendered image and blit it to the dumb buffer. Currently mesa has  no software support for this kind of hardware, but I think that could change soon.

I think that this is a huge step into the right direction. All the needed sources can be found on my github account. At the moment I am cleaning up the code and shortly I will send out RFC patch series for libdrm and mesa. Currently some hacks are needed to get it up an running so there is still a lot left to do.

Yes I think libdrm is needed and should not be part of the gallium driver. I even think xf86-video-armada could be using libdrm-etnaviv sooner or later. This one of the topics on my huge TODO list.

Russell does not want to maintain a 3rd GPU backend and with that fact I think I will merge the etnaviv libdrm part directly into the driver. Let’s see how the patch series gets accepted.

I think this the perfect time to say “thank you” to some guys. Wladimir thanks for the wonderful code basis you provided for the whole etnaviv project. Rob, thanks for your patience with me – at this point in time I was a complete newbie in the mesa source code and the whole GPU world. Thanks NVIDIA for their wonderful render-only patch. Emil thanks for helping me out with ideas to get render-only into a working state. Also quite important for spare-time open source development is a hardware sponsor. In may case I want to thank SolidRun for sending me two devices for etnaviv development purposes.

You have here two way how to archive your goal. Use simple int values to represent the Enum value or use Strings. The big advantage with strings it that you do not have to lookup what the meaning of value 4 is, but you can name the value with a String.

Here I will present you with an non QObject based way of doing it in Qt5. You may wonder why I do not want to use a QObject as base for my class. The answer is quite simple. I need to be able to have a copy constructor and assignment operator for my class.

So lets start with the simple class Item which has Enum called Type in it.

“APPLE” “CAR” “BIRD”

Here Qt’s MetaObject system comes to help. We use the MetaObject to get the correct QMetaEnum and make use of its valueToKey(..) and keyToValue(..) methods.

• Q_GADGET to get the processed by the meta object compiler (moc)
• Q_ENUMS to ‘export’ the enum to the metaObject

Qt’s MetaObject system saved my day and helped me to easily serialize C++ Enums in a very elegant way. The other more hacky solution would have been a big if-castle to check for each possible value and do everything on my own. But this could lead to problems if the Enum gets extended by an other developer not aware of the hand-written conversion methods.

All in all I am very happy with this solution.

Edit ~/.gitconfig

[sendemail] from = Firstname Lastname email@gmail.com smtpserver = smtp.gmail.com smtpuser = email@gmail.com smtpencryption = tls smtppass = PASSWORD chainreplyto = false smtpserverport = 587

As I am using Googles two factor authentication I needed to generate an app specific password.

If your browser supports NSI you should access my blog via https now. It took me some time to setup everything but my new hoster ueberspace made it a breeze to setup everything – thanks.

The biggest time safer for me is the switch to disqus comment system as it is quite time consuming to manage all the comments in the spam queue.

I hope you enjoy the new site and in the next blog I will talk about the current state of my biggest hobby project – etnaviv

[ 3.358155] vivante: module is from the staging directory, the quality is unknown, you have been warned. [ 3.373087] imx-sgtl5000 sound.15: sgtl5000 2028000.ssi mapping ok [ 3.379150] [drm] add child gpu2d [ 3.379154] [drm] add child gpu3d [ 3.380395] vivante-gpu 134000.gpu2d: pre gpu[idx]: 0x00000000 [ 3.380401] vivante-gpu 134000.gpu2d: adding core @idx 1 [ 3.380408] vivante-gpu 134000.gpu2d: post gpu[idx]: 0xecb56c10 [ 3.380460] vivante gpu-subsystem.11: bound 134000.gpu2d (ops gpu_ops [vivante]) [ 3.380467] vivante-gpu 130000.gpu3d: pre gpu[idx]: 0x00000000 [ 3.380473] vivante-gpu 130000.gpu3d: adding core @idx 0 [ 3.380479] vivante-gpu 130000.gpu3d: post gpu[idx]: 0xecb57210 [ 3.380502] vivante gpu-subsystem.11: bound 130000.gpu3d (ops gpu_ops [vivante]) [ 3.380533] IO:R f0200018 14010000 [ 3.380537] IO:R f0200020 00002000 [ 3.380540] IO:R f0200024 00005108 [ 3.380546] vivante gpu-subsystem.11: model: 2000 [ 3.380551] vivante gpu-subsystem.11: revision: 5108 [ 3.380554] IO:R f020001c e0296cad [ 3.380558] IO:R f0200034 c9799eff [ 3.380561] IO:R f0200074 2efbf2d9 [ 3.380564] IO:R f0200084 00000000 [ 3.380567] IO:R f0200088 00000000 [ 3.380572] vivante gpu-subsystem.11: minor_features: c9799eff [ 3.380578] vivante gpu-subsystem.11: minor_features1: 2efbf2d9 [ 3.380583] vivante gpu-subsystem.11: minor_features2: 0 [ 3.380588] vivante gpu-subsystem.11: minor_features3: 0 [ 3.380592] IO:R f0200000 00070100 [ 3.408629] IO:R f0200004 7fffffff [ 3.408632] IO:R f0200000 00070100 [ 3.412940] vivante gpu-subsystem.11: 130000.gpu3d: using IOMMU [ 3.413080] IO:R f01f8018 14010000 [ 3.413083] IO:R f01f8020 00000320 [ 3.413087] IO:R f01f8024 00005007 [ 3.413093] vivante gpu-subsystem.11: model: 320 [ 3.413098] vivante gpu-subsystem.11: revision: 5007 [ 3.413101] IO:R f01f801c e02c7eca [ 3.413105] IO:R f01f8034 c1399eff [ 3.413108] IO:R f01f8074 020fb2db [ 3.413111] IO:R f01f8084 00000000 [ 3.413114] IO:R f01f8088 00000000 [ 3.413120] vivante gpu-subsystem.11: minor_features: c1399eff [ 3.413126] vivante gpu-subsystem.11: minor_features1: 20fb2db [ 3.413131] vivante gpu-subsystem.11: minor_features2: 0 [ 3.413136] vivante gpu-subsystem.11: minor_features3: 0 [ 3.413139] IO:R f01f8000 00070100 [ 3.438615] IO:R f01f8004 7fffffff [ 3.438619] IO:R f01f8000 00070100 [ 3.442583] vivante gpu-subsystem.11: 134000.gpu2d: using IOMMU [ 3.442681] [drm] Initialized vivante 1.0.0 20130625 on minor 1

1. apt-get install libftdi-dev
2. Download and extract OpenOCD 0.8.0
3. run ./configure
4. run make && make install

This should give you an OpenOCD installation with the following configuration:

OpenOCD configuration summary ————————————————– MPSSE mode of FTDI based devices yes (auto) ST-Link JTAG Programmer yes (auto) TI ICDI JTAG Programmer yes (auto) Keil ULINK JTAG Programmer yes (auto) Altera USB-Blaster II Compatible yes (auto) Segger J-Link JTAG Programmer yes (auto) OSBDM (JTAG only) Programmer yes (auto) eStick/opendous JTAG Programmer yes (auto) Andes JTAG Programmer yes (auto) Versaloon-Link JTAG Programmer yes (auto) USBProg JTAG Programmer yes (auto) Raisonance RLink JTAG Programmer yes (auto) Olimex ARM-JTAG-EW Programmer yes (auto) CMSIS-DAP Compliant Debugger no

Now its time to check if a debugger connection can be established. As the JTAG is usb based you should see it via lsusb.

Bus 002 Device 005: ID 15ba:002b Olimex Ltd. ARM-USB-OCD-H JTAG+RS232 Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x15ba Olimex Ltd. idProduct 0x002b ARM-USB-OCD-H JTAG+RS232 bcdDevice 7.00 iManufacturer 1 Olimex iProduct 2 Olimex OpenOCD JTAG ARM-USB-OCD-H iSerial 3 OLWI19GT bNumConfigurations 1 […]

At this point OpenOCD should be able to connect to the JTAG. For the beginning you only need to provide the interface and target scripts. In my case the following works.

christian@chgm-pc:~$ sudo openocd -f interface/ftdi/olimex-arm-usb-ocd-h.cfg -f target/imx6.cfg Open On-Chip Debugger 0.8.0 (2014-05-05-11:14) Licensed under GNU GPL v2 For bug reports, read http://openocd.sourceforge.net/doc/doxygen/bugs.html Info : only one transport option; autoselect ‘jtag’ Warn : imx6.sdma: nonstandard IR value adapter speed: 1000 kHz Info : clock speed 1000 kHz Info : JTAG tap: imx6.dap tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) Info : TAP imx6.sdma does not have IDCODE Info : JTAG tap: imx6.sjc tap/device found: 0x2191e01d (mfg: 0x00e, part: 0x191e, ver: 0x2) Info : imx6.cpu.0: hardware has 6 breakpoints, 4 watchpoints Info : number of cache level 1 Info : imx6.cpu.0 cluster 0 core 0 multi core

The MMU uses a page table with a maximum size of 256KB. Where each Page Table Entry (PTE) is 4 byte long. The used page size is 4K and can not be changed via some registers etc. Lets have a look at the bit layout of a PTE.

What does all that code in the v4 driver? In the end it turned out to be a ‘simple’ memory manager. All the code is needed to keep track of which pages are mapped into the GPU address area. Index 0 of the big page table array maps directly to GPU address 0x80000000 and index 1 maps directly to 0x80001000. We can quite easily map Linux kernel pages into the address range of the GPU.

The solution I am working on will use drm_mm as memory manager and the iommu framework to keep the page table in sync.

1. Update mesa fork
2. Start working on an improved compiler
3. Start working on an kernel interface

I think that Rob will start soon on the kernel interface and the mesa update should be doable during some hours. So I think the next big and important step is to improve the compiler. What should I say… I have basic compiler understanding, did wrote a compiler and VM during my study… thats it. I have never written a single line of glsl and I do not completely understand the Vivante GPU. So a perfect starting point for doing some hacking 🙂 The success rate will be quite low and I hope to not lose my motivation too soon.

For instance

Following tests are showing good visual results compared to swrast:

• Hello_Triangle/CH02_HelloTriangle
• Simple_VertexShader/CH08_SimpleVertexShader
• CubeVBO/cube_vbo
• ParticleSystem/CH13_ParticleSystem
• Viewports/viewports

All other are visual corrupted or segfault. So there is still some work done to get all demos up and running.

Also this is my first reverse engineering project I contributed to and even I have never done any graphics related stuff – okay I did some OpenGL stuff during my studies.

I try to find some more time to help to create a fully open source graphics stack for Vivante GPUs.

If have not seen it yet: Here is a short video showing the current state of etnaviv on a iMX6q (Sabre Lite). Video in Google+ post

It turned out to be quite easy:

It solution to this problem is quite easy: http://explainshell.com/

The best thing is that the source code is released under GPL and can be found at GitHub

sudo add-apt-repository ppa:kubuntu-ppa/backports sudo apt-get update sudo apt-get dist-upgrade

I think it is really time to replace my Ubuntu installation with something different/better.

But wait… as I learned from my coreboot activities – memory setup is the hardest and most importest part. The custom board has 1GB of DDR3 on it and I started to look how u-boot does the DDR setup. And there I read the term DCD – Device Configuration Data.

DCD does contain the init sequence for DDR3 and I had to look up some stuff in the “i.MX 6Dual/6Quad Applications Processor Reference Manual” to find out that this must be some kind of black magic. I tried my luck with the DDR3 Stress Tester from Freescale and failed. It was so hard to get all those register correct if you do not know much about DDR3 at all.

Luckily I got a hint that in the Freescale commuity is something which could help me – thanks Fabio. It turns out to be an Excel sheet where I filled in few values and got a DDR3 init script for the DDR3 Stress Tester.

10 Minutes after I got the Excel sheet into my hands it looks like I got the memory up and running – nice!

The “magic” Excel sheet can be found here.

But what do I see… debugging option is disabled in the Debian squeeze package of ntp. WTF?! – the only nice way to do useful debugging without wireshark. The good thing is that Ubuntu had the same miss-configuration and got it fixed.

So I only need to rebuild the ntpd package with debugging enabled.

sudo apt-get build-dep ntpd

sudo apt-get source ntpd

cd ntp-4.2.6.p2+dfsg

nano debian/rules

dpkg-buildpackage -rfakeroot -uc -b

The result is a deb in the parent folder.

I am running a freescale based RFS with the binary libGAL.so blob in the user space. So why not look into etna_viv and get it compiled. It turns out to be as simple as this.

git clone git://github.com/laanwj/etna_viv.git cd etna_viv/native export GCABI=imx6 export CFLAGS="-D_POSIX_C_SOURCE=200809 -D_GNU_SOURCE -DLINUX -pthread" export CXXFLAGS="-D_POSIX_C_SOURCE=200809 -D_GNU_SOURCE -DLINUX -pthread" make

At the moment the GC2000 support is non existent but it should be possible to add support for it in the foreseeable future. To get a picture what needs to be done have a lookt at https://blog.visucore.com/2013/3/3/gc2000-vs-gc800

Triggered via SSE I am appending some messages via JavaScript.

$(’#progress’).append("<span class=‘ui-icon ui-icon-alert’ style=‘float: left; margin-right: .3em’;>" + stderr + “
”);

In order to automaticly scroll to the last line I am using this two magic lines of JavaScript:

var height = $(’#progress’)[0].scrollHeight; $(’#progress’).scrollTop(height);

It is simple as that.

The error occurs in ‘libcurl’, which is the underlying protocol for http. To get more details about the error, set GIT_CURL_VERBOSE=1

But whats exactly the problem here?

The SMBus specification describes a number of standardized transactions. Each chip on the bus can support each given transaction type or not. In practice, each slave chip only supports a subset of the SMBus specification. The Linux i2c subsystem abuses this transaction type for device detection purposes, because it is known to give good results in practice, but ideally it shouldn’t do that.

There have been some devices known to lock up the SMBus on Quick command with data bit = 1. In most cases these were write-only devices, which didn’t expect a transaction starting like a read (the SMBus specification says that a Quick command with data bit = 1 is writing 1 bit to the slave, but the I2C specification says this is a read transaction of length 0.)

This SMBus Quick command thing keeps causing trouble and confusing people. Not much we can do though. If your slaves don’t like the quick command, just don’t send that command to them.

SMBus quick command problem

The solution is quite simple: use i2c_new_probed_device(..) function for probing devices on the SMBus/I²C-Bus. By the way I have found a nice comparison from TI: SMBus vs. I²C

commit fd7e6128d5fb9b8297a4a20f3288c130a554147b Author: Christian Gmeiner christian.gmeiner@gmail.com Date: Thu Feb 14 10:24:59 2013 +0100 geodevga: fix wrong define name Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com commit b1268e8100f0bcf0655b65326856e6f33e3625c1 Author: Christian Gmeiner christian.gmeiner@gmail.com Date: Thu Feb 14 10:22:58 2013 +0100 geodevga: add debug to msr functions Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com commit dde4df84126a460c454ca79fc8dc5b0ae4aa876e Author: Christian Gmeiner christian.gmeiner@gmail.com Date: Thu Feb 14 10:19:05 2013 +0100 geodevga: move output setup to own function Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com commit bba85a38c67aa2b52f146b5cefe58b00f516fc2e Author: Christian Gmeiner christian.gmeiner@gmail.com Date: Thu Feb 14 10:13:59 2013 +0100 geodevga: move framebuffer setup Framebuffer setup has nothing to do with dc_setup(..) so move it to geodevga_init(..). Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com commit 0b3dee01385e65f2b88600c9b663589343ac4abe Author: Christian Gmeiner christian.gmeiner@gmail.com Date: Thu Feb 14 10:05:45 2013 +0100 geodevga: fix errors in geode_fp_* functions Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com commit 4b1d2be6e1c73d1fc9a984ca7fe6c14d433171cc Author: David Woodhouse David.Woodhouse@intel.com Date: Sun Feb 10 00:51:56 2013 +0000 Unify return path for CSM to go via csm_return() This allows us to keep the entry_csm code simple, and ensures that we consistently do things like saving the PIC mask (and later setting UmbStart) on the way back to UEFI. …

The first step is to generate the patches.

$ git format-patch -M origin/master 0001-geodevga-fix-errors-in-geode_fp_-functions.patch 0002-geodevga-move-framebuffer-setup.patch 0003-geodevga-move-output-setup-to-own-function.patch 0004-geodevga-add-debug-to-msr-functions.patch 0005-geodevga-fix-wrong-define-name.patch

Now we simply need to send them via mail – git helps here too 🙂

$ git send-email .patch 0001-geodevga-fix-errors-in-geode_fp_-functions.patch 0001-geodevga-fix-wrong-define-name.patch 0002-geodevga-move-framebuffer-setup.patch 0003-geodevga-move-output-setup-to-own-function.patch 0004-geodevga-add-debug-to-msr-functions.patch 0005-geodevga-fix-wrong-define-name.patch Who should the emails appear to be from? [Christian Gmeiner christian.gmeiner@gmail.com] Emails will be sent from: Christian Gmeiner christian.gmeiner@gmail.com Who should the emails be sent to (if any)? seabios@seabios.org Message-ID to be used as In-Reply-To for the first email (if any)? (mbox) Adding cc: Christian Gmeiner christian.gmeiner@gmail.com from line ‘From: Christian Gmeiner christian.gmeiner@gmail.com’ (body) Adding cc: Christian Gmeiner christian.gmeiner@gmail.com from line ‘Signed-off-by: Christian Gmeiner christian.gmeiner@gmail.com’ From: Christian Gmeiner christian.gmeiner@gmail.com To: seabios@seabios.org Cc: Christian Gmeiner christian.gmeiner@gmail.com Subject: [PATCH 1/5] geodevga: fix errors in geode_fp_ functions Date: Thu, 14 Feb 2013 10:34:32 +0100 Message-Id: 1360834477-18802-1-git-send-email-christian.gmeiner@gmail.com X-Mailer: git-send-email 1.7.12.2.421.g261b511 The Cc list above has been expanded by additional addresses found in the patch commit message. By default send-email prompts before sending whenever this occurs. This behavior is controlled by the sendemail.confirm configuration setting. For additional information, run ‘git send-email –help’. To retain the current behavior, but squelch this message, run ‘git config –global sendemail.confirm auto’. Send this email? ([y]es|[n]o|[q]uit|[a]ll): a OK. Log says: Server: smtp.gmail.com MAIL FROM:christian.gmeiner@gmail.com RCPT TO:seabios@seabios.org RCPT TO:christian.gmeiner@gmail.com From: Christian Gmeiner christian.gmeiner@gmail.com To: seabios@seabios.org Cc: Christian Gmeiner christian.gmeiner@gmail.com Subject: [PATCH 1/5] geodevga: fix errors in geode_fp_* functions Date: Thu, 14 Feb 2013 10:34:32 +0100 Message-Id: 1360834477-18802-1-git-send-email-christian.gmeiner@gmail.com X-Mailer: git-send-email 1.7.12.2.421.g261b511 Result: 250 2.0.0 OK 1360833086 q5sm77386411eep.11 - gsmtp … …

Free and open source software makes it possible to fix problems and/or implement new features in software I use. I could write a lot of text why I think it is a good idea to support the open source community but I want you to form an opinion about this topic buy simply using open source software and support it. It does not mean you need to send in some patches… it starts with simple things like bug reports or user support.

http://colorschemedesigner.com

http://codylindley.com/jqueryselectors/

The first idea is to use cbfstool. Thanks to some guys in the IRC channel it looks like the current build system does something like:

cbfstool -o $$(( $(CONFIG_ROM_SIZE) - $(CONFIG_CBFS_SIZE) )) …

So all we need is to change CBFS_SIZE to ROM_SIZE – 0x30 in .config file.

… CONFIG_CONSOLE_SERIAL8250=y # CONFIG_USBDEBUG is not set # CONFIG_K8_REV_F_SUPPORT is not set CONFIG_CPU_ADDR_BITS=32 CONFIG_BOARD_ROMSIZE_KB_2048=y # CONFIG_COREBOOT_ROMSIZE_KB_64 is not set # CONFIG_COREBOOT_ROMSIZE_KB_128 is not set # CONFIG_COREBOOT_ROMSIZE_KB_256 is not set … CONFIG_CORE_GLIU_500_266=y CONFIG_PLLMSRhi=0x39c # CONFIG_NORTHBRIDGE_AMD_AGESA is not set # CONFIG_AMD_NB_CIMX is not set # CONFIG_NORTHBRIDGE_AMD_CIMX_RD890 is not set CONFIG_CBFS_SIZE=0x1FFFD0 # # Southbridge # CONFIG_SOUTHBRIDGE_AMD_CS5536=y …

This results in the wanted result:

… coreboot.rom: 2048 kB, bootblocksize 688, romsize 2097152, offset 0x30 alignment: 64 bytes, architecture: x86 Name Offset Type Size vsa 0x30 stage 55124 config 0xd7c0 raw 2810 (empty) 0xe300 null 7256 fallback/romstage 0xff80 stage 19339 fallback/coreboot_ram 0x14b80 stage 38852 fallback/payload 0x1e380 payload 21831 (empty) 0x23900 null 1950728

And here the file based prove:

hexedit build/coreboot.rom 00000000 FF FF FF FF FF FF FF FF …….. 00000008 FF FF FF FF FF FF FF FF …….. 00000010 FF FF FF FF FF FF FF FF …….. 00000018 FF FF FF FF FF FF FF FF …….. 00000020 FF FF FF FF FF FF FF FF …….. 00000028 FF FF FF FF FF FF FF FF …….. 00000030 4C 41 52 43 48 49 56 45 LARCHIVE 00000038 00 00 D7 54 00 00 00 10 …T…. 00000040 00 00 00 00 00 00 00 28 …….(

#!/bin/bash if [ -e /dev/.initramfs ]; then echo YES else echo NO fi

This may not work under wheezy or any other working distribution. But that’s okay for now 🙂

• add systemd USE-flag
• emerge –ask –changed-use –deep @world
• emerge –ask systemd
• change grub config to use init=/usr/bin/systemd
• reboot

localhost christian # systemd-analyze Traceback (most recent call last): File “/usr/bin/systemd-analyze”, line 23, in from gi.repository import Gio ImportError: No module named gi.repository

This can be fixed with:

emerge -av dev-python/pygobject

Here are the first results:

localhost christian # systemd-analyze Startup finished in 2352ms (kernel) + 90695ms (userspace) = 93048ms localhost christian # systemd-analyze blame 3567ms NetworkManager.service 1311ms systemd-logind.service 530ms tmp.mount 528ms systemd-udevd.service 519ms systemd-vconsole-setup.service 393ms systemd-udev-trigger.service 363ms polkit.service 352ms sys-kernel-debug.mount 338ms dev-mqueue.mount 321ms dev-hugepages.mount 300ms boot-efi.mount 222ms systemd-sysctl.service 149ms systemd-user-sessions.service 114ms systemd-tmpfiles-setup.service 88ms console-kit-log-system-start.service 73ms console-kit-daemon.service 49ms dev-sda1.swap 44ms upower.service 33ms systemd-remount-fs.service

So my system boots 🙂 Lets see what is left to replace openrc.

Couldn’t register serial port 0000:02:0a.2: -28

In order to get more than 2 serial ports working, I “fixed” my currently used kernel config:

CONFIG_SERIAL_8250_NR_UARTS=32 CONFIG_SERIAL_8250_RUNTIME_UARTS=6

git clone https://github.com/git/git.git

The first thing you would try is to use ifconfig to change the mac address.

ifconfig eth0 hw ether xx:xx:xx:xx:xx:xx

root@OT:~# strace ifconfig eth0 hw ether 00:10:7e:02:52:b6 execve("/sbin/ifconfig", [“ifconfig”, “eth0”, “hw”, “ether”, “00:10:7e:02:52:b6”], [/* 11 vars */]) = 0 brk(0) = 0x943b000 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77d0000 access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat64(3, {st_mode=S_IFREG|0644, st_size=20075, …}) = 0 mmap2(NULL, 20075, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb77cb000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6", O_RDONLY) = 3 read(3, “177ELF111\0\0\0\0\0\0\0\0\03\03\01\0\0\0360m1\0004\0\0\0”…, 512) = 512 fstat64(3, {st_mode=S_IFREG|0755, st_size=1319176, …}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb77ca000 mmap2(NULL, 1329480, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb7685000 mprotect(0xb77c3000, 4096, PROT_NONE) = 0 mmap2(0xb77c4000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x13e) = 0xb77c4000 mmap2(0xb77c7000, 10568, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb77c7000 close(3) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7684000 set_thread_area({entry_number:-1 -> 6, base_addr:0xb76846c0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0 mprotect(0xb77c4000, 8192, PROT_READ) = 0 mprotect(0xb77ed000, 4096, PROT_READ) = 0 munmap(0xb77cb000, 20075) = 0 brk(0) = 0x943b000 brk(0x945c000) = 0x945c000 uname({sys=“Linux”, node=“OT”, …}) = 0 access("/proc/net", R_OK) = 0 access("/proc/net/unix", R_OK) = 0 socket(PF_FILE, SOCK_DGRAM, 0) = 3 socket(PF_INET, SOCK_DGRAM, IPPROTO_IP) = 4 access("/proc/net/if_inet6", R_OK) = -1 ENOENT (No such file or directory) access("/proc/net/ax25", R_OK) = -1 ENOENT (No such file or directory) access("/proc/net/nr", R_OK) = -1 ENOENT (No such file or directory) access("/proc/net/rose", R_OK) = -1 ENOENT (No such file or directory) access("/proc/net/ipx", R_OK) = -1 ENOENT (No such file or directory) access("/proc/net/appletalk", R_OK) = -1 ENOENT (No such file or directory) access("/proc/sys/net/econet", R_OK) = -1 ENOENT (No such file or directory) access("/proc/sys/net/ash", R_OK) = -1 ENOENT (No such file or directory) access("/proc/net/x25", R_OK) = -1 ENOENT (No such file or directory) ioctl(4, SIOCSIFHWADDR, {ifr_name=“eth0”, ifr_hwaddr=00:10:7e:02:52:b6}) = 0 exit_group(0) = ?

What this does is to change the mac address, but after a reboot this change is gone. So where is the mac address stored, you my ask. Normaly each NIC has an eeprom where some specific informations are stored like the mac address. And for linux there exists a nice tool to dump and change the contents of this eeproms – ethtool.

root@OT:~# ethtool -e eth0 Offset Values —— —— 0x0000 00 10 7e 01 fc 5b 00 00 00 00 01 03 01 47 00 00 0x0010 00 00 00 00 c0 49 01 00 00 00 70 00 00 00 00 00 0x0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0060 20 00 01 40 0a 41 00 00 00 00 00 00 00 00 00 00 0x0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e2 37

root@OT:~# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:10:7e:01:fc:5b inet addr:10.204.120.12 Bcast:10.204.127.255 Mask:255.255.192.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:812 errors:0 dropped:0 overruns:0 frame:0 TX packets:37 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:125002 (122.0 KiB) TX bytes:3195 (3.1 KiB)

Did you see it? We found the place where our mac address is stored 🙂 Lets try to change the mac address directly in the eeprom.

root@OT:# ethtool -E eth0 magic 0x1234 offset 0x5 value 0x5c root@OT:# ethtool -e eth0 Offset Values —— —— 0x0000 00 10 7e 01 fc 5c 00 00 00 00 01 03 01 47 00 00 0x0010 00 00 00 00 c0 49 01 00 00 00 70 00 00 00 00 00 0x0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0060 20 00 01 40 0a 41 00 00 00 00 00 00 00 00 00 00 0x0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 e2 36

In theory our new mac address should be available after an reboot.

root@OT:# reboot root@OT:# ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:10:7e:01:fc:5c inet addr:10.204.120.12 Bcast:10.204.127.255 Mask:255.255.192.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:482 errors:0 dropped:0 overruns:0 frame:0 TX packets:7 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:32327 (31.5 KiB) TX bytes:986 (986.0 B)

Success – now its time for the big fat warning:

Every NIC stores the mac address at different offsets etc. so its a good idea to first look at the datasheet and then make experiments. Also the magic value needed for ethtool needs to be kown – look at the corresponding linux driver.

The new repository can be found here: https://github.com/austriancoder/v4l2-em8300

Click Me

objdump -S ./build/cbfs/fallback/coreboot_ram.elf

and search for the address of the instruction pointer – may it help you to figure out whats going on 🙂

diff -rq /mnt/fs1 /mnt/fs2

• mount /dev/sda1 /mnt/
• mount -t proc none /mnt/proc
• mount -o bind /dev /mnt/dev
• chroot /mnt/ /bin/bash
• /usr/sbin/grub-install –recheck –no-floppy /dev/sda

With this routine it it is also possible to fix UUID problems.

Starting with this second the whole blog will be in English and it will cover a broader range of topics…

Ich habe schon länger nichts mehr von mir hören lassen, doch nun habe ich ein Update bezüglich em8300 und dem langsamen aber stätigem Prozess zur Aufnahme in den Mainline Kernel.

Im Linux Kernel 3.3.0 sind kleine Änderungen für die adv7170 und adb7175 Treiber eingeflossen, welche vom em8300 Treiber benötigt werden. Somit wäre es dann möglich direkt mit dem V4L2 Subdevices zu arbeiten. Was gibt es aber sonst noch zu tun, damit der Prozess irgendwann ein Ende findet?

• bt868 Treiber in den Mainline bringen
• VB2
• Evtl die DVB-API untersuchen, ob besser als V4L2 API für Ausgbae
• Rework des Firmware-Loaders
• Locking
• …

Ich hoffe, dass ich in den nächsten Wochen wieder ein wenig Zeit finde.

Ich habe die letzten zwei Tage genützt um den Audio Teil des Treibers ein wenig aufzuräumen. Ab jetzt wird nur noch ALSA unterstützt und alle Moduloptionen bezüglich Audio wurden entfernt. Langsam aber sicher habe ich schon viele Teile aufgeräumt und der Treiber wird immer besser 🙂

Über die nächsten Schritte in der Entwicklung bin ich mir noch nicht sicher. vbuf2 wäre sicherlich eine Überlegung wert, da ich möglichst viel Kernel-Funktionalität verwenden möchte – macht den Treiber schön klein und übersichtlich. Ich hoffe ich werde in den nächsten Wochen/Monaten wieder einmal Richtig viel Zeit fürs hacken haben.

Achja – Sourcen gibts hier.

echo “” | cpp -dD

Dies kann hin und wieder recht nützlich sein.

Auf meiner TODO findet sich im Moment folgendes:

• AC3-Support für ALSA
• ALSA Bugfixing
• StillPicture
• die letzten Sync-Probleme lösen

Es wird dann nicht mehr lange gehen, bis ich den buffer-sync-rewrite branch in den trunk mergen werde und dann sollte endlich ein neues langerwartetes Release folgen.

BTW: Es ist zu empfehlen einen modifizierten Treiber für die dxr3 zu verwenden, welchen es hier gibt: hg.assembla.com/em8300-cgmeiner

Zum Glück gibt es die Möglichkeit die XRuns zu debugen – siehe hier. Ich werde sicherlich noch ein paar nette Studen mit alsa verbringen.

$> PATH=. $> echo ‘a & a’ > a $> chmod 755 a; /bin/bash a

Nun brauche ich sehr viel Feedback bezüglich A/V sync… also alle testen. http://projects.vdr-developer.org/git/?p=vdr-plugin-dxr3.git;a=shortlog;h=refs/heads/buffer-and-sync-rewrite

Danke euch allen

Mein Kunde verwendet im Moment einen aktuellen Recher (Quad-Core) mit einem ebenso aktuellen Windows. Blöderweise werden keine Treiber von HP für diese Windows-Version zur Verfügung gestellt und ich musste nach einer Alternative ausschau halten. Und hier glänzt Linux. Ich verwende einen 2.6.32 Kernel und konnte mit diesem erfolgreich das externe Bandlaufwerk (Parallel-Port) erkennen/verwenden.

Dazu müssen folgende Module compiliert und geladen werden:

• epat
• paride
• pt

Ist das Bandlaufwerk verbunden und die Module geladen sollte folgendes via *dmesg *zu sehen sein.

paride: epat registered as protocol 0 pt: pt version 1.04, major 96 pt0: Sharing parport0 at 0x378 pt0: epat 1.02, Shuttle EPAT chip c6 at 0x378, mode 2 (8-bit), delay 1 pt0: HP COLORADO 20GBe, master, blocksize 512, 9209 MB

[mp3 @ 0x9e70a60]incorrect frame size

Diese kann ignoriert werden… die Ursache ist mir bekannt, doch ich bin mir noch nicht sicher, wie ich das am schönsten löse 🙂

Update:

Der Bug 169 ist nun mit Commit 961b570ff897b54beabdcb4c54e59049203ce10a gefixt.

meine Schwester benötigt für ihre Bachelorarbeit zum Thema „Der Einsatz von Social Media beim Verkauf von Merchandise-Produkten − Dargestellt an einem Praxisbeispiel aus der Musikbranche“ eure Hilfe.

Einfach http://vote.sinceyouaredead.at besuchen und sich 10 Minuten Zeit nehmen um die Umfrage zu beantworten. Unter allen Teilnehmer – EMail-Adresse vorausgesetzt – werden Preise verlost.

Danke!

Schönes Wochenende

endlich habe ich mich getraut, den alten SpuEncoder durch den neuen zu ersetzten, auch wenn es noch zu Problemen kommen kann. Doch dies war ein wichtiger Schritt in die richtige Richtung.

Bevor ich die bekannten Bugs im SpuEncoder behebe, brauche ich ein bisschen Abstand und von dieser Thematik und bin dabei die StillPicture-Methode zu fixen. Wie es sich herausstellt ist das Vorhaben – wie sollte es anders sein – nicht ganz trivial. Zu aller erst muss ich mich mit den verschiedenen Playmodes vertraut machen und da habe ich schon ein paar Dinge gefunden, die im Treiber nicht vorhanden sind. Ein Beispiel wäre hier  EM8300_PLAYMODE_SINGLESTEP. Ist zwar in der em8300.h vorhanden, wird aber vom Treiber nicht unterstützt. Das wird noch eine interessante Reise in das Land der em8300 werden. Es wäre schön, wenn es eine ordentlich dokumentierte API für die Treiber geben würde. Bin es aber eh schon gewohnt immer alles auszuprobieren zu müssen und nach 1-2 Tagen hackings eine Lösung zu finden.

greets

Stay tuned

ich bin auf der Suche nach Testern für das neue OSD.  Dazu einfach die aktuelle Entwicklerversion des Plugins herunterladen, installieren und testen.

Die Entwicklerversion ist entweder hier oder via git unter git://<a href="http://community.xeatre.tv/vdr-plugin-dxr3.git" target="_blank">community.xeatre.tv/vdr-plugin-<span>dxr3</span>.git</a> verfügbar. Probleme, Wünsche etc. bitte unter http://projects.vdr-developer.org/projects/show/plg-dxr3 melden.

Danke an Alle

Update

Hier noch zwei Screenshots, die das kleine Tool gtkspu zeigen, welches einen SPU-Datenstrom darstellen kann. Hier sieht das Ganze nicht so schlecht aus. Bei meinem Source stimmen auf jeden Fall die Farben nicht.

Update 2

Ich habe nun zwei kleine Bugs behoben und nun schaut das ganze schon recht gut aus. Die letzten Fehler werde ich in den nächsten Tagen beheben und dann folgt ein git push und jeder kann testen.

Nun da meine Masterarbeit abgeschlossen ist und ich am kommenden Donnerstag meine Masterprüfung (mündlich) habe, finde ich langsam wieder Zeit für das Plugin. Und das erste das unbedingt gefixt werden muss ist das OSD. Der Source wird leichter verständlich und ist übersichtlicher. Was noch fehlt ist das Handling für Bpp != 2 und hier mache ich diesen Moment gute Fortschritte.

Stay tuned….

mittlerweile ist viel passiert und der syncbuffer und das demuxdevice sind komplett aus dem Source verschwunden. Und mein erstes Teilziel ist erreicht. Ich kann zwischen den Kanälen zappen und ich bekomme jedes mal ohne Tonknister und Co. einen sauberen Sound und das mit guten Umschaltzeiten. Eine Problem für die vielen Probleme mit dem Sync waren dann bemerkbar, als ein OSD angezeigt wurde… habe die Ausgabe abgedreht und siehe da… um Welten besser.

Als nächstes möchte ich Video auf den TV zaubern und das Lippen-Syncron.. see ya

Eine Region hat einen Start- u. Endzeile und wird genauer ducht Sektionen bestimmt – mittels Startreihe. Ich hoffe ich finde bzw. erfinde solch einen Erkennungsalgorithmus… dann wäre das OSD wesentlich besser.

Cheers

cFixedLengthFrame oder warum doppele Datenhaltung

Im Moment wird aus dem Pes-Stream ein cDxr3PesFrame definiert, welcher wichtige Informationen ala Pes, Payload etc. beinhaltet. Dann wird – unter gewissen Umständen – dieser cDxr3PesFrame in einen cFixedLengthFrame kopiert und im SyncBuffer verarbeitet.

Nun habe ich die Idee, den cDxr3PesFrame überall zu verwenden… aus diesem Grund werde ich als erstes die Datenstruktur zur Speicherung von Frames im Syncbuffer auf eine LinkedList abändern. Danach wird schrittweise der cFixedLengthFrame eliminiert. Diese Designänderung macht den Ablauf im Plugin wesentlich einfacher.

Pes-Stream —> wird zu —> cDxr3PesFrame —> wird in SynBuffer gespeichert —> wird via Output-Thread ausgegeben

Mal schauen, wie lange ich für die Änderungen brauche und viele neue Bugs ich einscheusen kann 🙂

im moment Arbeite ich daran den neuen Pes-Parser in das Plugin zu integrieren. Leider ist das nicht immer so einfach um die Gefahr, neue Bugs zu erzeugen, ist relativ hoch. Ich muss mir langsam auch mal Gedanken machen, wann ich ein Art Beta-Version machen sollte. Ich denke, dass dies noch so lange dauern wird, bis auch das Buffering und Syncing überarbeitet ist.

Nun mal ein Blick in die Vergangenheit 🙂 Ich habe vor mehreren Monaten begonnen, das Plugin von Grundauf neu zu schreiben… unter anderem auch das OSD… ich verwendete zum testen gtkspu und ich denke der Unterschied ist sehr gut sichtbar.  Oben der neue OSD Code und unten der alte OSD Code.

Bis diese Änderungen in das Plugin einfließen, werden aber noch ein paar Monate vergehen… da es noch sehr viele andere Dinge zu machen gibt… das wird wohl in einem fast rewritte des Plguins enden.

Desweiten bin ich im Moment auch mit meiner Master-Arbeit beschäftigt und das hat mehr Prioritäten als alles andere, auch wenn ich an gewissen Tagen lieder etwas anderes machen würde, als mich mit Java und AVR32 auseinander zu setzten.

git rm dxr3syncbuffer.c git rm dxr3syncbuffer.h git rm dxr3demuxdevice.c git rm dxr3demuxdevice.h

Das ist zwar eine brachialte Art und Weise, doch irgnedwann muss man das Buffering und Syncing neu schreiben. Nun geht es darum, alles wieder ohne Fehler zum compilieren zu bringen und dann das Plugin wieder so funktionstüchtig zu machen wie die 0.2.9 Version. Es werden große Änderungen sein, doch es wird sich auszahlen.

Ich bin mir auch im klaren darüber, dass die jetzige git Version evt nicht so stabil läuft wie die 0.2.9, doch das ist nur normal, wenn man viele Dinge über den Haufen wirft und neu erfindet. Gut Ding brauch seine Zeit.

PS: Alsa Audioausgabe ist hin und wieder buggy und bei einigen funktioniert garnix – keine Angst, dass steht auch auf meiner TODO 🙂

Mein großes Ziel ist zum einen Alsa für die Soundausgabe zu unterstützten und zum anderen das Plugin wesentlich stabiler zu machen. Alsa funktioniert schon recht gut, auch wenn es noch Probleme beim Umschalten geben kann und Digital PCM und AC3 noch nicht unterstützt werden. Doch ich bin auf dem richtigen Weg.

Ich bin immer sehr froh über Testberichte 🙂 Die aktuellen Sourcen gibts hier: http://projects.vdr-developer.org/git/?p=vdr-plugin-dxr3.git;a=summary

Im Moment ist Alsa noch nicht per standard verfügbar, sonder muss in dxr3device.c von Hand aktiviert werden. Am besten nach folgender Zeile ausschau halten:

audioOut = new cAudioAlsa();

diese auskommentieren und die Zeile mit cAudioOss() einkommentieren.

Viel Spaß

*Unzip the archive, then process the resulting files to obtain a numeric result. You’ll be taking the sum of lines from files matching a certain description, and multiplying those sums together to obtain a final result. Note that files have many different extensions, like ‘.pdf’ and ‘.js’, but all are plain text files containing a small number of lines of text. *

• Sum of line 4 for all files with path or name containing BCD and ending in .xml Sum of line 3 for all files with path or name containing EFG and ending in .xml *Hint: If the requested line does not exist, do not increment the sum.

• Multiply all the above sums together and enter the product below. *(Note: Answer must be an exact, decimal representation of the number.)

Mit ein wenig Bash-Scripting ist das auch sehr schnell und einfach lösbar. Viel Spaß beim hacken 🙂

Zum einen hat das nächste Semester des Master-Studiums begonnen und aus diesem Grund habe ich einiges um die Ohren. Angefangen von AVR32 über Simulation und Modellierung bis hin zur IPhone-Programmierung. Doch auch meine Arbeit in der großen Welt des Open-Source ist auch noch da, wenn nicht immer sichtbar. Ich arbeite, wenn ich Zeit finde an allem was mit Dxr3 zu tun hat und sende hier und da ein paar Patches ab. Wenn alles nach meinem Willen geht, sollte der em8300 Treiber irgendwann in den offiziellen Kernel kommen und sich schön in V4l2 integrieren. Doch bis dahin habe ich noch einiges vor mir. Es ist immer wieder schwer, ob ich am Plugin oder am Treiber weiter arbeiten soll, doch das Plugin muss endlich mal raus. Wäre doch schade um die viele Arbeit.. tja.. bald ist wieder mal Wochenende und evt kann ich dann wieder hacken.

Musikalisch gesehn ist mein Leben auch abwechslungsreich geworden und ich kämpfe immer noch mit den gleichen Problemen. Wie zum Teufel kann ich all meine kreative Engerie gut auf der Gitarre umsetzten und mal ein paar neue Songs meinen Bandmembers zeigen. Ich habe einfach zu viele gute Riffs und Parts im Kopf, sodass ich das Problem habe nicht alle in einen Song packen zu können. Tja.. thats live.

Es sind Ferien und man hat hin und wieder Zeit ein wenig was zu programmieren… das Dxr3-Plugin ist fast so weit, dass das OSD funktioniert. Ich habe das OSD-Bitmap mit rle encoded, habe das OSD in Regionen zu max 4 Farben aufgeteilt und kenne auch schon das DVD Subtitle Format recht gut, doch es ist einfach noch nichts zu sehen… entweder habe ich noch was vergessen oder das erstellte Paket ist $%@%.

Bis in 4-5 Tagen sollte dann endlich alles so weit sein, dass ich die erste Alpha der 0.3 er Serie announcen werde.

/me geht jetzt mal an die frische Luft

• Prüfen ob audio_is_initialized überhaupt benötigt wird
• Eine elegante Lösung für set_prescaled_volume finden (audiohw_set_volume(l, r))
• Einige Sainty-Checks einbauen, ob eine bestimmte AUDIOHW_CAPS Kombination ok ist
• sound_val2phys in die Audio-Codec Treiber auslagern
• Für die cutoff Funktionen eigene CAPS definieren und verwenden
• Support für 1.5 DB Schritte verbessern
• sound_set_loudness und Co in den mas35xx Treiber verschieben
• Den DSP für den Simulator verwenden

Es ist zwar eine lange Liste, doch ich bin nicht unter Zeitdruck 😉

options snd-hda-intel enable=1 index=0 alias snd-card-0 snd-hda-intel options snd-hda-intel model=6stack

Happy Hacking

Nachdem mein Arbeitsrechner nun wieder online ist, werde ich weiter an meinen Projekten arbeiten und hin und wider mal blogen.

…

Plugins: vdr -P”name [OPTIONS]”

dxr3 (0.3.0_rc1) – em8300 based output device

-v {pal/ntsc}                –videosystem {pal/ntsc}                 video system to use default: pal

habe heute ein wenig Zeit gefunden, und habe nun einen Lippen-Synchronen Ton mit passendem Bild 🙂 Leider ist der A/V-Sync Code noch nicht sehr ausgereift und deswegen geht beim Umschalten entweder Bild oder Ton verloren. Das ‘Problem’ sollte ich über das Wochenende gefixt haben und dann kann ich wieder einen Punkt aus meiner ToDo streichen.

Als nächstes werde ich entweder das OSD angehen, oder eine Infrastruktur entwickeln, damit der GrabImage-API Aufruf funktioniert bzw das Spektrum-Analyser PCM-Daten vom Plugin bekommt.

Ein Valgrind-Test könnte evt auch nicht schaden und ja.. ein das Plugin crasht beim beenden des VDR’s noch.. wird noch ein wenig dauern, bis ich Tester brauche und meine Quellen in den SVN auf sourceforge hochladen werde.

Stay tuned

Nachdem A/V Sync gefixt ist und das OSD funktioniert habe ich folgendes noch auf meiner Liste (ausschnitt. nicht sortiert nach Prio)

• Frabwerte mittels OSD einstellen
• ImageGrab –> irgendwann soll mein Atmo auch gehen
• PCM-Source für das Spectrum-Analyzer Plugin
• i18n

Ich hoffe ich finde die nächsten Tage viel Zeit für dieses Projekt…

Hier mal ein kleiner Vorgeschmack:

Feb 26 14:44:59 vdr vdr: [24405] initializing plugin: dxr3 (0.3.0_rc1): TODO Feb 26 14:44:59 vdr vdr: [24405] [dxr3-decoder] using avcodec/ffmpeg version 3352580 build 3352580 Feb 26 14:44:59 vdr vdr: [24405] [dxr3-interface] ready… Feb 26 14:44:59 vdr vdr: [24405] ERROR: /dev/em8300_ma-0: Datei oder Verzeichnis nicht gefunden Feb 26 14:44:59 vdr vdr: [24405] [dxr3-output-audio] using alsa driver Feb 26 14:44:59 vdr vdr: [24405] [dxr3-interface] ioctl 1074021127 on 0 with result 0 Feb 26 14:44:59 vdr vdr: [24405] [dxr3-interface] ioctl 1074545410 on 0 with result 0 Feb 26 14:44:59 vdr vdr: [24405] [dxr3-interface] ioctl 1074021126 on 0 with result 0 Feb 26 14:44:59 vdr vdr: [24405] [dxr3-interface] ioctl 1074021137 on 0 with result 0 Feb 26 14:44:59 vdr vdr: [24405] [dxr3-interface] ioctl 1074021136 on 0 with result 0 Feb 26 14:44:59 vdr vdr: [24405] initializing plugin: live (0.1.0): Live Interactive VDR Environment Feb 26 14:44:59 vdr vdr: [24405] setting primary device to 2 Feb 26 14:44:59 vdr vdr: [24412] Audio-Output Thread (dxr3) thread started (pid=24405, tid=24412) Feb 26 14:44:59 vdr vdr: [24413] Video-Output Thread (dxr3) thread started (pid=24405, tid=24413) Feb 26 14:44:59 vdr vdr: [24405] assuming manual start of VDR Feb 26 14:44:59 vdr vdr: [24405] SVDRP listening on port 2001 Feb 26 14:44:59 vdr vdr: [24405] setting current skin to “sttng” Feb 26 14:44:59 vdr vdr: [24405] loading /etc/vdr//themes/sttng-default.theme Feb 26 14:44:59 vdr vdr: [24405] starting plugin: dxr3 Feb 26 14:44:59 vdr vdr: [24405] starting plugin: live Feb 26 14:44:59 vdr vdr: [24405] LIVE: initial file cache has 82 entries and needs 300358 bytes of data! Feb 26 14:44:59 vdr vdr: [24416] KBD remote control thread started (pid=24405, tid=24416) Feb 26 14:44:59 vdr vdr: [24405] remote control KBD – learning keys Feb 26 14:44:59 vdr vdr: [24405] ERROR: no OSD provider available – using dummy OSD! Feb 26 14:45:01 vdr vdr: [24409] CAM 1: no module present Feb 26 14:45:09 vdr vdr: [24405] switching to channel 2 Feb 26 14:45:09 vdr vdr: [24424] transfer thread started (pid=24405, tid=24424) Feb 26 14:45:09 vdr vdr: [24425] receiver on device 1 thread started (pid=24405, tid=24425) Feb 26 14:45:09 vdr vdr: [24426] TS buffer on device 1 thread started (pid=24405, tid=24426) Feb 26 14:45:09 vdr vdr: [24405] ERROR: no OSD provider available – using dummy OSD! Feb 26 14:45:09 vdr vdr: [24405] live reloading timers Feb 26 14:45:10 vdr vdr: [24413] [dxr3-output] starting Feb 26 14:45:10 vdr vdr: [24424] setting audio track to 1 (0) Feb 26 14:45:10 vdr vdr: [24424] [dxr3-audio-alsa] switching to analog audio Feb 26 14:45:10 vdr vdr: [24412] [dxr3-output] starting Feb 26 14:45:10 vdr vdr: [24412] [dxr-audio-alsa] changing samplerate to 48000 (old 0) Feb 26 14:45:10 vdr vdr: [24412] [dxr-audio-alsa] changing num of channels to 2 (old 0)

Hier einmal die großen Ziele von diesem Projekt:

• Eigener Audio-Treiber für die zwei Mas-Codec
• Einfache Möglichkeit um für ein Codec zu definieren was es alles in Hardware machen kann Z.b.: Bass, Prescaler,…
• Einheitliches Interface um die Lautstärke zu regulieren –> audiohw_set_volume(l, r)
• Preinit/Postinit aufräume

Eine sehr große Liste, doch sollte machbar sein. Ich freue mich schon auf ein paar Stunden Programmierarbeit.

Dieser Fehler bekam ich bei einem Update des NetworkManager’s unter Gentoo. Scheinbar ist hängt dies mit Perl, intltool und dem xml parser zusammen. Für mehr Informationen einfach einen Blick auf https://bugs.gentoo.org/show_bug.cgi?id=41124

Und hier nun die sehr einfache Lösung – works for me(tm)

emerge  XML-Parser networkmanger

Happy Hacking..

Ich spiele im Moment mit dem Gedanken bei der Entwicklung von KDE aktiv mitzuwirken. Wäre auf jeden Fall keine schlechte Idee, da ein so grosses Projekt nie genug fähige  Programmierer,  Artiests, … haben kann.

• Als ersten einmal die Ausgabe von lsusb -vvv:

Bus 002 Device 012: ID 0a4d:0090 Evolution Electronics, Ltd Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0a4d Evolution Electronics, Ltd idProduct 0x0090 bcdDevice 1.13 iManufacturer 1 Evolution Electronics Ltd. iProduct 2 USB Keystation 49e iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 101 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 3 Audio Class bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 9 bInCollection 1 baInterfaceNr( 0) 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 1 Audio bInterfaceSubClass 3 MIDI Streaming bInterfaceProtocol 0 iInterface 0 MIDIStreaming Interface Descriptor: bLength 7 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 65 MIDIStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 2 (MIDI_IN_JACK) bJackType 1 Embedded bJackID 1 iJack 0 MIDIStreaming Interface Descriptor: bLength 6 bDescriptorType 36 bDescriptorSubtype 2 (MIDI_IN_JACK) bJackType 2 External bJackID 2 iJack 0 MIDIStreaming Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (MIDI_OUT_JACK) bJackType 1 Embedded bJackID 3 bNrInputPins 1 baSourceID( 0) 2 BaSourcePin( 0) 1 iJack 0 MIDIStreaming Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 3 (MIDI_OUT_JACK) bJackType 2 External bJackID 4 bNrInputPins 1 baSourceID( 0) 1 BaSourcePin( 0) 1 iJack 0 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 bRefresh 0 bSynchAddress 0 MIDIStreaming Endpoint Descriptor: bLength 5 bDescriptorType 37 bDescriptorSubtype 1 (GENERAL) bNumEmbMIDIJack 1 baAssocJackID( 0) 3 Endpoint Descriptor: bLength 9 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 0 bRefresh 0 bSynchAddress 0 MIDIStreaming Endpoint Descriptor: bLength 5 bDescriptorType 37 bDescriptorSubtype 1 (GENERAL) bNumEmbMIDIJack 1 baAssocJackID( 0) 1 Device Status: 0x0000 (Bus Powered)

• Nun einmal die Ausgabe von dmesg beim Einstecken des Keyboards:

usb 2-6: new full speed USB device using ohci_hcd and address 14 ohci_hcd 0000:00:0a.0: GetStatus roothub.portstatus [5] = 0x00100103 PRSC PPS PES CCS usb 2-6: skipped 1 descriptor after interface usb 2-6: skipped 5 descriptors after interface usb 2-6: skipped 1 descriptor after endpoint usb 2-6: skipped 1 descriptor after endpoint usb 2-6: default language 0x0409 usb 2-6: new device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-6: Product: USB Keystation 49e usb 2-6: Manufacturer: Evolution Electronics Ltd. usb 2-6: uevent usb 2-6: usb_probe_device usb 2-6: configuration #1 chosen from 1 choice usb 2-6: adding 2-6:1.0 (config #1, interface 0) usb 2-6:1.0: uevent usb 2-6:1.0: uevent snd-usb-audio 2-6:1.0: usb_probe_interface snd-usb-audio 2-6:1.0: usb_probe_interface – got id usb 2-6: adding 2-6:1.1 (config #1, interface 1) usb 2-6:1.1: uevent usb 2-6:1.1: uevent drivers/usb/core/inode.c: creating file ‘014’ hub 2-0:1.0: state 7 ports 10 chg 0000 evt 0040

• Die Konfiguration des Kernels

Ist eigentlich sehr sehr einfach. Man muss nur **Device Drivers/Sound/Advanced Linux Sound Architecture/USB Devices/USB Audio/MIDI driver **als Modul oder fest in den Kernel kompilieren.

Schon kann man mit dem Midi-Keyboard in wine und nativ arbeiten, z.B. mit rosegarden.

Revision 15850 rockt 🙂

modprobe usbserial vendor=0x0781 product=0x7421 debug=1

picocom /dev/ttyUSB0

digit = ‘0’|’1’|’2′. hexdigit = digit|’A’|’B’|’C’|’D’|’E’|’F’. vorzeichen = ‘-‘|’+’. zahl = [vorzeichen] hexdigit {hexdigit}.

Wird zu:

digit = ‘0’ oder ‘1’ oder ‘2’ hexdigit = ‘digit’ oder ‘A’ oder ‘B’ oder ‘C’ oder ‘D’ oder ‘E’ oder ‘F’ vorzeichen = ‘-‘ oder ‘+’ zahl = entweder leer oder gleich ‘vorzeichen’ ‘hexdigit’ keinem, einem, oder mehreren ‘hexdigit’ EBNF check ok

Zweites Beispiel mit Fehler…

digit = ‘0’|’1’|’2′. hexdigit = zahl|’A’|’B’|’C’|’D’|’E’|’F’.

wird zu…

digit = ‘0’ oder ‘1’ oder ‘2’ hexdigit = EBNF-Error: ‘zahl’ not defined – at line 2

• emerge sys-devel/icecream

• rc-update add icecream default

• /etc/conf.d/icecream nach eigenen Wünschen bearbeiten*

• /etc/init.d/icecream start

Diese Schritte auf allen Gentoo Maschienen durchführen, welche am Compile-Cluster teilhaben sollen.

Nachdem der Cluster nun einsatzbereit ist, muss nur noch /etc/make.conf und PATH angepasst werden, damit der Cluster verwendet werden kann.

• export PATH=/usr/lib/icecc/bin/:$PATH

• PREROOTPATH=”/usr/lib/icecc/bin” in /etc/make.conf hinzufügen

Nun wird bei jedem emerge der Cluster verwendet und auch bei normalen Compile-Aufgaben. Im Moment habe ich einen kleinen Compile-Cluster bestehend aus 3 Gentoo-Rechner…

Happy Hacking…

• Im Compile-Cluster darf es nur einen Node mit ICECREAM_RUN_SCHEDULER=”yes” geben.

Jetzt fehlt nur noch der Userspace 🙂 Unter Gentoo reicht ein  einfaches ***emerge sys-power/suspend ***und dem Supendieren steht nichts mehr im Weg. Unter KDE ist KPowersave sehr zu empfehlen.

1. # emerge layman
2. # layman -a science
3. # echo “source /usr/portage/local/layman/make.conf” » /etc/make.conf
4. # emerge -av octave

These are the packages that would be merged, in order:

Calculating dependencies… done! [ebuild N ] app-admin/eselect-blas-0.1 0 kB [ebuild N ] sci-mathematics/glpk-4.22 USE=”-doc” 1,385 kB [ebuild N ] app-admin/eselect-lapack-0.1 0 kB [ebuild N ] dev-tcltk/expect-5.43.0 USE=”X -doc” 514 kB [ebuild N ] dev-util/gperf-3.0.3 845 kB [ebuild N ] sci-libs/blas-reference-20070226 USE=”-debug -doc” 5,208 kB [ebuild N ] dev-util/dejagnu-1.4.4-r1 USE=”-doc” 1,056 kB [ebuild N ] virtual/blas-1.0 0 kB [1] [ebuild N ] sci-libs/lapack-reference-3.1.1-r1 USE=”-debug -doc” 0 kB [ebuild N ] virtual/lapack-1.0 0 kB [1] [ebuild N ] sci-mathematics/octave-2.9.14 USE=”readline -curl -debug -doc -emacs -hdf5 -zlib” 9,185 kB [1]

Total: 11 packages (11 new), Size of downloads: 18,190 kB Portage tree and overlays: [0] /usr/portage [1] /usr/portage/local/layman/science

Would you like to merge these packages? [Yes/No]

# emerge crossdev && crossdev i386-mingw32

Danach muss man nur noch ./configure && make crosstest im Wine-Verzeichnis ausführen und man bekommt Binaries für Windows. Happy Hacking

Happy Reading