Firmware interface changes - where are they detailed please?

[rosery]

Hi. I hope this is an appropriate place to ask - I'm working on the HAL for RISCOS. I had a frame buffer that worked more or less OK with firmware from early March. Having finally located this repository, I have tried using the mid may firmware. Many things have moved. e.g. a frame buffer is returned aligned to 0x1000 - That is an improvement, though ideally we require megabyte alignment. What I'm leading to, is, where can I find the changes to the firmware interface as they happen please? It is not much fun chasing a moving target almost blind... Thanks in advance ..

[popcornmix]

Currently you just have the github commit comments, and the diffs in the linux kernel tree (any interface changes will impact on the kernel). I guess a wiki page describing the mailbox protocol (including setting up framebuffer) would be useful. Especially if kept up to date. I'll put it on my list...

[popcornmix]

Currently you just have the github commit comments, and the diffs in the linux kernel tree (any interface changes will impact on the kernel). I guess a wiki page describing the mailbox protocol (including setting up framebuffer) would be useful. Especially if kept up to date. I'll put it on my list...

[rosery]

Hi, and thanks for this. What is particularly puzzling me is that firmware for early march gave me a framebuffer which I could then (before mmu came on) poke and see the result on screen. The FB I get with the current (5 day old) firmware, requested in the same way, syncs up the screen, but does not show these pokes .. Also the ATAG stuff appears missing .. do I now need a specific command in a specific file (command.txt?) to enable this behaviour. Thanks John

[popcornmix]

This sounds like a caching issue. Try adding disable_l2cache=1 to config.txt. If that fixes it you probably do want the L2 cache on (it improves performance), but you need to ensure your bus addresses are using the correct alias. Should be 0xCxxxxxxx when L2 is disabled, and 0x4xxxxxxx when L2 is enabled.

[rosery]

I'll try that shortly. Can we set up l2 caching from the arm11 side, or must it be in config.txt?

[popcornmix]

config.txt. It is the GPU that launches the ARM, and the arm code must be loaded through the right alias.

[rosery]

Yes .. L2 caching was the answer.. Is ther a list of config.txt tags.. Or shall I fire back those I've located?

[rosery]

Ok .. I guess I can deduce what I need from the top bits of the fb address that is returned .. Many many thanks for the help ..

[rosery]

Do ATAGs get loaded now? If so at what address in the image please?

[rosery]

Ok Am I being stupid, or am I missing something critical? Frame buffer address returned with l2 on is 0x4D385000,, and 0xCD385000 if disabled. Before arm mmu comes on, if the address is CD (L2 off) I can poke the address and see the results on screen. If GPU L2 is on, hence using 4D I do not see the results of the poke .. I.e. I cannot get a usable FB I can write to in l2 mode Thanks

[popcornmix]

http://elinux.org/RPi_config.txt for config.txt options. ATAGS are still loaded as they used to be. Nothing changed there.

If L2 enabled, and framebuffer is reported at bus address 0x4D385000 you need to access through the VC/ARM MMU with ARM physical address. I think you will use 0x0D385000 to get there. (You would also use the same address in the L2 disabled case - the VC/ARM MMU enforces the top nibble of the bus address).

[rosery]

Thanks for the syntax.. That is good. I have to be missing something on the FB

1: with the l2 turned off in config.txt, I can actively write the FB at 0d385000 and at cd385000 . This is very early, before any arm mmu is turned on. Writing to screen means writing a 10101010 bit pattern. 2: the same code, writing at 0d385000 or 4d385000 produces nothing on screen.

I stall the arm straight after the bit pattern write, so nothing else ought to be happening.. Diagnostic output from the arm side is identical.. there is only one line in config.txt, setting the l2 thing to 1 or 0

Can you shed any light?

[popcornmix]

I'd expect that to work. Suppose you fill the whole framebuffer - do you see anything there? (I'm wondering if it's getting stuck in a cache or write combining buffer).

[rosery]

Yes.. I fill the whole buffer .. Works ok cache off, fails cache on. Be happy to send you he image in use if that helps..

[popcornmix]

What address are you poking down the mailbox describing your frambuffer info? It should be a bus address (e.g. 0x4xxxxxxx when L2 is enabled).

[rosery]

