trbrenke
Posts: 5
Joined: Wed Aug 16, 2017 2:13 am

compute module 1.1 boot

Wed Aug 16, 2017 2:22 am

I am having recent issues.
using the IOboard and older compute module (U1 samsung) I can place them in boot mode and load an image.
using the newer Rev 1.1 moduals (U1 Elpida) requires the rpiboot.exe made in July of 2017.

both boards are marked as Rev 1.1. What changed?
the image that work on the Samsung U1 does not work on the Elpida U1.

why are they labled the same when the hardware is different?

AND more importently, what do I need to make an custome image for the Elpida marked IC that works?

Thanks, Tony

bptech
Posts: 10
Joined: Mon Aug 28, 2017 2:54 pm

Re: compute module 1.1 boot

Mon Aug 28, 2017 3:38 pm

I have a similar problem. More information:

1. My application is a headless server well tested and validated using Wheezy and the original CM1. Hundreds of units have been built, tested and are in use.

2. We got in a new shipment of CM1, identical in appearance except using the Elpida RAM chip. They still say Rev 1.1. Both say "Made in P. R. C." They have a symbol that looks like "JX" and a JX02 notation above the 94V-0 notice. The vias are slightly larger and the solder mask film is not well registered with the copper. The BGA parts look off center slightly.

3. These new parts will not program with the original version of RPIboot. The program just halts forever waiting for the response. We got in the newer version of rpiboot and it seems to program, but when we reboot all we get is a pattern of 8 flashes of the activity light, pause repeat. No activity on the serial port, in the development kit board no display, dead.

4. I did manage to load a light version of Jessie and it does boot up. But though it reports 512M of RAM, memtester reports that it can lock only 65K of RAM. /proc/CPUINFO says BCM2835, where on a working Wheezy board it says BCM2708. But it is not the later version CPU.

5. So it looks like a rogue version, we are sending them back. But is it possible that this is a stealth undocumented update, and that parts we get from other suppliers will have this issue? Would it work if we started over with Raspbian Stretch lite? Why would a part with the same processor but a different RAM chip fail to work with rpiboot? Or maybe it needs a slower memory clock for the Elpida?

User avatar
DougieLawson
Posts: 29746
Joined: Sun Jun 16, 2013 11:19 pm
Location: Basingstoke, UK
Contact: Website

Re: compute module 1.1 boot

Mon Aug 28, 2017 5:16 pm

For all current CM1 & CM3 boards you MUST use the latest version of Rpiboot https://www.raspberrypi.org/documentati ... lashing.md

The latest upstream Linux kernel dropped the BCM270x numbers and labels ALL raspberries as BCM2835 regardless of whether they're Pi0, Pi1, Pi2B, Pi3B, CM1, CM3 or CM3Lite.

Latest Jessie includes that 4.9 kernel.
Current Stretch also includes that 4.9 kernel.
Microprocessor, Raspberry Pi & Arduino Hacker
Mainframe database troubleshooter
MQTT Evangelist
Twitter: @DougieLawson

Since 2012: 1B*5, 2B*2, B+, A+, Zero*2, 3B*3

Please post ALL technical questions on the forum. Do not send private messages.

bptech
Posts: 10
Joined: Mon Aug 28, 2017 2:54 pm

Re: compute module 1.1 boot

Mon Aug 28, 2017 5:55 pm

Thanks, DougieLawson. Sounds like the processor got upgraded to remove a bug, which trashed earlier code. Or there was a bug in the code that had the RAM clock too fast for the Elpida chip. Or something.

If that is really what happened we need a new spin of the code and another trip through customer validation. It is not possible to use the normal apt-get upgrade path because the units will not boot. It would be nice if this were covered in the data sheet or somewhere in the documentation. If there are specific changes that can be done to patch the software it would work a lot better than redoing the whole development process on a raw new install.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 17882
Joined: Sat Jul 30, 2011 7:41 pm

Re: compute module 1.1 boot

