Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What happened to the build code #293

Closed
MrEngman opened this issue Jun 26, 2014 · 8 comments
Closed

What happened to the build code #293

MrEngman opened this issue Jun 26, 2014 · 8 comments

Comments

@MrEngman
Copy link

In the latest commit, 4f63c3b, firmware/extra/uname_string shows Linux version 3.12.23+ with build #1 PREEMPT Thu Jun 26 17:26:49 BST 2014.

Should it not be something like #692 or similar. Or has it reverted to #1 because Raspbian is now compiled with gcc 4.8 rather than gcc 4.7?

@popcornmix
Copy link
Contributor

I built this on a new machine.
I did copy over the .version from the old linux tree which seemed to work for the test build, but it got reset on the actual build. I'll see if I can find out why.

@MrEngman
Copy link
Author

OK.

And now, for the first time ever, after rpi-update my Pi refuses to boot. I have updated code using rpi-update every time it changes to verify wifi drivers I compile work or not work with the new code and this is the first time ever my Pi will not boot.

Now trying to find out why.

@popcornmix
Copy link
Contributor

I have successfully ran rpi-update and rebooted.
Are you using start_cd (gpu_mem < 32), start_x (start_x=1) or default start?

Let me know if reverting a file makes it boot. It's possible something is broken on new build machine, or you may have just got unlucky.

@Doormatty
Copy link

I just ran rpi-update and rebooted remotely. All good.

On Thu, Jun 26, 2014 at 1:37 PM, popcornmix notifications@github.com
wrote:

I have successfully ran it.
Are you using start_cd (gpu_mem < 32), start_x (start_x=1) or default
start?

Let me know if reverting a file makes it boot. It's possible something is
broken on new build machine, or you may have just got unlucky.


Reply to this email directly or view it on GitHub
#293 (comment)
.

popcornmix added a commit that referenced this issue Jun 26, 2014
See: #293

kernel: Set build number back to normal monotonic sequence
See: #293

kernel: bcm2708: Avoid hang when timer_set_next_event is called with MAX_INT
See: raspberrypi/linux#616

kernel: armctrl: Don't mask interrupts from ack
See: raspberrypi/linux@39e4e12
popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Jun 26, 2014
See: raspberrypi/firmware#293

kernel: Set build number back to normal monotonic sequence
See: raspberrypi/firmware#293

kernel: bcm2708: Avoid hang when timer_set_next_event is called with MAX_INT
See: raspberrypi/linux#616

kernel: armctrl: Don't mask interrupts from ack
See: raspberrypi/linux@39e4e12
@popcornmix
Copy link
Contributor

@MrEngman
Looks like start_cd.elf is broken. I've pushed a fix.
Set gpu_mem=64 to allow booting (or revert to older firmware) then run rpi-update.
You should then be able to set gpu_mem=16.

Build number should also be back to an expected number (#692).

@MrEngman
Copy link
Author

gpu_mem=16 Before updating it was running 3.12.22+ #691.

Copied the boot directory files from another Pi running 3.12.20+ #687 and my broken Pi is running again. So now I'm running rpi-update again. Let's see what happens in a few minutes. OK rpi-update has finished so rebooting.

And it is now working. So I guess start_cd.elf was broken then as you've updated the commit.

Phew, excellent, thanks for sorting it so quickly. Good to get back to normal. And the build looks good too, #692. well done.

@popcornmix
Copy link
Contributor

Okay to close?

@MrEngman
Copy link
Author

Certainly. Thanks for the quick update

neuschaefer pushed a commit to neuschaefer/raspi-binary-firmware that referenced this issue Feb 27, 2017
See: raspberrypi#293

kernel: Set build number back to normal monotonic sequence
See: raspberrypi#293

kernel: bcm2708: Avoid hang when timer_set_next_event is called with MAX_INT
See: raspberrypi/linux#616

kernel: armctrl: Don't mask interrupts from ack
See: raspberrypi/linux@39e4e12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants