Related
This might sound really odd... but I'm looking to -NOT- use my g1 as a phone... I want to uh... (shoot me if you must) want to remove Android, and install a very light ubuntu install or other gnu/linux derivative like DSL (which cannot be ported to armel probably) to my phone and use it as a mini mini computer...
my question to the DREAM community on XDA here is... can it be done... and for any reason I ever want to go back... do you think it'd be reversible?
My main reasoning is this... I have a nokia 5310, and I work a crappy produce job at a supermarket... I fear my G1 getting broken, and have not used it in the last 2 months. also, I'd be interested in learning how to work stuff out and try to get androided ported over to the new 3g Dash if that was possible, cause that phone looks very nice... IMHO though so... please criticism and responses of all kinds welcome to this question.
The closest I've seen is installing Debian with only terminal =/ sorry. You can look under development for more info.
well actually... with vncviewer you can uh... vnc to it and have x11 running with icewm or lxde
vnc viewer local host
I'm not pro at this. Sorry if my advice was bad. lol
No not bad... but good... thank you. I am looking for "ANY" information... and you fit the requisites. Thanks friend
The reason for running x11 and debian on top of android through vnc is that drivers for the g1 hardware aren't available. Unless you want to write these drivers yourself, I'd forget this one. By the time you get it working, your g1 will be fossilised.
I'd be willing to go and try to learn how to do it.
it'd be a fun project... i mean the thing is just sitting here... I mean... I could always perhaps make a completely stripped down version of android. I only want it to use Wi-Fi... and that's pretty much it... I just want it to be an MID
I want to make sure I understand the situation:
1) You have a cheaper phone so do not use the G1 for fear of damaging it.
2) Since you do not use the G1 you want to:
- tinker with it, most likely destroying it in the process if you succeed at anything.
- install a more conventional Linux distro on the phone, which will require at least some programming knowledge as well as intimate knowledge of Linux. If you want X then it as gone from challenge to an impressive feat.
and finally
3) You want to port android to the Dash 3G.
Your decision making process is a little questionable, but hopefully there is some reasoning I missed or you did not mention.
My advise to you would be: Please learn to walk before you attempt to fly.
A stripped down android would be more feasible. You would not have X, but you should be able to port quite a bit of commandline tools over, to include a more user friendly shell. Then you could try and cross compile X, which will take a lot of patience. If you manage to succeed though. from that point you could do a headless X session and attach to it vian VNC in much the same way as is currently done with debian. Alternatively you could try and port the G1 drivers over to the freerunner project and work from that direction, but this would be much more difficult.
It seems a terrible waste of time in my opinion but if you want to try, go for it. Personally I say sell the G1 and buy a nokia n810. It is a little larger but still small and is a mid.
If however you are set on this course I would suggest hanging out on the IRC channels and getting advice from the ROM cookers, Cyanogen in particular since he rebuilds the linux kernel for the G1, something you will be doing a lot of.
Well most birds learn to fly before they walk. And I think I will go down the trail of a custom Android build. I just wanted to know of it being possible to make it work.
I mainly refer to the fact I didn't want it to break ie the screen or the digitized I assume you mean the xda channel... ... so yes I will choose to jump into the pool before the water is full in it thank you for the advice and knowledge
Dear all,
Why don't we create some tutorial and advices for new developers who love X1 and Android but don't have much knowledge about Linux kernel, Gitorious...
I have cloned the Kernel repository but still don't know where to start with
I think many of us want to help too
Thanks for reading
Nice Step, i will be with you in this project and wish more devs will come with us.
Thanks
There are instructions on how to compile the kernel on the wiki:
http://wiki.xda-developers.com/inde...ngx20.thex20.Kernelx20.fromx20.thex20.Sources
I added instructions to get wifi working a week or so ago.
I too want to cook an Android dist from scratch, we will need to go back and figure out what has been done (i.e required modifications to fix the screen flip)
It will be very useful to have this info on the wiki as one may need to do it all again for future Android releases (i.e 2.2, 2.3)
edit: There is some technical info at http://www.htc-android.com/viewforum.php?f=5
I hope you can make goot work on it (fingercrossing)
I only have windows programming knowledge some C++ knowledge. So, is there anyone can tell me about the environment for develop a kernel, which knowledge do i need to focus on ^^ I still don't familiar with all those thing yet, I just want to help and i know i have to improve my knowledge for that
I like the idea of having a HOWTO, so that everyone can join in development. But i am not sure, that it is even possible. It is too big.
Downloading/cloning sourcecode, setting up build environment and cross-compiler and building a linux kernel is actually the easy part. A good guideline was postet by Tremere, and google is always your friend
Now the REAL WORK begins. Linux kernel source code is not very well documented. And the kovsky hardware specs are not documented at all. Well, some chips have been identified and datasheets where found, but many things are simple and painfull trial-and-error and may never work at all.
Then is the problem of finding the right source files in the source-tree. It helps looking into git-log and analyse changes made.
Then is the problem of data-structures and functions defined and used all over the source. There is no guide or something that explains what structure is used when and where. If you are lucky, you find some irc-chat-logs
Then is the problem that you can not debug, only add messages and stuff.
Then is the problem on how to approach, lets say GPS or Camera. You have to know about GPIOs, bus-systems, driver-models, ...
Then is the problem that one day has only 24 hours
Anyway, i would like to see, that you prove me wrong!
it's not about proving you're wrong, it's all about proving you CAN !!!! you've bring it far from the start, I dont think that the battery or camera can scare you!!!!
Vdelf I know you have worked alot on this, I put all my trust in you!!! I cant help you becaus I dont know how!!!
so I support you more than anybody because I really really want all this Xperoid to be fixed!!
vdelf said:
I like the idea of having a HOWTO, so that everyone can join in development. But i am not sure, that it is even possible. It is too big.
Downloading/cloning sourcecode, setting up build environment and cross-compiler and building a linux kernel is actually the easy part. A good guideline was postet by Tremere, and google is always your friend
Now the REAL WORK begins. Linux kernel source code is not very well documented. And the kovsky hardware specs are not documented at all. Well, some chips have been identified and datasheets where found, but many things are simple and painfull trial-and-error and may never work at all.
Then is the problem of finding the right source files in the source-tree. It helps looking into git-log and analyse changes made.
Then is the problem of data-structures and functions defined and used all over the source. There is no guide or something that explains what structure is used when and where. If you are lucky, you find some irc-chat-logs
Then is the problem that you can not debug, only add messages and stuff.
Then is the problem on how to approach, lets say GPS or Camera. You have to know about GPIOs, bus-systems, driver-models, ...
Then is the problem that one day has only 24 hours
Anyway, i would like to see, that you prove me wrong!
Click to expand...
Click to collapse
Thanks for your advices
if building the kernel is the easy part i'm a long looong way from being useful xD
probably my x86_64 bit fedora doesn't like me very much, got stuck with glibc dependencies errors or some wrong step at the arm installation... ¿could an x86 virtualized ubuntu save my day? as ive read some of the first testing was done in a debian distro, so ill try my luck with it.
damn... learning is fun... i just hope my Xperia doesn't learn how to burn while i'm playing with it xD
monovaldes said:
if building the kernel is the easy part i'm a long looong way from being useful xD
probably my x86_64 bit fedora doesn't like me very much, got stuck with glibc dependencies errors or some wrong step at the arm installation... ¿could an x86 virtualized ubuntu save my day? as ive read some of the first testing was done in a debian distro, so ill try my luck with it.
damn... learning is fun... i just hope my Xperia doesn't learn how to burn while i'm playing with it xD
Click to expand...
Click to collapse
A while ago, someone (can't remember exactly) posted a link to a linux vmware image for kovsky development -
you could start with that, although any linux system should be no problem, since there are no distro -specific
"packages" to use in this kernel development ( possibly except git )
Hell, I don't even use a VM - I have a slackware 12 install running on coLinux
under windows 7 and it works a treat!
angusmcb said:
A while ago, someone (can't remember exactly) posted a link to a linux vmware image for kovsky development -
you could start with that, although any linux system should be no problem, since there are no distro -specific
"packages" to use in this kernel development ( possibly except git )
Hell, I don't even use a VM - I have a slackware 12 install running on coLinux
under windows 7 and it works a treat!
Click to expand...
Click to collapse
well, that is a very nice alternative for users which don't like linux messing with their drives (not myself though xD)... thanks anyway
couldn't really tell which was the actual problem for me, i just got it working fine after installing an i686 distro on top of the x86_64 one
and... now comes the easy part, right? haha
will get onto studying
I've been installing Gentoo on my X1
http://wiki.xda-developers.com/index.php?pagename=Gentoo_on_HTC
The good thing about Gentoo is although the compilation takes forever (especially under an emulated ARM chroot!), it allows us to build a system from first principles and also build packages to our needs.
A lot of this has been googling for what people have done on the Xperia and other HTC devices, particularly with the Ubuntu ports.
Hopefully all the knowledge I've gained will make it real easy to get MeeGo running.
I ran across this about a week ago on one of the many other XDA forums (can't remember which one now).
It is an updated version of Odin3, version 1.30.
All the existing ROM's that I see packaged here that require Odin to flash are bundling Odin3 v1.00, and it seems people have tons of problems with that version. I myself have v1.00 stall/hang more often than it works when flashing.
I figured it'd be a good idea to have a Dev thread on this for several reasons.
1). For people to post feedback on it relative to Odin3 v1.00
2). To find out precisely where this came from, and whether or not it's the most current version.
Odin3 v1.30 works insanely better for me as it hasn't once hung on a flash for me......(yet), though given the differences we all experience in Windows versions (XP, 2003, Vista, 7, x86, x64, etc..) and differences in USB chipset hardware I figure it'd be a good thing to have some feedback and discussion about it's relative merits or lack thereof.
(i.e. Just because *I* think it's way better doesn't necessarily mean that it is)
I do know one thing for certain. If we can all discover a safer way to flash we'll all significantly reduce our chance of bricking our lovely phones.
(note: I figured it'd be a good idea to cross-post this here as it's gotten a bit buried over in Themes and Apps, and Odin3 is a Dev tool of sorts...)
Thx for posting this here
Thx I'll try it out when it comes time
Going to give this a try shortly. Will update on how it goes.
***
Used it to revert to stock then to flash the JI2 modem over FrankinTwiz w/KingKlick's kernel and worked flawlessly.
** Using the drivers found in the Dev section w/Win7 64
I was having problems flashing Eugenes modem.bin through odin. Froze 3 times nearly bricking phone.
I was on win 7, 64bit.
Hope this new version helps
Sent from my SGH-T959 using Tapatalk
I have been using this since this weekend. I have used it to flash my phone 20 times or so. It works just fine. However, I never had a problem with v1.0, so YMMV.
By the way, what are the DLL files in there used for? I just deleted them.
Thanks for this, added to the bible under useful links.
in regards to 1.3, yes, it works, however 1.0 is still the most stable.
krylon360 said:
in regards to 1.3, yes, it works, however 1.0 is still the most stable.
Click to expand...
Click to collapse
I've found the exact opposite to be true. But I don't mention that to be contentious. One unique aspect perhaps of my Windows machines is they're all running x64 versions of Windows (1 Vista box, 2 "7" boxes).
I easily get 70 plus percent fail to flash rates with v1.00 (meaning the flash stalls, almost always at the beginning of the flash), but this may merely be a symptom of the Samsung x64 drivers playing nicer with 1.30 and not Odin3 at all.
So far out of a dozen and a half or so flashes using 1.30, I've had zero failures that resulted in me having to re-engage download mode or face the dreaded "OMGIBRICKEDMYPHONE" screen. I did have one FAIL notice once, but Odin didn't lock up like it always does for me with v1.00, and all it took was disconnecting/reconnecting the phone and clicking START again and all was well.
The plot thickens.
I have flashed with 1.0 probably 40 or so times, and flashed with 1.3 probably 15 to 20 times, and I have never had a fail on either.
I would say that an Odin fail is directly tied to the stability of your computer. I would run a spy-ware check and/or check for driver problems.
t1n0m3n said:
I have flashed with 1.0 probably 40 or so times, and flashed with 1.3 probably 15 to 20 times, and I have never had a fail on either.
I would say that an Odin fail is directly tied to the stability of your computer. I would run a spy-ware check and/or check for driver problems.
Click to expand...
Click to collapse
If it weren't happening consistently on three spyware free x64 machines, running Samsung's WHQL Certified x64 drivers, I'd tend to agree with you.
And it doesn't take a lot of walking through brick threads here and in the other dev forums on XDA to see it's quite the common occurrence. But like your experience it does seem that people have either zero problems or nothing but problems, with little middle ground.
And don't take this the wrong way, or as me grandstanding, but I built my first computer 28 years ago...with a soldering iron. I've worked professionally in the industry for two decades. It's only Android that's relatively new to me. I've already thought through the likelihood of spyware and other possible resource conflicts and came up empty.
At this point I'm leaning towards this being an x64 environment issue exacerbating the already well known timing issues with Odin3, but that's still just anecdotal experience at play here. Given how wonky (and useless) WHQL certification can be, it could also be the drivers. Tempted to pull one of my old dual core x86 boxes out of mothballs to try some 32bit action and see if things change.
At the end of the day I'm just trying to discern what's the best Odin3 to be using. It was updated for a reason one would think, but it's hard enough finding useful info about Odin3 period.
masterotaku said:
If it weren't happening consistently on three spyware free x64 machines, running Samsung's WHQL Certified x64 drivers, I'd tend to agree with you.
And it doesn't take a lot of walking through brick threads here and in the other dev forums on XDA to see it's quite the common occurrence. But like your experience it does seem that people have either zero problems or nothing but problems, with little middle ground.
And don't take this the wrong way, or as me grandstanding, but I built my first computer 28 years ago...with a soldering iron. I've worked professionally in the industry for two decades. It's only Android that's relatively new to me. I've already thought through the likelihood of spyware and other possible resource conflicts and came up empty.
At this point I'm leaning towards this being an x64 environment issue exacerbating the already well known timing issues with Odin3, but that's still just anecdotal experience at play here. Given how wonky (and useless) WHQL certification can be, it could also be the drivers. Tempted to pull one of my old dual core x86 boxes out of mothballs to try some 32bit action and see if things change.
At the end of the day I'm just trying to discern what's the best Odin3 to be using. It was updated for a reason one would think, but it's hard enough finding useful info about Odin3 period.
Click to expand...
Click to collapse
Just fyi guys, im running x86 7 using ODIN 1.0 and still experienced about a 50% failure rate. Just food for thought. However as of lately I'm either getting better at hitting start or ODIN has been in better spirits. FWIW I will try ODIN 1.3 in my future flashes to see if there is any difference.
I've found that when you start odin v1.0 and when it finds your phone you have to work fast like 10 sec, put the files in and then hit start and it works well for me I'm on win 7 x64.
Vista x64, I never installed the Samsung WHQL drivers at all. I used the drivers that come with the Android SDK, using Odin 1.0, I have only had one fail, and it was my fault, i accidentally pulled the USB plug, lord knows how many flash's I've done through odin, been using it since theres been custom ROMs available.
I'm going to agree with its people's systems that affect Odin. Anyone who has done any kind of work on Windows knows that it's driver system for devices, while nice and simple in theory, is nowhere near as convenient when it comes to practice. Not too mention the hardware aspect of USB controller chips or North/Southbridges on the motherboards having some kind of high frequency interference, bad HAL level drivers, or just a bad chip creating data throughput or connection consistency problems... yet another reason to go Mac or Linux.
angryPirate12 said:
Vista x64, I never installed the Samsung WHQL drivers at all. I used the drivers that come with the Android SDK, using Odin 1.0, I have only had one fail, and it was my fault, i accidentally pulled the USB plug, lord knows how many flash's I've done through odin, been using it since theres been custom ROMs available.
I'm going to agree with its people's systems that affect Odin. Anyone who has done any kind of work on Windows knows that it's driver system for devices, while nice and simple in theory, is nowhere near as convenient when it comes to practice. Not too mention the hardware aspect of USB controller chips or North/Southbridges on the motherboards having some kind of high frequency interference, bad HAL level drivers, or just a bad chip creating data throughput or connection consistency problems... yet another reason to go Mac or Linux.
Click to expand...
Click to collapse
I guess the only problem with that take, is that you can count the reliable Linux and Mac firmware tools for Android on the fingers of one foot. There is one project running that I've been following. It's an early alpha and buggy as a roach motel at this stage (not disparaging the authors....it's the nature of being an alpha).
Coming up to speed on all of this out of necessity and curiosity I'm still going to lean towards Odin3 v1.0 itself as the primary culprit for a few obvious reasons. And even if it works reliably for many that still doesn't mean it is issue free. And with me even saying that I also acknowledge that the phones themselves play a significant role.
XDA Dev forums are a useful resource, and it doesn't take much digging around the other Android dev forums to see that timing issues between different model phones and Odin3 v1.0 are a significant issue. The subtle differences in the different Android phones themselves is as much an issue as the firmware tool, this much is painfully apparent. One gets motivated to do this sort of digging when one thinks they've bricked there phone!
There's also the obvious question. Why was Odin3 updated to a newer version? Probably to fix something....
At the end of the day I'm not trying to be divisive or argumentative here. I'm just trying to reason my way through this as best I can. At the very least we have another software tool at our disposal, one that at least anecdotally is worth using should you have issues with the older version of the software.
Out of curiosity I did actually un-mothball an old XP SP2 32bit box I'd been using as a dedicated StepMania system in my kids room (till they turned into teenagers and stopped caring about DDR clones), and Odin3 v1.0 works far better on that old hardware. Version 1.30 does also, but if your comparing the two on a system where v1.0 is already working reliably...well your missing the point.
Having said that, I know I'm in a unique position. I have 4 desktop systems, a laptop, a 3 Terabyte NAS, and a Home Theater PC, and a house I wired with Gigabit Ethernet because I roll like that. I also have spare PC's in storage here and there because I work on them and networks for a living. I have easy options many people who simply want to tinker with their shiny new phones do not.
More tools and less bricks = good.
thanks for this
masterotaku said:
I guess the only problem with that take, is that you can count the reliable Linux and Mac firmware tools for Android on the fingers of one foot. There is one project running that I've been following. It's an early alpha and buggy as a roach motel at this stage (not disparaging the authors....it's the nature of being an alpha).
Coming up to speed on all of this out of necessity and curiosity I'm still going to lean towards Odin3 v1.0 itself as the primary culprit for a few obvious reasons. And even if it works reliably for many that still doesn't mean it is issue free. And with me even saying that I also acknowledge that the phones themselves play a significant role.
XDA Dev forums are a useful resource, and it doesn't take much digging around the other Android dev forums to see that timing issues between different model phones and Odin3 v1.0 are a significant issue. The subtle differences in the different Android phones themselves is as much an issue as the firmware tool, this much is painfully apparent. One gets motivated to do this sort of digging when one thinks they've bricked there phone!
There's also the obvious question. Why was Odin3 updated to a newer version? Probably to fix something....
At the end of the day I'm not trying to be divisive or argumentative here. I'm just trying to reason my way through this as best I can. At the very least we have another software tool at our disposal, one that at least anecdotally is worth using should you have issues with the older version of the software.
Out of curiosity I did actually un-mothball an old XP SP2 32bit box I'd been using as a dedicated StepMania system in my kids room (till they turned into teenagers and stopped caring about DDR clones), and Odin3 v1.0 works far better on that old hardware. Version 1.30 does also, but if your comparing the two on a system where v1.0 is already working reliably...well your missing the point.
Having said that, I know I'm in a unique position. I have 4 desktop systems, a laptop, a 3 Terabyte NAS, and a Home Theater PC, and a house I wired with Gigabit Ethernet because I roll like that. I also have spare PC's in storage here and there because I work on them and networks for a living. I have easy options many people who simply want to tinker with their shiny new phones do not.
More tools and less bricks = good.
Click to expand...
Click to collapse
Well said.
ok this might seem like a noob question but i'm a linux guy, haven't used microsoft in forever so when i downloaded the .rar for odin and try to open it , it says i have to choose a program to open it with. What do i do to actually open odin so i can use it?
You need an unarchiving program to uncompress a .rar usually winrar though 7zip will work as well.
Isn't there an even newer version of Odin, something like 1.4 or 1.5? I swear I thought I saw a newer version somewhere.
Edit:
Found it, it is v1.52
http://forum.xda-developers.com/showpost.php?p=8780525&postcount=131
Hey guys,
Does anyone know if there is a way to compile source code right on the device? I remember some people asking for this way back in the day but it wasn't really practical on such small devices. With a xoom and a bt keyboard though, it's almost as easy as using a regular laptop. I know there are a few different compilers for the iphone(c, c++, java) so I'm sure it is possible. I haven't seen anything but perhaps I'm just looking in the wrong places.
Thanks,
Samuel Maskell
so I'll take that as a no..
I'd love to work on this but I wouldn't really know where to start
I do have some programming experience
but I don't really know anything about how compilers are made
besides a basic overview we did in my computer architecture course
In theory, if you rooted and installed ubuntu, you could install the dev toolchain/eclipse. But it's crappy enough on 2gb of memory, 1gb on the xoom would be ridiculous.
I installed Ubuntu/eclipse on my cr48. It's barely usable.
Developing for android requires a desktop.
That being said, sometimes I make small code changes and build from the cli on my cr48.
smaskell said:
so I'll take that as a no..
I'd love to work on this but I wouldn't really know where to start
I do have some programming experience
but I don't really know anything about how compilers are made
besides a basic overview we did in my computer architecture course
Click to expand...
Click to collapse
Yeah, I really don't see eclipse running very well on a xoom
It doesn't even run that well on my desktop with 4gb of ram and 3.2ghz 6-core processor
like you said, developing for android requires a desktop
but I wasn't really thinking about making android apps on the xoom(although that would be awesome)
I'm mostly just thinking of simple cli programs
something like this would be great
http://www.youtube.com/watch?v=-BDylxLzUEM
Edit: skip to about 1 minute in. the first part is just him writing the code on his desktop and then copying the source file over to his iphone. I don't see any reason why he couldn't have written the code on his iphone though
Your best bet would be to setup a box (with your compiler) somewhere and SSH in. Edit file locally, push to box, SSH in, compile, pull results back.
If you don't have a *nix box handy, you can try something like Slicehost.
that's actually not a bad plan
I use my school's computers to compile things through ssh sometimes anyways
still, I think would be pretty cool to compile right on the device
if it can be done for iphone, it can (and should) be done for android
smaskell said:
that's actually not a bad plan
I use my school's computers to compile things through ssh sometimes anyways
still, I think would be pretty cool to compile right on the device
if it can be done for iphone, it can (and should) be done for android
Click to expand...
Click to collapse
So you can compile applications using the NDK, but you still have to be on a non-Xoom box to do this.
In theory, it should be possible for you to cross-compile gcc for arm and push that to the xoom to do your compiling there. This is a bit more complicated, however, as you can't just specify --ARCH=arm to gcc's ./configure script.
This thread is in regard to the unofficial development of the Cyangonmod 7.1 for the Dell Streak 7. Absoluetelly nothing works. So a lot of work needs to be done.
First git the entire Cyangonmod 7.1 tree from them, and then drop these files into the device/dell/streak7 folder
http://www.mediafire.com/?q1w57v797u9p953
This rips the files from a stock Android 2.2 image, so you need to make sure that you are at a stock 2.2 image. My next goal is to upgrade to a stock HC and try making the scripts for that and see if it gets me closer.
As of right now, it boots "Dell" logo, then goes to the black screen with "ANDROID" on it, and that is as far as I can get it.
Look at the files, and let me know what changes I should make and in what script.
Driver wise, I believe you might be better off trying to backport the stock HC drivers.
GB <-> HC/ICS are more similar then eclair/froyo <-> GB in respect to drivers.
That's the reason it took half a year to hack together GB for the s5 and why it only tooks weeks to hack froyo from eclair
Rumor has it that dell attempted to port GB to the s7 before giving up, they lost a couple months at Q12011 doing that and likely scrapped everything, then they restarted on porting 3.1 then moved to 3.2 and that's why the summer was pretty quiet and why the S5 prob got no updates all summer
I dont have any substantial evidence to back any of it up, but the timelines all line up far too nicely, dell prob has only a single team for the s5/7/venue, the s10 is done by a different company.
Yeah, I am thinking I am going to try that direction next. Got a list of all the libs, now just need to re-write the scripts.
CM 7.1, Is that gonna be Honeycomb based?
Mysticales said:
CM 7.1, Is that gonna be Honeycomb based?
Click to expand...
Click to collapse
CM7 is Gingerbread...
Nice, gonna check this out once it arrives
You should have killed me, when you had the chance
Mysticales said:
CM 7.1, Is that gonna be Honeycomb based?
Click to expand...
Click to collapse
Cm never did honeycomb because google never released source
I've pulled a list of all the files I need to work with, now will be the time consuming part of checking the scripts to see if they are already listed and then adding the ones that are not listed.
Not to sound negative, but with Dell having released the official HC build and so, would people really use Gingerbread on their tablet?
Mysticales said:
Not to sound negative, but with Dell having released the official HC build and so, would people really use Gingerbread on their tablet?
Click to expand...
Click to collapse
I'm doing this for the same reason any hacker does anything.
For the sheer f*** of doing it.
Currently I am working on building a tegra2 2.6.35 gingerbread kernel.
Hypothetically, if he can get GB to actually work (and by work i mean functional with all the hardware functioning properly) he'll be a dozen steps closer to being able to port over to ICS.
I cant say that it would ultimately lead to ICS, but the documentation generated would help a lot (assuming it's all documented lol)
Documentation......I knew I was forgetting something.
Well, the easy steps right now will be as soon as I get it to boot using CM7.1, i will figure out how to git it up to Cyangonmod and have them review it. Currently I got the information I need to port to CM7.1, its just a matter of plugging that information in. The problem I am wondering is that the current kernel in their directory, I have no idea who built it or what it contains.
Building a working kernel is very tough since I have never done it before. Nvidia does have a Tegra 2 Gingerbread image built and a Tegra 2 Gingerbread kernel build available, its just a matter of me figuring out how to get them to work because I have never done this before.
So this usually consists of me doing the following
1. Run 'make -j4'
2. Get error
3. Research error
4. Attempt some fixes
5. Repeat step 1-4
The s7 is really similar the nvidia's vendeta reference board, and I think that's what dell tried to base their GB attempt off of.
(Also what cpu are you using? -j4 is small unless you're compiling on a laptop or something)
TheManii said:
The s7 is really similar the nvidia's vendeta reference board, and I think that's what dell tried to base their GB attempt off of.
(Also what cpu are you using? -j4 is small unless you're compiling on a laptop or something)
Click to expand...
Click to collapse
Actually it is the ventana (tegra 2 250) board as far as I can tell.
I've got a couple files that say 'init.ventana.rc' on them, plus 'init.streak7.rc'. These were pulled from the ~/ directory
I am in contact with Nvidia in regard to some questions I have but haven't heard from them in a week, they are probably slammed with questions all the time.
Just wanted to say, that nice to see someone interested and capable in doing something for streak7. keep up mate
Sent from my Dell Streak 7 using Tapatalk
giveen said:
I'm doing this for the same reason any hacker does anything.
For the sheer f*** of doing it.
Currently I am working on building a tegra2 2.6.35 gingerbread kernel.
Click to expand...
Click to collapse
Oh dont get me wrong, Its cool that you do that, its the same reason I mess around. I guess its just with Steve working on Honeystreak R8+ and ICS. Just was a wonder how many would use GB.
Too bad one can dual boot. Like have HC on Nand, and boot into a diff Android build on SD. Why would this be cool? Cause honestly.. sometimes HC can suck, least when it comes to mass storage mode. I could see myself using a dual boot at times to boot in GB with my streak 7. =)
the dell streak 7 has a Nvidia Harmony broad also could you not use cm7 Advent Vega as a base
Yes, I have looked into it, and in fact I've stolen lots of information from that build and put into into the build system I am working on.
So before I go on a holiday break, a bit of an update.
Bad News:
I started all over and started working my scripts. Currently its having a problem with my 'recovery.fstab'. Its saying its not there, but I FREAKIN KNOW ITS THERE!!!!!! and its written correctly in my scripts.
Good News:
Two successfull zImages built, one based off of Nvidia's 2.3 stuff combined with DJ_Steve's configuration, probably won't boot because its missing some drivers.
And the other is a DJ_Steve's HC kernel, but I asked him to check over some errors I got, even though it successfully built.
The reason why I built new zImages is because I couldnt' verify who created the kernel file in the github. The label on the folder was 'koush' but I asked him and he said he did not build it, so I have no idea who started the project, hence why I decided to build a new one.
So AFTER I figure out the recovery.fstab error, I will try out both of my new kernels and see which one does the job.
After I take a break.
I got several errors out of the way but....
The CM7 build is on hold, indefinitely. I am currently helping out with the ICS build and it takes a lot of my time and also taking care of my pregnant wife and two children. With the release of ICS, I might not even bother with it after this. And if I do, it will be a casual effort.
I see working on the ICS build as the assistant to a very talented ROM developer a a huge learning process and it is actually helping me become much better at making ROM's.