Pi Zero RAM lost

Pi Zero should have 512MB RAM but only 128MB are usable in RISC OS. Where are the rest?

anything to do with config.txt – possibly gpu_mem?

Sorry I forget (as I wrote on arcsite.de) change GPU_men from 64 to 32MB… no changes after restart. Only 128MB (113 free).

It is perhaps a silly question, but you did use the line “gpu_mem_512=32” instead of “gpu_mem=32”?

This fixup.dat fix the problem with my Zero…

I tried that fixup.dat on my Pi2, but I can still only see 130 MiB? any ideas, as it shoudl have 1 GiB?

I have looked for the answer in here but didn’t manage to find it, so sorry as I know this was discussed elsewhere.

Maybe the start.elf and the bootcode.bin from here https://www.riscosopen.org/forum/forums/9/topics/3753?page=3#posts-48102 are helping.

Hi Raik,

Sorry for the delay, life has been getting busy!

Sadly those files didn’t fix the issue.

For reference I am running 5.23 19/11/2015

I have also noticed that on a 512 MiB Pi 1 B (rev2) it is also showing 130 MiB RAM available.

Another SD card in that PiB shows 512 MiB….but won’t boot in the Pi2, it just hangs.

just to test, I also used the config.txt from the working card on the non-working card in the Pi2, and it still showed only 130 MiB

Does the problem go away with a plain RC14 image?

I had the same issue recently, I grabbed the latest firmware files from here – https://github.com/raspberrypi/firmware/tree/master/boot

The files you need are;
1. bootcode.bin
2. fixup.dat
3. start.elf

The latest firmware only seems to work with recent ROM images, the RC14 image wouldn’t start.

The latest firmware only seems to work with recent ROM images, the RC14 image wouldn’t start.

Oh, yes it does start! (It is pantomime season after all.)

Make sure when you copy them into $.!Boot.Loader that they are in capital letters before you copy them. RISC OS 5.21 should then start correctly. No later version is currently supported – after RC14 (RISC OS 5.21 Feb 2015) you are on your own!

I obtained the new firmware by downloading the Raspian SD card image, putting it onto an SD card, copying the three firmware files to another directory on my PC, downloading the RC14 SD card image onto the SD card, and then copying the three (latest) firmware files onto a USB pen drive.

This image (above) shows a vanilla Raspberry Pi RC14 image showing that I have capitalised the three firmware fles and copied them into $.!Boot.Loader and then rebooted. It boots slightly more slowly than the original (Feb 2015) firmware.

This image shows that I have renamed the RC14 RISC OS ROM image to ‘RISCOS14/IMG’ (maintaining a 8.3 name) and copied the new ROM image, capitalised, as ‘RISCOS/IMG’ and rebooted. All working. You’ll note that the zero pain module has been copied into $.!Boot.Choices.PreDesk as the latest ROMS require this.

Zeropain is explained in Archive 23:12 which should be hitting doormats real soon now.

Odd! With the RC14 ROM and the latest firmware, I just get a coloured screen and RISC OS doesn’t start the init stage.

Try putting the RC14 firmware back using the same method of copying that you used to put the latest firmware there. You’ll find that the way you put the firmware there was the problem.

For example rename BOOTCODE/BIN to BOOTNEW/BIN, START/ELF to START/NEW and FIXUP/DAT to FIXUP/NEW and then copy the original RC14 firmware (using the same coying method you used for the n ew firmware). You should (if your copying method was OK) see it all start up exactly as RC14 did. Then look in !Boot.Loader and report what you see.

Pi Zero gives a ZeroPain report for the DDE (whilst running the application !Builder 0.25 (23-Jul-2014)), see below, [even though it says it is fixed]:

Time: Tue Jan  5 16:50:15 2016
Location: Application space
Current Wimp task: Unknown
Last app to start: <Tools$Dir>.Acorn.amu -f <Build$Dir>.Env.Makefile FIXED=yes find-amu-version

R0  = 00013ef8 R1  = 00013f00 R2  = 00000000 R3  = 000181cc
R4  = 00013ef8 R5  = 00013ef8 R6  = 00000000 R7  = 00000000
R8  = 00000000 R9  = 00017e34 R10 = 000154e4 R11 = 00016158
R12 = 0001615c R13 = 0001614c R14 = 0000d3ec R15 = 0000cf9c
DFAR = 00000008  Mode USR32  Flags nzCv if   PSR = 20000110