That caught it.. I was poking the 0xc address till I found what address was returned, then using that. I did get an 0x4 address returned.. But starting on 0x4 seems to bring it to life - thanks

I presume I have to see an ATAG to determine in the kernel whether to use L2 addressing or not?

I still cannot find where the ATAGs stuff is loaded to prior to arm start .. I was expecting to find it at 0x00000100. Overwriting some of the kernel image. Has it moved beyond the end?

[popcornmix]

The cache alias isn't passed to ARM through ATAGs. Basically only L2 enabled is expected. If it is working, then there is no reason to disable L2 cache. Performance is significantly improved with it enabled.

See here for info on kernel loading: https://github.com/raspberrypi/linux/issues/16

Do you currently use the ATAGS? Do you use the first32K at start of your ARM image? I'd have thought you'd want to: disable_commandline_tags=1 and not use the first32K. Just have your ARM image starting at 0.

[rosery]

Where it was useful was in discovering the amount of RAM available. If I've read the issue 16 bit OK, this info is available in a device tree. What isn't clear to me is how I should get at this .. (killing the first 32k is not a problem for us.. )

One thing RISCOS needs that is (almost) a show stopper for us to change is 'inverse transparency'. Where you use the alpha channel to define 0xff as fully opaque, we use it to be fully transparent . Hopefully a mod to provide this as an option is going through. Also quite a lot of our code assumes megabyte alignment in the frame buffer start. Is that also possible?.

Many Many thanks for you help on all this

John

[popcornmix]

Megabyte alignment should be straightforward. I'll add a new alignment entry into the fbinfo_s struct (annoyingly changing that forces kernel/start.elf to be updated together). If you have any other requests for fbinfo_s ask now.

Inverse transparency is a problem. The hardware doesn't support that directly. We can ignore the alpha byte. The only other solution is to no longer display a live buffer, but have you updating a backbuffer. An operation (e.g. mailbox write) causes GPU to copy this buffer, inverting the alpha bytes, and display the new buffer. This is obviously a more expensive solution.

[rosery]

Do I read it right that I provide a template device tree file (dtb) and in the config.txt. provide the tree file name and hex address to load it at?

[popcornmix]

Yes. Currently the dtb file will just be loaded untouched. There is a plan for entries the GPU knows about (e.g. framebuffer width) to be overwritten, but that is not implemented yet.

[rosery]

Hm. so how is your alpha channel implemented .. a straight forward hard coded linear convertor, a DSP style multiplication, or a LUT? ..

the following describes how we- ideally - work I might as well list all the formats that RISC OS can currently use. If the answer is "yes we can do all of those" then naturally we'll be very happy!

Bit fields in the following descriptions are little-endian.

32bpp mode:

bits 24-31: 0 or transparency bits 16-23: blue bits 8-15: green bits 0-7: red

16bpp mode:

bit 15: 0 or transparency bits 10-14: blue bits 5-9: green bits 0-4: red

In 16 and 32bpp modes, the red/green/blue fields would ideally be fed through independent LUTs for each channel, to facilitate gamma correction and special effects (such as fading the screen to black when entering the screensaver). On platforms which enable the framebuffer to be blended with additional video plane(s), the top bits can optionally be used as transparency (i.e. the opposite of alpha, so 0 = opaque, and 0xFF = transparent). Again, we can make use of a LUT for this channel if it is available.

At a pinch, we can make 16bpp 565 work appear to operate as 5551, by careful programming of LUT values, but at the cost of reduced dynamic range on the blue and green channels - so obviously it would be better if we can have the video system working in native 5551.

1, 2, 4, 8bpp modes:

All bits are used as an index into a colour LUT (palette). Where pixels are smaller than bytes, they are packed in a little-endian order (so bits 0-3 of the first byte in 4bpp mode is the leftmost pixel). There isn't currently any API for colour-keying, instead we treat the LUT as though it outputs 4 channels (so any palette index may produce any alpha value, in addition to its RGB vector).

Bit of a mouthfull.. What could you manage do you think? Thanks

[rosery]

dtb file .. ok.. how, at present, can I determine the amount of ram available, if ATAG not in use?

[popcornmix]

For now I guess sticking with a specific start.elf and assuming memory split is easiest. For future: are you using our startup (first32K) code? do you want atags? do you want a device tree? would you prefer a new interface using mailbox. e.g. a get/set property interface?