Mon Aug 28, 2017 6:53 pm

I've pushed this up the chain of command, sounds important. Cannot comment on it right now as not my field of expertise; we are all back in office tomorrow so hopefully will be some more information available then.

James
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Please direct all questions to the forum, I do not do support via PM.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4436
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: compute module 1.1 boot

Mon Aug 28, 2017 7:56 pm

Most likely the ram chip supplier changed and requires slightly different timings. The bootloader.bin and start*.elf files in /boot deal with that.
You could try taking everything except kernel.img from /boot of a recent image and putting them into /boot on your cm image. The old linux install should still work on top of the new firmware/bootcode.

It's certainly not a cpu change. Bcm2835 and bcm2708 are effectively synonymous. To the pedantic one is the core silicon, and the other is the packaged device.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

bptech
Posts: 10
Joined: Mon Aug 28, 2017 2:54 pm

Re: compute module 1.1 boot

Tue Aug 29, 2017 11:40 am

Thanks 6by9, I will try your suggestion of updating the /boot files. It seems pretty possible that the memory clock rate is the issue, since there is really no difference in the boards except one uses a Samsung RAM chip and the other uses an Elpida RAM chip.

We are using a custom dt-blob.dts file which is in /boot so I will look at the files one by one to see which should be copied from the newer version supplied by rpiboot and which should be retained.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 4436
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: compute module 1.1 boot

Tue Aug 29, 2017 7:45 pm

Having looked at what is in /boot, I suspect bootcode.bin may be sufficient. The next step is *.elf and *.dat. The rest is all Linux kernel stuff that should be left alone if you want to stay on an old kernel/distro.
Almost all RAM chips need slightly different setups, and if nothing else then the firmware needs to recognise what I suspect is an updated revision in the OTP to know how to interpret it and adapt RAM parameters appropriately.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
Please don't send PMs asking for support - use the forum.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

bptech
Posts: 10
Joined: Mon Aug 28, 2017 2:54 pm

Re: compute module 1.1 boot

Tue Sep 05, 2017 12:19 am

No luck getting anything to boot using any combination of files in /boot and the old Wheezy image. In some cases it ends in a kernel panic, sometimes does not boot at all with 8 flashes of the activity light.

Something in the OTP programming in the processor has well and truly bricked old versions of Raspbian before 4.9. There is no documentation of the start.elf to give me any hints and the documentation for the new device tree setup does not cover this situation.

So I started the process of migrating to Stretch using the minimal Stretch image that will fit in the 4G flash of the CM1.

This also does not work because I am using the clock output on GPIO 44 for the LAN9512 hub and Ethernet chip. Just like the old Pi B+.

In the old Wheezy system I did a few lines in a dt-blob.dtb to set up the clock (clock_setup...) and assign it to the GPIO (pin@44 {function = "gp_clk"...). The new system does not seem to have anything equivalent to this.

I tried to force it to be a b+ by copying the bplus bcm2708-rpi-b-plus.dtb tp dt-blob.dtb, adding the lines that define the EMMC GPIO pins and adding the line "device_tree=dt-blob.dtb" to config.txt. No luck. The system boots but the LAN9512 never starts.

If there is no way to do this I will have to add a crystal to get the clock, but we have hundreds of boards already in production so this is not a great option. I did anticipate this situation and provided pads for the crystal so it won't be an ugly tack-on. But I hate those giant HC49 crystals, they are fragile and an added source of dropouts.

Do I:
1. Create an overlay for the LAN9512? If so, how do I configure the clock?
2. Add clock configuration lines to the dtb file? If so, what is the syntax? Can I just copy the lines from /proc/device-tree that work for a b-plus?
3. Am I stuck adding a crystal, and if so will the LAN9512 work as an added USB device? I suspect that it will because at that point it is just like any other USB hub with an Ethernet adapter plugged in. Not sure about the MAC address though. These devices need to be identifiable on the network via the MAC address for proper setup.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1312
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: compute module 1.1 boot

Tue Sep 05, 2017 5:53 am

Don't confuse dt-blob.bin with Device Tree. It is just a way of configuring pins and clocks from the firmware, and has not changed since the first Pis except to add definitions for new hardware. Grab the latest dt-blob.dts from the firmware repo here, add the settings you need, compile it as before and copy dt-blob.bin to /boot.

bptech
Posts: 10
Joined: Mon Aug 28, 2017 2:54 pm

Re: compute module 1.1 boot

Tue Sep 05, 2017 7:27 pm

Not sure why, but the /boot/dt-blob.bin file just doesn't work with the latest Stretch.
  • pi@raspberrypi:~$ cat /proc/version
    Linux version 4.9.41+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611) ) #1023 Tue Aug 8 15:47:12 BST 2017
