Related
I've been at this for a few weeks, and its bugging me.
I've been looking up on how to build/port ROMs for the Milestone (A853), and there is almost nothing that points me in the right direction. I want to be able to install it via OR's update menu.
This is what I've done so far:
Gotten, and set up HTC Android Kitchen by dsixda.
Downloaded the rom I want to port.
Extracted the rom system and boot images.
Replaced the boot.img-kernel with a stock Milestone boot.img-kernel taken from a nandroid backup. (I know all about the locked bootloader)
Rebuilt the kernel
Modified the build.props
Rebuilt the *.zip
Copied to Open Recovery/updates
Applied update.
So here's where it gets sticky. According to the output, the ROM installs fine. No errors nothing. However, after the first reboot, it goes directly to the bootloader screen with an error of: a5,69,4E,00,23 or something like that.
I'm royally stumped and would really like to get this going in the same way CM or Crono's is installed. Any ideas or advice would be GREATLY appreciated.
dynamite1985 said:
I've been at this for a few weeks, and its bugging me.
I've been looking up on how to build/port ROMs for the Milestone (A853), and there is almost nothing that points me in the right direction. I want to be able to install it via OR's update menu.
This is what I've done so far:
Gotten, and set up HTC Android Kitchen by dsixda.
Downloaded the rom I want to port.
Extracted the rom system and boot images.
Replaced the boot.img-kernel with a stock Milestone boot.img-kernel taken from a nandroid backup. (I know all about the locked bootloader)
Rebuilt the kernel
Modified the build.props
Rebuilt the *.zip
Copied to Open Recovery/updates
Applied update.
So here's where it gets sticky. According to the output, the ROM installs fine. No errors nothing. However, after the first reboot, it goes directly to the bootloader screen with an error of: a5,69,4E,00,23 or something like that.
I'm royally stumped and would really like to get this going in the same way CM or Crono's is installed. Any ideas or advice would be GREATLY appreciated.
Click to expand...
Click to collapse
Is that meant to work for the milestone? I dont see milestone listed on supported devices.
Is this the kitchen you are referring to?
ya thats the one i was referring to.
I know its not supported, but I was looking at the outputs of the zips it creates, and comparing them to some ROMs out there (notably CM6.1 and Cronos) and they are pretty much the same. The only thing that I have noticed thats different is that the Milestone doesn't use the updater-script that this particular kitchen generates. So, if I pretty much leave the updater-script alone, it will install, up until I reboot, and I get the error code I mentioned before.
If I let the kitchen generate the updater-script, the installation aborts, usually with a 'Status 4' or 'Status 7' error.
dynamite1985 said:
ya thats the one i was referring to.
I know its not supported, but I was looking at the outputs of the zips it creates, and comparing them to some ROMs out there (notably CM6.1 and Cronos) and they are pretty much the same. The only thing that I have noticed thats different is that the Milestone doesn't use the updater-script that this particular kitchen generates. So, if I pretty much leave the updater-script alone, it will install, up until I reboot, and I get the error code I mentioned before.
If I let the kitchen generate the updater-script, the installation aborts, usually with a 'Status 4' or 'Status 7' error.
Click to expand...
Click to collapse
Sorry buddy. I ain't a developer. Try sending a PM to Luca or Kabaldan or Feeyo ( on cronosproject ) and see if they can help.
The boot.img contains kernel and rootfs with init and its scripts. Nothing in it can be directly changed if you want the Milestone to be able to boot.
The kitchen obviously rebuilds the boot.img - err a5,69,4E,00,23 means that the boot.img signature check failed.
You can't do this on Milestone - that's why the sh-hijack + 2nd-init are used in custom compiled ROMs for Milestone to be able to use customized init scripts.
kabaldan said:
The boot.img contains kernel and rootfs with init and its scripts. Nothing in it can be directly changed if you want the Milestone to be able to boot.
The kitchen obviously rebuilds the boot.img - err a5,69,4E,00,23 means that the boot.img signature check failed.
You can't do this on Milestone - that's why the sh-hijack + 2nd-init are used in custom compiled ROMs for Milestone to be able to use customized init scripts.
Click to expand...
Click to collapse
so I'm a little confused...
it seems to me that I should be compiling the kernal with the 2nd-init attack, which confuses me because of the BL issue. or is the stock boot.img used with a customized system.img?
i've tried the latter part, and gotten the noted error.
I like to tweak my ROMs before a flash. i.e. make changes to /system apps; framwork tweaks... etc.
However, whenever I try to replace a kernel zImage or modem binary(using 7z, so as not open archive), I get stuck at a bootloop.
I can replace .apks and .pngs no problem using this method.
Can zImage and .bin be replaced as well? Does redbend also need to be copied? Since .bin and zImage reside in same folder in ROM... which redbend to use if needed?
Thank you?
Whenever I use a new kernel in Loki, or test one personally, I use the version of redbend that the dev included with their kernel initially. Modem does not seem to matter. Are you using a kernel that is meant for the version of Android that matches your rom? If you want to, specifically, what are you using?
This is interesting to me as well, as I did not know you could flash a zip that had been added to, so can you briefly explain how this is done? I would much rather inject my apps than do the titanium backup dance.
I also noticed that SGS Kernel flasher flashes the zImage by simply copying it, and rebooting.
If you are about to tell me I can manipulate my FS to add anything i want, in an update.zip, then sir, I love you.
BTW, if its a simple explanation, whats the redbend file do?
Br1cK'd said:
Whenever I use a new kernel in Loki, or test one personally, I use the version of redbend that the dev included with their kernel initially. Modem does not seem to matter. Are you using a kernel that is meant for the version of Android that matches your rom? If you want to, specifically, what are you using?
Click to expand...
Click to collapse
Exactly what Br1cK'd said. Use the redband that's with the kernel. If pulling the kernel from a rom and a modem from a different one same deal. Also be careful which kernels you use ie: right kernel for phone and version of Android.
d33dvb said:
This is interesting to me as well, as I did not know you could flash a zip that had been added to, so can you briefly explain how this is done? I would much rather inject my apps than do the titanium backup dance.
I also noticed that SGS Kernel flasher flashes the zImage by simply copying it, and rebooting.
If you are about to tell me I can manipulate my FS to add anything i want, in an update.zip, then sir, I love you.
BTW, if its a simple explanation, whats the redbend file do?
Click to expand...
Click to collapse
No sir it is not quite that simple. Proper settings have to be in the update script for everything to install properly. Replacing one file for another of the same name usually works and some files can be added but system apps and additional folders need to be in the update script.
Br1cK'd said:
Whenever I use a new kernel in Loki, or test one personally, I use the version of redbend that the dev included with their kernel initially. Modem does not seem to matter. Are you using a kernel that is meant for the version of Android that matches your rom? If you want to, specifically, what are you using?
Click to expand...
Click to collapse
Br!ck'd, fan of your work and EDT as a whole... great dev team! It happens on any kernel/ROM combo I have tried, which is interesting. Update.zips just carry signed certs and simple copy bash scripts, essentially pushing new files to correct directories, correct? I definitely check for kernel compatability before, I am noobish, not noobtacular
d33dvb said:
This is interesting to me as well, as I did not know you could flash a zip that had been added to, so can you briefly explain how this is done? I would much rather inject my apps than do the titanium backup dance.
I also noticed that SGS Kernel flasher flashes the zImage by simply copying it, and rebooting.
If you are about to tell me I can manipulate my FS to add anything i want, in an update.zip, then sir, I love you.
BTW, if its a simple explanation, whats the redbend file do?
Click to expand...
Click to collapse
1. I believe redbend is samsung tool for flashing volatile memory (NAND).
2. You can use 7zip to explore archives/apks without extracting them and breaking signings. Thus you can simple copy paste .apks/.pngs to appropriate directories without extracting
Most update zips are the actually apk and simple scripts in a flashable container. Roman form EDT has an excellent tool for creating flashable zips if interested... but yes you can manipulate file system of phone and archives. I use adb from recovery. Or android commander is a useful tool as well
EDIT: Explodingboy gives better explanation above
I use untermench's modified redbend. It's the same thing except it removes that ugly blue splash screen every time it is run. That said, I've simply copied over OS and CW into the trigger zips to override the stock kernel. And I never received any reports if it not working from anyone (and I've had releases with both).
Point being, in my experience it doesn't really matter (so long as everything matches). I've done the same for previous modems.
And as you said, all it's doing is copying them to the proper partitions.
Sent from my SGH-T959 using Tapatalk
birgertime said:
I use untermench's modified redbend. It's the same thing except it removes that ugly blue splash screen every time it is run. That said, I've simply copied over OS and CW into the trigger zips to override the stock kernel. And I never received any reports if it not working from anyone (and I've had releases with both).
Point being, in my experience it doesn't really matter (so long as everything matches). I've done the same for previous modems.
And as you said, all it's doing is copying them to the proper partitions.
Sent from my SGH-T959 using Tapatalk
Click to expand...
Click to collapse
Very cool... thanks.
Also, you are going to think I am crazy... but that ugly blue splash screen can tell me if it is a bad flash or not. When it happens on the top of screen= good flash, on bottom = gonna need to flash again, cause behavior goes wonky. Maybe just bizarre coincidence???
Poser said:
Br!ck'd, fan of your work and EDT as a whole... great dev team! It happens on any kernel/ROM combo I have tried, which is interesting. Update.zips just carry signed certs and simple copy bash scripts, essentially pushing new files to correct directories, correct? I definitely check for kernel compatability before, I am noobish, not noobtacular
Click to expand...
Click to collapse
I've seen you around, you're not noobtacular, but hell I'm still way noobish about a lot of things. Dig the avatar btw. I don't know if I can give an intelligent enough answer to your question, would probably have nobody running Loki by tomorrow, lol. Have you grabbed any logs, or tried to, while its looping?
I have no issues doing this with winrar.
Sent from my Amazing Captivate using the XDA Premium App Infused with Tiger Blood
Br1cK'd said:
I've seen you around, you're not noobtacular, but hell I'm still way noobish about a lot of things. Dig the avatar btw. I don't know if I can give an intelligent enough answer to your question, would probably have nobody running Loki by tomorrow, lol. Have you grabbed any logs, or tried to, while its looping?
Click to expand...
Click to collapse
<Palm to forehead> Probably should logcat... duh.
Just flashed with with custom kernel/modem combo... seems to be booting fine, will report any anomalies.
Only thing I did different was copy zImage and redbend from Kernel.zip
Thanks peoples!
Interestingly enough (I don't know the reasons), it looks like Motorola left a copy of Nvflash and Atrix-specific bootloader.bin for it on the Atrix. What's interesting about Nvflash is that it allows for targeted backup and restore of partitions (i.e. something along the lines of what Nandroid allows for, except at a lower level), which decreases recovery time when developers do something that ends up soft-bricking their phone. It should also break us free of our dependence on SBFs because we'll be able to create our own backups.
Anyways, the Nvflash on the phone is the Linux i386 binary. The bootloader.bin isn't platform specific, as it's meant for the target, rather than the host. THe archive is available in /usr/local/share/motorola/fireboxmake/OSH_tools.tgz.
Unfortunately, this is where we get stuck, because we don't currently know how to get a connection to the phone. And that's where all of you come in! Can you get further? I've gotten this far:
Code:
Nvflash started
rcm version 0X4
Command send failed (usb write failed)
I imagine that some of the functionality may end up requiring the --sbk flag (and we don't know the SBK right now), but I'm hoping that we can at least backup and restore /system, /data, and /osh.
Update: Information I've obtained indicates that this is the error you get when the SBK you pass in doesn't match the SBK on the system. So, no luck until we get that SBK.
Update 2: Additional links from dasmoover:
Tegra crypto engine source snapshot
/osh/usr/local/share/motorola/fireboxmake
Credit to dasmoover for the find.
Correct me if I'm wrong but isn't this the same thing as which apparently folks are trying to get taken down in the name of keeping the info under wraps?
I would like to excuse myself for earlier. I am glad that you have turned this in to something positive.
Sent from my MB860 using XDA Premium App
JdeFalconr said:
Correct me if I'm wrong but isn't this the same thing as some other thread, which apparently folks are trying to get taken down in the name of keeping the info under wraps?
Click to expand...
Click to collapse
It's related, but it's not quite the same thing. If nothing else, you have the binaries for this right now on your phone (dasmoover posted a link on the IRC channel 12 hours ago or so). I'm at this mostly for the backup/restore capabilities of Nvflash rather than bootloader hacking. Even if we only ever had that much, I'd be thrilled, because I hate having to re-SBF and set everything up again every time I soft brick my phone.
Also: I've been planning on posting this for a few hours now, before that other post even went up. I'm... disappointed to see that other post, but these two things aren't after the same thing.
http://gititbit.ch/fbm1 - /osh/usr/local/share/motorola/fireboxmake
also contains OSH_tools.tgz.
Firebox is the development name for the Webtop system. This contains the tools to prep the partition image for flashing. There are also some files IDA generated.
May be of use: http://gititbit.ch/tces1 - Tegra Crypto Engine Source Snapshot
do you mind me asking but.. what was that other thread about that it warranted getting deleted.
seven2099 said:
do you mind me asking but.. what was that other thread about that it warranted getting deleted.
Click to expand...
Click to collapse
it got deleted for a reason - let it be
I think we are getting warmer now .......... this calls for some investigation.
minooch said:
it got deleted for a reason - let it be
Click to expand...
Click to collapse
Wow he was just asking a questing...If you feel that even just telling him/us what the thread was about is so bad/dangerous then i think there is a bigger problem here. This should be a place to share information, ideas and if we start cracking down on that then we lose so much (yes if it is copyrighted or under nda then take it down)
http://forum.tegratab.com/viewtopic.php?f=13&t=18
They've been using nvflash to flash their tablet.
Perhaps someone can pull their SBK right out of the phone
sys/fuse/SecureBootKey
I doubt it is of any use because once pulled from the phone it appears as 0 bytes.
Looking at it from the phone shows nothing.
my guess is, as the path describes, a fuse, once lit, makes the file blank.
I navigated to nvflash with root explorer and executived the file. All get is executing file and nothing. I figured this would be.the case. Where would this need to run? A recovery state?
Sent from my MB860 using XDA App
sifon187 said:
I navigated to nvflash with root explorer and executived the file. All get is executing file and nothing. I figured this would be.the case. Where would this need to run? A recovery state?
Click to expand...
Click to collapse
The recovery state would be similar to the RSD recovery state (set on boot by pressing Volume Down) except that there's a specific Nvflash one. But, that's the one I can't get to respond properly.
LOOK HERE
LOOK HERE
http://forum.xda-developers.com/showthread.php?p=13145274#post13145274
blackax said:
Wow he was just asking a questing...If you feel that even just telling him/us what the thread was about is so bad/dangerous then i think there is a bigger problem here. This should be a place to share information, ideas and if we start cracking down on that then we lose so much (yes if it is copyrighted or under nda then take it down)
Click to expand...
Click to collapse
there is a separate dev forum that we can't access for DEVs only that that information is being used on. it being in the open here might hurt our chances of being able to exploit anything as moto might find it and patch it before the devs have a chance to get at it.
Is the Dev forum on XDA or.somewhere else just curious
Sent From My Gibgerblurred Phone
it's on xda, but you have to be a recognized developer of xda to access it.
PAulyhoffman said:
Perhaps someone can pull their SBK right out of the phone
sys/fuse/SecureBootKey
I doubt it is of any use because once pulled from the phone it appears as 0 bytes.
Looking at it from the phone shows nothing.
my guess is, as the path describes, a fuse, once lit, makes the file blank.
Click to expand...
Click to collapse
I am a complete noob and not close to a dev but if pulling the file blanks it the why not view the file while still on the phone while using an external source or application? Again like I said noob so sorry if alreay tried
thats just my 2 cents
sent from XDA mobile
Wow give a dime at least...
Sent from my MB860 using XDA App
drock212 said:
I am a complete noob and not close to a dev but if pulling the file blanks it the why not view the file while still on the phone while using an external source or application? Again like I said noob so sorry if alreay tried
Click to expand...
Click to collapse
Ends up being the same thing. Running sudo cat on the file prints nothing. That was one of the first things tried, even before copying the file.
deleted .
Finally ! That bug was very annoying to me.
I'll try the fix asap, thanks a lot!
e: works like a charm!
Yeah, it was a so annoying issue...
I wonder why so less people visited this thread .
I copied this ZIP onto my SD card,rebooted, went into clockwork mod, install zip, choose zip and flashed this,rebooted but am stuck on the HTC screen now for over 7 minutes am i doing something wrong?
It's as well i made a backup or id lose everthing
jonny68 said:
I copied this ZIP onto my SD card,rebooted, went into clockwork mod, install zip, choose zip and flashed this,rebooted but am stuck on the HTC screen now for over 7 minutes am i doing something wrong?
It's as well i made a backup or id lose everthing
Click to expand...
Click to collapse
Try adding the libaudio.so to your ROM.zip (with 7-zip or WinRAR) at the right directory and flash the ROM.zip again. That's what I am doing everytime I change something
j4n87 said:
Yeah, it was a so annoying issue...
I wonder why so less people visited this thread .
Click to expand...
Click to collapse
Because you posted it in the "Themes and Apps" section
thanks a lot for post here
great job
kackburt said:
Try adding the libaudio.so to your ROM.zip (with 7-zip or WinRAR) at the right directory and flash the ROM.zip again. That's what I am doing everytime I change something
Click to expand...
Click to collapse
you mean copy the actual zip file into the ROM zip and then flash?
jonny68 said:
you mean copy the actual zip file into the ROM zip and then flash?
Click to expand...
Click to collapse
Unzip the cwm with the fix and navigate to "system/lib" and copy the "libaudio.so".
then open the rom zip navigate to "system/lib" and paste the "libaudio.so" there.
Didn't understand your previous post..did you make a backup or not?
If not...just flash your current rom again, you won't lose your data if you do this.
Only the files that you edited in /system like gps.conf or other tweaks you have to edit again.
Tried on UD3.3.0 wont boot... :s
People dont understand that this work the best on CM7 nexus roms.
That by installing this fix on CM7 or AOSP you will probaly lose the robo and high volume on first call fix. That most roms have custom libs including this lib. Minimum requirements I would say CM7 2.34 and AOSP 2.34 since cm7 and AOSP are the most equal roms to each other.
To say it simple you cant just simply flash this on every rom also make sure your permission is right.
Is this fix able to work on an HTC Desire running 2.3.4 Oxygen ROM?
jonny68 said:
I copied this ZIP onto my SD card,rebooted, went into clockwork mod, install zip, choose zip and flashed this,rebooted but am stuck on the HTC screen now for over 7 minutes am i doing something wrong?
It's as well i made a backup or id lose everthing
Click to expand...
Click to collapse
If you have a nandroid backup, you should be on the safe side!
Try to wipe cache partition first, then the dalvik cache and then flash the zip-file.
All of these actions take place in the CWM.
Hope it works!
The libaudio.so fix was submitted to gerrit (Change I24a4a11b: Fix for a1026 suspend)by Jordon aka Jyxent. It was mergered with the latest nightlies, and should be merged with CM 7.0.4
jens1288 said:
The libaudio.so fix was submitted to gerrit (Change I24a4a11b: Fix for a1026 suspend)by Jordon aka Jyxent. It was mergered with the latest nightlies, and should be merged with CM 7.0.4
Click to expand...
Click to collapse
Yes, that fix works fine. I'm not sure it fixes the few seconds delay that affects all Gingerbread phones though but there was another potential workaround submitted for that too.
http://review.cyanogenmod.com/#change,5420
I have yet to include it in my build and try it though.
The story on the front page links to the wrong fix. The libaudio fix was for the wonk on the Nexus One. The libaudio library is hardware specific and may cause issues on other devices that don't share the same processor.
I've submitted a patch to gerrit that helps with the call delay here:
http://review.cyanogenmod.com/#change,5420
Thank you for clearing that up jyxent. To go into a bit more detail...
The fix that was posted, as jyxent mentioned, is for the Nexus One. That is for the infamous "wonk" that has been plaguing N1 users since the Gingerbread nightlies started (who woulda thunk it was just a single line that needed to be added).
The 2-3 second delay is something that affects most (if not all) Gingerbread installs. Currently there isn't a simple "fix" for this. It requires recompiling portions of Gingerbread. jyxent's fix is submitted to CM, but I don't see any reason why this can't be applied to AOSP as well. It has yet to be reviewed by the CM dev team (at least it doesn't have any comments on it yet). It might be something that can be made into some device-independent flashable zip, but it has yet to be created.
j4n87 said:
Unzip the cwm with the fix and navigate to "system/lib" and copy the "libaudio.so".
then open the rom zip navigate to "system/lib" and paste the "libaudio.so" there.
Didn't understand your previous post..did you make a backup or not?
If not...just flash your current rom again, you won't lose your data if you do this.
Only the files that you edited in /system like gps.conf or other tweaks you have to edit again.
Click to expand...
Click to collapse
done thanks
Can this be done manually with root explorer, by copying the libaudio.so to/system/lib and a reboot?
This thread is for FlashCast image developers ONLY. If you are not developing a FlashCast image, please do not post here. Post in the main thread instead.
Hello developers! I hope that this thread can serve as a place for you to ask any questions you may have about FlashCast development or internals, make feature requests, and report issues you're having. I will edit this post with FAQs as they come up. Until then, take a look at my documentation on GitHub, which contains documentation and sample code to help you create FlashCast mods.
tchebb said:
This thread is for FlashCast image developers ONLY. If you are not developing a FlashCast image, please do not post here. Post in the main thread instead.
Hello developers! I hope that this thread can serve as a place for you to ask any questions you may have about FlashCast development or internals, make feature requests, and report issues you're having. I will edit this post with FAQs as they come up. Until then, take a look at my flashcast-samples repository on GitHub, which contains documentation and sample code to help you create FlashCast mods.
Click to expand...
Click to collapse
So far its working great! Plan on releasing a rooted 13300 system image with this soon, but I was wondering, is there a possibility you could create a partition backup option? so like
Code:
backup_mtd_partition 'rootfs' 'system.img'
Where it will make a folder called backup on the jump drive, and store the rootfs file system with the name of system.img? also a md5 for each file would be nice. I know I could just have a script dd the mount point, but would be nice to see a function to call.
ddggttff3 said:
So far its working great! Plan on releasing a rooted 13300 system image with this soon, but I was wondering, is there a possibility you could create a partition backup option? so like
Code:
backup_mtd_partition 'rootfs' 'system.img'
Where it will make a folder called backup on the SD card, and store the rootfs file system with the name of system.img? also a md5 for each file would be nice. I know I could just have a script dd the mount point, but would be nice to see a function to call.
Click to expand...
Click to collapse
This would definitely be a useful feature. I can see a few implementation details that would need to be worked out in a non-obvious fashion, though:
There is currently no way for a imager script to directly access the root of the user partition. This is intended to prevent multiple scripts from having access to the same filesystem and possibly overwriting each others' files. Instead, scripts are executed in a temporary directory whose contents are discarded on device shutdown. It seems like the solution to this would be to create numbered backup directories, like there are numbered logs now, for mods to place their backups in.
It wouldn't be desirable for a mod to take a backup every time it was flashed, as not everyone cares about backups and they take up lots of space. There would need to be some way for the user to decide whether or not they wanted backups. Maybe another flag file?
Finally, taking a backup of an MTD partition using nanddump (dd should not be used to image NAND partitions, since it is not bad-block aware) images the entire partition, when (in the case of squashfs) only a small part actually has a filesystem on it. This means that a single rootfs backup will take up 400MB on the USB drive. I would want to implement something which can back up only the part of a partition which squashfs is using before I release backup functionality.
Obviously, this is a prime candidate for a new helper function, because of these non-trivial complications. I'll see if I can make the necessary changes to FlashCast and release backup functionality as part of v1.1. Thanks for the suggestion!
One more suggestion, if you do not mind.
How about the ability to flash multiple zips at once? So, if I have 2 files I want to flash, first one will stay eureka_image.zip, and then the next one would be eureka_image1.zip, or some similar process to allow multiple zips.
The issue here would be a naming scheme that would be easy for users to use and understand. so maybe if you flash a single file, just use eureka_image.zip, and if multiple, each would have a number added, starting from 1 and counting up in the order you want them flashed?
ddggttff3 said:
One more suggestion, if you do not mind.
How about the ability to flash multiple zips at once? So, if I have 2 files I want to flash, first one will stay eureka_image.zip, and then the next one would be eureka_image1.zip, or some similar process to allow multiple zips.
The issue here would be a naming scheme that would be easy for users to use and understand. so maybe if you flash a single file, just use eureka_image.zip, and if multiple, each would have a number added, starting from 1 and counting up in the order you want them flashed?
Click to expand...
Click to collapse
This is something I intend to implement. My current plan is to support a eureka_images directory, which can contain any combination of zipped and unzipped mods which will be flashed in alphabetical order. Mod authors can distribute their mods with a prefixed number, so, for example, you could distribute 00_13300_rooted.zip and 59_unlocator_dns.zip. I'll write a standard for how to determine the numbers (e.g. full system images get 00-09, major/minor filesystem changes get 40-49/50-59 respectively depending on how many files they affect, etc). It's not perfect and there can still be conflicts, but it should allow most mods to be flashed in a mostly sane order. I'm open to any suggestions or improvements you might have.
tchebb said:
This is something I intend to implement. My current plan is to support a eureka_images directory, which can contain any combination of zipped and unzipped mods which will be flashed in alphabetical order. Mod authors can distribute their mods with a prefixed number, so, for example, you could distribute 00_13300_rooted.zip and 59_unlocator_dns.zip. I'll write a standard for how to determine the numbers (e.g. full system images get 00-09, major/minor filesystem changes get 40-49/50-59 respectively depending on how many files they affect, etc). It's not perfect and there can still be conflicts, but it should allow most mods to be flashed in a mostly sane order. I'm open to any suggestions or improvements you might have.
Click to expand...
Click to collapse
Sounds great to me! Only other suggestion I have is to add another flag file which would allow Flashcast to continue flashing the multiple zips, even if one errors out.
So, by default if multiple zips are going to be flashed, and it errors on the first, it would stop, get a red LED, and then reboot.
with a flag file present, maybe ignore_errors, even if it errors out on the first zip, it would continue down the chain of zips until it finishes all of them.
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
bormeth said:
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
Click to expand...
Click to collapse
Most of the resources seem to be kept in the .pak files contained in /chrome. The first step to theming would be figuring out what format those are in and how to unpack and repack them. You might want to start by taking a look at the content_shell source code, as it might have some documentation or scripts for working with .pak files.
tchebb said:
Most of the resources seem to be kept in the .pak files contained in /chrome. The first step to theming would be figuring out what format those are in and how to unpack and repack them. You might want to start by taking a look at the content_shell source code, as it might have some documentation or scripts for working with .pak files.
Click to expand...
Click to collapse
Im gonna dive into it
Have a little bug report.
If a person has more then 85~MB in their eureka_image folder, and then they start a SquashFS File system edit, flashcast will report an error saying out of space. Now, here is the error part. Even though it failed to mount with an error, the imager.sh file will continue to run, and will then attempt to flash back a corrupt file, causing a non-bootable chromecast until the system partition is re-flashed.
bormeth said:
Anyone got any idea how to get started with some themes for the chromecast? Will be more than happy to help, as soon i know where to start.
Click to expand...
Click to collapse
The first script on THIS SITE will unpack the .PAK files, although it unpacks everything as a .png as it was made for a different Chromium device. So you would have to manually go rename all the files to their correct extension for the files, but because it expects everything to be a .png it won't pack back properly. The second script, technically should unpack/pack as proper file extensions, but I never got it to work right as I have little to no knowledge of Python.
The chromium source has a script,data_pack.py (which I can't link to since I'm a new user ATM) which can be used to pack and unpack .PAK files. The script posted above seems to be lifted from this source and modified to detect a few filetypes and write the unpacked files. But if you want to modify or add images and need to repack them, this script will help you figure it out. I'll work on adding and making some changes to the theme and give some instructions.
how to mount usb drive
Haven't used linux in years. Thanks!
Hey, want to do some poking around in the flashcast .bin file...how do I go about doing that? What is the file format, and is the image mountable in linux? Even better might be to extract files/folders from the image...what tool can I use to do that?
Ok, so I'm doing some dinking around...I've looked into buildroot, and I think for the most part I understand what is going on. I also tried building from source, and it appears to have worked. So, from this poking around I have a few assumptions I've made and a few questions. Correct me if I'm wrong anywhere but.......
Basically, you've built a generic bootloader for the device using buildroot. This is not related at all to the stock CC bootloader (although maybe you borrowed a few drivers, etc). I would guess that the buildroot bootloader has just what you need to display a picture on the TV and do some basic file system operations, and I would also guess that the buildroot bootloader is missing a few features that the stock bootloader has - therefore, it wouldn't be possible to run a full-fledged ROM off of this bootloader. Am I right so far? If so, what is missing from the buildroot bootloader? Libraries? Binaries? No idea?
Also, to access something like USB storage, the buildroot bootloader is able to include the required /dev devices, whereas it wouldn't be possible to include this on CC's stock bootloader without the source. So, doing something like accessing a ROM from an external flash drive isn't feasible because of these limitations? Basically, all that is possible with the current bootloader (of course, the insecure one which allows for unsigned code to run) is to add a few binaries to the stock CC ROM (things like adb, dropbear, etc), maybe add some access to those binaries through Web GUI, etc.
Am I on the right track? Is there anything you would add/correct? Thanks for the help. I'm trying to understand
tomg09 said:
Ok, so I'm doing some dinking around...I've looked into buildroot, and I think for the most part I understand what is going on. I also tried building from source, and it appears to have worked. So, from this poking around I have a few assumptions I've made and a few questions. Correct me if I'm wrong anywhere but.......
Basically, you've built a generic bootloader for the device using buildroot. This is not related at all to the stock CC bootloader (although maybe you borrowed a few drivers, etc). I would guess that the buildroot bootloader has just what you need to display a picture on the TV and do some basic file system operations, and I would also guess that the buildroot bootloader is missing a few features that the stock bootloader has - therefore, it wouldn't be possible to run a full-fledged ROM off of this bootloader. Am I right so far? If so, what is missing from the buildroot bootloader? Libraries? Binaries? No idea?
Also, to access something like USB storage, the buildroot bootloader is able to include the required /dev devices, whereas it wouldn't be possible to include this on CC's stock bootloader without the source. So, doing something like accessing a ROM from an external flash drive isn't feasible because of these limitations? Basically, all that is possible with the current bootloader (of course, the insecure one which allows for unsigned code to run) is to add a few binaries to the stock CC ROM (things like adb, dropbear, etc), maybe add some access to those binaries through Web GUI, etc.
Am I on the right track? Is there anything you would add/correct? Thanks for the help. I'm trying to understand
Click to expand...
Click to collapse
Buildroot does not let us build a bootloader, it lets us build a custom linux distribution that runs on the chromecast. The reason it is unable to do anything "graphical" minus the static image is due to licensing of the marvell GPU driver the chromecast uses. It is currently closed source, so it is unable to be compiled. We can use the blob from the stock OS, but ATM there is no need, and this can cause licensing issues.
Also, you can still access /dev and such on the stock OS. The big thing is the stock OS has usb input disabled at a kernel level, so it doesn't mount or detect any devices plugged in when the OS is running. This is circumvented though if you build and use your own custom kernel. For the features Eureka-ROM adds to the stock OS, we add those by using googles open source cross compiler for the device to build supported binaries.
Hmm...interesting. So, if I understand the booting process properly, upon power-on, a small bit of code called the bootloader is run, loading the kernel into memory (where, among other things, the graphics driver is located). From there, other components of the operating system are loaded on "top" of the kernel. So, it's not the bootloader that's rebuilt - but the kernel - with buildroot. Now, what sort of things would be possible if an open source alternative for the graphics driver were available (bear with me in the hypothetical), or even if one were to take the blob from the stock CC kernel? Turn CC into an android stick, complete with USB input device compatibility maybe?
Now on another note. I want to learn about cross-compiling. I am thinking of trying my hand at cross-compiling samba for the chromecast. Now if I understand the buildroot compiling process correctly, the right compiler for making chromecast-runnable binaries is compiled (or do you include it externally), and in theory, it should be possible to compile samba, right? I've been poking around the buildroot directory tree with the chromecast source superimposed over the top, and as of yet, I havent found the compiling binary (gcc, maybe?). I will look in a bit more depth. Once I find this, it should be as simple as specifying host and target architecture, putting the compiler for the CC in PATH, and compiling, right?
Thanks again for your help, and if you feel this isn't the appropriate place to post this, let me know.
tomg09 said:
Hmm...interesting. So, if I understand the booting process properly, upon power-on, a small bit of code called the bootloader is run, loading the kernel into memory (where, among other things, the graphics driver is located). From there, other components of the operating system are loaded on "top" of the kernel. So, it's not the bootloader that's rebuilt - but the kernel - with buildroot. Now, what sort of things would be possible if an open source alternative for the graphics driver were available (bear with me in the hypothetical), or even if one were to take the blob from the stock CC kernel? Turn CC into an android stick, complete with USB input device compatibility maybe?
Now on another note. I want to learn about cross-compiling. I am thinking of trying my hand at cross-compiling samba for the chromecast. Now if I understand the buildroot compiling process correctly, the right compiler for making chromecast-runnable binaries is compiled (or do you include it externally), and in theory, it should be possible to compile samba, right? I've been poking around the buildroot directory tree with the chromecast source superimposed over the top, and as of yet, I haven't found the compiling binary (gcc, maybe?). I will look in a bit more depth. Once I find this, it should be as simple as specifying host and target architecture, putting the compiler for the CC in PATH, and compiling, right?
Thanks again for your help, and if you feel this isn't the appropriate place to post this, let me know.
Click to expand...
Click to collapse
If we had a fully working open source graphics driver, lots could be accomplished. Full custom linux distributions could run x11 shells, we could have xbmc working with hardware decoding, and yes android would technically be possible if enough people wanted to put the time and effort into it. You can take the blob from the rom to do some of this, but things like hardware accelerated decoding will still not be possible due to the fact there is no documentation on how to use the blobs properly for things like that. (this is my understanding so I may be off on some small details, @tchebb can probably explain it more in depth.)
As for cross compiling, you just need to use googles prebuilt toolchain as the compile source.
Link: https://code.google.com/p/chromecast-mirrored-source/source/browse?repo=prebuilt
Mind if I ask why you want to compile samba? do you want to host media or files from a chromecast device? I actually have CIFS added to the eureka-kernel configs on our repo, so if you compile our kernel from source, you can mount samba shares on the chromecast device using the CLI.
ddggttff3 said:
As for cross compiling, you just need to use googles prebuilt toolchain as the compile source.
Link: https://code.google.com/p/chromecast-mirrored-source/source/browse?repo=prebuilt
Mind if I ask why you want to compile samba? do you want to host media or files from a chromecast device? I actually have CIFS added to the eureka-kernel configs on our repo, so if you compile our kernel from source, you can mount samba shares on the chromecast device using the CLI.
Click to expand...
Click to collapse
Cool. Thanks for the link. Basically, I'm just looking to learn about cross compiling for mobile devices. I figure samba seems easy enough. It was the first thing that came to mind. Any other ideas for something to cut my teeth on? Other binaries that would be well suited to CC, but are easy to compile?
tomg09 said:
Cool. Thanks for the link. Basically, I'm just looking to learn about cross compiling for mobile devices. I figure samba seems easy enough. It was the first thing that came to mind. Any other ideas for something to cut my teeth on? Other binaries that would be well suited to CC, but are easy to compile?
Click to expand...
Click to collapse
One more question...I've looked through the toolchain...the way it's set up is somewhat confusing. In the root directory of the toolchain: bin=gcc, g++, everything else I need to compile. What are the two folders entitled "arm-unknown-linux-gnueabi" and "target-arm-unknown-linux-gnueabi"? They seem to have relevant stuff (one has gcc, g++, etc except without the arm-unk... prefix, and other binaries which seem important). How do I use these/should I use these/why are they kept separate?
Thanks for the help.