piCore-7.0alpha8

[andyj]

OK. Now that you put my nose in it I see it. Still not 100% clear on what's soldered on the the board and which are the add-ons but I might yet figure it out.

On a slightly different piCore alpha topic, it occured to me that the bulk of the boot process time is spent loading extensions. It also occured to me that there are "groups" of extensions that don't depend on each other, like X doesn't need networking (if you're not listening for remote connections) and sound to start. Anymore than networking needs X and sound or sound needs X or networking. Given that the PI2 is a quad-core, it occured to me that maybe some of these could be loaded in parallel. I realize this would be a big change from the current serial process, but it could be a big help in the long run. I can say from experience that make -j4 when compiling the kernel helps a lot on the pi2. The boot process would need to be able to call tce-load with different lists and start the networking tasks while the X libraries are still loading. The trick would be knowing when the last list was done (and didn't die for some reason). For a few extensions it probably doesn't matter, but for 100+ it would be nice.

[Rich]

Hi andyj
If most of the time is spent reading the storage device, you won't see much improvement in loading extensions
since while one core is reading it blocks the others from accessing the storage device.

[andyj]

Which is faster to set up? Copy2fs clearly reads the whole file into RAM. What about mounting via loop and linking? Does that read through the whole file too or is it clever enough to just read the file system structure from the file and then create the links? How much actual RAM does a loop mounted device use? We would need some really granular timing data.

[andyj]

And back to the vim extension, how do I get it to replace the vi link in /usr/bin when it loads?

[bmarkus]

And back to the vim extension, how do I get it to replace the vi link in /usr/bin when it loads?

Put it to /usr/local

[bmarkus]

I typically do an in place upgrade, so my onboot.lst file contains references to KERNEL, rather than specific kernel versions.   Extensions with a reference to KERNEL do not load from within onboot.lst

tce-bootload just reports that it is not available.  it appears KERNEL is not expanded properly.   The odd thing is that it does properly expand references to KERNEL when in the .dep files.

Confirmed, it is a bug, thanks for reporting. Will fix in next release.

[Paul_123]

Which is faster to set up? Copy2fs clearly reads the whole file into RAM. What about mounting via loop and linking? Does that read through the whole file too or is it clever enough to just read the file system structure from the file and then create the links? How much actual RAM does a loop mounted device use? We would need some really granular timing data.

Loading extensions during the boot process is handled with a micropython script  tce-bootload.   This is already much faster than the old method of loading extensions.  Take a look at the file /var/log/tce-bootload

Creating the symbolic links still takes the bulk of the time.    If you use copy2fs, it still mounts the extensions, but it copies the files rather than making symlinks.....then it un-mounts the extension.   This would definitely take longer.

Code: [Select]

Deplist creation for 20 extensions ready: 0s
Mounting 48 extensions ready: 2s
ldconfig return value: 0
depmod return value: 0
Symlinking ready: 6s
Script finished: 6s


[bmarkus]

Upon further research it may be because that option that wasn't compiled in. Where can I find the compile options that have been used for busybox VI? It still seems like it would be easier to port the vim extension.

vim.tcz added to 7.x repo.

[curaga]

Which is faster to set up? Copy2fs clearly reads the whole file into RAM. What about mounting via loop and linking? Does that read through the whole file too or is it clever enough to just read the file system structure from the file and then create the links? How much actual RAM does a loop mounted device use? We would need some really granular timing data.

Read up on squashfs internal structure to find how the data is placed. Symlinking does not read the whole file, but just the directory info (file names, etc.). A single loop mount at our default 4kb blocksize used some tens of kb of RAM.

[Gerrelt]

The onboard audio card is now enabled by:
audio=on
in the config.txt

Hi Steen,

Yes, that worked! This is wat I did, first mount partition 1, and then open the config.txt :

Code: [Select]

sudo mount /dev/mmcblk0p1
sudo nano /mnt/mmcblk0p1/config.txt

And I then added ",audio=on" to the end of the "dtparam" line. It now looks like this:

Code: [Select]

dtparam=i2c=on,spi=on,i2s=on,audio=on
Thanks.

Greetings,
    Gerrelt.

[Paul_123]

Was playing wtih a Rpi B+, and I'm having a problem where the kernel module for the wifi card is not loading on boot.   The USB bus is registering the stick, but just not loading the driver.

If I plug in the USB stick after the pi is booted, then the kernel module loads just fine.    Also loading the driver manually in bootlocal works fine too.

[Gerrelt]

I've had a problem like this too, but not perticularly with this piCore version. In the end it appeared to be that a reboot doesn't always work with some USB wifi adapters.
The USB wifi adapter didn't really reboot properly when the Pi was rebooted.

Unplugging the power to the Pi (and with it the USB wifi adapter), and waiting until the lights (on power adapter and Pi) are really off, and then plug the power back in "solved" it.

I think the reboot via the command line happens to fast for the USB wifi adapter to react, leaving it in a corrupt state.

Unplugging it for every reboot is a bit off a nuisance though...

[Paul_123]

I've not been using wifi alot on the picore lately.   So I don't know when this started.  But was definitely not an issue with picore 6.1   I don't think there is a corruption, as there are no errors and if I load the kernel driver manually, it works just fine.   

This is acting like the USB is starting faster than we are mounting the kernel drivers in the extensions.