I am using openwrt to build an embedded system image - and wondering whether I can add multple device tree files (dtb) in single image.
Basically, I have multiple hardwares which needs to share the single image file for all.
Upgrade will happen with the single image for different hardware.
Question is, current our boot-loader code has some kind of code to "override" some important params based on hardware type.
Rather than doing aboves, i want to put multiple device tree files (dtb) and make boot loader to load / read - right dtb file and pass the params to kernel based on hardware type.
Is it possible? If so, what would be the way to do it
Thanks in advance!
Related
In my practice I faced with the task - visualize some process memory content in real time. The main idea is read arbitrary part of remote process memory, represent it as image, and show in a separate window, then repeat these action with some interval, and in result get dynamic visualization of memory content. For example, it will be useful for view framebuffers/textures that located in process memory. Do exists any tools/software for this purpose? Thanks.
So, I did not find any utilities, and so I created my own tool.
This is mem2pix, program which allows to real-time visualizing some part of remote process memory, supports many pixel format type. Currently works on both Windows and Linux.
I would like to create an app that uses
Swift
CoreData
'Documents' which work in the standard macOS fashion [custom extension, a single 'file'/filewrapper containing all data relating to that document]
This does not appear possible. The documentation states very clearly that
NSPersistentDocument does not support some document behaviors:
File wrappers. [..]
which makes me think that the usual ways of dealing with images in CoreData - binary data with 'allow external storage' and save them to a different location, store the URL in the database - cannot be used with NSPersistentDocument. I want my users to be able to do the usual Finder operations on my 'file' (duplicate, move to external storage, restore from external backup) and need all my data to be in one single package.
The SQL version of the file store results in the usual three-fold stack when saving - .sqlite, .sqlite-shm, .sqlite-wal - which is useless as a 'document'.
Is there a solution I have overlooked? (examples are very sparse; the Big Nerd Ranch sample does not solve this, either; neither Marcus Zarra nor Objc.io touch on NSPersistentDocument).
The only option that will work with NSPersistentDocument the way you want it is to store the images directly in the database. You need a Binary Data attribute on your entity, but you cannot turn on the Allows External Storage option.
If you turn on this option, Core Data will decide - depending on the size - whether to store the image directly in the database or in a hidden folder inside the folder where your document is located:
(I made the folder visible entering cmd-shift-. in the Finder). The sample document is named Test 1.doof and it contains three images:
You can see that the hidden folder .Test 1_SUPPORT/EXTERNAL DATA contains two files, which are the two bigger images (1.3 MB and 494 KB). The third one with only 50 KB is stored inside Test 1.doof. If you move Test 1.doof into another folder, the hidden folder is left behind. Opening the file in that other folder leads to two missing images.
Storing the images inside the database is not that bad if you put the binary data into a separate entity with a one-to-one relation to the rest of the data, like so:
That way the image does not interfere with any search or sort operation. NSPersistentDocument gives you a lot of cool functionality for free, so you should use it anyway if possible.
Two additional remarks:
If you turn on Allows External Storage for an attribute, you do not have to care about URLs or where to store the images, Core Data does that for you (but not in a useful way for document-based apps).
These shm or wal files are temporary files that appear "sometimes", for databases without external storage as well. If they stick, you can safely remove them when you app is closed.
If you want to put more then just a database in your document, then you should implement NSDocument instead of NSPersistentDocument. In that case you don't get built-in support for CoreData, but you can use your document as a container for multiple file types.
See also Is NSDocument and CoreData a possible combination, or is NSPersistentDocument the only way?
There should be a standard, board and architecture independent way to do this just like there is with initfamfs, no?
I'm using powerpc and linux-3.10, if it matters. If there are better facilities later, I'd be interested to hear about them.
And if anyone knows of a board where this is currently working that I could use as a reference, that would also be helpful.
I've been searching and searching and I find a lot of information about why dts/dtb exists, a fair amount about the ongoing discussion of whether they are useful, and some about how to write dts or use existing dts, but nothing about how to embed them.
Quick descriptions or pointers to relevant doc would be very much appreciated.
What you need is Flattened Image Tree format (FIT). FIT uses DTS syntax/format to describe images embedded into one master image. For example you can package zImage and one or more DTB files and initramfs image and what so ever. Take a look at these slides for details.
If the bootloader supports device tree, the DTB can be loaded like any other (u/m)Image, but should have it pass to the kernel. If not, we have to use kernel CONFIG_(ARM_)APPENDED_DTB to load newer kernels. Not an option for PowerPC?
cat x.dtb >> zImage
To load an initramfs in that case, use CONFIG_INITRAMFS_SOURCE to include it in the kernel build.
I'm working on a Flash GUI project which has many images need to be dynamically loaded at runtime.
Problem:
Currently everytime a class initializes, it loads its assets (images) from HDD, but that usually takes too long (for example: I have a list of 100 items, each item has the same background, which is a PNG image stored on HDD, but it has to load the image 100 times from HDD to render the list, because the item's class gets to be initialized 100 times). Also, I want assets to be hidden from the users, so I want to pack it up somehow, into a single file.
Solution:
I think of SWC. I heard it's sort of library for Flash. But I have almost no experience on working with SWC. And there are too many images, would take very long to manually import and put class name for each of them in the FLA library. But I already have an XML file which stores the class names and the path to each class' assets. So I can load all the images into a variable, but I don't know how to actually write that variable into a SWC file on HDD to load it later as a library.
[MyButton.png] --load to RAM--> [myButton:Bitmap] --write to SWC file on HDD--> [Assets.swc] --import the SWC file at runtime--> [addChild(assets.myButton)]
The text in bold is the part I'm missing.
Thanks for your time! Any help is greatly appreciated.
SWC is a file that you "precompile" it's pretty much the same as a swf, but really nothing that you "create on the fly". The biggest difference is that a swc is something that is "compiled into" an swf and not loaded dynamically. That is, you can't load a swc-file during runtime, it is provided during compile time.
So, every picture added to the swc will increase its' size, the good thing is that it can be shared between different swf-files.
Now, correct me if I understood you wrong, but it seems like you reload the picture from hard drive whenever that picture is used? So 100 instances of "Ball" which is linked to the picture "Ball.png" would load that file 100 times?
If that is the case, why not just create an ImageManager and let that one keep one instance of the loaded images and then share it among all the instances that uses that image?
AFAIK there is no easy way to do this, however I wrote a blog post (since I couldn't find a better way to give you that solution) if you are interested in an example with caching loaded images.
It's pretty naive and revolves around a static ImageManager, loading only images, caching them by their url-id and then providing a new instance of the bitmapdata if they are allready loaded. However, it works like a charm and it is WAY MORE efficient than always loading the image from hard drive.
You can find the blog post here: http://messer1024.blogspot.se/2012/12/caching-loaded-images-in-as3.html
I want to maintain a list of block numbers as they are physically written to using the linux kernel source. I plan to modify the kernel source to do this. I just need to find the structure and functions in the kernel source that handle writing to physical partitions and get the block numbers as they write to the physical partition.
Any way of doing this? Any help is appreciated. If I can find where the kernel is actually writing to the partitions and returning the block numbers, that'd work.
I believe you could do this entirely from userspace, without modifying the kernel, using the blktrace interface.
It isn't just one place to check. For instance, if the block device was an iSCSI or AoE target, you would be looking for their respective drivers, then ultimately the same on the other end.
The same would go for normal SCSI, misc flash devices, etc, minus network interaction.
VFS just pulls these all together in a convenient, unified and consistent interface for calls like read() and write() to work while providing buffering. The actual magic, including ordering and write barriers are handled by the block dev drivers themselves.
In the case of using device mapper, the path alters slightly. It goes from vfs -> dm_(target) -> blockdev_driver.