Tiny Core Linux
Tiny Core Base => Raspberry Pi => piCore Test Releases => Topic started by: bmarkus on September 20, 2013, 01:09:29 PM
-
I'm pleased to announce piCore 5.0.alpha3 for the Raspberry Pi.
5.0.alpha3 changelog:
- kernel updated to 3.11.1
- udev/udevadm updated
- fixed USB hotplug issues
- zram/zcache enabled
5.0.alpha2 changelog:
- busybox, zlib, e2fsprogs, util-linux, bcrypt, zsync rebuilt with GCC 4.8.1
- libgcc_s.so.1 and libstdc++.so updated to GCC 4.8.1 libs
- removed visudo which was an x86 binary
5.0.alpha1 changelog:
- common TC 5 script base
- eglibc 2.18
- kernel 3.10.10
- busybox 1.21.1
- zlib 1.2.8
- e2fsprogs 1.42.8
- util-linux 2.23.2
- added bcrypt to base
- dropped scm type extension support
- cleanup, unneded files removed
- file reorganization
- updated Broadcom firmware
Download link: piCore-5.0.alpha3.img.gz (http://tinycorelinux.net/5.x/armv6/piCore-5.0.alpha3.img.gz) md5 (http://tinycorelinux.net/5.x/armv6/piCore-5.0.alpha3.img.gz.md5.txt)
-
In this release zram/zcache is enabled as a built-in functionality, so you can use zswap. To enable, delete the nozswap boot option in /mnt/mmcblk0p1/cmdline.txt file. During next boot a 105M compressed swap will be enabled automatically on Model-B with 512M RAM.
To see open a terminal and type
cat /proc/swaps
About zswap:
Zswap is a compressed swap cache, able to evict pages from the compressed cache, on an LRU basis, to the backing swap device when the compressed pool reaches it size limit or the pool is unable to obtain additional pages from the buddy allocator. Its approach trades CPU cycles for reduced swap I/O. This trade-off can result in a significant performance improvement as reads to and writes from to the compressed cache are almost always faster that reading from a swap device which incurs the latency of an asynchronous block I/O read.
-
Hi bmarkus
Just tried to build my piCorePlayer on your piCore 5.0 alpha 3.
Overall it is working fine.
1. The USB mounting stuff of an extra USB stick is done automatically now - so that problem is solved.
2 /dev/mmcblk0p1 is still not mounted automatically - so I have to perform a "sudo mount /dev/mmcblk0p1" before I can manipulate the files here. Is that the way you want it to be - or? Anyway it is different from previous versions where it was mounted automatically.
So thank you very much.
Steen
-
Hi bmarkus
I was wondering: you write that you now are using GCC 4.8.1 - does it mean that I have to change anything on my end if I want to compile a single ALSA module which I will change in your ALSA package?
I mean should I update my cross-compiler or??
Steen
-
Hi bmarkus
I was wondering: you write that you now are using GCC 4.8.1 - does it mean that I have to change anything on my end if I want to compile a single ALSA module which I will change in your ALSA package?
I mean should I update my cross-compiler or??
Steen
Keep as it is, no need to change. Kernel was crosscompiled with GCC 4.7.2, applications created with GCC 4.6.3 in piCore 4.7 with EGLIBC 2.13 are running fine with current EGLIBC 2.18, etc...
-
mmcblk0p1 is not used (no /tce nor /cde on) therefore not mounted. If you have been using piCore-X previously it was mounted due to the CDE directory.
-
hi bmarkus
I'm having trouble with a script I use for enabling HDMI output in piCorePlayer.
It is like this:
sudo echo hdmi_drive=2 >> /mnt/mmcblk0p1/config.txt
So it adds hdmi_drive=2 to the config.txt file and this is working both in version 5.0 alpha3 and version 4.7.7
However, it won't survive a reboot in version 5, whereas it is present in config.txt after a reboot in version 4.7.7.
Steen
-
piCore 5.0 doesn't use mmcblk0p1 at all. Do you mount partition before doing anything with it?
-
bmarkus,
First of all, I'm a newbie. This is my first time on this forum.
Are you saying that you derived piCore 5.0 from Tiny Core Linux or from some other distro? I ask because I'm attempting to rebuild Tiny Core Linux with serial debug support in the kernel.
Thanks,
ParadigmInversion
-
piCore 5.0 is the official Raspberry Pi port of TC 5.0
-
piCore 5.0 doesn't use mmcblk0p1 at all. Do you mount partition before doing anything with it?
Yes I do mount the partition, and I can see the files and cat /mnt/mmcblk0p1/config.txt will output the content of the config.txt file, so it is available.
The problem is that any change I do to the file is not maintained after a reboot. Whereas in 4.7.7 the changes was still there after a reboot.
Steen
-
How are you changing the file?
-
Like this
sudo echo hdmi_drive=2 >> /mnt/mmcblk0p1/config.txt
Steen
-
Like this
sudo echo hdmi_drive=2 >> /mnt/mmcblk0p1/config.txt
Steen
Do not overwrite system configuration file, just change the relevant parameter. First try it manually with an editor to see it is effective. For scripting use sed for example.
-
Hi bmarkus
It doesn't matter how I change the /mnt/mmcblk0p1/config.txt file
I have used :
1. sudo echo hdmi_drive=2 >> /mnt/mmcblk0p1/config.txt which by the way don't overwrite the file but just add a new line containing hdmi_drive=2 to the end of the file.
2. sudo vi /mnt/mmcblk0p1/config.txt - and change a line and then saved it. And I verified by doing a cat /mnt/mmcblk0p1/config.txt that the file was changed.
However, after a reboot the changes are lost. In version 4.7.7. I did not have this problem, as any change was still present after a reboot.
Steen
-
It works here. What are you doing after modifying the file? Try:
sudo echo hdmi_drive=2 >> /mnt/mmcblk0p1/config.txt
sudo sync
before doing anything else to force writing back cache to physical media.
There is a
#hdmi_drive=2
line in the original config file so would be better to remove trailing # than adding it to the end.
-
Nope any change I make is still not present after a reboot?
-
Nope any change I make is still not present after a reboot?
Can't reproduce.
-
Hi bmarkus.
Just tested an idea.
Doing all this via ssh using dropbear results in my previous findings, that changes does not survive a reboot.
However, working directly at the rpi with a keyboard, then the changes do survive a reboot.
So somehow there is a problem using ssh and dropbear.
I don't know if it has any importance but in order to use dropbear, I had to make a password for user tc. But it is not different from what I did in version 4.7.7 and here everything is well also via ssh and dropbear.
Steen
-
Have no idea how it can be related to dropbear. My test was done also via SSH but using openssh.
-
Hi bmarkus
I started from scratch again.
From a clean picore5 I installed Dropbear.
Then made a passwd for tc:
sudo passwd tcThen manually started dropbear
sudo /usr/local/etc/init.d/dropbear start
Then logged in via SSH and:
mount /dev/mmcblk0p1
sudo echo hdmi_drive=2 >> /mnt/mmcblk0p1/config.txt
Then rebooted - I hurrah the change survived a reboot.
********************************************
Then I would like microcore to remember its passwd and to start Dropbear automatically, therefore I made the following changes:
The content of /opt/.filetool.lst:
opt
home
etc/passwd
etc/shadow
usr/local/etc/dropbear/dropbear_dss_host_key
usr/local/etc/dropbear/dropbear_rsa_host_key
And the content of /opt/bootlocal.sh
#!/bin/sh
# put other system startup commands here
usr/local/etc/init.d/dropbear start
Now Dropbear starts automatically and I can log in using user:tc and password:(the one I just made) --- but any changes I make to the /mnt/mmcblk0p1/config.txt file does not survive a reboot
**********************************************
If I instead changes the content of /opt/.filetool.lst to (removes etc/shadow) :
opt
home
etc/passwd
usr/local/etc/dropbear/dropbear_dss_host_key
usr/local/etc/dropbear/dropbear_rsa_host_key
Then Dropbear still starts but microcore does not remember the passwd for tc, so I cant log in via SSH until I via keyboard connected to rpi make a password again like
sudo passwd tc
Then I momentarily can connect from another computer via SSH, and any change I make to the /mnt/mmcblk0p1/config.txt file can survive a reboot.
So I think somehow the user management/password is involved in the problem or the etc/shadow backup in the .filetool.lst?
Steen
-
Hi bmarkus
What do you think about this problem?
Do you think that it could be something about the password or user management in version5 compared with version 4.7.7 ?
Steen
-
No idea. Sounds local probéem, not related to piCore 5.0alphax
Can't reproduce.
-
No idea. Sounds local probéem, not related to piCore 5.0alphax
Can't reproduce.
I'm really sorry that you can't reproduce using dropbear.
Can you spot if I have done anything wrong in my post above?
I will give it one more try, otherwise I will stick to version 4.7.7 which is working fine.
Steen
-
Can you make a copy of your SD card with DD and send it?
-
Hi bmarkus
Here is a link to the image. : http://rapidshare.com/share/13300978A521499EC521F8221763E0B5
I have once again started from scratch and only installed dropbear, made a password for tc and change .filletool.lst and opt/bootlocal.sh
Dropbear is starting automatically and you login with user=tc password=nosoup4u
Once again you can't save changes to the config.txt file via SSH but it saves fine when directly connected.
You will have to mount the mmcblk0p1 first:
mount /mnt/mmcblk0p1
Hope you find the problem.
Steen
-
Hi Steen
will take a look during the weekend.
Bela
-
Steen
tested with your image. Procedure works correctly as expected. Logging via SSH I can add a text line to config.txt as you described. After rebooting the previously appended line is there and config.txt file time is correctly indicates time of modification. It works, can't reproduce your situation.
Regards... Bela
-
Hi bmarkus
Thank you very much for looking into this.
I really had tried to understand this problem, but as you were unable to confirm even with my own image - then the problem must be at my end. That made me think it all over again, and the only difference I could see was that we used different SD-cards.
Therefore, I purchased a new card, and voila now it is working. So my old card seem to be responsible for my issue - and I will try to see if I can figure out how?
Onece again thank you for your tremendous support. Everything is fine now.
Steen
-
Steen
glad to hear your problem solved. Still I do not understand how it happened.
Bela
-
hi bmarkus
I hope you are not tired of all my posts.
I have now come to the ralink wifi issue.
Just as in the 4.7.7 piCore I need to do this in version 5:
sudo ifconfig wlan0 down
and
sudo ifconfig wlan0 up
Otherwise it is not working.
So it seems like the wifi is "up" before the firmware is loaded
2.
In addition I can't connect. It is able to scan my network, but I always get the following result with the ralink wifi adaptor in version 5:
This is from piCore version 5
Select Wifi Network
ESSID Enc Qual Channel Type
1. Steens 2.4GHz on 49 7 WPA
2. Djurs5 on 17 3 WPA
Enter selection ( 1 - 2 ) or (q)uit: 1
Enter password for Steens 2.4GHz (8 to 63 characters): "MY Secret code"
Sending credentials to requested access point Steens 2.4GHz...................
udhcpc (v1.21.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
Failed to connect.
This is from version 4.7.7
Select Wifi Network
ESSID Enc Qual Channel Type
1. on 41 1 WPA
2. Steens 2.4GHz on 29 7 WPA
Enter selection ( 1 - 2 ) or (q)uit: 2
Enter password for Steens 2.4GHz (8 to 63 characters): My secret code
Sending credentials to requested access point Steens 2.4GHz..
udhcpc (v1.20.1) started
Sending discover...
Sending discover...
Sending select for 192.168.1.12...
Lease of 192.168.1.12 obtained, lease time 604800
deleting routers
adding dns 193.162.153.164
adding dns 194.239.134.83
tc@box:~$
Steen
-
Steen,
not tired, at least not because of you. I'm happy if others are testing and using it. I see I must buy a WiFi adapter :)
Can you disable WPA and run AP open to see is it a wpasupplicant issue or not?
Bela
-
Steen
these WIFI adapters offered here by the official RPI distributor:
http://malnapc.hu/yis/periferiak/usb-s-wifi-eszkoz
Unfortunately chipset is not mentioned. Is your one of them?
-
Just as in the 4.7.7 piCore I need to do this in version 5:
sudo ifconfig wlan0 down
and
sudo ifconfig wlan0 up
Otherwise it is not working.
So it seems like the wifi is "up" before the firmware is loaded
Are you referring to loading extensions "onboot"?
-
wpa_supplicant updated to 2.0
-
Hi bmarkus
Just update wpa-supplicant to version 2 - however it did not improve.
However, if I removed protection from my router it can connect fine.
This is piCore v 5 alpha 3 with updated wpa-suppicant, but without protection on the router:
Select Wifi Network
ESSID Enc Qual Channel Type
1. Djurs5 on 25 3
2. Steens 2.4GHz off 21 9
Enter selection ( 1 - 2 ) or (q)uit: 2
udhcpc (v1.21.1) started
Sending discover...
Sending select for 192.168.1.12...
Lease of 192.168.1.12 obtained, lease time 604800
deleting routers
adding dns 193.162.153.164
adding dns 194.239.134.83
So what to try next?
-
Steen
these WIFI adapters offered here by the official RPI distributor:
http://malnapc.hu/yis/periferiak/usb-s-wifi-eszkoz
Unfortunately chipset is not mentioned. Is your one of them?
Sorry, no they look different from mine.
I bought this one: http://www.ebay.com/itm/271180617205?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 (http://www.ebay.com/itm/271180617205?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649)
Steen
-
As wpa_supplican 1.0 was working in 4.7.7 didn't expect 2.0 update as a fix for 5.0, just a regular update.
I must find a WiFi dongle to test :(
-
Steen
these WIFI adapters offered here by the official RPI distributor:
http://malnapc.hu/yis/periferiak/usb-s-wifi-eszkoz
Unfortunately chipset is not mentioned. Is your one of them?
Sorry, no they look different from mine.
I bought this one: http://www.ebay.com/itm/271180617205?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 (http://www.ebay.com/itm/271180617205?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649)
Steen
Good price, big antenna. Looks impressive :)
-
Steen
these WIFI adapters offered here by the official RPI distributor:
http://malnapc.hu/yis/periferiak/usb-s-wifi-eszkoz
Unfortunately chipset is not mentioned. Is your one of them?
Sorry, no they look different from mine.
I bought this one: http://www.ebay.com/itm/271180617205?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649 (http://www.ebay.com/itm/271180617205?ssPageName=STRK:MEWNX:IT&_trksid=p3984.m1497.l2649)
Steen
Good price, big antenna. Looks impressive :)
The first one you posted (this one (http://malnapc.hu/yis/raspberry-wi-pi-usb-s-wlan-modul-802-11n)) looks a lot like mine (this one (http://nl.farnell.com/element14/wipi/dongle-wifi-usb-for-raspberry-pi/dp/2133900#)).
It's got the RT5370 chipset, and I have it working with piCore 5.0.alpha2.
When I find some time, I will re-install my Raspberry with alpha3 and test it again.
-
Hi gerrelt.
What kind of protection do you use in your network? I couldn't get it to work using WPA-personnel, whereas it connected fine without any protection of the router.
Probably I should test wap as well.
Steen
-
I am using WPA, with my own wpa_supplicant.conf file.
The file looks like this:
# reading passphrase from stdin
network={
proto=RSN
scan_ssid=1
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP
ssid="MyWifiName"
psk="a_very_secret_password"
}
Then I use this script to connect:
# ------------------begin script-----------------
echo ----------------------------------- >> /tmp/_wifi.log
date >> /tmp/_wifi.log
echo ----------------------------------- >> /tmp/_wifi.log
ifconfig wlan0 up >> /tmp/_wifi.log
for i in $(seq 1 5)
do
sleep 1
echo try $i >> /tmp/_wifi.log
iwlist wlan0 scanning >/dev/null
if [[ $? -eq 0 ]]
then
echo succeeded >> /tmp/_wifi.log
break
fi
echo unsuccesfull >> /tmp/_wifi.log
done
wpa_supplicant -B -Dwext -i wlan0 -c /opt/wpa_supplicant.conf >> /tmp/_wifi.log
/sbin/udhcpc -b -i wlan0 -x hostname:cherry >> /tmp/_wifi.log
# ------------------eind script-----------------
I wanted to use the wifi.tcz script, but that does not use the -b option in the udhcpc command. The -b option waits until it obtains a lease, and does not quit. My modem is slow or something, because without the -b it doesn't always work.
-
Hi!
No X-version of this new build?
Kind greetings,
meo
-
Hi!
No X-version of this new build?
Kind greetings,
meo
tce-load -iw TC
-
Hi Bmarkus,
This evening I installed Alpha 3, and everything is working great!
Wifi is working with the ralink RT5370 WiFi adapter.
Beside the normal WiFi installation/settings I normally do, I had to install the extra ralink drivers like this:
tce-load -wi firmware-ralinkwifi.tcz
And then, after a reboot, it worked!
The modprobes that were needed in alpha 2 are not needed anymore.
Thanks! :)
Greetings,
Gerrelt.
-
Thanks for the feedback. Regarding WiFi, are you using WPA?
-
Thanks for the feedback. Regarding WiFi, are you using WPA?
Yep. See: reply #41 (http://forum.tinycorelinux.net/index.php/topic,15934.msg94359.html#msg94359).
-
hi bmarkus
Just tried with my other wifi adaptor a Comfast WU710N: chipset RTL8188CUS.
This one has been working in all your piCore versions up until version 5. I usually only need to install wifi.tcz via tce package manager.
However in version 5 (after installing wifi.tzc (and not the ralink firmware)):
When writing:
iwconfigI get this error:
iwconfig: error while loading shared libraries: libiw.so29: cannot open shared object file: No such file or directory
I don't know if this is related with the ralink wifi problem?
Steen
-
Install libiw.tcz
-
Hi
Thanks - Did you fix something already?
I just started from scratch once again with piCore 5, installed wifi.tcz (and now I noticed that it also downloaded libiw - I don't remember if it did so before)?
But anyhow, now my Comfast adaptor is working (sort of) it can scan and detect my router but I get exactly the same result as with the ralink adaptor:
ESSID Enc Qual Channel Type
1. Steens 2.4GHz on 77 7 WPA
2. Djurs5 on 65 3 WPA
Enter selection ( 1 - 2 ) or (q)uit: 1
Enter password for Steens 2.4GHz (8 to 63 characters): ********
Sending credentials to requested access point Steens 2.4GHz...................
udhcpc (v1.21.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
Failed to connect.
So it has the same problem. Somehow Gerrelt seems to be able to work around the problem with his manual set-up script.
Steen
-
Try this:
http://forum.tinycorelinux.net/index.php/topic,15934.msg94359.html#msg94359
-
So it has the same problem. Somehow Gerrelt seems to be able to work around the problem with his manual set-up script.
It could be because I use -b with the udhcpc command instead of -n, which the wifi.tcz script uses.
From the udhcpc man page:
-n Exit with failure if lease is not immediately obtained
-b Background if lease is not immediately obtained
So, -n exits with a failure if, after certain time, the lease is not obtained.
With -b the process goes to the background and keeps waiting until a lease is obtained.
Our Raspberries aren't the fastest machines, so -b might be more suitable then -n.
Also if your network or router isn't very fast, -b might be more suitable too.
This is the result of using -n :
udhcpc (v1.21.1) started
Sending discover...
Sending discover...
Sending discover...
No lease, failing
Failed to connect.
Have you tried my wpa_supplicant.conf and wifi script?