Database Users

LINUX BOOTS at OPAL! Thanks to linwizard project!

Hi there,
I got Linux to boot at OPAL via linwizard project. Here are steps needed to get it work.
1) download image from:
http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/gizard-20080602.tar.bz2
2) copy content of file to the microSD card
3) edit default txt and replace init=/linuxrc with init=/bin/sh
4) run haret and let it boot.
After a while you'll get to shell. No graphics.
Now you can attach microusb cable and connect it with your linux laptop (I recommend ubuntu)
and you will get usb0 interfece to start up.
Which IP to use to connect with OPAL I still must investigate.

Well ip connectivity now works:
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>
Notas:/# ifconfig usb0 up 192.168.2.200 netmask 255.255.255.0
Listik:/usr/src/linux-2.6.27/Documentation# ping 192.168.2.202
PING 192.168.2.202 (192.168.2.202) 56(84) bytes of data.
64 bytes from 192.168.2.202: icmp_seq=1 ttl=64 time=2.95 ms
64 bytes from 192.168.2.202: icmp_seq=2 ttl=64 time=1.72 ms
And how to do it:
prolong "set CMDLINE" line with
ip=192.168.2.202:192.168.2.200:192.168.2.200pal:usb0
But in this image there doesn't seem to be any telnet/ssh server running. I will try cook image with ssh server support later

Download error
Were not able to re-upload

404 file not found error!!

http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/
and open latest gizard-<date>.tar.bz2
or that I suppose.
The latest link should be http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/gizard-20090703.tar.bz2

does this mean any chance of android working? anyone tried?

Hey,
I'm a new Opal user and I'm interested in getting *nix running on my device. I still haven't had the chance to mess around with this stuff but I'm excited to see this thread.
I was looking into the possibility of running Android on the Opal and it seems the closest thing is this thread bout running it on the Herald (it uses the same processor as the Opal).
I don't any experience in Linux porting so I thought I'd share this, in case anyone else is interested. And at the same time, I'll try to see if I can get something working based on what has been/is being done for other devices.
Sorry for the long post.

Hey Folks,
Any progress on getting Android on Opal? I am eagerly waiting to load one.
Kindly let me know, if this version of Linux when loaded, gives the UI.
Cheers'
Vijay
cijoml said:
Hi there
I got Linux to boot at OPAL via linwizard project. Here are steps needed to get it work.
1) download image from:
http://tinderbox.x86.dev.gentoo.org/embedded/linwizard/gizard-20080602.tar.bz2
2) copy content of file to the microSD card
3) edit default txt and replace init=/linuxrc with init=/bin/sh
4) run haret and let it boot.
After a while you'll get to shell. No graphics.
Now you can attach microusb cable and connect it with your linux laptop (I recommend ubuntu)
and you will get usb0 interfece to start up.
Which IP to use to connect with OPAL I still must investigate.
Click to expand...
Click to collapse

Android can boot on Opal
I have some good news, Android can boot on the Opal. This is just a proof of concept as it's missing tons of drivers and is completely useless.
Touchscreen and all keys except for the volume control (and obviously the reset button) are not working. So you basically can't do anything when you run it.
What I tried is the same as what's written in this thread about running Android on Gene. They're using the build made for the Herald/Wing (just as I was proposing in my last post) with customized initramfs and kernel.
You'll find all the necessary details in that thread. However, there's a newer build than the one mentioned there it's wing-linux-0.4pre2.cab. And the suitable kernel for that build is supposed to be the pre2 posted in this post but it didn't work on my Opal so I tried the older Gene kernel and it worked. The main difference between the two is bluetooth support, and that's obviously is of no use for us.
This doesn't effect the Windows rom, nor does it requires any special partitioning. Still it's best to have everything backed up before launching it, just in case.
This is the official site for the wing/herald build:
http://wing-linux.sf.net/
This thread on their forums about the Gene port will probably be of use to us:
http://sourceforge.net/apps/phpbb/wing-linux/viewtopic.php?f=4&t=4
I'm reading about the next steps but as I said before, I don't have any previous experience or knowledge about this type of things. If someone can give me hand, I would be more than grateful. At any rate, once I have better understanding of the concept I'll contact the people behind the Wing and the Gene ports.
P.S: If you do try to run this, keep in mind that this will take lots of time, specially for the first launch. And when you get an error saying something like "android sh: can't access tty" just ignore it and keep waiting. After a while you'll have a flashing "android" on the screen, and after some more waiting you'll reach the main screen.

Is this just THE BEGINNING
Sooper Stuff..!! So is this just THE BEGINNING??
How do we port the drivers and other required information in the build?
Cheers'
Vijay
www.msigeek.com