[rosery]

Hi

I'll have to assume memory until I can find a way to determine it ..

Currently I accommodate the fact that some of the first 32k might be overwritten. Device tree I suppose could be useful, but we've never used it before, so it is something not essential.. If the mailbox used a get/set property interface then it would be possible for any OS to discover what lay underneath, and feed back any control info that might be relevant.

There are several bits of information we do need to discover, such as serial numbers, MAC addresses, amount of available RAM, etc. I had found these in ATAGs but given that others found the 'pollution' of the first part of the image troublesome, wouldn't it really be easier for all if , having started one's code in the arm, the arm could then query what lay underneath via (I guess) the mailbox structure .. even if what it then did equated to giving you a buffer containing the atag info.

hopefully this is helpful. I'm out and about tomorrow, but will try to keep an eye on this Thanks

[rosery]

I've got a quick answer to whether it is L2 enabled or not - request a FB with L2 addressing (top bits &4). It'll currently return no FB address if it isn't L2 enabled .. So retry with no cache addressing (top bits &c). This works with the start.elf of 17 may. and hopefully moving forward

John

[popcornmix]

From display guy:

The VC4 model is:

• we composit in sRGB
• we do any gamma correction & color-space tweaks for a particular display after all composition, and immediately before display.

<= 8bpp pixels can use a palette, so any A,R,G,B mapping is possible. Palette modes are slow (1 pixel/clock).

8bpp provides NO way to remap alpha, red, green, or blue values before composition. VC4 alpha means opacity, like on just about any other hardware. There is NO LUT.

In RGB5551, the alpha bit is an "opaque" bit.

[rosery]

we do any gamma correction & color-space tweaks :: how do these get applied? .. is that where the top 8 bits - transparence/opacity - is applied, or is it applied to the original composit?

thanks

Oh.. and any more thoughts on mailbox requeste etc?

[rosery]

Hi Without wanting to sound pushy, do you have any idea when you'll be able to provide firmware with megabyte aligned frame buffer, and the swapped byte ordering? .. talking around, it seems that simply ignoring the transparency/alpha channel would be practical .. after all, I guess we do only have one graphics plane? or will we be able to get the gpu side doing stuff in other planes?

Many thanks

John

[popcornmix]

I've done the easy ones. Latest firmware on github supports: framebuffer_ignore_alpha=1 framebuffer_align=0x100000 hvs_swap_red_blue=1

Not hugely tested, so let me know if any problems.

Handling multiple planes and alpha is a bit tricky (mostly due to inverted alpha value), but it is possible. I'm willing to get it working, but until you have a real requirement (e.g. you have GPU accelerated video working), it's not high priority.

[rosery]

Hi -- Many thanks ... but .. With just the 3 lines you gave me (above), and the github start.elf,loader.bin, and bootcode.bin, put up 3hrs ago with comment 'Invert sense of filtered group. Switch HDMI I2C clock from 100kHz to' .. I get a frame buffer aligned to 0x40, and (generally) doesn't seem to work.. I seem to get similar behaviour with the kernel.img there too .. Arm comes up after 1 to2 secs .. first signs of life on the screen at about 8 secs .. 'life' is flashing of the screen led 3 times before going out. nothing displays though. screen is a mac 30" screen that prior to this behaves correctly.

linux kernel with same switches in CONFIG.TXT still shows the same 0x40 buffer alignemnt.

Have I missed something please?

[rosery]

"(e.g. you have GPU accelerated video working)" what info is available to do this please .. is it 'public' or is it ATM just using a binary blob within linux? Thanks

[rosery]

Hi.. for what it is worth, just confirmed things are still misbehaving here for your version " rebuild with ipv6 enabled"

john

[popcornmix]

Does it work without the new entries in config.txt?

On Thursday, May 31, 2012, rosery wrote:

Hi.. for what it is worth, just confirmed things are still misbehaving here for your version " rebuild with ipv6 enabled"

john

---

Reply to this email directly or view it on GitHub: https://github.com/raspberrypi/firmware/issues/22#issuecomment-6024746

[rosery]