It still reads the bvm2708-rpi-cm.dtb file, never sees dt-blob.bin
  • 002383.871: brfs: File read: 4381216 bytes
    002386.737: brfs: File read: /mfs/sd/bcm2708-rpi-cm.dtb
    002386.759: Loading 'bcm2708-rpi-cm.dtb' to 0x435a20 size 0x3a44
Tried it with and without device-tree=dt-blob.bin in the config.txt. The system boots and shows video on the HDMI output but never turns on the LAN9512.

The lines I used in the CM section of the dt-blob.bin file:
Under pin_config:

Code: Select all

            pin@p31 { function = "output"; termination = "no_pulling"; startup_state = "active"; }; // LAN_RUN
            pin@p44 { function = "gp_clk"; termination = "pull_down"; }; // ETH_CLK - Ethernet 25MHz output
Under pin_defines:

Code: Select all

         pin_defines {
            pin_define@EMMC_ENABLE {
               type = "internal";
               number = <47>;
           };
           pin_define@LAN_RUN {
               type = "internal";
               number = <31>;
            };
            pin_define@ETH_CLK {
               type = "internal";
               number = <44>;
            };
         }; // pin_defines
None of the items that were defined in the dt-blob.bin were in the /proc/device-tree. The vcdbg output shows no lines being processed from dt-blob.bin. I am probably missing something really obvious, but can't see what it is.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1186
Joined: Sat Sep 10, 2011 11:43 am

Re: compute module 1.1 boot

Tue Sep 05, 2017 7:41 pm

The dt-blob.bin is not read by the kernel (which is what you are doing by playing with device-tree etc) it is automatically read by the firmware at boot time (before the kernel is even loaded from the disk)

This is completely different and separate from the kernel device tree and in fact has a completely different layout etc. Just assume they are completely different and never the twain...

If you use a dt-blob file you should see it's effect on the pins after loading the kernel if you do "raspi-gpio get"

Make sure you edit the pins_cm or pins_cm3 sections as appropriate (you can delete the other sections happily to reduce the size of the file)

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1312
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: compute module 1.1 boot

Tue Sep 05, 2017 7:53 pm

I don't know how I can say this more clearly:

dt-blob.bin is not Device Tree.

You will never see anything from dt-blob.bin appearing in /proc/device-tree because dt-blob.bin is not Device Tree.

Don't try and load dt-blob.bin using "device-tree=dt-blob.bin" (or even "device_tree=dt-blob.bin", which will probably stop your Pi from booting), because dt-blob.bin is not Device Tree.

bptech
Posts: 10
Joined: Mon Aug 28, 2017 2:54 pm

Re: compute module 1.1 boot

Tue Sep 05, 2017 8:45 pm

Ok, thanks for your help. I assume the lines shown in my earlier comment for the modifications to dt-blob.dts are appropriate, and I should be seeing the clock output in my hardware. So far, no output.

In the old Wheezy version I also had to add some clock configuration lines, but there is nothing like that in the current dt-blob.dts standard file.

I will put this card in a development kit and download the rasp-gpio package and see if the GPIOs are being set up as specified in the dt-blob.bin. Can't do it in the target hardware, no Ethernet.

