Core v7.0beta3

[gerald_clark]

It is used when loading the entries in onboot.lst.

[andyj]

Even after the system is booted some still get copied in and some don't. Looking at tce-load it depends on $FROMWHERE. If the extension is in optional and copy2fs.flg is set in the tce dir OR the extension does not have a path and is in the pwd and copy2fs.flg is set in the pwd then it will be copied, otherwise it gets linked in (assuming no -c or copy2fs.lst). This is consistent with what I'm observing in tests. I'm assuming this is the design.

[Misalf]

If I move all the linking from the build script to the startup script, how would I know in the startup script whether or not the extension was copied in or loop mounted? Would it be as simple as looking for the loop mount point, or is there a built in way to know?

I'd claim you don't need to know. Just link or copy from  "/"  regardless of if it was copied to RAM or mounted, it's at the same location.

I always boot my USB stick using  /etc/sysconfig/tcedir/copy2fs.flg . All extensions are loaded to RAM, also afer boot and in between unmounts. Haven't seen this feature to stop working.

[Misalf]

I have just seen this feature to stop working, too.
If running  tce-load -i  from  /etc/sysconfig/tcedir/optional ,  $FROMWHERE  gets a value of "." (a dot for current directory), while the  install()  function checks for the existence of  ./copy2fs.flg  (which would translate to  /etc/sysconfig/tcedir/optional/copy2fs.flg ).

However, I don't know why but this seems to be intended.
http://forum.tinycorelinux.net/index.php/topic,13166.msg72669.html#msg72669

[andyj]

I've developed a number of extensions under this beta that I think are ready for beta testing as well. Is there extension beta testing or do I just submit them for TC 7? Specifically, I'm referring to open-vm-tools, PHP 7, Postgresql 9.5, and supporting libraries.

[Juanito]

Please go ahead and submit them for tc-7.x with a note in the info file that they are for testing.

[andyj]

In submitqc line 240 the test for version 6 needs to be updated for version 6+.

[coreplayer2]

lately while on the road I've been investigating why wifi drivers disconnect from AP's

I'm currently using tc-7b3

I'm not 100% sure where this error originates, be it the device driver or the kernel.   May not be related to the original disconnects but I've noticed driver's have difficulty in loading it's desired firmware file is not located at /lib/firmware yet to resolve the issue an alternative method is used.

notice the direct loading error and resolution if loaded from /usr/local/lib/firmware/

Code: [Select]

tc@box:~$ dmesg | grep iwl
[   10.558184] iwlwifi 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
[   10.562345] iwlwifi 0000:06:00.0: Direct firmware load for iwlwifi-5000-5.ucode failed with error -2
[   10.562346] iwlwifi 0000:06:00.0: Falling back to user helper
[   10.880948] iwlwifi 0000:06:00.0: loaded firmware version 8.83.5.1 build 33692 op_mode iwldvm
[   10.895468] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEBUG disabled
[   10.895471] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[   10.895472] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[   10.895474] iwlwifi 0000:06:00.0: Detected Intel(R) Ultimate N WiFi Link 5300 AGN, REV=0x24
[   10.895645] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   10.917819] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[   29.587946] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   29.591677] iwlwifi 0000:06:00.0: Radio type=0x0-0x2-0x0
[   29.727804] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   29.730796] iwlwifi 0000:06:00.0: Radio type=0x0-0x2-0x0
tc@box:~$
however if I re-create the extension where firmware is installed to /usr/lib/firmware, then firmware is directly loaded successfully

Code: [Select]

tc@box:~$ dmesg | grep iwl
[   10.465335] iwlwifi 0000:06:00.0: can't disable ASPM; OS doesn't have ASPM control
[   10.480928] iwlwifi 0000:06:00.0: loaded firmware version 8.83.5.1 build 33692 op_mode iwldvm
[   10.492672] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEBUG disabled
[   10.492674] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEBUGFS disabled
[   10.492675] iwlwifi 0000:06:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[   10.492677] iwlwifi 0000:06:00.0: Detected Intel(R) Ultimate N WiFi Link 5300 AGN, REV=0x24
[   10.492723] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   10.515657] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[   35.947811] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   35.951477] iwlwifi 0000:06:00.0: Radio type=0x0-0x2-0x0
[   36.084178] iwlwifi 0000:06:00.0: L1 Disabled - LTR Disabled
[   36.087153] iwlwifi 0000:06:00.0: Radio type=0x0-0x2-0x0
tc@box:~$
Is this of any concern to us? or has the effectiveness of the driver changed because of this?

[dentonlt]

Maybe this is off-topic, but it seems relevant enough.

I do a kernel rebuild to drop modules I don't need and put the ones I need into the kernel. That's not a problem.

If I build the 4.2.9 kernel on TC 6.4/x86_64, I get a 5mb bzImage.

The same build/config/scripts on TC 7.0beta3/x86_64 gives me an 8.5mb bzImage.

I wouldn't normally care ... but that's 60% change. Same build config, same scripts. Should a different gcc make that big a difference?



Sent from my HTC_0P6B6 using Tapatalk

[Juanito]

Which version of gcc?

Did you gzip/advdef the kernel modules?

[Juanito]

How about:

Code: [Select]

if [ "$(version | sed 's/\..*//')" -gt "5" ]; then?

Edit: updated extension posted.

[Juanito]

notice the direct loading error and resolution if loaded from /usr/local/lib/firmware/

I'd assumed that message occurred when the kernel driver did not contain the firmware (a la broadcom wl), but no, I don't think it's a problem.

[curaga]

@coreplayer2

Usually if the firmware is not available the first time, the driver will print a message and exit. Then if the firmware is loaded later, the driver will try to load again, and this time succeed, like in your dmesg. So in practice, the message is the only difference.

@dentonlt

Clearly a bug/suboptimal behavior somewhere, most likely in gcc. Though the official build didn't grow at all, the added 100kb or so came from new options.

If you want to, you could go trying different gcc versions, and if it still happens in the latest 5 series or 6 git, report to them and isolate what caused it.

[andyj]

I used -ge "6", but -gt "5" works too. 

While we're on the subject of beta testing, I would like to make a proposal: In theory the extensions are supposed to have a copy of the license available. Technically this doesn't mean that it needs to be _IN_ the "some-xyx-extension.tcz" file, but that it be available _WITH_ the file. In my cursory scan of many of the extensions available I noticed that the license files are lacking. Rather than repackage them to be in compliance, I propose that we create a new file with a name such as "some-xyz-extension.tcz.lic" to compliment the existing files which would have the text of the license in it. Because the license file names can vary based on the type of license itself, this would standardize that. I say beta test because this suggests that a new "License" tab be added to the app browser and that the license be downloaded with the extension, so there would need to be a few strategic code updates. Thoughts?

[Juanito]

Note that the license for all of the extensions will be in the source tarball in the repo src folders - apart from licenses which expressly state that they should be in the extension itself, they are already available.