Pi 3B+

[gavinmc42]

I think I totally hijacked this post?
Anyway was reading Sakaki's 32bit on 64bit wiki
https://github.com/sakaki-/gentoo-on-rpi3-64bit/wiki/Running-32-bit-Raspbian-Packages-on-your-64-bit-Gentoo-System
She is using Raspbian Lite, which I find bloated anyway

Not sure but is it possible to run 32bit Picore on Gentoo64?
Don't remember using chroot before or having a 64bit Pi OS to try this on .

[gavinmc42]

Bela,
I had trouble with the 10Beta3a, you need to put a test link in the child board section at the top for version 10.
I had to dig deep for them
Beta3a get to these lines
.....
Starting udev daemon for hotplug support...  Done.
modprobe: can't change directory to '4.14.33-piCore': no such file or directory
modprobe: can't change directory to '4.14.33-piCore': no such file or directory

But 10Beta2 works on cards, 128MB to 32GB, SD and uSD.
I am using it to test my old cards, have collected 40+ cards now,
Not including the installed running ones.
Got 10+ dud cards, not surprising as some go back 6 years

Etcher writes the piCore zip files quickly, other OS's take forever to write and test.
Only tested on an old PiB, A+, 3B and new 3B+ .
Still need to test on old A, B+, Zero's and old Pi2.

Might need more testing on the 3B+, I saw one lockup out of 3 boots.
What Sdram speed are you running?
There also seems to be some recent lan chip changes.

I will do more testing, now that I have 20 cards working
 

[bmarkus]

Hi Gavin,

thanks for testing. I see these random boot issues also, need some more investigation.

Regarding modprobe, on which board you get it, arm6 or arm7?


Regards,

Béla

[gavinmc42]

Hi Bela,

Did a lot more testing today, using a different version of Etcher on a Windows box.
Just to check if Etcher was the problem or I had corrupted images.

It looks like 10Beta3a works on newer Pi's like the 3B/3B+, these use uSD cards.
Same uSD in an adapter for A or B halts at the modprobe lines.
10Beta3a on SD cards also halts there, this seems to be a hotplug daemon?

uSD on old Pi2 goes into kernel panic, only tested this with two uSD's.

10Beta2a works on all Pi's/uSD's/SD's.

Another bug, SSHing into Pi's, MC has mouse issues, look like same issue on Beta2a and Beta3a.
Superputty to remote Pi and running MC, left click mouse button generates codes not actions.
MC graphics have black/blank areas too.

So yes modprobe has issues with BCM2835 and perhaps BCM2836.
Is the SD MMC running at different clocks/timeouts?

[gavinmc42]

Some more tests and consistency in results
5 x Zero's, 3 x A+, 2 x B+  10Beta3a - same lock at modprobe, Beta2a works fine.

Old 3B and new 3B+ Beta2a - kernel panic, Beta3a works fine.

Works fine in both cases means they go past the SHA256 key pair stuff to cmdline when a key is hit

Conclusion
Use Beta2a on BCM2835
Use Beta3a on BCM2837 and perhaps 2836?

Yet to test Zero W, but I suspect same result for other BCM2835's?

Checked and confirmed old A's, B's worked with SD and uSD card Beta2a.
Not SD or uSD card dependent.
Did not realize I have so many Pi's or cards till they were all in one spot.

[Paul_123]

uSD on old Pi2 goes into kernel panic, only tested this with two uSD's.

Take a closer look at the kernel panics.   Add   pause_on_oops=x  to the kernel command line (x is number of seconds to pause).    It is likely a known issue with 4.14.y kernels and initramfs's.   It is a race condition in the startup of the USB FIQ handler, rpi has not been able to resolve yet.  Reference: https://github.com/raspberrypi/linux/issues/2450

- Only appears to be affected by initramfs systems.
- Running headless appears to not lockup.
- Disabling the FIQ handler works too, but brings back the horrible USB issues.

I did a tremendous amount of testing while working on pCP, every new kernel changes the timing, which means some kernel versions are more susceptible to the problem.

[bmarkus]

Still the same issue with 4.16.y

https://www.raspberrypi.org/forums/viewtopic.php?t=206400

[Paul_123]

We are at 4.14.26 on pCP, 4.14.22 was horrible, but .24 and .26 seem to boot >98% of the time.   I've not built a higher kernel yet.   One other thing I noticed is that a linaro_gcc 7.3 tool chain made a slightly less stable kernel.  So I'm using the default Raspberry pi tool chains for an intel based build system.

[TimJ]

I need to purchase some more WiFi enabled Pis, but the RPI3B is no longer available, only the RPi3B+, hence my interest in Picore 10.

I have downloaded Beta3a and tried it on a RPi3 and found that the kernel panics about 1 in 7 boots, (or reboot). I will be using these devices headless so I have tried in that mode and so far appears stable. ( about 20 power up boots and 20 reboots).

Or would it be a workaround to replace the kernel from PiCore 9  (4.9.22) on PiCore 10? or does the RPi3B+ require a newer kernel? I might try and do it.

There is a minor issue in that using showapps breaks the mounting of extensions.

Feedback (most recent call last)
File "/usr/bin/bootload", line 106 in <module>
File "/usr/bin/bootload", line 97 in <module>
TypeError: extra keyword arguments given

And no extensions get mounted.

Thanks for all your efforts and great work. It is appreciated.

Tim.

[Paul_123]

The pi3B+ needs the newer kernel/firmware.  There are wifi and ethernet patches for the pi3B+ that are not in the 4.9.y tree as well.  RPI has officially abandoned the 4.9.y tree.

 In all of my testing (I've been using 4.14 kernels since December of last year),   I've not seen boot crashes when running headless.

[TimJ]

Bela, you are a star.

I see that beta4a using 4.14.41 is on the website and I have run it all day yesterday, rebooting countless times with an HDMI monitor attached. No problems at all.

I have added modules for 1wire temp sensor and RTC and edited the device tree to add an EEPROM and all is still fine.

Many Thanks

Tim.

[bmarkus]

Thanks for the feedback. I tested it intensively in the last days. Yes, boot is stable now adding

Code: [Select]

dwc_otg.fiq_enable=0 and dwc_otg.fiq_fsm_enable=0
to command line. Another issue I found is ZSWAP. When it is enabled, there are random 'Error writing swap' messages and few times system is freezing. Adding NOZSWAP to cmdline it works fine, and compiling large applications like GCC has no any memory or media read/write issues. I will upload a new beta with NOZSWAP as default.

All together I'm not happy with 4.14 at all. Except RPi3+ 4.9.y works better.

[Paul_123]

If you are using any USB devices, disabling FIQ is going to create more problems.  (Remember the early rpi days)  If I turn off FIQ, my use keyboards are useless, and network throughput plummet.   

What compression algorithm are you using for zswap.  I've not seen swap errors before, I'm using LZ4

[bmarkus]

If you are using any USB devices, disabling FIQ is going to create more problems.  (Remember the early rpi days)  If I turn off FIQ, my use keyboards are useless, and network throughput plummet.   

It is up to users whether to enable or disable it in command line. I know all the drawback disabling it, however at least it provides reliable booting.

[bmarkus]

What compression algorithm are you using for zswap.  I've not seen swap errors before, I'm using LZ4

lzo, can be reproduced with zbud and z3fold allocators.