PhilE
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1312
Joined: Mon Sep 29, 2014 1:07 pm
Location: Cambridge

Re: compute module 1.1 boot

Tue Sep 05, 2017 8:59 pm

The fragments you posted look plausible, but it would help to see (ideally as a download link) the entire dt-blob.dts and the compiled dt-blob.bin.

Note that none of this GPIO configuration has changed between Wheezy and Stretch - the file you used before should still work now.

bptech
Posts: 10
Joined: Mon Aug 28, 2017 2:54 pm

Re: compute module 1.1 boot

Tue Sep 05, 2017 9:29 pm

Here is a link to the dts and dt-blob.bin. https://1drv.ms/f/s!AuB6n66r0e7uibMs6pUPTPgrGehgRg

bptech
Posts: 10
Joined: Mon Aug 28, 2017 2:54 pm

Re: compute module 1.1 boot

Tue Sep 05, 2017 10:08 pm

I downloaded the wiringPi package and did a gpio allreadall. Pin 44 should be a gp_clk function but it still shows as an input. It should be ALT0 if it is to be GPCLK1 as specified in the dt-blob.bin. So it doesn't look like dt-blob.bin is working.

gsh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 1186
Joined: Sat Sep 10, 2011 11:43 am

Re: compute module 1.1 boot

Wed Sep 06, 2017 1:37 pm

After booting can you do:

Code: Select all

sudo vcdbg log msg 2>&1 | grep blob
and

Code: Select all

sudo vcdbg log msg 2>&1 | grep gpioman
What do these return?

Why aren't you using raspi-gpio get? This is the official method for getting information about the pins

Gordon
--
Gordon Hollingworth PhD
Raspberry Pi - Director of Software Engineering

bptech
Posts: 10
Joined: Mon Aug 28, 2017 2:54 pm

Re: compute module 1.1 boot

Wed Sep 06, 2017 2:35 pm

Gordon, raspi-gpio get just comes back with command not found. Guess it is not in the minimal Stretch distro that will fit in a 4G CM1.

Actually I found that the /boot/dt-blob.bin file was not present in the last version I was trying to test. I put it in and now the hardware works.

So it is possible to run Stretch on my hardware with the new CM1 and the updated dt-blob.bin. Thanks for your help on debugging this.

I think at this point the best procedure is to redo the development process with current versions of Apache, Python, ser2net etc. and the latest version of the Raspbian system.

bptech
Posts: 10
Joined: Mon Aug 28, 2017 2:54 pm

Re: compute module 1.1 boot

Tue Oct 10, 2017 8:56 pm

Final word on this for anyone who has a similar problem. Here is how I resolved it with my system:
1. Load the original working image for your software on a Samsung CM1.
2. Attach keyboard and screen if you can, or SSH in, or do whatever you have to do to get a console. Maybe you will have to operate it in a Compute Module IO board to get a console and screen.
3. Do whatever you have to do to get an internet connection. My system has Ethernet so I used that, if you have Compute Module IO you can use an Ethernet USB adapter. Probably on a powered hub if you also need the keyboard.
4. sudo apt-get update
5. sudo apt-get dist-update
6. Click y enter when it asks permission to update
7. There should be lots of updates
8. When it is done, sudo reboot so it starts up in the new system
9. My system went to Wheezy 4.1.9 But it did change some files in /boot/ According to earlier posters it should need 4.9 to work with the new CM1 units, but my system was good with only 4.1.9
10. Read the image using the new RPI-Boot and Win32imager.
11. Write the new image to an Elpida CM1 unit
12. It should now boot, but there may be bugs due to incompatible user software. These will have to be debugged on the new system.
13. I had to add dtoverlay=mmc to the /boot/config.txt to prevent random failures to boot

I'd consider this issue closed but I'm not the original poster. They have not contributed since the first post, so I hope that means they got it figured out on their own.

Return to “Compute Module”

Who is online

Users browsing this forum: No registered users and 2 guests