Tiny Core Linux
Tiny Core Base => Raspberry Pi => Topic started by: bmarkus on December 13, 2019, 02:08:02 AM
-
First beta of piCore 11 released. Changes:
- glibc updated to 2.30
- gcc updated to 9.2
- uPython updated
-
Nice progress Bela.
Any plans to change change the base from here.
- OpenSSL 1.1.1
- plus what you have above.
If you would like, I can build the wifi stuff.
-
There appears to be a problem with /mnt/mmcblk0p1/11.0beta1av7.gz?
I cannot boot this on an RPi3B.
I can extract 11.0beta1a.gz and 11.0beta1av7l.gz, without problems, but with 11.0beta1av7.gz: $ zcat /tmp/11.0beta1av7.gz | sudo cpio -i -H newc -d
cpio: unsupported cpio format, use newc or crc
-
Interesting, I'm developing on 3+. Will check.
-
Just to add to Juanito's post, and FWIW, I compiled gnu cpio-2.13 to see if it can extract the pi3 image.
tc@box:/tmp/remaster$ zcat ../11.0beta1av7.gz | sudo /tmp/cpio/usr/local/bin/cpio -i -H newc -d
/tmp/cpio/usr/local/bin/cpio: warning: skipped 8534 bytes of junk
zcat: unexpected end of file
/tmp/cpio/usr/local/bin/cpio: premature end of file
-
...
If you would like, I can build the wifi stuff.
Done that and have wifi on a pi zero W running 11.0beta1 working.
I've kept everything together (sources, .build and the resulting tczs), so could submit a load of extensions. But since I haven't had feedback on the first couple I sent through, I'm a bit hesitant to send more. (Are my tcz submits not going down some /dev/null somewhere?)
Let me know if I can help.
-
Hi Twist
Assuming armv6, if they are listed here:
http://tinycorelinux.net/11.x/armv6/tcz/
then they are in the repository.
-
Rich, yes that's what I would expect to happen at some point (not yet listed atm).
For me the proces after submitting to picoresubmit _at_ gmail.com is a black hole. All I'm saying is: if it helps, I can sent through a couple more to get the 11x repo built up with some of the basic extensions like wifi and it's deps. Just not sure if my contributions meet the standard, and are received in good order.
-
Hi Twist
I'm afraid that's all I know about this. Maybe one of the administrators can provide more insight into this issue.
-
Typically the extension maintainer does the updates, I maintain a lot of the rpi specific packages (wifi, rpi firmware, rpi-vc) I do them for pCP anyway. But even I have to send everything through Bela to get posted. He is just very busy. Wish there was an automated way for distribution.
-
Hi Twist
Paul_123 brings up a point I forgot to mention. When updating an extension, protocol is to contact the person listed in the
Extension_by field in the .info file to see if they are OK with you updating it.
-
Ah, wasn’t aware of that ‘protocol’. I happily listed myself in the submitted .info files ;)
I understand there’s a need to keep in control somehow. And it’s a pity if an individual (bmarkus) is burdened with that task. But I have to agree with Paul_123 that it would be great if there was more direct way to publish extensions. I’m not all that familiar with ‘git’, but surely a similar form of version control system with ‘public’ contributions could be a possibility? ... anyway i’m drifting way off topic here, sorry.
So Paul_123, would you be interested in my extensions to get wireless up op 11.xbeta1?
libnl, wireless_tools, libiw, iw, wpa_supplicant
I can imagine you’d rather stay in control and do them yourself, given pCP.
-
The protocol is there mainly for consistency in packages. Bela and I were talking last year about a package management system......but that takes alot of time bandwidth to get working that we really didn't have.
As for wifi, crda integration is just as important to the rpi chipsets. It will need rebuilt against the latest openssl. I have build scripts for everything. I was waiting for Bela to comment on the base for piCore11 There are core packages that if changed causes rebuilds of everything. And then there are Silly things like the location of ssl certs too.
We'll see what happens.
-
Completely understand your point on time bandwidth.
I have no clue how big the install base is for picore (or tinycore). I guess pCP -being so easy to install- brings a lot of users (but not a lot will have ever heard of an tcz extension).
On wifi: I have(/had) no clue what crda is, so that's probably an indication I shouldn't be trusted to built the 'official' 11x extensions for wifi ;-) Happy I got my pi zero w up though.
Openssl in 11.0beta1a is already on 1.1.1d by the way.
-
11.0beta1a updated on the server. The armv7 initrd file was corrupted, sorry for that. Now it is expected to work, please try. If not, let me know. No other changes made.
-
piCore 11.0beta1a armv7 now boots OK on an RPi3 B+ :)
-
piCore 11.0beta1a armv7 now boots OK on an RPi3 B+ :)
Thanks!
-
Great work!
But can't get working eethernet on RPi 3B+
-
It works for me - do you see any errors in dmesg?
Are you using ipv4 or ipv6?
-
dmesg | grep error gives none
dmesg | grep eth gives none
orange light on ethernet port is blinking
router see nothing
ifconfig gives only lo0 interface
using ipv4
-
There should be an amber and a green light - is the cable bad?
-
No, cable is good. All perfect on tinycore 10beta. But on 11beta there is no ethernet :'(
-
11.0beta1a updated on the server. The armv7 initrd file was corrupted, sorry for that. Now it is expected to work, please try. If not, let me know. No other changes made.
I too can confirm the v7.gz boots okay on 3B+.
However now the 11.0beta1a.gz seems to have a problem when booting on Zero W:
On serial console I get:
[ 0.947671] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
[ 0.956222] CPU: 0 PID: 1 Comm: swapper Not tainted 4.19.81-piCore #1
[ 0.962848] Hardware name: BCM2835
[ 0.966393] [<c0017f44>] (unwind_backtrace) from [<c0014b98>] (show_stack+0x20/0x24)
[ 0.974380] [<c0014b98>] (show_stack) from [<c06b80e8>] (dump_stack+0x20/0x28)
[ 0.981831] [<c06b80e8>] (dump_stack) from [<c0024648>] (panic+0xdc/0x258)
[ 0.988924] [<c0024648>] (panic) from [<c0971760>] (mount_block_root+0x25c/0x2b4)
[ 0.996633] [<c0971760>] (mount_block_root) from [<c0971a18>] (mount_root+0x108/0x148)
[ 1.004777] [<c0971a18>] (mount_root) from [<c0971bc8>] (prepare_namespace+0x170/0x1d4)
[ 1.013008] [<c0971bc8>] (prepare_namespace) from [<c09711c8>] (kernel_init_freeable+0x20c/0x25c)
[ 1.022144] [<c09711c8>] (kernel_init_freeable) from [<c06ccbe4>] (kernel_init+0x18/0x100)
[ 1.030649] [<c06ccbe4>] (kernel_init) from [<c00090ac>] (ret_from_fork+0x14/0x28)
[ 1.038426] Exception stack(0xdacf1fb0 to 0xdacf1ff8)
[ 1.045010] 1fa0: 00000000 00000000 00000000 00000000
[ 1.056075] 1fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 1.067142] 1fe0: 00000000 00000000 00000000 00000000 00000013 00000000
[ 1.075296] ---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) ]---
[ 1.433391] random: fast init done
Mounted the boot partition on another pi, then trying to copy 11.0beta1a.gz I get:
tc@box:~$ cp /mnt/sda1/11.0beta1a.gz /tmp/.
cp: read error: Input/output error
And it fails to copy the complete file:
tc@box:/tmp/remaster$ la /mnt/sda1/11.0beta1a.gz
-rwxrwxrwx 1 tc staff [b]4973924[/b] Dec 11 2019 /mnt/sda1/11.0beta1a.gz
tc@box:/tmp/remaster$ la ../11.0beta1a.gz
-rwxr-xr-x 1 tc staff [b]4931584[/b] Jan 1 00:06 ../11.0beta1a.gz
This is happens with a freshly written image to a formatted SD card. Tried with two different SD cards (brand and size) that are known to be good.
On OSX, when I try to copy the 11.0beta1a.gz file it errors: "The finder can't complete the operation because some data in "11.0beta1a.gz" can't be read or written (error code -36)"
Writing the previous 11.0beta1a image (with the corrupted v7.gz) to the same SD card I can boot the Zero W again.
-
Ethernet not working on latest 11beta1a :-\
But I've tried 11alpha1a and ethernet woks perfect!
On RPi 3B+
Also check both on RPi4B - both ethernet works fine!
11beta1a downloaded from here http://tinycorelinux.net/11.x/armv7/test_releases/RPi/
-
requested "dmesg | grep net" and got this on RPi 3B+ with 11beta1a:
lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized): No External EEPROM.Setting MAC Speed
lan78xx 1-1.1.1:1.0 (unnamed net_device) (uninitialized): int urb period 64