0000cf54 : e51f183c : LDR     R1,&0000C720
0000cf58 : e590200c : LDR     R2,[R0,#12]
0000cf5c : e5b13008 : LDR     R3,[R1,#8]!
0000cf60 : e3520000 : CMP     R2,#0
0000cf64 : 1a000007 : BNE     &0000CF88
0000cf68 : e5932008 : LDR     R2,[R3,#8]
0000cf6c : e580200c : STR     R2,[R0,#12]
0000cf70 : e5922008 : LDR     R2,[R2,#8]
0000cf74 : e5a32018 : STR     R2,[R3,#24]!
0000cf78 : e5b0200c : LDR     R2,[R0,#12]!
0000cf7c : e3520000 : CMP     R2,#0
0000cf80 : 191ba800 : LDMNEDB R11,{R11,R13,PC}
0000cf84 : ea000008 : B       &0000CFAC
0000cf88 : e5922000 : LDR     R2,[R2,#0]
0000cf8c : e5a32008 : STR     R2,[R3,#8]!
0000cf90 : e580200c : STR     R2,[R0,#12]
0000cf94 * e5b21008 * LDR     R1,[R2,#8]!
0000cf98 : e5902008 : LDR     R2,[R0,#8]
0000cf9c : e5a21018 : STR     R1,[R2,#24]!
0000cfa0 : e590000c : LDR     R0,[R0,#12]
0000cfa4 : e3500000 : CMP     R0,#0
0000cfa8 : 191ba800 : LDMNEDB R11,{R11,R13,PC}
0000cfac : ebffffcf : BL      &0000CEF0
0000cfb0 : eaffffe1 : B       &0000CF3C
0000cfb4 : e1a0c00d : MOV     R12,R13
0000cfb8 : e92dd800 : STMDB   R13!,{R11,R12,R14,PC}
0000cfbc : e24cb004 : SUB     R11,R12,#4
0000cfc0 : e15d000a : CMP     R13,R10
0000cfc4 : 4b001988 : BLMI    &000135EC
0000cfc8 : e51f18b0 : LDR     R1,&0000C720
0000cfcc : e3500001 : CMP     R0,#1
0000cfd0 : 03a00004 : MOVEQ   R0,#4

--------------------------------------------------------------------------------

Hope this is helpful. I get 464MB of RAM, using the config.txt gpu_mem=48 but clock speed seems to be 700MHz not the widely suggested 1000MHz, even though I commented out the line init_emmc_clock=100000000 in case that was the problem. RISC OS ran first time using the same SD card image as I had tried on the model A+ (30-Dec-2015 Edit: should be 20-Dec-2015 as no further changes were made to CVS in 2015 after 20-Dec-2015 rom so that the AX8872B-based ethernet dongle would work and Nov 2015 firmware taken from the latest Raspian SD card image).

Haven’t tried a vanilla RC14 SD card image though. Would be useful to have a ‘latest development rom image before zero pain kicked in’ for download for the Pi as (unlike all the other platforms) there is no ‘stable’ release for the Pi to revert to and the vanilla RC14 image SD card image predates the AX8872B update to EtherUSB and [in any case] won’t work on the Pi Zero just by adding the latest rom…

Would be useful to have a ‘latest development rom image before zero pain kicked in’ for download for the Pi

That would be the July 2nd image – the announcement was 4th July stating July 5th was the first ZPP build.

You’re welcome to a copy, assuming a mail address…

Many thanks, but I do have a 30-Dec-2015 Edit: 20-Dec-2015 build so ’I’m all right Jack’ applies – in any case I’m not sure the licensing allows you to do that. That is the earliest build for the Pi that includes the AX7732B Ethernet changes. I just felt it would be a useful thing to have on the downloads page as an up to date, pre-2016 rom build [so that it works with zero pain rather than with ZeroPain]. Even if it can’t be called ‘stable’ (although I am not sure why it can’t as it has been unchanged for 10 months – perhaps we need a new word like ‘metastable’).

in any case I’m not sure the licensing allows you to do that.

Why not? It grants one the right to use and distribute the RISC OS source code and object code. If he sends you the beta Pi ROM archive (as fetched from ROOL), that includes the licence, as required.
He isn’t making a derivative work, so no source release is required. It’s all on ROOL anyway, as it is, in effect, proper RISC OS. Just older versions of it (hence CVS being a useful tool?).

Have I missed something that allows one to build their own custom RISC OS but not distribute archived copies of the real thing?

I do have a 30-Dec-2015 build so ’I’m all right Jack’ applies

Misunderstanding on my part:

1. Firstly that you were looking for a pre-ZPP build rather than the last 2015 build
2. Secondly that you were actually looking fo it to be available to all on the ROOL downloads pages.

As you say the “I’m alright Jack” does apply. In my case I have an archive of past builds, which I have supplied to others for test purposes and I also have a modified “2016” version ZeroPain (although I haven’t built a non-date reliant version at present)

Pi Zero gives a ZeroPain report for the DDE (whilst running the application !Builder 0.25 (23-Jul-2014)), see below, [even though it says it is fixed]

The real error is from amu, I’ll bet a bag of walnuts that you selected an environment from the Environment menu? Under the bonnet that runs the Env obey file which in turn calls amu to find out some version numbers and stuff, that’s why the current wimp task is “Unknown”.

Aside: the latest DDE should have !Builder 0.26 in it.

Aside: the latest DDE should have !Builder 0.26 in it.

There is no !Builder in DDE26. The one pointed to above reports itself as 0.25 (23-Jul-14), as in its Messages file, and despite what the VersionNum file says.

clock speed seems to be 700MHz not the widely suggested 1000MHz, even though I commented out the line init_emmc_clock=100000000 in case that was the problem.

The correct settings for the Pi Zero to give the proper clock speed for the Zero are as follows:

arm_freq=1000
core_freq=400
gpu_freq=300
sdram_freq=450

So I’ll redo the benchmarks in due course.

Edit: note with the extra command force_turbo=1. Benchmarks now updated.

The one pointed to above reports itself as 0.25 (23-Jul-14), as in its Messages file, and despite what the VersionNum file says.

We were using the latest !Builder, it was just wrongly versioned. I now have it from cvs identified as 0.26 (31-Oct-14).

Many thanks.

Following Chris Hall’s advice I have managed to create an SD card which boots and runs RISCOS on the Pi zero. However the tip of the cursor does not correspond to the active point. It is about half an inch to the left on the left hand side of the screen and about the same amount to the right at the right hand end of the screen. Is this a known problem? Can it be fixed?
Thanks.