A Lil' help
I'm going through the Gene port thread here and on the Wing-linux sourceforge forums but I'm still a bit overwhelmed.
I would appreciate any help as I'm completely new to porting. I have some programming and linux knowledge but never attempted this type of things.
Click to expand...
Click to collapse
So am I.
Hmmm...
Right. Lets do it the way I did it.
1. Get the touchscreen working. Through HaRET, you must have got the GPIO interrupt whenever you pressed the touchscreen. You must have got two numbers corresponding to each press - a smaller number and a bigger number. The smaller number is the GPIO, and the larger number is, well, lets say a special GPIO value for the same pin.
Now checkout the Gene branch through git.
Goto /wing-linux/kernel/arch/arm/mach-omap1/board-htcherald.c
Scroll down to a block of code where you'll see the touchscreen code. Enter the smaller number in the .dav_gpio statement, and the IRQ number in the OMAP_GPIO_IRQ() statement below.
2. Follow the Kernel build instructions on the development section of the wing-linux wiki (the two make commands)
Copy the zImage into the linux folder on your SD card
Boot into wing-linux. The touchscreen should start working.
3. Now, hopefully, after the touchscreen's working, You would essentially just require two more buttons - the home button and the back button for minimum functionality. Everything else can be worked on by the touchscreen.
Then follow the instructions on the wing-linux forum (Page 2) to get the KEY(row,col) values of the keys on your handset. Hopefully you should get atleast a couple. Note down the corresponding keys and their KEY(r,c) values output.
4. Fire up board-htcherald.c again and goto the place where you have the KEY(r,c,KEY_blah) thing and replace the codes as per your obtained KEY(r,c,KEY_blah) values (The Home button is the one commented as Left Button)
5. That's all I can help you with as of now. I'm also figuring out a stable way of getting the DPad and the center select key to work, but It'll take some time.

Thanks kshaurya!
(This guy right here is the one who fixed the kernel for Gene, I asked him for some pointers).
I don't want to take my device apart just yet (I usually do my best not take to dismantle anything that I haven't owned for at least 3 months unless absolutely necessary) and I couldn't find a place that states what touchscreen it uses. I'm just hoping that it's the same a tsc2046 as well. [Is there anyone without a warranty and/or willing to check for us?]
I'm gonna double check the values I got from the touchscreen as for some reason I seem to have to IRQ values, probably forgot to get rid of some spamming irq. And, at the same time, I'm currently setting up a VM as a building environment, my main boot is Intrepid 64 and there's no 'psyco' package for 64 machines.
If anyone else have some experience and wants to try this, refer to: http://www.handhelds.org/moin/moin.cgi/HaRET_20Documentation (using haret to get the GPIO and IRQ values needed).
And to:
http://sourceforge.net/apps/trac/wing-linux/wiki/Development (acquiring the source code from Wing Linux and how to build it).
And a quick question for anyone that tried booting Android on the Opal, what screen did you get when Android finally finished booting?

I don't want to take my device apart just yet
Click to expand...
Click to collapse
Huh? where did that come from? Wing Linux will not touch your WM.
I seem to have to IRQ values
Click to expand...
Click to collapse
Do you mean two? Well, that's exactly what you should get. Even if it's just one, enter that value in the code.
my main boot is Intrepid 64 and there's no 'psyco' package for 64 machines
Click to expand...
Click to collapse
Oh no. dont tell me that you are building the entire thing. all you need to do is build the KERNEL! Please! Don't go into building the whole thing from scratch. Use the make ARCH ARM commands given on that page.

kshaurya said:
Huh? where did that come from? Wing Linux will not touch your WM.
Click to expand...
Click to collapse
I mean to check the screen, in case it turned out to be different that what you have.
kshaurya said:
Do you mean two? Well, that's exactly what you should get. Even if it's just one, enter that value in the code.
Click to expand...
Click to collapse
Yeah, stupid typo.
I noticed now that one of them appears when I keep the screen 'touched' for a bit longer.
kshaurya said:
Oh no. dont tell me that you are building the entire thing. all you need to do is build the KERNEL! Please! Don't go into building the whole thing from scratch. Use the make ARCH ARM commands given on that page.
Click to expand...
Click to collapse
I'm not gonna build the complete thing. Seems like I got too exited and failed to notice that building the kernel only requires a cross-compile toolchain, te rest is for compiling the whole thing.
I'm not THIS stupid usually . Honestly!
Thanks again!

I'm not THIS stupid usually . Honestly!
Click to expand...
Click to collapse
Its pretty normal

Weird.
I've only changed the two touchscreen values and built the kenrel. It finished without any error but now it won't boot.
It gets stuck, even before the space allocation part, with this error: "sh: can't access tty; job control turned off". And then it displays a prompt.
I'll try modifying an older build, I'm pulling them from the repos at the moment.
After all, the pre2 kernel from Gene didn't boot on my device (although it got stuck later on).

Try doing a clean install - Remove the linux folder and try again.
Also, make sure that you're not forgetting to checkout the Gene branch.
Code:
git checkout Gene
Is your default.txt modified? And have you downloaded the modified initramfs.cpio?
check in the Gene forums for that.