no.. it seems not to .. can you suggest anything else to try? - the sync light on the screen, which is out when screen drive is valid, flashes 3 flashes at about 8 secs in.. probably 1/4 sec on and 1/4 sec off, this it repeats approx every 10 flash intervals .. (5 secs ish) .. not sure if this is any help thanks

[rosery]

Going back through the start.elf commits, the last version that would start my monitor was about 14 days ago "popcornmix 14 days ago Rebuilt with sdcard patch improvement. Firmware allows power state to… " .. Have now tried the current start.elf on a different monitor - tv - and it displays.. so something in start.elf mods since then has stopped my monitor (mac 30" cinema screen) accepting your HDMI ..investigating ..

[rosery]

Going back through the start.elf commits, the last version that would start my monitor was about 8 days ago "wjt 8 days ago Remove unnecessary executable bits. "" .. Have now tried the current start.elf on a different monitor - tv - and it displays.. so something in start.elf mods since then has stopped my monitor (mac 30" cinema screen) accepting your HDMI ..investigating .. next commit fails to boot the monitor. have tried with hdmi_force_hotplug=0 (or 1) config_hdmi_boost=4 in config.txt .. no change. just doesn't like the monitor. Any thoughts please?

Also ATAGS .. Do I have to have 'your' bottom 32k to get ATAGS inserted at 0x100? They used to just appear at 0x100 overwriting my image, now, since around when the disable_commandline_tags thing appeared I do not seem to get them .. Again, Am I missing something? .. I have tried with that set =0 or =1

Thanks

[rosery]

(should I put any of this in another 'issue'? what is preferred?)

[asb]

@rosery it probably makes sense to make a new issue for the monitor regression, because if other people are suffering a similar regression they're more likely to come across it. Could you dump your EDID and relevant information from /opt/vc/bin/tvservice?

[rosery]

will do later. what is the 'best' linux image to start from? .. as you may have realised, I'm not actually running with linux here

[asb]

At the moment, you're probably best off grabbing the 'squeeze' image at http://www.raspberrypi.org/downloads and updating the firmware.

[popcornmix]

I've found a regression in hdmi out code. start.elf is updated. Does that fix problem?

[rosery]

Hi.. that certainly fixed the ability to display on my monitor .. thanks

I have confirmed that framebuffer_ignore_alpha=1 does ignore the alpha channel.. at least in 32bit mode as tried. I cannot make framebuffer_align=0x100000 give me any better than 0x40 alignment at 0x100 gave 0x09395200 at 0x1000 gave 0x09396000 at 0x8000 gave 0x09390000 at 0x10000 gave 0x9395040, as at 0x100000

i.e. it rounds/alignd, but limited to modulo 64k .. i.e. I would hope to get at align=0x100000 0x09400000

As best I can tell at this stage the hvs_swap_red_blue seems permanently on (as seen from riscos .. ) =0 and =1 appear to make no difference. I'll try booting this in linux shortly to confirm

Thanks John

[rosery]

Hi.. Any thoughts about the alignment thing? (if you have any eta it would be great to know..). Many thanks. John

[popcornmix]

You are correct. I did step through the allocation code and an alignment of 1M isn't supported (it stores alignment in a limited size bitfield). I'll sort something out soon.

[popcornmix]

Can you try this version: https://dl.dropbox.com/u/3669512/start.elf

Hopefully the alignment will be as requested.

[rosery]

Hi, many thanks, alignment now does as expected. We definitely have colour swap in 32 bit mode, though not convinced about 16bit mode. the hvs_swap_red_blue seems to make no difference. Is this 'intelligence' intended please?

Is there anywhere reliably where the hard info the used to be passed in ATAGs is located.. I have found the ram size word at 0x80 above the base of the vcram space. Occasionally I see the ATAG set at 0x100 above there, but it doesnt appear relaibly??

Many thanks

[rosery]

atags issue fixed with kernel_old=1.. thanks for that.

megabyte frame buffer alignment fixed in start.elf from 10-6-2012 .. thanks

[popcornmix]

Can you check #47 for a alternative way of getting ATAGs etc.

[rosery]

first look says.. Fantastic.. thanks.. will try to get on top of it this eve.. I'd suggest a couple more properties.. e.g set rb swap, set ignore alpha, etc.. then config.txt becomes more or less redundant in distinguishing between riscos booting and linux booting.

Agani.. Fantastic.. Many thanks