BlackHole Vu+ Solo 1.6.7

Status
Not open for further replies.
Logan

Logan

Vip
Vu+ solo need the new boot loader to use the filesystem of the new kernel-
So we have to wait untile Vu+ will release the bootloader update for Solo (i think soon).
 
sakisdvb

sakisdvb

BH Lover
I have read new boot loader makes receiver take bigger images.
What is the benefit for bigger images ?

Regards.
 
Shiro

Shiro

BH-C
sakisdvb said:
I have read new boot loader makes receiver take bigger images.
What is the benefit for bigger images ?
Regards.
Click to expand...

The new bootloader is needed to load the ubifs used by the new 3.1.1 kernel that assure better performances.

About ubifs:
One thing people have to understand when dealing with UBIFS is that UBIFS is very different to any traditional file system - it does not work on top of block devices (like hard drives, MMC/SD cards, USB flash drives, SSDs, etc). UBIFS was designed to work on top of raw flash, which has nothing to do with block devices. This is why UBIFS does not work on MMC cards and the like - they look like block devices to the outside world because they implement FTL (Flash Translation Layer) support in hardware, which simply speaking emulates a block device on top of the built-in raw flash. Please, make sure you understand the differences between raw flash and, say, MMC flash before dealing with UBIFS. This section should help.
Overview

UBIFS is a new flash file system developed by Nokia engineers with help of the University of Szeged. In a way, UBIFS may be considered as the next generation of the JFFS2 file-system.
JFFS2 file system works on top of MTD devices, but UBIFS works on top of UBI volumes and cannot operate on top of MTD devices. In other words, there are 3 subsystems involved:
  • MTD subsystem, which provides uniform interface to access flash chips. MTD provides an notion of MTD devices (e.g., /dev/mtd0) which basically represents raw flash;
  • UBI subsystem, which is a wear-leveling and volume management system for flash devices; UBI works on top of MTD devices and provides a notion of UBI volumes; UBI volumes are higher level entities than MTD devices and they are devoid of many unpleasant issues MTD devices have (e.g., wearing and bad blocks); see here for more information;
  • UBIFS file system, which works on top of UBI volumes.
Here is a list of some of UBIFS features:
  • scalability - UBIFS scales well with respect to flash size; namely, mount time, memory consumption and I/O speed does not depend on flash size (currently it is not 100% true for memory consumption, but the dependency is very weak, and this may be fixed); UBIFS (not UBI!) should work fine for hundreds of GiB flashes; however, UBIFS depends on UBI which has scalability limitations (see here); nonetheless, the UBI/UBIFS stack scales much better than JFFS2, and if UBI becomes a bottleneck, it is always possible to implement UBI2 without changing UBIFS;
  • fast mount - unlike JFFS2, UBIFS does not have to scan whole media when mounting, it takes milliseconds for UBIFS to mount the media, and this does not depend on flash size; however, UBI initialization time depends on flash size and has to be taken into account (see here for more details);
  • write-back support - this dramatically improves the throughput of the file system in many workloads, comparing to JFFS2, which is write-through; see here for more details;
  • tolerance to unclean reboots - UBIFS is a journaling file system and it tolerates sudden crashes and unclean reboots; UBIFS just replays the journal and recovers from the unclean reboot; mount time is a little bit slower in this case, because of the need to replay the journal, but UBIFS does not need to scan whole media, so it anyway takes fractions of a second to mount UBIFS; note, authors payed special attention to this UBIFS aspect, see here;
  • fast I/O - even with write-back disabled (e.g., if UBIFS is mounted with the "-o sync" mount option) UBIFS shows good performance which is close to JFFS2 performance; bear in mind, it is extremely difficult to compete with JFFS2 in synchronous I/O, because JFFS2 does not maintain indexing data structures on flash, so it does not have the maintenance overhead, while UBIFS does have it; but UBIFS is still fast because of the way UBIFS commits the journal - it does not move the data physically from one place to another but instead, it just adds corresponding information to the file system index and picks different eraseblocks for the new journal (i.e., UBIFS has sort of "wandering" journal which constantly changes the position); there are other tricks like multi-headed journal which make UBIFS perform well;
  • on-the-flight compression - the data are stored in compressed form on the flash media, which makes it possible to put considerably more data to the flash than if the data were not compressed; this is very similar to what JFFS2 has; UBIFS also allows to switch the compression on/off on per-inode basis, which is very flexible; for example, one may switch the compression off by default and enable it only for certain files which are supposed to compress well; or one may switch compression on by default but disable it for supposedly uncompressible data like multimedia files; at the moment UBIFS supports only zlib and LZO compressors and it is not difficult to add more; see this section for more information.
  • recoverability - UBIFS may be fully recovered if the indexing information gets corrupted; each piece of information in UBIFS has a header which describes this piece of information, and it is possible to fully reconstruct the file system index by scanning the flash media; this is very similar to JFFS2; to make it more clear, imaging you have wiped out the FAT table on your FAT file system; for FAT FS this would be fatal; but if you similarly wipe out UBIFS index, you still may re-construct it, although a special user-space tool would be required to do this (this utility is not implemented at the moment, though);
  • integrity - UBIFS (as well as UBI) checksums everything it writes to the flash media to guarantee data integrity, UBIFS does not leave data or meta-data corruptions unnoticed (JFFS2 is doing the same); By default, UBIFS checks only meta-data CRC when it reads from the media, but not the data CRC; however, you may force CRC checking for data using one of the UBIFS mount options - see here.
