linux-tegra-nv-3.4 Nvidia tegra3 kernel branch for grouper - Nexus 7 Developer Discussion [Developers Only]

linux-tegra-nv-3.4 Nvidia tegra3 kernel branch for grouper - Nexus 7 Developer Discussion [Developers Only]

Title says it all.
Basically, I'm gonna need help on this, I don't know how much, but I will need it. I'm pushing all my changes to my GitHub repo regularly, but so far I'm simply trying to get the grouper board files set up. Here's how I'm going about that:
cherry-pick Google's commits which added grouper support to 3.1.10 kernel
Fix conflicts
Compile
Inspect errors
Update grouper board files against kai board files commits from here (from the k3.3: kai: Updates to board files commit onwards
Recompile
etc.
Beyond this I'm not really too knowledgeable in al the device tree stuff. Sure, I've read up on alot of stuff, but have no practical experience. Therefore once I've got the board files how I think they should be, if things still don't work then I will need help. Luckily, it looks like the kai board and grouper are extremely similar. So with any luck it'll work without too much hassle.
Beyond this stuff will probably be broken anyway, so I will need help with that.
Feel free to discuss anything relevant, and to offer anything you think might be useful. There are some real devs here who would make a big impact on this, as there's only so much blind tinkering I can do.
Thanks

Here's an updated link https://github.com/enssorcel/Grouper-3.4
The first on doesn't seem to be working

USBhost said:
Here's an updated link https://github.com/enssorcel/Grouper-3.4
The first on doesn't seem to be working
Click to expand...
Click to collapse
Woops sorry, I linked to my testing branch so I had deleted it already. For whoever's following this, you want to go here to see what I've merged into the master branch i.e. what I've fixed, and click the branch pulldown and go here to see what we've been working on, the names are self-explanatory.
Thanks to @sgt. meow 's help we've made quite a bit of progress, we've fixed the errors for the majority of the grouper files so we're getting close to a successful compilation. Beyond that, who knows.
EDIT: Just fixed board-grouper-power.c. sensors will be the next focus, hopefully fixed soon.
EDIT1: All board files are fixed! (well, the compilation errors are gone, but we don't know if they work yet)

Well we've got a zImage built, but I don't think it boots. It'd be helpful if you lot could test to make sure though, just flash in recovery: http://d-h.st/7h3
I don't suppose anyone has a serial cable and access to UART or anything similar?

HTCDreamOn said:
Well we've got a zImage built, but I don't think it boots. It'd be helpful if you lot could test to make sure though, just flash in recovery: http://d-h.st/7h3
I don't suppose anyone has a serial cable and access to UART or anything similar?
Click to expand...
Click to collapse
have you used a grouper boot.img for repacking zImage?

HTCDreamOn said:
Well we've got a zImage built, but I don't think it boots. It'd be helpful if you lot could test to make sure though, just flash in recovery: http://d-h.st/7h3
I don't suppose anyone has a serial cable and access to UART or anything similar?
Click to expand...
Click to collapse
Yeah, it doesn't boot on my tilapia. But I'm glad you use agnostic-kernel

lupohirp said:
have you used a grouper boot.img for repacking zImage?
Click to expand...
Click to collapse
Of course I used the stock boot.img from 4.4.3 unpacked it with unmkbootimg, replaced the zImage, repacked with mkbootimg then replace the boot.img in the agnostic kernel with the new one.
frantisek.nesveda said:
Yeah, it doesn't boot on my tilapia. But I'm glad you use agnostic-kernel
Click to expand...
Click to collapse
I don't know if it would boot on tilapia anyway, I think they use the same board files so maybe. Yeah its especially awesome for stuff like this cause I don't need to worry about making a different version for everyone who wants to test it on different file systems :victory: that said it'd be great if someone can test this on ext4 to make sure.
So can anyone help? Even it you can just be a guinea pig with a serial cable

Will test now
Edit: stuck on Google screen
Edit: I am All-F2FS Carbon ROM

USBhost said:
Will test now
Edit: stuck on Google screen
Edit: I am All-F2FS Carbon ROM
Click to expand...
Click to collapse
This is either because we have more work to do to get it booting, or because the defconfig is being stupid, I remember I couldn't get franco kernel to boot unless I used cyanogenmod's defconfig although of course that's for 3.1.10 so that's not really an option.

HTCDreamOn said:
This is either because we have more work to do to get it booting, or because the defconfig is being stupid, I remember I couldn't get franco kernel to boot unless I used cyanogenmod's defconfig although of course that's for 3.1.10 so that's not really an option.
Click to expand...
Click to collapse
you can use 3.1 kernel config. BTW i saw your config and you don't have added F2FS drivers, so on F2FS roms will not boot. We must test on ext4 rom......otherwise seems a good base for start.

HTCDreamOn said:
It'd be helpful if you lot could test to make sure though, just flash in recovery: http://d-h.st/7h3
Click to expand...
Click to collapse
Hangs at Google logo
Grouper, SlimKat 4.4.4 build 5.2, (all ext4).

lupohirp said:
you can use 3.1 kernel config. BTW i saw your config and you don't have added F2FS drivers, so on F2FS roms will not boot. We must test on ext4 rom......otherwise seems a good base for start.
Click to expand...
Click to collapse
OK I'll try cyanogen's defconfig and see what happens. Will I have to regen for 3.4 or can I just use it straight off? I've added f2fs support in my f2fs-testing branch and enabled it now, thanks for the tip
Lar5 said:
Hangs at Google logo
Grouper, SlimKat 4.4.4 build 5.2, (all ext4).
Click to expand...
Click to collapse
Thanks, now we know it'd definitely not an fs problem :good:

Don't give up your doing great
Remember I'm here to help test and i may even reformat my nexus 7 back to
All-EXT4 to help test

USBhost said:
Don't give up your doing great
Remember I'm here to help test and i may even reformat my nexus 7 back to
All-EXT4 to help test
Click to expand...
Click to collapse
Don't worry, not giving up, just thinking. We Ideally need someone with a serial cable because we're kinda stuck without debuuging unless we can find someone who can spot the problems from the code.

HTCDreamOn said:
Don't worry, not giving up, just thinking. We Ideally need someone with a serial cable because we're kinda stuck without debuuging unless we can find someone who can spot the problems from the code.
Click to expand...
Click to collapse
where can one get such a cable

USBhost said:
where can one get such a cable
Click to expand...
Click to collapse
You need to make one, basically the N7 has a UART port in the headphone jack but you need to make an adapter: http://blog.accuvant.com/jduckandryan/building-a-nexus-4-uart-debug-cable/ it's widely assumed the process is the same for all Nexus devices but I haven't found anyone testing it with the N7 do there's no confirming it would work. Hopefully if it didn't then it'd must be a case of enabling stuff in the kernel (there may have been some commits disabling it for release). If you wanna help out then this would be invaluable though

HTCDreamOn said:
You need to make one, basically the N7 has a UART port in the headphone jack but you need to make an adapter: http://blog.accuvant.com/jduckandryan/building-a-nexus-4-uart-debug-cable/ it's widely assumed the process is the same for all Nexus devices but I haven't found anyone testing it with the N7 do there's no confirming it would work. Hopefully if it didn't then it'd must be a case of enabling stuff in the kernel (there may have been some commits disabling it for release). If you wanna help out then this would be invaluable though
Click to expand...
Click to collapse
interesting I'll see what I can do
Not making any promises
Edit: it shouldn't be too hard to make
Just need $17.17 to make it
Will see

I'm not sure you'll have much luck with the UART cable. An RD (now retired) got his device to recognise the UART board, but failed to receive any output.

As you all probably know, even after updating the board files against KAI from the nvidia source, we couldn't get it to boot. So we applied a few commits from Google, and guess what, still doesn't boot. If anyone wants to join in the chat at hangouts, drop in your gmail here. We need all the help we can get.

Maybe the kernel boots far enough to leave some traces in last_kmsg. The only problem is that the contents are lost if the device is powered off. If you're lucky the contents survive a short time without power. But usually if the kernel boots far enough it will panic and restart itself.

Related

[2ndboot][04-10-2012] Custom kernel... this time with radio

It seems that finally I was able to boot custom kernel with working radio
It's not very stable yet(it stops/crashes at bootanimation quite frequently), and is quite laggy just after boot, but once it boots it seems to be almost usable. Wifi works, sdcard also. Haven't checked bluetooth.
Credits for this goes to:
* milestone1 devs... for sharing 2ndboot source code and providing so much info regarding milestone1/2 phones
* Motorola ... for providing source code(not fully working, but was a great help anyway) for enabling UART over micro usb for debugging purposes(without this I woudn't make any progress)
* tezet... for making quite good roms used by 2ndboot
If you wish to try it(BEWARE THAT IT MIGHT BRICK YOUR PHONE, SO DON'T SAY THAT I HAVEN'T WARNED YOU ), then do as follows:
1. Install tezet's JB10(if you don't have one already).
2. extract 2ndboot.tar(attached) into /data folder, check that /data/2ndboot/hbootuser file has execute permissions.
3. overwrite /system/bootmenu/script/2nd-boot.sh(DON'T TOUCH 2nd-init.sh!!!) with the one from tar(2nd-boot.sh.tar) and check it has execute permissions.
4. reboot into bootmenu
5. change the default boot method to 2ndboot
6. Restart your phone. Most likely it will crash few times at bootlogo, but be patiant, it finally should boot
7. If you wish to get back to 2nd-init, then enter bootmenu again and change default boot method back to 2nd-init, or manually boot 2nd-init
Click to expand...
Click to collapse
Please let me know if someone actually run it and was able to boot(so that to find out if I haven't forgot to include some more files(see changelog for 03.10.2012)
KNOWN LIMITATIONS
Boots very sloooowly
Its' quite laggy just after boot.
GPS does not seem to work yet
Click to expand...
Click to collapse
CHANGELOG
01.10.2012 - corrected battery problems(thanks to Quarx and kabaldan)
03.10.2012 - corrected ramdisk(previous one was calling some script which I forgot to attach to this post, new one has this script inside), so that now you should be able to boot it; updated instructions how to install it; enabled TLS in the kernel(thanks to kabaldan)
04.10.2012 - touch driver updated, now should work with lastest JB(thanks to Eleanor_Ir, Quarx), adb fixed(I hope, stability fix(thanks to Quarx)
Click to expand...
Click to collapse
NOTES for devs
In milestone2(as probably in many others UMTS phones made by Motorola) the BP is somehow very sensible and does not like to be disconnected/reenumerated. The main goal of this 2ndboot is then to not allow it to be disconnected. To do this, in the new kernel I've skipped a few resets(EHCI, TLL, individual port resets), and instead of enumerating BP, I've used the hardcoded usb device address(which for milestone2 seems to be equal to 2).
I attach patch(radio.patch) with the changes I've done to the kernel sources from here:
http://sourceforge.net/projects/milestone.motorola/files/MILS2_U6_4.1-22/
This seems to work(sometime) for both milestone2 and defy.
For other motorola phones:
1. First of all, check with lsusb what's the address and vendor/product id of your BP(for milestone2 it's 0x22b8 and 0x40e6).
2. If the BP usb device address is 2, then just apply the patch(probably it will need some small modifications), and check if it works.
3. If the BP usb device address is not 2, then edit usb/core/hub.c function hub_port_init(providing that it's there for your kernel), and replace 0x02 in the place where usb_control_msg to get descriptors is sent with address of your device
If it does not work, then you can try the following:
Create a procedure to send usb GetDescriptors request using omap3 ehci registers, and call it at different boot stages/usb initialization stages to find out how long the radio remains attached, and comment/change appropriate fragments of kernel code, to preserve this until usb port is initialized. If you wish, I can share the procedure I've written(in the patch file this is that czecho_get_descriptors called in many places) for milestone2, but it probably would need some modification to work with your device).
2ndboot module sources are here:
https://github.com/czechop/2ndboot

Wow, thats perfect This could bring M2 development to another level.
Holding thumbs up and keep it up!

Great news! Thx for your work. I've just bought an OTG cable to start playing with kernel stuff and here's a surprise

Fabulous! That means it starts a new era in the development of our MS2 Roms!

Wonderful job man

Brilliant
Sent from my A953 using Tapatalk 2

I'm gonna try on the Motorola Bravo as soon as PA is done uploading. Hopefully this'll work on Froyo kernels as well :fingers-crossed:
What kernel are you using? A recompiled MS2 GB kernel unmodified?
Awesome job man. This could possibly be the start of a new generation of roms for our common platform if this works on other similar phones like the Defy\Bravo. Only time will tell .

Well good work OP, can this be implemented on other Moto phones like Defy?

Great work !
I see that your work is based on Moto's Linux kernel (2.6 branch as far as I remember...)
Any hope of using another kernel source one day ?

Great News!, Thanks
Waiting for source code

Wow! Tezet and Quarx on the same thread?! I feel like up on the Mount Olypmus lol
Great job, man!...been following your work from General section.
P.S. add Kabaldan to the list Clash of the Moto Titans

skeevy420 said:
I'm gonna try on the Motorola Bravo as soon as PA is done uploading. Hopefully this'll work on Froyo kernels as well :fingers-crossed:
What kernel are you using? A recompiled MS2 GB kernel unmodified?
Awesome job man. This could possibly be the start of a new generation of roms for our common platform if this works on other similar phones like the Defy\Bravo. Only time will tell .
Click to expand...
Click to collapse
Yes, I use MS2 GB U6_4.1-22(http://sourceforge.net/projects/milestone.motorola/files/MILS2_U6_4.1-22/) kernel... but with modified usb host driver.

nidhish91 said:
Well good work OP, can this be implemented on other Moto phones like Defy?
Click to expand...
Click to collapse
I think it can be.
With defy it probably should be easy, as I've seen there was 2ndboot(without radio) already build for it, so most likely only new kernel would need some tuning

czechop said:
I think it can be.
With defy it probably should be easy, as I've seen there was 2ndboot(without radio) already build for it, so most likely only new kernel would need some tuning
Click to expand...
Click to collapse
XT720 users also waiting for instructions for new kernel tuning, cause we have working 2ndboot without radio. =)

boorce.com said:
Great work !
I see that your work is based on Moto's Linux kernel (2.6 branch as far as I remember...)
Any hope of using another kernel source one day ?
Click to expand...
Click to collapse
It should be easy to apply some(perhaps most) 2.6.32 upstream patches to the motorola kernel sources.
Don't know however how difficult it would be to start from another kernel version. Don't know also how motorola proprietary modules/libs would behave with newever kernel version. But, as they say, impossible is nothing

czechop said:
I think it can be.
With defy it probably should be easy, as I've seen there was 2ndboot(without radio) already build for it, so most likely only new kernel would need some tuning
Click to expand...
Click to collapse
In kernel only modified usb driver or some more changes for boot?

fjfalcon said:
XT720 users also waiting for instructions for new kernel tuning, cause we have working 2ndboot without radio. =)
Click to expand...
Click to collapse
Will share source code probably early next week(currently am at work, and during weekend most likely won't be sober enough

Quarx said:
In kernel only modified usb driver or some more changes for boot?
Click to expand...
Click to collapse
In 2ndboot module I've added code to disable lcd before starting new kernel(otherwise new kernel could not initialise properly dss), and in new kernel I've only modified usb driver(perhaps more things will need to be modified, as I'm facing problem with BATTD sayins something about power ic fail, BTW, does someone know what that could mean?), so that it skips restaring EHCI, TLL and don't start enumeration, but just used the old usb device address(assigned by the original kernel), which for M2 is always 2(at least during my tests).

I2c Fail can be caused by wrong permissions for /dev/cpp*
I tried your prebuilt binaries on defy http://pastebin.com/jKjQ2ykn
Black screen + buttons lights and reboot after ~20sec

Quarx said:
I2c Fail can be caused by wrong permissions for /dev/cpp*
I tried your prebuilt binaries on defy http://pastebin.com/jKjQ2ykn
Black screen + buttons lights and reboot after ~20sec
Click to expand...
Click to collapse
Thanks for hint regarding permissions...will check that
Regarding prebuilt binaries on defy, hard to say what's wrong(not sure how much the phones differ). Anyway, you probably would need to use devtree from your device. Also you could unpack ramdisk, and check the init.*.rc scripts if they are ok(e.g. I mount system partion using p21, not sure if that's the same for defy, and staff like that).

Tubuntu - questions and issues

This should probably be posted here, but I sadly don't have the required 10 posts to do so.
There's one issue that I noticed that is actual in 0.2.2alpha. When you choose to flash Jhinta 3.1x kernel and not 2.6x kernel, it is still linux.img that is being flashed, instead of jlinux.img.
Also there's one question (or rather a feature request). Once you have dual boot up and running it would be nice to be able to flash linux rootfs only (ubuntu.img) without changing the partition table and loosing current android install. You can't currently do that with Tubuntu, right?
Best regards,
Alex

Serkenar said:
This should probably be posted here, but I sadly don't have the required 10 posts to do so.
There's one issue that I noticed that is actual in 0.2.2alpha. When you choose to flash Jhinta 3.1x kernel and not 2.6x kernel, it is still linux.img that is being flashed, instead of jlinux.img.
Also there's one question (or rather a feature request). Once you have dual boot up and running it would be nice to be able to flash linux rootfs only (ubuntu.img) without changing the partition table and loosing current android install. You can't currently do that with Tubuntu, right?
Best regards,
Alex
Click to expand...
Click to collapse
hi!
that will be on my next release cause i flash my tubuntu image so much. i'm trying to push out a backup menu along with that new rootfs option

x3maniac said:
hi!
that will be on my next release cause i flash my tubuntu image so much. i'm trying to push out a backup menu along with that new rootfs option
Click to expand...
Click to collapse
Hi,
I'm really glad to hear that! Looking forward to the next Tubuntu release
I'd also like to ask to include cifs kernel module in your kernel build.
Thank you

Serkenar said:
Hi,
I'm really glad to hear that! Looking forward to the next Tubuntu release
I'd also like to ask to include cifs kernel module in your kernel build.
Thank you
Click to expand...
Click to collapse
new version is up with Flash rootfs only :laugh:
future release of kernel i will put cifs. right now i'm trying to get zram and overclocking right 1st.
lol i feel like a one man operation. make the program to flash ubuntu images, didn't find one i liked. so i went ahead and made one. feel that the kernel is missing too much stuff. and went ahead and i'm making that now lol... am i missing anything else i need to learn/do? hahahaha
but i'm loving it!
thanks for the support

x3maniac said:
new version is up with Flash rootfs only :laugh:
future release of kernel i will put cifs. right now i'm trying to get zram and overclocking right 1st.
lol i feel like a one man operation. make the program to flash ubuntu images, didn't find one i liked. so i went ahead and made one. feel that the kernel is missing too much stuff. and went ahead and i'm making that now lol... am i missing anything else i need to learn/do? hahahaha
but i'm loving it!
thanks for the support
Click to expand...
Click to collapse
Thank you for your effort
Speaking about your own kernel, I tried compiling one from Jhinta source, but I received odd errors at boot time. First it was this kind of errors:
lists.litmus-rt.org/pipermail/litmus-dev/2012/000215.html
it was suggested there to try changing CONFIG_DEVTMPFS_MOUNT kernel config value, I did that, and then I got some other odd errors, so I gave up
Right now I have a more or less stable 12.04 kubuntu+3.10.1 jhanti kernel with hw acceleration, sound, zram (used netinstall 0.6). I'm only missing overclocking and a cifs module, that's why I tried building my own kernel, but never got it booting. I don't know any sane methods of backing up and restoring linux on tf101 (well, dd + gzip should work, but that's rather stupid), so I'm a little hesitant about flashing your lubuntu right now. I think I'll still give it a go, but before I do that, don't you know any easy way to back up my current linux install?
Thank you

Serkenar said:
Thank you for your effort
Speaking about your own kernel, I tried compiling one from Jhinta source, but I received odd errors at boot time. First it was this kind of errors:
lists.litmus-rt.org/pipermail/litmus-dev/2012/000215.html
it was suggested there to try changing CONFIG_DEVTMPFS_MOUNT kernel config value, I did that, and then I got some other odd errors, so I gave up
Right now I have a more or less stable 12.04 kubuntu+3.10.1 jhanti kernel with hw acceleration, sound, zram (used netinstall 0.6). I'm only missing overclocking and a cifs module, that's why I tried building my own kernel, but never got it booting. I don't know any sane methods of backing up and restoring linux on tf101 (well, dd + gzip should work, but that's rather stupid), so I'm a little hesitant about flashing your lubuntu right now. I think I'll still give it a go, but before I do that, don't you know any easy way to back up my current linux install?
Thank you
Click to expand...
Click to collapse
i'm now compiling from his source. for the 3.1.10 kernel i'm using. why try to reinvent the wheel? i just recompiled and added oc and cifs, i didn't run into any compile issues but i did run into boot issues so changing the kernel to compress with lzmo instead of gzip fixed it. hope that helps

Thank you for your work on this
x3maniac said:
i'm now compiling from his source. for the 3.1.10 kernel i'm using. why try to reinvent the wheel? i just recompiled and added oc and cifs, i didn't run into any compile issues but i did run into boot issues so changing the kernel to compress with lzmo instead of gzip fixed it. hope that helps
Click to expand...
Click to collapse
x3maniac I was wondering if you have ever checked out openELEC linux. They just pushed out a new version on Distrowatch and it looks like it will have support for ARM devices. It is very lightweight at 106mb and is made to run XBMC out of the box. Might be worth a try due to its size and media streaming abilities.
Thanks

thelangosta said:
x3maniac I was wondering if you have ever checked out openELEC linux. They just pushed out a new version on Distrowatch and it looks like it will have support for ARM devices. It is very lightweight at 106mb and is made to run XBMC out of the box. Might be worth a try due to its size and media streaming abilities.
Thanks
Click to expand...
Click to collapse
thanks for the info. i will look into it, i do have a arch linux version working with 3.1 which is only about 200mb.
edit:
they have a arm version 83mb! lols

Cool
x3maniac said:
thanks for the info. i will look into it, i do have a arch linux version working with 3.1 which is only about 200mb.
edit:
they have a arm version 83mb! lols
Click to expand...
Click to collapse
Wow that is small. I have seen Roms that small but never an os. Wait, is that openELEC or Arch you are talking about.
On another note if I do end up getting around to trying your method with arch which desktop would you recommend?
Thanks

thelangosta said:
Wow that is small. I have seen Roms that small but never an os. Wait, is that openELEC or Arch you are talking about.
On another note if I do end up getting around to trying your method with arch which desktop would you recommend?
Thanks
Click to expand...
Click to collapse
openelec(rasbery pi)
if you want it to look nice then enlightment e17. for a light weight DE they make it very pretty with all the effects like compiz
or lxde

x3maniac said:
i'm now compiling from his source. for the 3.1.10 kernel i'm using. why try to reinvent the wheel? i just recompiled and added oc and cifs, i didn't run into any compile issues but i did run into boot issues so changing the kernel to compress with lzmo instead of gzip fixed it. hope that helps
Click to expand...
Click to collapse
Compression was already set to lzma. I can't figure out what I was doing wrong. Yet, you're right, no point to reinvent the wheel.
I see you've recently released your Lubuntu V1.1-rc1. The specs sound great! Could you please post the rootfs download link and also post your kernel img?
Thank you for the great work you're doing!

Serkenar said:
Compression was already set to lzma. I can't figure out what I was doing wrong. Yet, you're right, no point to reinvent the wheel.
I see you've recently released your Lubuntu V1.1-rc1. The specs sound great! Could you please post the rootfs download link and also post your kernel img?
Thank you for the great work you're doing!
Click to expand...
Click to collapse
the link to image and kernel is up. http://forum.xda-developers.com/showthread.php?t=1995157

x3maniac said:
the link to image and kernel is up. http://forum.xda-developers.com/showthread.php?t=1995157
Click to expand...
Click to collapse
I gave it a go First of all, Tubuntu flashes .\images\linux.img when choosing to flash "2.6x x3maniac kernel", I assume it should flash .\images\xlinux.img
That's not a big issue, but should be fixed
A quick list of things I noticed.
1. Things that work:
-1.2 GHz OC
-Usb mouse (when plugged before system boots, otherwise not - that's due to 3.1.10 kernel, I guess)
-cifs module
-chromium
-terminal (right clicking on your tf101linux gadget -> Shortcuts -> Terminal)
-screen brightness up/down buttons. You just have to be mindful to avoid turning the screen off this way - it won't turn on afterwards and you'll have to force reboot.
-ntfs read/write
2. Things that don't work:
-touchpad
-XF86poweroff button
-System Tools -> XTerm/UXTerm
-sound: Audacious complains "ALSA error. No suitable mixer element found. snd_mixer_find_selem failed". Gnome MPlayer just won't produce any sound, and youtube html5 videos too.
-plugging in an external usb drive. It's totally ignored. A pen drive doesn't even blink, nor the drive appears in /dev it works now. It didn't during initial launch. Don't know why, but a reboot cured this.
Also, it happens quite often that system freezes for no apparent reason and only force reboot helps. It happened twice with me already, although it's been less then an hour since I flashed lubuntu.
Tell me if you need some additional info
Regards

Serkenar said:
I gave it a go First of all, Tubuntu flashes .\images\linux.img when choosing to flash "2.6x x3maniac kernel", I assume it should flash .\images\xlinux.img
That's not a big issue, but should be fixed
A quick list of things I noticed.
1. Things that work:
-1.2 GHz OC
-Usb mouse (when plugged before system boots, otherwise not - that's due to 3.1.10 kernel, I guess)
-cifs module
-chromium
-terminal (right clicking on your tf101linux gadget -> Shortcuts -> Terminal)
-screen brightness up/down buttons. You just have to be mindful to avoid turning the screen off this way - it won't turn on afterwards and you'll have to force reboot.
-ntfs read/write
2. Things that don't work:
-touchpad
-XF86poweroff button
-System Tools -> XTerm/UXTerm
-sound: Audacious complains "ALSA error. No suitable mixer element found. snd_mixer_find_selem failed". Gnome MPlayer just won't produce any sound, and youtube html5 videos too.
-plugging in an external usb drive. It's totally ignored. A pen drive doesn't even blink, nor the drive appears in /dev it works now. It didn't during initial launch. Don't know why, but a reboot cured this.
Also, it happens quite often that system freezes for no apparent reason and only force reboot helps. It happened twice with me already, although it's been less then an hour since I flashed lubuntu.
Tell me if you need some additional info
Regards
Click to expand...
Click to collapse
i love your report! keep up the good work. this helps me narrow down the problems but without a dock i can't fix some of the issues. but try this
touchpad:
edit /etc/X11/Xorg.conf
Code:
Section "InputClass"
MatchIsTouchpad "on"
Identifier "Touchpads"
Driver "mtrack"
EndSection
should fix the touchpad issue.
i will look into fixing my script for the brightness issue. located int /usr/local/bin/tfbright
what were you doing when you freeze? i don't have a dock(still waiting for it in the mail) so i don't know if it's related to that.
i've been looking at nvidia git and downloaded there source for the linux4tegra kernel. it' compiled fine but wont boot. don't know why yet

x3maniac, I know it is off topic a bit but I just wanted to mention that I appreciate your attitude towards your work and especially criticism (aka feedback) from others about your work. Reminds me of my EVO 4G days running tommytomato's classic rom. His threads were always friendly and optimistic, much like your own.
Sent from my SPH-L710 using Tapatalk 2

x3maniac said:
i love your report! keep up the good work. this helps me narrow down the problems but without a dock i can't fix some of the issues. but try this
touchpad:
edit /etc/X11/Xorg.conf
Code:
Section "InputClass"
MatchIsTouchpad "on"
Identifier "Touchpads"
Driver "mtrack"
EndSection
should fix the touchpad issue.
i will look into fixing my script for the brightness issue. located int /usr/local/bin/tfbright
what were you doing when you freeze? i don't have a dock(still waiting for it in the mail) so i don't know if it's related to that.
i've been looking at nvidia git and downloaded there source for the linux4tegra kernel. it' compiled fine but wont boot. don't know why yet
Click to expand...
Click to collapse
Strange, but there's no /etc/X11/xorg.conf
I tried creating it with `Xorg :1 -configure`, but I get "No devices to configure. Configuration failed."
I also tried creating /etc/X11/xorg.conf with the following content
Code:
Section "InputClass"
MatchIsTouchpad "on"
Identifier "Touchpads"
Driver "mtrack"
EndSection
but touchpad wont' work.
Like I said, there appears to be no apparent reason for those freezes The only things they had in common are the following:
(as far as I can remember)
-I had a cifs share mounted
-pen drive was plugged in
-chromium was opened
I understand that isn't helpful at all, but atm I can't reproduce those freezes myself. They occur kind of randomly.
I hope linux4tegra kernel does boot after all
Thank you for your work
EDIT: 30 minutes without freezes, I hope they're gone for good! :laugh:

djlenoir said:
x3maniac, I know it is off topic a bit but I just wanted to mention that I appreciate your attitude towards your work and especially criticism (aka feedback) from others about your work. Reminds me of my EVO 4G days running tommytomato's classic rom. His threads were always friendly and optimistic, much like your own.
Sent from my SPH-L710 using Tapatalk 2
Click to expand...
Click to collapse
+1 Totally agree

djlenoir said:
x3maniac, I know it is off topic a bit but I just wanted to mention that I appreciate your attitude towards your work and especially criticism (aka feedback) from others about your work. Reminds me of my EVO 4G days running tommytomato's classic rom. His threads were always friendly and optimistic, much like your own.
Sent from my SPH-L710 using Tapatalk 2
Click to expand...
Click to collapse
Serkenar said:
+1 Totally agree
Click to expand...
Click to collapse
as far as i see it, you guys are helping me get a working version. user/tester are as important as the devs making them. or else dev's would be out of the job. lols that's how i see it

I let lubuntu running and it froze smth like 20 minutes ago Without me doing anything. Chromium was running, pen drive plugged in and a cifs share mounted.
I'll leave it running without a pen drive plugged in, shares mounted and chromium running to see if it freezes eventually.

Serkenar said:
I let lubuntu running and it froze smth like 20 minutes ago Without me doing anything. Chromium was running, pen drive plugged in and a cifs share mounted.
I'll leave it running without a pen drive plugged in, shares mounted and chromium running to see if it freezes eventually.
Click to expand...
Click to collapse
i'm guessing jhanti's kernel is not stable. i was starting to use it more and got a random freeze. cpu1 went to sleep and wont wake up. looking into that.. i might just take nvidia's kernel 3.1.10 and try to get that working.

WARNING: You will need TWRP configuration in your device tree soon!

Sometime in the next few days (maybe this weekend), we will be merging https://gerrit.omnirom.org/#/c/1169/
This will allow TWRP to build properly on userdebug builds. As a warning, it WILL break anyone who doesn't have TWRP config in their device tree when it is merged! (You will get errors about missing files in bootable/recovery/res if I recall correctly)
See http://forum.xda-developers.com/showthread.php?t=1943625 for info on various TWRP device tree configurations. At an absolute minimum I believe you will need the device resolution added to avoid breaking your build.
For additional details, see:
Find5:
https://gerrit.omnirom.org/#/c/1633/
Yuga:
https://gerrit.omnirom.org/#/c/1682/ (Depends on fusion3-common changes)
pollux-common (pollux_windy and pollux don't have specific items and just inherit common):
https://gerrit.omnirom.org/#/c/1155/ (Depends on fusion3-common changes)
fusion3-common:
https://gerrit.omnirom.org/#/c/1152/
flo:
https://gerrit.omnirom.org/#/c/1634/
mako:
https://gerrit.omnirom.org/#/c/1635/

@Entropy512
Hey there!
Add me on hangouts sir:
[email protected]
What about this TWRP configuration for honami?
https://github.com/Omni-Xperia/android_device_sony_rhine-common/commits/cm-10.2
i have built one for pollux and it works

Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .

iofthestorm said:
Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .
Click to expand...
Click to collapse
Pretty much what happens is, TeamWin will get a device tree, modify it to be compatible with TWRP, and use that to build for that device. The actual core source for TWRP itself is in a separate repository that is constantly updated. So pretty much its like this : once your device tree is modified to build TWRP for your device during a build, it will build using TWRP source , which is android_bootable_recovery, for omnirom specifically.
Think of it like this: you setup a device tree to say "build TWRP using this source code" . once the device tree is looking for that source code, it'll always build twrp without issues (for the most part). Now the location your device tree looks to is the twrp source itself, which is updated and improved all the time, so if you're device tree is setup properly for tarp, you will have a recovery.img in your out directory after a build that is as up-to-date build of twrp to when you last did a repo sync
Sent from my SGH-I337 using Tapatalk

jakew02 said:
Pretty much what happens is, TeamWin will get a device tree, modify it to be compatible with TWRP, and use that to build for that device. The actual core source for TWRP itself is in a separate repository that is constantly updated. So pretty much its like this : once your device tree is modified to build TWRP for your device during a build, it will build using TWRP source , which is android_bootable_recovery, for omnirom specifically.
Think of it like this: you setup a device tree to say "build TWRP using this source code" . once the device tree is looking for that source code, it'll always build twrp without issues (for the most part). Now the location your device tree looks to is the twrp source itself, which is updated and improved all the time, so if you're device tree is setup properly for tarp, you will have a recovery.img in your out directory after a build that is as up-to-date build of twrp to when you last did a repo sync
Sent from my SGH-I337 using Tapatalk
Click to expand...
Click to collapse
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.

iofthestorm said:
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.
Click to expand...
Click to collapse
You mention mount points for the SD, I have been building for the HTC One S and while all the mount points in the my ville/rootdir are correct for example in the fstab.qcom file
# SD card
/devices/platform/msm_sdcc.1/mmc_host/mmc0 /storage/sdcard0 auto defaults voldmanaged=sdcard:36
The rom shows it as unavailable/missing and asks me to format the SD card, I tried and the message keeps popping up.
Basically my question is, will building twrp recovery for the device sort out the missing SD card.

iofthestorm said:
Ah thanks, that's useful, but not really what I was asking about. I got that part, I just wanted to know if flashing the ROM actually flashes the recovery that was built in tree as well, and it seems like the answer is no (at least for me my recovery didn't change). As such it seems like the main point that Entropy512 was making is that if you don't add the resolution to your BoardConfig.mk the build won't complete, but otherwise it doesn't really matter if you set the other parameters correctly.
The paths I was referring to were the mount points for the internal and external SD, I thought they had changed since ICS but I think they might still have symlinks to the old paths for compatibility's sake.
Click to expand...
Click to collapse
flashing a ROM will never flash a recovery, but some devices have the recovery as part of the boot.img, so when you flash a new kernel, for example, you will be flashing a new recovery as well

iofthestorm said:
Just wondering, does this recovery actually get flashed when installing? I.e. do all the parameters need to be set properly to build the ROM, or just enough to not break the build? I'm already using TWRP and I'm not sure of the right BoardConfig.mk settings but if I'm just trying to port it to my device that shouldn't matter right? Though I noticed there are device trees on the TeamWin GitHub for building TWRP, for my device (n8013) it seems out of date.
Edit: well cool, turned out not to matter and it seems like my build actually booted, I'm pleasantly surprised .
Click to expand...
Click to collapse
Ideally you should have a goal of building a fully functional recovery.
However, with the exception of older Samsungs (galaxys2 family and older for the most part) and Sonys, you don't NEED the recovery to be fully functional. With the galaxys2 family and Sonys - yeah you need it. (Actually Sonys do have a workaround, but the GS2 family does not.)
That said, leaving a partially configured recovery configuration is bad practice.

jakew02 said:
flashing a ROM will never flash a recovery, but some devices have the recovery as part of the boot.img, so when you flash a new kernel, for example, you will be flashing a new recovery as well
Click to expand...
Click to collapse
Yeah, that'd be what I was thinking of. My first Android phone, the Samsung Fascinate, had a weird setup like that.
Entropy512 said:
Ideally you should have a goal of building a fully functional recovery.
However, with the exception of older Samsungs (galaxys2 family and older for the most part) and Sonys, you don't NEED the recovery to be fully functional. With the galaxys2 family and Sonys - yeah you need it. (Actually Sonys do have a workaround, but the GS2 family does not.)
That said, leaving a partially configured recovery configuration is bad practice.
Click to expand...
Click to collapse
Alright, that's what I figured. Yeah, I'll fix it later for sure, I just didn't have the time this weekend and I didn't plan on submitting a patch to make it officially supported anyway, as I just wanted to try it out for myself at this point. And I figured since it's the n8013 you'd be the best person to support that anyway, I only know enough to get myself in trouble.
(do you still have your N8013 by the way?)

iofthestorm said:
Yeah, that'd be what I was thinking of. My first Android phone, the Samsung Fascinate, had a weird setup like that.
Alright, that's what I figured. Yeah, I'll fix it later for sure, I just didn't have the time this weekend and I didn't plan on submitting a patch to make it officially supported anyway, as I just wanted to try it out for myself at this point. And I figured since it's the n8013 you'd be the best person to support that anyway, I only know enough to get myself in trouble.
(do you still have your N8013 by the way?)
Click to expand...
Click to collapse
I do, but it mostly collects dust these days. At some point I'll try to get Omni up on it, I've just had too much else to do lately.

So another question, what is the mechanism by which twrp.fstab is used? I decided to flash my recovery for the heck of it (sidenote: on the 4.4 branch it still has the AOSP recovery in the manifest, but I just added omnirom/android_bootable_recovery to my local_manifests.xml) and it actually runs but nothing appears to be mounted. I notice that some TWRPify commits have a twrp.fstab but they don't do a PRODUCT_COPY_FILES for that file so I'm wondering how it even gets used? I see for example that your commit for flo is doing it: https://gerrit.omnirom.org/#/c/1523/ but then this guy didn't actually add it to PRODUCT_COPY_FILES for hammerhead: https://gerrit.omnirom.org/#/c/1588/ . Is that just a mistake on Mithun's part, or am I misunderstanding how this fstab is used? Is there any reason for it to be any different than the fstab.smdk4x12 in the device tree? Just trying to figure out how things work here.
Also, is it preferable to use the by-name symlinks over the raw /dev/block/mmcblk0p9 type device identifiers? Should I open another thread for this?
My hackjob device trees are https://github.com/ibrahima/android_device_samsung_n80xx-common and https://github.com/ibrahima/android_device_samsung_n8013 .
Edit: I guess my main question is, how is that twrp.fstab different from TARGET_RECOVERY_FSTAB? Some of the device trees with it (eg. your flo changeset that I linked above) don't seem to set this unless I'm looking in the wrong place, and I've seen at least one that sets TARGET_RECOVERY_FSTAB to /etc/twrp.fstab. Found this quote from @Dees_Troy:
You can create a twrp.fstab file and then use PRODUCT_COPY_FILES += device/oem/codename/twrp.fstab:recovery/root/etc/twrp.fstab to get the twrp.fstab into the recovery ramdisk
Click to expand...
Click to collapse
from http://forum.xda-developers.com/showthread.php?p=45164117 . If I already have an /etc/recovery.fstab it should work without the twrp.fstab right?
Edit2: Oh, derp, the twrp.fstab explanation is in the "How to Compile TWRP" thread. Filing away for later reading... (this is fun and all, but my professors aren't going to accept an Android 4.4 build in place of my homework )
Edit3: My god, this is basically me: http://xkcd.com/356/ and the truck is my homework/midterms... welp, at least I got a recovery with proper fstab, so for anyone else trying to TWRPify yes, you do need a twrp.fstab because the new fstab format in Android 4.3+ is not used by TWRP yet so you need one in the older format for it to mount your stuff. Haven't actually tried flashing anything with my recovery yet, but I feel like it should probably work, but again... trucks and all that

If it's not in PRODUCT_COPY_FILES - yes, that is a mistake.
(hopefully that commit isn't merged - accessing omni's gerrit is problematic for me from some locations. If the TWRP FSTAB is added to the device tree but isn't being copied that's grounds for a -1)

Yeah, he -1ed it himself for other reasons I suppose. Cool cool, looks like I'm learning stuff
By the way, after the hard drive meltdown and subsequent loss of two weeks of gerrit data, a lot of the links in your OP are broken in that they go to different tickets which have now subsumed those ticket numbers that were lost. For those who are curious and have been foiled by Gerrit's somewhat obtuse search box, if you type message:TWRP in the search box (to search commit messages) you'll find examples.

[Q] Any tips/guides around for someone who wants to make a rom from scatch?

And what I mean, no android kitchen and those kind of tools. Simple from the start where you are forced to do all the work yourself.
(I have to much free time)

E-13 said:
And what I mean, no android kitchen and those kind of tools. Simple from the start where you are forced to do all the work yourself.
(I have to much free time)
Click to expand...
Click to collapse
Cyanogenmod is a great place to start since its stock, http://wiki.cyanogenmod.org/w/Development

Trozzul said:
Cyanogenmod is a great place to start since its stock,
Click to expand...
Click to collapse
Ah, thank you. I will look into that.
Small problem I (probarly) have. I also have a mediatek phone (main phone) and I heard there are a few problems when you want to make roms for those. It was due to lack of released source or something?

E-13 said:
Ah, thank you. I will look into that.
Small problem I (probarly) have. I also have a mediatek phone (main phone) and I heard there are a few problems when you want to make roms for those. It was due to lack of released source or something?
Click to expand...
Click to collapse
that is true, the kernel of mediatek has problems with Cyanogenmod so its a little hard. mediatek kinda sucks to develop for.

Trozzul said:
that is true, the kernel of mediatek has problems with Cyanogenmod so its a little hard. mediatek kinda sucks to develop for.
Click to expand...
Click to collapse
Wouldn'tv it be easier to start with vanille android then or modify the stock ROM bit by bit?

E-13 said:
Wouldn'tv it be easier to start with vanille android then or modify the stock ROM bit by bit?
Click to expand...
Click to collapse
always start with modifying the stock rom, every few changes you make you should check out if they work and repeat that process.

Trozzul said:
always start with modifying the stock rom, every few changes you make you should check out if they work and repeat that process.
Click to expand...
Click to collapse
Is there a way I can make my current ROM into a flash able zip?

E-13 said:
Is there a way I can make my current ROM into a flash able zip?
Click to expand...
Click to collapse
that i wouldnt know where to get information on, im sure there are tools for this, make a backup and unzip it and see what you can do from there, of course you can flash a backup but its a start.

Trozzul said:
that i wouldnt know where to get information on, im sure there are tools for this, make a backup and unzip it and see what you can do from there, of course you can flash a backup but its a start.
Click to expand...
Click to collapse
I was able to extract the boot.img,recovery.img and the META-INF map. If I am right, I didnt miss anything else thats important. Right?

E-13 said:
I was able to extract the boot.img,recovery.img and the META-INF map. If I am right, I didnt miss anything else thats important. Right?
Click to expand...
Click to collapse
Hmm I'm pretty sure there should be a few more things, go to CyanogenMod and download a random file for whatever phone and check out those files. Make sure its a stable and not nightlie

Trozzul said:
Hmm I'm pretty sure there should be a few more things, go to CyanogenMod and download a random file for whatever phone and check out those files. Make sure its a stable and not nightlie
Click to expand...
Click to collapse
I got one from the.. eh.. HTC one.
The main files (and I looked around already) are:
META-INF
system
boot.img
Thats it. And inside system there are the "standard" folders and build.prop.
I got this already tough.
-Now a small thing, this is a mediatek device, And from what I see/understood a pain in the everything to make roms for this.
I did find this about: http://sourceforge.net/projects/alcatel/files/
A huge file ;p. It seemed to be files about the kernel. The files:
boinic
external
kernel
mediatek
system
With a line I found in a readme in mediatek/kernel:
The "mediatek/kernel/" directory is intended for Mediatek solution kernel specific non-customization codes.
Anyway, back to the point. I got system, boot.img and Meta-inf
I think I got everything ready

E-13 said:
I got one from the.. eh.. HTC one.
The main files (and I looked around already) are:
META-INF
system
boot.img
Thats it. And inside system there are the "standard" folders and build.prop.
I got this already tough.
-Now a small thing, this is a mediatek device, And from what I see/understood a pain in the everything to make roms for this.
I did find this about: http://sourceforge.net/projects/alcatel/files/
A huge file ;p. It seemed to be files about the kernel. The files:
boinic
external
kernel
mediatek
system
With a line I found in a readme in mediatek/kernel:
The "mediatek/kernel/" directory is intended for Mediatek solution kernel specific non-customization codes.
Anyway, back to the point. I got system, boot.img and Meta-inf
I think I got everything ready
Click to expand...
Click to collapse
Looks like you do, I must have been thinking about something inside meta inf that let's you change all the icons

Trozzul said:
Looks like you do, I must have been thinking about something inside meta inf that let's you change all the icons
Click to expand...
Click to collapse
*cheers* But I dont really get this part. (probarly for advanced peeps) Why is it so hard to make roms for mediatek. I get they dont release the source code/code you guys need for that. But where is the code for you so badly need for that.

E-13 said:
*cheers* But I dont really get this part. (probarly for advanced peeps) Why is it so hard to make roms for mediatek. I get they dont release the source code/code you guys need for that. But where is the code for you so badly need for that.
Click to expand...
Click to collapse
I don't know whoever owns mediatek has the codes obviously. Mediatek CPUs are terrible anyway so I'm sure nobody will leak the codes

Well, not that terrible to be honest. Mine works pretty good. (am just kinda fed up with alcatel ;p) And alot of people have devices running on mediatek cpu's. Just someone needs to put real good effort into it. (and hope he doesnt get into problems for it xD)

E-13 said:
Well, not that terrible to be honest. Mine works pretty good. (am just kinda fed up with alcatel ;p) And alot of people have devices running on mediatek cpu's. Just someone needs to put real good effort into it. (and hope he doesnt get into problems for it xD)
Click to expand...
Click to collapse
Well i wish you good luck, and if you get to somehow release a rom please be sure to hit me up on it what Alcatel device do you have by the way? if you do get a new device in the future that has Cyanogenmod support what i recommend you should do is download the latest stable and just theme that all you want (im sure you know how to move apks to make them SYSTEM apps), and when you think your ready from building it from source jump right in.

Trozzul said:
Well i wish you good luck, and if you get to somehow release a rom please be sure to hit me up on it what Alcatel device do you have by the way? if you do get a new device in the future that has Cyanogenmod support what i recommend you should do is download the latest stable and just theme that all you want (im sure you know how to move apks to make them SYSTEM apps), and when you think your ready from building it from source jump right in.
Click to expand...
Click to collapse
Haha. Thank you I have a Alcatel One Touch Scribe HD. (8008D) Supported by nothing! (expect framaroot )
Now time to abuse my phone and hopefully not turn it into a paperweight.

Well, The rom is done. Added a few Apk's. Now need to look over it and get the guts to flash it

Development Questions

I've been waiting for agrabren to drop his cm code for several months now. Guess that kid really did swallow him whole. Well, I got tired of waiting and decided to see if I could get cm to build myself. Heh, not so much. I can't even get cwm to build and boot correctly. So, I'm here to see if someone can point out what I'm doing wrong.
Here's what I did to build. Pulled CM 11.0 and set up the build directories. Copied device/nvidia and vendor/nvidia from the most recent shield tree. Copied the kernel from the shield tree into device/nvidia/roth and modified the configs to build from there. I modified some of the configs and made cm.mk based off the tf701t port which also uses a tegra 4. A lunch and a couple makes later, I got a recovery.img, but it's too big. 8.2MB won't fit in a 8 MB partition. The kernel came out at 5.9 MB and the ramdisk-recovery.img is 2.3 MB. In an official shield build, the ramdisk-recovery.img is 777KB. I know cwm has a lot more in it, but I seem to be missing something to shave 200KB off it. BoardConfig.mk has the recovery partition size set to 8MB, but that doesn't seem to make a difference. Is there something somewhere that can be used to strip less useful stuff out the recovery image?
Thanks for any help,
Steel01

Steel01 said:
I've been waiting for agrabren to drop his cm code for several months now. Guess that kid really did swallow him whole. Well, I got tired of waiting and decided to see if I could get cm to build myself. Heh, not so much. I can't even get cwm to build and boot correctly. So, I'm here to see if someone can point out what I'm doing wrong.
Here's what I did to build. Pulled CM 11.0 and set up the build directories. Copied device/nvidia and vendor/nvidia from the most recent shield tree. Copied the kernel from the shield tree into device/nvidia/roth and modified the configs to build from there. I modified some of the configs and made cm.mk based off the tf701t port which also uses a tegra 4. A lunch and a couple makes later, I got a recovery.img, but it's too big. 8.2MB won't fit in a 8 MB partition. The kernel came out at 5.9 MB and the ramdisk-recovery.img is 2.3 MB. In an official shield build, the ramdisk-recovery.img is 777KB. I know cwm has a lot more in it, but I seem to be missing something to shave 200KB off it. BoardConfig.mk has the recovery partition size set to 8MB, but that doesn't seem to make a difference. Is there something somewhere that can be used to strip less useful stuff out the recovery image?
Thanks for any help,
Steel01
Click to expand...
Click to collapse
I was previously working on cm but failed as I don't have the device. I suggest building the aosp 4.3 for the shield then work your way up to cm
http://nv-tegra.nvidia.com/gitweb/?...;a=blob_plain;f=README;hb=rel-roth-r3-partner
My idea was to see what's needed and not needed as a lot won't be used in cm.

Unjustified Dev said:
I was previously working on cm but failed as I don't have the device. I suggest building the aosp 4.3 for the shield then work your way up to cm
http://nv-tegra.nvidia.com/gitweb/?...;a=blob_plain;f=README;hb=rel-roth-r3-partner
My idea was to see what's needed and not needed as a lot won't be used in cm.
Click to expand...
Click to collapse
I've got the device and some development knowledge, but a complete lack of android build system knowledge.
I've got the nvidia 4.3 recovery to build (on a VM since it's less tolerant of JDKs than cm), the rest should compile easily enough. So if I was to build up from there, what kind of process would I be looking at? I would presume start with replacing the recovery with cwm. If so, where am I looking to replace stuff at?
Do you still have any of the work you had started?
Steel01

Steel01 said:
I've got the device and some development knowledge, but a complete lack of android build system knowledge.
I've got the nvidia 4.3 recovery to build (on a VM since it's less tolerant of JDKs than cm), the rest should compile easily enough. So if I was to build up from there, what kind of process would I be looking at? I would presume start with replacing the recovery with cwm. If so, where am I looking to replace stuff at?
Do you still have any of the work you had started?
Steel01
Click to expand...
Click to collapse
Yes, getting the recovery booting is the first thing.I can't really help right now but in a few hours or so I will pm you here's the github i'm going to be working at (removed) as you see there's not really anything there. I'm working on making the device tree work in a cm tree. It will probably be a while before my aosp build finishes. If you wish to chat on hangouts pm your email address .

Unjustified Dev said:
Yes, getting the recovery booting is the first thing.I can't really help right now but in a few hours or so I will pm you here's the github i'm going to be working at https://github.com/CM-Shield as you see there's not really anything there. I'm working on making the device tree work in a cm tree. It will probably be a while before my aosp build finishes. If you wish to chat on hangouts pm your email address .
Click to expand...
Click to collapse
Thanks, pm sent. Guess I'll fire off a full aosp build so we'll have the same trees available at that time.
Steel01
Edit: Today's just not my day. None of my builds from nvidia's aosp 4.3 r3 tree boot. A normal boot hangs at the shield logo. The recovery gives me the red triangle (not terribly surprised since nvidia's official gives me that too, only agrabren's cwm recovery works for me). I didn't think too much of it when I built off of openjdk 1.6, but now that I pulled sun's 1.6-41 and it still doesn't boot, I'm a bit miffed. Shouldn't be a reason why I can't build off CentOS. Maybe I'll load up a Debian or Mint VM and try building off that. I really don't want to touch Ubuntu which all the android docs are written for...

Okay, so I don't feel so bad anymore. The kernel boots fine. But the system image generated from the official shield tree doesn't. It starts the boot animation and hangs. But I have adb and complete shell access. Wipes don't help. Which if I was to guess means I have a java problem on the build VM. The C only kernel is fine, but nothing else works right. Big surprise there. That or something like the graphics blob didn't get packaged in. I'll play with it some more and might be able to build a working system by the time Unjustified Dev pushes some code up...
Steel01
Edit: And according to a logcat, I'm missing some so's. Don't know if I missed a build failure or if the official tree is broken.

Steel01 said:
Okay, so I don't feel so bad anymore. The kernel boots fine. But the system image generated from the official shield tree doesn't. It starts the boot animation and hangs. But I have adb and complete shell access. Wipes don't help. Which if I was to guess means I have a java problem on the build VM. The C only kernel is fine, but nothing else works right. Big surprise there. That or something like the graphics blob didn't get packaged in. I'll play with it some more and might be able to build a working system by the time Unjustified Dev pushes some code up...
Steel01
Edit: And according to a logcat, I'm missing some so's. Don't know if I missed a build failure or if the official tree is broken.
Click to expand...
Click to collapse
Did you get the closed source binaries extracted?

Unjustified Dev said:
Did you get the closed source binaries extracted?
Click to expand...
Click to collapse
Yeah I did. I'm running another build and capturing the output this time to see if there's a build failure. The files the log was complaining about are in a vendor prebuilt folder, but didn't get copied to out like most of the other files in that directory did. If this build does the same, I'll hand copy the files into the out directory and hope the command to build the system image just globs that directory.
Steel01

Steel01 said:
Yeah I did. I'm running another build and capturing the output this time to see if there's a build failure. The files the log was complaining about are in a vendor prebuilt folder, but didn't get copied to out like most of the other files in that directory did. If this build does the same, I'll hand copy the files into the out directory and hope the command to build the system image just globs that directory.
Steel01
Click to expand...
Click to collapse
I suggest creating a better call to vendor blobs you can clearly find which ones are needed create an extract-files.sh script as so. I've began partially haven't had time to work on it. I chose a nvidia device because some of the blobs are the same naming less time.
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/extract-files.sh
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/proprietary-files.txt
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/setup-makefiles.sh

Unjustified Dev said:
I suggest creating a better call to vendor blobs you can clearly find which ones are needed create an extract-files.sh script as so. I've began partially haven't had time to work on it. I chose a nvidia device because some of the blobs are the same naming less time.
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/extract-files.sh
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/proprietary-files.txt
https://github.com/CyanogenMod/android_device_asus_tf700t/blob/cm-11.0/setup-makefiles.sh
Click to expand...
Click to collapse
Ah, okay. It would be better to base off the tf701t, though. It's a tegra 4 device whereas the tf700t is a tegra 3. I'll see what I come up with after I flash stock back.
Steel01

Steel01 said:
Ah, okay. It would be better to base off the tf701t, though. It's a tegra 4 device whereas the tf700t is a tegra 3. I'll see what I come up with after I flash stock back.
Steel01
Click to expand...
Click to collapse
Actually I was just looking at it. We have an advantage we already have a device tree and I like their layout so I'm going to copy that when I have time and build from it.
Still some unsolved things I will discuss later

Unjustified Dev said:
Actually I was just looking at it. We have an advantage we already have a device tree and I like their layout so I'm going to copy that when I have time and build from it.
Still some unsolved things I will discuss later
Click to expand...
Click to collapse
Yeah, that would make it much simpler. I had that device tree building inside the cm11 repo a couple days ago, but I broke the kernel build somewhere along the way and haven't figured out what I did yet.
I'm currently working on getting the blob list together. Skimming the tf701t down to what exists on the shield, then building up from there. Will probably take a couple days with my schedule though, so you might beat me through it.
Steel01

Steel01 said:
Yeah, that would make it much simpler. I had that device tree building inside the cm11 repo a couple days ago, but I broke the kernel build somewhere along the way and haven't figured out what I did yet.
I'm currently working on getting the blob list together. Skimming the tf701t down to what exists on the shield, then building up from there. Will probably take a couple days with my schedule though, so you might beat me through it.
Steel01
Click to expand...
Click to collapse
I got latest ota image from nvidia and extracted the system.img will be tomorrow when I finish gathering all blobs and I will send you a pm. once we get cwm working we can move forward wish the guy who compiled it got a change to upload his source so I can see how to do the dtb stuff . I know someone who can help I will contact them tomorrow

Unjustified Dev said:
I got latest ota image from nvidia and extracted the system.img will be tomorrow when I finish gathering all blobs and I will send you a pm. once we get cwm working we can move forward wish the guy who compiled it got a change to upload his source so I can see how to do the dtb stuff . I know someone who can help I will contact them tomorrow
Click to expand...
Click to collapse
Okay, great. I Got a hack of cm build together using the attached proprietary-files.txt and a prebuilt kernel from the shield tree. Ended up missing a couple so's, but I'm done for the night. Once you get the device tree to compile, can you push that to the github org and give me access to it?
On the dtb issues, doesn't the normal kernel compile output the dtb?
The official BoardConfig sets:
TARGET_USE_DTB := true
TARGET_KERNEL_DT_NAME := tegra114-roth
BOOTLOADER_SUPPORTS_DTB := true
Then kernel.mk sets:
KERNEL_DTS_PATH := $(KERNEL_PATH)/arch/$(TARGET_ARCH)/boot/dts/$(TARGET_KERNEL_DT_NAME).dts
BUILT_KERNEL_DTB := $(NV_KERNEL_INTERMEDIATES_DIR)/arch/$(TARGET_ARCH)/boot/$(TARGET_KERNEL_DT_NAME).dtb
and further down calls
+$(hide) $(kernel-make) $(TARGET_KERNEL_DT_NAME).dtb
That correctly gives me the dtb file. Though, chances are there are other lines I missed that affect it.
Steel01

Steel01 said:
Okay, great. I Got a hack of cm build together using the attached proprietary-files.txt and a prebuilt kernel from the shield tree. Ended up missing a couple so's, but I'm done for the night. Once you get the device tree to compile, can you push that to the github org and give me access to it?
On the dtb issues, doesn't the normal kernel compile output the dtb?
The official BoardConfig sets:
TARGET_USE_DTB := true
TARGET_KERNEL_DT_NAME := tegra114-roth
BOOTLOADER_SUPPORTS_DTB := true
Then kernel.mk sets:
KERNEL_DTS_PATH := $(KERNEL_PATH)/arch/$(TARGET_ARCH)/boot/dts/$(TARGET_KERNEL_DT_NAME).dts
BUILT_KERNEL_DTB := $(NV_KERNEL_INTERMEDIATES_DIR)/arch/$(TARGET_ARCH)/boot/$(TARGET_KERNEL_DT_NAME).dtb
and further down calls
+$(hide) $(kernel-make) $(TARGET_KERNEL_DT_NAME).dtb
That correctly gives me the dtb file. Though, chances are there are other lines I missed that affect it.
Steel01
Click to expand...
Click to collapse
I read that from the OC kernel thread and it's 1am here so I'm done for the night as well. I am giving you permission to CM-Shield right now. I already cloned tf701 device tree and renamed it. I was working on adding in the files from nvidia tree some are going to go prebuilt might need some patches from nvidia git as well not so sure right now. I really need to get this device. Blindly working isn't much fun. As far as I know you use fastboot flash dtb that dtb is never updated and might not be needed not sure yet I have never had to deal with dtb.

Unjustified Dev said:
I read that from the OC kernel thread and it's 1am here so I'm done for the night as well. I am giving you permission to CM-Shield right now. I already cloned tf701 device tree and renamed it. I was working on adding in the files from nvidia tree some are going to go prebuilt might need some patches from nvidia git as well not so sure right now. I really need to get this device. Blindly working isn't much fun. As far as I know you use fastboot flash dtb that dtb is never updated and might not be needed not sure yet I have never had to deal with dtb.
Click to expand...
Click to collapse
Alright. If you haven't got the dtb stuff straightened out by the time I get back to my dev machine tomorrow night, I'll tackle that. I've had some hobbyist experience with that on some embedded dev boards. In general, I wouldn't think the dtb would ever change. Definitely not within a kernel version. Definitely needed, though. But in the spirit of open source and building as much as possible from source, it will be good to make that build. Shouldn't be too difficult. And yes, 1:30 AM does bad things to cognizance. *passes out*
Steel01
Edit: I took a look at the tf701t kernel tree this morning. The dtb part may already be done if we base from there. A dts file already exists for roth (arch/arm/boot/dts) and the make file a dir up appears to glob the dts directory and build dtb's for each. I don't have access to a build tree to verify that atm, though. Bit if that's true, the kernel should be as simple as cloning tf701t, renaming its defconfig and modifying what little differences there are if any, then copying the dtb to the out directory.
Edit 2: A bit of googling turned up http://www.armadeus.com/wiki/index.php?title=Kernel-with-device-tree which says a config flag handles building dtb's. The tf701t config already sets CONFIG_MACH_ROTH=y, so I'm wondering if that kernel won't boot on the shield out of the box. Something I'll try once I get back to my dev machine tonight.

Well, I did get the dtb to build using the CM-Shield device tree and the kernel from tf701t. Haven't been able to test yet, though. And it was kind of a hack, but I don't know a better place to plug it than modules. In BoardConfig.mk after the two target kernel lines:
KERNEL_DTB:
*tab* make -C $(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" tegra114-roth.dtb
*tab* mv $(KERNEL_OUT)/arch/arm/boot/tegra114-roth.dtb $(OUT)
TARGET_KERNEL_MODULES := KERNEL_DTB
That should probably pull arch and compiler prefix from cm env cars, but I don't know what they are. The dtb name should also be set as a const. Once I see if the kernel boots in a couple hours, I'll push my device branch up. Only kernel change was renaming the defconfig.
Steel01

Steel01 said:
Well, I did get the dtb to build using the CM-Shield device tree and the kernel from tf701t. Haven't been able to test yet, though. And it was kind of a hack, but I don't know a better place to plug it than modules. In BoardConfig.mk after the two target kernel lines:
KERNEL_DTB:
*tab* make -C $(KERNEL_OUT) ARCH="arm" CROSS_COMPILE="arm-eabi-" tegra114-roth.dtb
*tab* mv $(KERNEL_OUT)/arch/arm/boot/tegra114-roth.dtb $(OUT)
TARGET_KERNEL_MODULES := KERNEL_DTB
That should probably pull arch and compiler prefix from cm env cars, but I don't know what they are. The dtb name should also be set as a const. Once I see if the kernel boots in a couple hours, I'll push my device branch up. Only kernel change was renaming the defconfig.
Steel01
Click to expand...
Click to collapse
So far going to push unmodified kernel now https://github.com/CM-Shield/android_device_nvidia_roth

Progress finally. Got a cwm recovery that boots and looks like it works plus fits in the partition. Most of the buttons aren't mapped yet and the screen is rotated, but that should be the east part to fix.
Steel01

Getting closer. But still no dice. Logcat of current iteration.
Steel01

Database Info

welcome