Already tried the clean install, no dice. The default.txt is untouched and I'm using the modified intramfs. What happened this time is different from what happens using the original one, it's not asking me to specify the partition size but instead it's waiting for a command. I could probably ssh via usb but I have no clue how that might help.
And I've already checked out the Gene branch from the beginning.
I've tried compiling the kernel for pre1 (after changing the screen values) from SVN and it did boot (both using the cabs for pre1 and pre2) but no touch screen yet. All in all, I'm guessing that there's too much hardware difference here.
And the button for lowering volumes didn't work either, it seems like whatever you changed for getting it to work on Gene is the same as what we need here, but I'll think about that later.
I only have two ideas left:
- Trying to go back to a more stable build (with lesser features and lesser possibilities for errors). Maybe 0.3.
- Trying to create some kind of hybrid kernel using this alongside the HTC Vogue build as it probably has closer hardware to the Opal (obviously, I'm talking about everything beside the MSM7500 400MHz processor that it has). I'm hoping it won't get to this cause I'm definitely under qualified for that at the time being.

What happened this time is different from what happens using the original one, it's not asking me to specify the partition size but instead it's waiting for a command.
Click to expand...
Click to collapse
Could you post a screenshot?
I've tried compiling the kernel for pre1 (after changing the screen values)
Click to expand...
Click to collapse
I'm assuming you mean the touchscreen values? Try interchanging and see.
Trying to go back to a more stable build
Click to expand...
Click to collapse
I wouldn't recommend that. Defeats the whole purpose.
Why don't you try getting in touch with darkstar?

kshaurya said:
Could you post a screenshot?
Click to expand...
Click to collapse
A friend borrowed my digital camera, I tried my laptop's webcam but the text it too blurry. Couldn't fix it using gimp either. So here's exactly what's showing on the screen:
Code:
mdir: Cannot creat directory `/mnt' : File exists
modprbe: could not parse modules.dep
initramfs: Creating device nodes:
initramfs: Loading /initrd.d/10-initfs.sh module
initramfs: Loading /initrd.d/30-wingboot.sh module
Selected:
ROOT_DEVICE=/dev/
CMDLINE=debug quiet psplash=false loglevel=7 init=/sbin/init console=tty0 video=omapfb:accel fbcon=rotate:3 4 root=/dev/
initramfs: Loading /initrd.d/80-loopboot.sh module
initramfs: Loading /initrd.d/85-blockboot.sh module
booting from: /dev/
mount: Mounting /dev/ on /mnt failed: Invalid argument
Unable to mount rootfs device
sh: can't access tty; job control turned off
/ $
And after the prompt, on the same line, there's a flashing '_' waiting for input.
Using the original zImage (from the pre2 cab) it's right around here that the screen clears and the Wing Linux installation script kicks in.
kshaurya said:
I'm assuming you mean the touchscreen values? Try interchanging and see.
Click to expand...
Click to collapse
Will try that next.
kshaurya said:
I wouldn't recommend that. Defeats the whole purpose.
Click to expand...
Click to collapse
I meant it as just a temporary test to till the cause of the incompatibility is figured out. With less things that could go wrong, it'll be easier to locate the ones that are going wrong.
kshaurya said:
Why don't you try getting in touch with darkstar?
Click to expand...
Click to collapse
You're right. I should post a thread on the project's forums asking for his help.

NVidia BCT File aka Binary Configuration Table.

Hi everyone,
I'm currently working with a Devboard NVidia Tegra 250 Harmony DevKit since about a year.
I've past my year to study Tegra's architecture and comportment on high level abstraction layers, using my GNU/Linux (Debian distrib) on it.
Now I'm working to understand this board a little more deeper, and now a day, I'm facing some problem with it.
Indeed, I'm currently trying to understand what it is this Binary Configuration Table binary.
About my research, it seems to be a Firmware like which is in charge of DDR Memory controller and Bootloader call.
So, my first question is: Am I on the right way with this definition?
Secondly, why did NVidia do this crappy thing??? I mean, there is no any other company working with ARM which choose to use this thing.
I also have a TI Omap based board, and there is no such thing on it.
Well, if anyone has informations/documentations/Links, I'll be happy to read them.
I've searched about this on Google, and for now, the only interesting things that I've found are coming from TrimSlice Wiki and xda-developers forums.

BCT is more commonly referred to as Boot Configuration Table.
It contains a large number of configuration options, among them location, size and load address of the boot loader.
Have a look at the bct_dump tool in the cbootimage repository.

Many thanks for this informations.
So, basically, I've download the L4T package, and just try to replace the default fastboot.bin with my cross-compiled u-boot for Tegra250.
Unfortunatly, it's not working at all :-(
My problem is the following one:
Code:
Nvflash started
rcm version 0X20001
System Information:
chip name: t20
chip id: 0x20 major: 1 minor: 2
chip sku: 0x8
chip uid: 0x097c81c641816097
macrovision: disabled
hdcp: enabled
sbk burned: false
dk burned: false
boot device: nand
operating mode: 3
device config strap: 0
device config fuse: 0
sdram config strap: 0
sending file: static.bct
- 4080/4080 bytes sent
static.bct sent successfully
downloading bootloader -- load address: 0x108000 entry point: 0x108000
sending file: uboot.bin
| 173920/173920 bytes sent
uboot.bin sent successfully
waiting for bootloader to initialize
and then, I can wait for a looooonggg time for nothing, it seems that the uboot.bin doesn't do anything while the default fastboot.bin (900kb) correctly execute the next step on the script.
Is there any trick to do to be able to have a debug output?

eppeP said:
BCT is more commonly referred to as Boot Configuration Table.
It contains a large number of configuration options, among them location, size and load address of the boot loader.
Have a look at the bct_dump tool in the cbootimage repository.
Click to expand...
Click to collapse
If that is the case, OMAP4 does have something similar, the Configuration Header. http://nishanthmenon.blogspot.com/2009/05/configuration-header-no-more-x-loader.html

eppeP said:
BCT is more commonly referred to as Boot Configuration Table.
It contains a large number of configuration options, among them location, size and load address of the boot loader.
Have a look at the bct_dump tool in the cbootimage repository[/URL].
Click to expand...
Click to collapse
-MANY MANY MANY thanks for this URL, I was looking for this software for a long time.
I've been able to read and generate new BCT with it now
But, I'm still unable to boot on U-Boot :-(
Entropy512 said:
If that is the case, OMAP4 does have something similar, the Configuration Header.
Click to expand...
Click to collapse
Yep, exactly, but basically, NVidia is less complicate in the load process but the way they handle the ROM boot and bootloader call is really crappy
I'm still investigating on my board, I really want to replace the fastboot with U-boot and push my whole system on NAND.

DR I said:
-MANY MANY MANY thanks for this URL, I was looking for this software for a long time.
I've been able to read and generate new BCT with it now
But, I'm still unable to boot on U-Boot :-(
Yep, exactly, but basically, NVidia is less complicate in the load process but the way they handle the ROM boot and bootloader call is really crappy
I'm still investigating on my board, I really want to replace the fastboot with U-boot and push my whole system on NAND.
Click to expand...
Click to collapse
Any progress on it yet ?
Sent from my HTC One X

tids2k said:
Any progress on it yet ?
Click to expand...
Click to collapse
I've made some progress, but the way NV do not share at all this kind of informations is a little bit sad :-(
I go forward step by step, I currently trying to build my own BCT based on the one provided by NVidia on it's L4T and CBootImage, but it seems to have some tricky things to know with the default BCT.
Mine is not compiling, CBootImage do not want to eat it
I'll gonna do some test tonight.
I let you inform of any evolve.

DR I said:
I've made some progress, but the way NV do not share at all this kind of informations is a little bit sad :-(
I go forward step by step, I currently trying to build my own BCT based on the one provided by NVidia on it's L4T and CBootImage, but it seems to have some tricky things to know with the default BCT.
Mine is not compiling, CBootImage do not want to eat it
I'll gonna do some test tonight.
I let you inform of any evolve.
Click to expand...
Click to collapse
thats good news, as far as with my understanding the tegra 3 follows the same chip architect and we would be able to debug with the same resources and might be able to induce a different BCT over the partial layer, thus giving access to an unsecured bootloader like UBOOT ?

tids2k said:
thats good news, as far as with my understanding the tegra 3 follows the same chip architect and we would be able to debug with the same resources and might be able to induce a different BCT over the partial layer, thus giving access to an unsecured bootloader like UBOOT ?
Click to expand...
Click to collapse
Yes, indeed, I should now be able to do that, BUT, keep in mind that you have to sign your bootloader with csign before loading it on the Tegra DevKit.
This sounds completly crazy for me because the purpose of this board, as it's named, should be to DEVEL on it and then, you need to sign your bootloader?? C'mon NVidia, this is completly nuts, I don't really know if I'll continu to support and use their DevKit, I don't have time to waste with those kind of proprietary things.
If you're also working on that kind of board, we probably should help each other

Hi everyone,
I've been granted by NVidia to access their TRM so now I should be able to perform everything I want on the board.
So, I'll retry to install the u-boot during the week-end and see what's going on when I try to load it into the board.
So far, I've not been able to put anyone of my baremetal programs into the board and u-boot neither.
Sent from my Galaxy Nexus using XDA

What an expert said about eMMc bug!

In case that someone missed it
(tnx to user garwynn)
Fresh off the press...
Q: Do you know the commands to reset the eMMC controller in question?
Originally Posted by Ken Sumrall (Android)
Once the chip has locked up, no command will reset it. It must be power cycled. If instead you are asking how to clear the metadata so the chip works again, the only solution I know is to update the firmware inside the chip, and that also wipes all the data. This probably includes factory calibration data that must be saved before the firmware is updated, and restored after. Also, the boot loader is probably in the chip, and must be restored after the firmware update, or the device will be bricked. This is a dangerous operation, because if something goes wrong, the device will probably be bricked. (emphasis added)
Q: Is there any documentation available on this issue? If so and it is private is it possible to have it released?
Originally Posted by Ken Sumrall (Android)
It is private, I'm asking if I can release it, along with the code to update the emmc firmware. Don't get your hopes up, my guess is the answer will be no.
Q: Alternate erase method?
Originally Posted by Ken Sumrall (Android)
If you really want to erase data on a rev 0x19 samsung emmc chip, I suggest you just write zeros to the entire partition.
Q: Difference between GB/ICS Wipe
Originally Posted by Ken Sumrall (Android)
IIRC, when using recovery to wipe the phone on GB, the make_ext4fs() library would not issue an erase command first, it would just write one a new blank filesystem. This, of course, doesn't really erase all the private data of the user, so we changed make_ext4fs() to first erase the partition, then write out the new filesystem. You can see the code in system/extras/ext4_utils/wipe.c, which didn't exist in gingerbread, but does in honeycomb and later. It is the erase operation on the rev 0x19 firmware that can cause the emmc chip to lockup. (emphasis added)
Regarding Entropy512's summary of observations:
Originally Posted by Ken Sumrall (Android)
Regarding the notes on MMC_CAP_ERASE, the just lists the cards ability to perform the erase command. In other words, if the mmc_erase() function works. What is more important is if anyone calls the mmc_erase() function. Looking at the mmc driver, in drivers/card/block.c, it is only called when a secure discard or discard request is made. As far as I know, those requests are only sent if the filesystem is mounted with the "discard" option, or if userspace code does an ioctl() to erase a partition, like make_ext4fs does. So check the mount options on the filesystems. *If they don't specify "discard", the erase operations are probably not happening.
Of course, a simple debugging printk() in the mmc_erase() function will tell you if anyone is calling it.
Additional info not directly related to questions:
Originally Posted by Ken Sumrall (Android)
The lockup doesn't happen immediately after power-on. The chip doesn't lock up until a sector is referenced that has corrupted wear leveling data inside the chip. Once that sector is referenced, the chip will lockup hard, and the only thing that will get it talking again is to power cycle it. Once it is power cycled, the chip will talk again, until that bogus sector is accessed.
http://forum.xda-developers.com/showpost.php?p=26521643&postcount=293

So, absolutely no CWM wipe for Note, until we got a solution? Maybe change custom ROM CWM wipe as write zeros or delete all files instead of file system format?

It just seems crazy that Samsung/Google cannot release a small file to flash that would fix this problem. I'm sure they could if they really wanted to.

I am asking Samsung Singapore about the eMMC bug on their facebook page. Hope to get some info on whether the bug is proliferating across region ICS versions or have they actually silently fixed it.

for what the note is worth and they sold millions it should be fixed now this is putting me off getting another samsung ,which i really do like them it feels like they have let us down

It is not just the Note, it is all Eyxnos based Samsung phones including the GSII. I could be wrong, but I think they sold a few of those...
It is not just CWM wipe that is the problem. You can brick performing a factory reset on official XXLPY (and all official ICS kernels so far... and all leak ICS kernels). The only safe kernels are those based on GT-I9100 Update4 source code release - this includes XplodWILD's CM9 release (and it's derivatives such as Asylum, Paranoid, MIUI) and Entropy's DAFUQ and that other WizDom kernel with more to come now that there is source available.
FYI, the N7000 source even has the MMC_CAP_ERASE bug. Just look at Franko's kernel thread.

Global recall lmao
Sent from my GT-N7000 using Tapatalk 2

nickshertzer said:
It is not just the Note, it is all Eyxnos based Samsung phones including the GSII. I could be wrong, but I think they sold a few of those...
It is not just CWM wipe that is the problem. You can brick performing a factory reset on official XXLPY (and all official ICS kernels so far... and all leak ICS kernels). The only safe kernels are those based on GT-I9100 Update4 source code release - this includes XplodWILD's CM9 release (and it's derivatives such as Asylum, Paranoid, MIUI) and Entropy's DAFUQ and that other WizDom kernel with more to come now that there is source available.
FYI, the N7000 source even has the MMC_CAP_ERASE bug. Just look at Franko's kernel thread.
Click to expand...
Click to collapse
And the devs on here, now that they have a source, will eventually remove that MMC_CAP_ERASE code from the kernel. Just give them some time. If Samsung won't do anything, then we at XDA will make the best of what we can. And I say Samsung and not Google because the ball really is in Samsung's court, not Google's.

wasnt this published a little while ago on the portal?

panyan said:
wasnt this published a little while ago on the portal?
Click to expand...
Click to collapse
Yes, it was.

So that makes sense FINALLY. GB never did a true wipe, sorta like a soft format pc. Can we just modify the ics kernels to mmc_erase() as how gb runs it and get rid of the new code? This is a temporary work around.

PoisonWolf said:
Can we just modify the ics kernels to mmc_erase() as how gb runs it and get rid of the new code? This is a temporary work around.
Click to expand...
Click to collapse
that was my exact thoughts too as i was reading it -> just do a quick wipe and not full erase

panyan said:
that was my exact thoughts too as i was reading it -> just do a quick wipe and not full erase
Click to expand...
Click to collapse
Yeah, like how Ken talked about Honeycomb and forward having wipe.c, let's just get rid of that nonsense.
I dont know how it works, but if you're on Gingerbread, and you encrypt your phone, and you do a full-wipe in CWM, can a person still access the data? I mean, we now know that they could with the right tools since the information is still on the chip, just not easily accessible. But if it is encrypted, can it be decrypted and accessed? I guess what's the encrypting algorithm and is it the same for all devices?
If the information cannot be accessed if it is encrypted, then paranoid folks shouldn't have to worry with soft wipes.
Can anyone confirm that a 32 GB Note shipped with the same 0x19 firmware on the emmc?

Markuzy said:
I am asking Samsung Singapore about the eMMC bug on their facebook page. Hope to get some info on whether the bug is proliferating across region ICS versions or have they actually silently fixed it.
Click to expand...
Click to collapse
Well don't hold your breath that would mean that Samsung has made a BIG mistake in their's firmware's and that would produce lots of anger and sales drop.
I think IF they decide that they will eventually fix this it would be in big quiet and just like part of "new" firmware like 4.0.4 etc

panyan said:
wasnt this published a little while ago on the portal?
Click to expand...
Click to collapse
andreww88 said:
Yes, it was.
Click to expand...
Click to collapse
Where? This was written yesterday so i don't know what is exactly "little while ago" ?

Additional info not directly related to questions:
Originally Posted by Ken Sumrall (Android)
The lockup doesn't happen immediately after power-on. The chip doesn't lock up until a sector is referenced that has corrupted wear leveling data inside the chip. Once that sector is referenced, the chip will lockup hard, and the only thing that will get it talking again is to power cycle it. Once it is power cycled, the chip will talk again, until that bogus sector is accessed.
Click to expand...
Click to collapse
This concerns me the most. Is there any way to "test" all sectors of the phone's emmc to see if we have the bogus sector?
Like a terminal command to create a file of X size so you could "fill" up the entire phone with a bogus file. Could this work?

PoisonWolf said:
This concerns me the most. Is there any way to "test" all sectors of the phone's emmc to see if we have the bogus sector?
Like a terminal command to create a file of X size so you could "fill" up the entire phone with a bogus file. Could this work?
Click to expand...
Click to collapse
Yes that would be very useful, to actually check if our phones are already damaged ...

Hm, makes me wonder about some peoples SODs

GocaS6 said:
Where? This was written yesterday so i don't know what is exactly "little while ago" ?
Click to expand...
Click to collapse
http://www.xda-developers.com/android/hard-brick-bug-on-galaxy-s-ii-and-note-leaked-ics-kernels/

panyan said:
http://www.xda-developers.com/android/hard-brick-bug-on-galaxy-s-ii-and-note-leaked-ics-kernels/
Click to expand...
Click to collapse
If you read it carefully you'll notice that this is not same conversation

MMC_CAP_ERASE Verification

Chainfire kindly created a small app that verified and displayed the firmware revision number - 0x19 being the fatal version. Almost all of our GN's have this firmware revision and basically this means that all of our Gn's can be bricked. For the moment we do not have the possibility of upgrading the firmware so we are stuck with this as a "feature".
However it be interesting to know if the currently installed kernel possesed MMC_CAP_ERASE functionality or not, since it is the Kernel that "intitiates" the bricking process.
Does anyone know if it would be possible to create such an app ?
I can imagine the scenario where one day a kernel is released which has MMC_CAP_ERASE functionality active but that the kernel is annonced as having it inactive or vice versa.
It would also allow us to know when the official kernels will have this functionality removed.
Unfortunately I do not have experience/knowledge necassary to write such an app.

Roy_W said:
Chainfire kindly created a small app that verified and displayed the firmware revision number - 0x19 being the fatal version. Almost all of our GN's have this firmware revision and basically this means that all of our Gn's can be bricked. For the moment we do not have the possibility of upgrading the firmware so we are stuck with this as a "feature".
However it be interesting to know if the currently installed kernel possesed MMC_CAP_ERASE functionality or not, since it is the Kernel that "intitiates" the bricking process.
Does anyone know if it would be possible to create such an app ?
I can imagine the scenario where one day a kernel is released which has MMC_CAP_ERASE functionality active but that the kernel is annonced as having it inactive or vice versa.
It would also allow us to know when the official kernels will have this functionality removed.
Unfortunately I do not have experience/knowledge necassary to write such an app.
Click to expand...
Click to collapse
Not an Android developer, but my educated guess is that it will be improbable, if not impossible, to build such an App. As I understand it, this property is embedded in some .c code of a Kernel, so not possible to read it via an App. If this property is stored in some config file which Kernel reads/uses then possibly an App can be written to read the same config file. As I said, not a dev in this field.

Good idea! Not an expert in the field either, but I believe some kernels have their settings available at /proc/config or /proc/config.gz, but that's not necessarily the case (depending on settings actually used at compilation). I'd also venture guessing that Samsung kernels don't do it , but can't check as I'm on a CM9-based ROM right now. We would need to check if any of the two locations above exist using a Samsung kernel.
Well that's one way to go around it anyway, there may be others

cooldoud said:
Good idea! Not an expert in the field either, but I believe some kernels have their settings available at /proc/config or /proc/config.gz, but that's not necessarily the case (depending on settings actually used at compilation). I'd also venture guessing that Samsung kernels don't do it , but can't check as I'm on a CM9-based ROM right now. We would need to check if any of the two locations above exist using a Samsung kernel.
Well that's one way to go around it anyway, there may be others
Click to expand...
Click to collapse
Samsung kernels do not enable /proc/config.gz
In addition, even if they did, MMC_CAP_ERASE is a flag within the source code of mshci.c - not a config item in the defconfig.
The only way to check if MMC_CAP_ERASE is present is to attempt to issue an erase command and see if it returns an error or not... The problem with this approach is pretty obvious...
There's no way to verify that a recovery or update-binary is safe without testing it against an instrumented kernel.
There's no way to verify that a kernel is safe without performing dangerous tests. It might be that a small erase is far less likely to cause damage than a large one - but this is too risky.

Entropy512 said:
In addition, even if they did, MMC_CAP_ERASE is a flag within the source code of mshci.c - not a config item in the defconfig.
Click to expand...
Click to collapse
Oh well, bad suggestion it seems, didn't think this was so deep the source. Thanks for the knowledge sharing though!

Byte code signature
From what I now understand MMC_CAP_ERASE is a flag that is either set or not.
If a kernel was compiled with the flag set and then the same kernel was compiled with the flag unset, would this not allow for a byte code signature to be detected.
This byte code signature could then be used in a binary search of an installed kernel.
This is guess work on my behalf and I could be completely wrong with my approach .

Roy_W said:
From what I now understand MMC_CAP_ERASE is a flag that is either set or not.
If a kernel was compiled with the flag set and then the same kernel was compiled with the flag unset, would this not allow for a byte code signature to be detected.
This byte code signature could then be used in a binary search of an installed kernel.
This is guess work on my behalf and I could be completely wrong with my approach .
Click to expand...
Click to collapse
Too much else changes from kernel to kernel. It's one bit set in a single variable, it's not like the MC1N2 initialization data which are huge fixed data structures.
Searching for a single bit set in a single integer variable when you don't know where that int is stored is impossible to reliably do.
Sent from my GT-P7510 using Tapatalk 2

mmc->caps
Entropy
I have googled copy of the mshci.c file and I see that the MMC_CAP_ERASE of used in order to initialise or not a struct named mmc->caps.
I can't find the declaration of mmc->caps but would it be possible to interogate
mmc->caps in order to read it's current state. This would allow us to see if the MMC_CAP_ERASE had or not been included in its initilisation ?
R

this is nearly impossible. yes there are ways to do it but i will take too much time and effort and will not worth it. my advice is look kernels which states it removed that flag like speedmod. if you want to be sure about the official kernels you need to wait until samsung releases source codes so you can look if that flag is set or not.

Having given a little bit more thought to the replies.
1 : The mmc-caps is a struct that is held at the kernel level.
2 : The Andoird SDK does not provide APIs that allow us to directly obtain information from the kernel level.
Therefore not an easy program to write.
Question : What method/language/technique would Chainfire have used in order to read the firmware level when he wrote his app?

Roy_W said:
Having given a little bit more thought to the replies.
1 : The mmc-caps is a struct that is held at the kernel level.
2 : The Andoird SDK does not provide APIs that allow us to directly obtain information from the kernel level.
Therefore not an easy program to write.
Question : What method/language/technique would Chainfire have used in order to read the firmware level when he wrote his app?
Click to expand...
Click to collapse
The chip cid/name are exported in the sysfs even on stock kernels. The fwrev is part of the cid string.
That capabilities variable, I am fairly certain, is not exported anywhere in sysfs. One could add exporting of it to the source, but that's kind of pointless - it's easy enough to verify open source kernels for safety, it's Samsung's binaries that are difficult.

Thanks for replying guys, you have made things clearer.
This bug is interesting even though it is potentially fatal.

Unlock bootloader without SD card

Hello and thank you to anyone that can point me in the right direction.
I was recently given a Note 3 from a friend and for whatever reason it will not detect any SD card. The SD cards are fine and work in my other Android phones, Windows computers and anything else. So aside from that, is there any way to unlock the bootloader on this phone without the use of an SD card? All the methods I've come across mention one is needed. Thanks.

NM. I think I found what I was looking for here.

riotstarter said:
NM. I think I found what I was looking for here.
Click to expand...
Click to collapse
Possibly* a lesser-effort way - same thread, but here.
I say "possibly" because you didn't state which OS release was on the phone. (I can assume MI9->NC4, OB6, or OF1 as you must be rooted. NJ6, NK1, and PL1 are - as of this time - problematic for easy rooting).
There were some dependencies of the exploit code on OS version due to the location of the "CID" value moving around inside the kernel volatile filesystem /sys. You might have to take account of that in building/modding the code. (Either that or just get rid of the CID check if you know that you have a 0x15 eMMC chip device). Unfortunately, you need to thoroughly read about the first 350 posts in that thread to completely understand the discoveries that were made.
Anyway, some pointers to version compatibility are here.
* @beaups code is very straightforward. (@donc113 's mods of that code have the correct binary patching blob for the SM-N900V - beaups's github code was for the AT&T version of the phone) You probably will have more troubles setting up a toolchain than actually modding or compiling the code if you go that route.
good luck.
ps good to see someone in here that's not afraid of a compiler

bftb0 said:
Possibly* a lesser-effort way - same thread, but here.
I say "possibly" because you didn't state which OS release was on the phone. (I can assume MI9->NC4, OB6, or OF1 as you must be rooted. NJ6, NK1, and PL1 are - as of this time - problematic for easy rooting).
There were some dependencies of the exploit code on OS version due to the location of the "CID" value moving around inside the kernel volatile filesystem /sys. You might have to take account of that in building/modding the code. (Either that or just get rid of the CID check if you know that you have a 0x15 eMMC chip device). Unfortunately, you need to thoroughly read about the first 350 posts in that thread to completely understand the discoveries that were made.
Anyway, some pointers to version compatibility are here.
* @beaups code is very straightforward. (@donc113 's mods of that code have the correct binary patching blob for the SM-N900V - beaups's github code was for the AT&T version of the phone) You probably will have more troubles setting up a toolchain than actually modding or compiling the code if you go that route.
good luck.
ps good to see someone in here that's not afraid of a compiler
Click to expand...
Click to collapse
Thanks I appreciate the response. Yes I am on OF1 with a 0x15 chip. I've downloaded donc113's file and Android SDK/NDK. Does donc113's mod of the code already include what I'd be needing the SDK/NDK for? I'm definitely not afraid of trying something unfamiliar, I just want to ensure I'm doing it right. I'll do some more digging and see if I can figure things out a little more.

riotstarter said:
Does donc113's mod of the code already include what I'd be needing the SDK/NDK for?
Click to expand...
Click to collapse
Should be. Really the only thing you should check to see is if the path in /sys to the CID file on your OF1 phone is one of the paths that he is checking for. You can use the "strings" command for that.
OK, I just downloaded his code and did that ("strings" command). Here are the paths he is searching:
Code:
/sys/devices/msm_sdcc.1/mmc_host/mmc0/mmc0:0001/cid
/sys/devices/platform/msm_sdcc.1/mmc_host/mmc0/mmc0:0001/cid
/sys/class/mmc_host/mmc0/mmc0:0001/cid
/sys/devices/msm_sdcc.1/mmc_host/mmc1/mmc1:0001/cid
If OF1 uses one of these, then you don't even need to compile anything, just run the binary.**
**there is a brutal form of "avoid compiling" hackery where you simply perform a binary edit of an executable file in order to change a constant value in the code such as a string. So long as the replacement string is shorter than the original, you can just replace the string and null-pad the unused length (as strings are assumed to be null-terminated in C). For example, if there was a pathname in a .bss or .rodata segment such as
Code:
/foo/original/path/filenameX
/bar/replacement/myname\0\0\0\0\0
this works so long as the replacement string's bytelength is less than or equal to the length of the original string. (And the code is not performing a signing or other integrity check of itself.)
Only to be used when you don't have the code to be compiled or emergencies such as when you are in a hurry LOL.
(Obviously you can not shorten or lengthen the file at all doing this: all the byte offsets in the file must remain unchanged).

https://forum.xda-developers.com/showthread.php?p=71448959
Sent from my SM-N900V using Tapatalk

Am on Sm-n900v (Rooted)
Android 5.0
0B6.
Want to unlock bootloader but need some strict instructions