Click to expand...
 
sakisdvb

sakisdvb

BH Lover
Shiro said:
The new bootloader is needed to load the ubifs used by the new 3.1.1 kernel that assure better performances.

About ubifs:
Click to expand...
Dear Shiro
Thank you for the clarification.

This means we must format all USB devices (HDD,Flash drives) on VU+ Solo with new file format?
The media already on USB HDD or Flash drives (Videos,Picons,Swap file,Settings,etc,,,) are no longer visible/Usable?
The new Kernel supports ext1,ext2,ext3 format ?
 
angelofsky1980

angelofsky1980

BlackHole Driver Specialist
sakisdvb said:
Dear Shiro
Thank you for the clarification.

This means we must format all USB devices (HDD,Flash drives) on VU+ Solo with new file format?
The media already on USB HDD or Flash drives (Videos,Picons,Swap file,Settings,etc,,,) are no longer visible/Usable?
The new Kernel supports ext1,ext2,ext3 format ?
Click to expand...
ABSOLUTELY NO!
UBIFS and UBI are internal formats like JFFS2 used in the past or in another boxes.
Flash procedure is not changed.
 
sakisdvb

sakisdvb

BH Lover
Great ! ! :victory:
Can't wait, to test new Bootloader and BH image.

P.S.
UBIFS is a new flash file system......
Click to expand...
Sorry I didn't read text carefully.
In case I would like to change back to previous Image and kernel is this possible ?
 
angelofsky1980

angelofsky1980

BlackHole Driver Specialist
sakisdvb said:
I am not curious to ask, why VU+ Solo is left last to update to new kernel/image.
Click to expand...

Vu+ has made code to build a kernel 3.1.1 image for SOLO but the box needs CFE update. When Vu+ release this update, Solo can boot and use the new kernel and new images.
I'm very tired to repeat same things.
The only thing we can do now is to wait.
 
sakisdvb

sakisdvb

BH Lover
Thank you Angelofsky1980.
I am very sorry I made you feel this way.
I have not knew, the delay is Manufactures responsibility.
Lets Wait Then.

Regards.
 
angelofsky1980

angelofsky1980

BlackHole Driver Specialist
sakisdvb said:
Thank you Angelofsky1980.
I am very sorry I made you feel this way.
I have not knew, the delay is Manufactures responsibility.
Lets Wait Then.

Regards.
Click to expand...
Vu+ has already made a very good job with new kernel and it's so busy with Ultimo.
I think in concurrency with Ultimo launch and the next Official Image, they release a Solo CFE update.
 
josechuuu

josechuuu

Vu+ Newbie
I think why so late in vu+solo, it is normal to believe that the team is dedicatedmore to vu+duo, vu+uno, vu+ultimo, and this is not a crime
 
markb

markb

Vu+ Newbie
It would be a crime if they are selling receivers that are no longer supported without letting people know, but let's be patient and wait. I do think it looks as if the Solo is a lesser priority and I wonder if this is the case. I hope not. We will see. I am looking forward to testing the new kernel on my almost new Solo.
 
angelofsky1980

angelofsky1980

BlackHole Driver Specialist
markb said:
It would be a crime if they are selling receivers that are no longer supported without letting people know, but let's be patient and wait. I do think it looks as if the Solo is a lesser priority and I wonder if this is the case. I hope not. We will see. I am looking forward to testing the new kernel on my almost new Solo.
Click to expand...
I'm curious too to test the Solo and new kernel ;)
 
josechuuu

josechuuu

Vu+ Newbie
markb said:
It would be a crime if they are selling receivers that are no longer supported without letting people know, but let's be patient and wait. I do think it looks as if the Solo is a lesser priority and I wonder if this is the case. I hope not. We will see. I am looking forward to testing the new kernel on my almost new Solo.
Click to expand...
I wait to be wrong, but for one month I take reason..........
 
sakisdvb

sakisdvb

BH Lover
The one think makes VU+ Receivers Better from the others is
support from manufacturer and of course BH-Team.

If for reason a two years old receiver like VU+ Solo
is no more or less supported, this is (for me at least)
a very good reason not to buy VU+ again. :no:

If they update receivers and leave older models to their fate the company will make the same
mistake like all other manufactures who tried and fail to stand from the crowd (and eventually forgotten).

But to build new models and support them firstly is only natural.
For time being VU+ has the best support and I believe angelofsky1980 is correct. :yes: :yes:
angelofsky1980 said:
Vu+ has already made a very good job with new kernel and it's so busy with Ultimo.
I think in concurrency with Ultimo launch and the next Official Image, they release a Solo CFE update.
Click to expand...
 
Status
Not open for further replies.
Top