Danger of Bricking a Device

#1

I would like to refer to (this quote refers to N2 images and is just an example)

Disclaimer: DO NOT attempt to install these images on any other device, as doing that will brick your device.

as an example of what I am asking about.

In what way is this dangerous?
How would a different image brick a device? … what would it do that would screw up the device beyond recovery?
Is the danger in the dtb file? (presuming there is one)

Thanks for any info available.

#2

It’s more of a warning to people who have CE installed to internal, as the uboot will be overwritten and the box will not boot again.
In any case, currently the 4.9 kernel is not going to work with any older SoCs.

#3

Thank you for responding. I believe you have answered my question, but for explicit clarity you might let me know if the following is true …

Inserting and booting an SD card with any CE image written to it will not brick the device.

It is only when performing such actions as installtointernal, which overwrites the original structure (partition) and files (bootloader?) of the device that problems arise.
If this is the case, then would having an image of what was on the internal drive be of use to recover such an event?

I apologise if I seem to be pedantic.
Bricking to me previously meant hardware damage, as all others were recoverable in some way if prepared for the worst.

#4

If you were to burn a N2 image to an SD card and try to boot it from a S905X or S912 box, you’d probably just end up in a boot loop (or black screen) until you remove the SD. It shouldn’t affect the internal install, but I can’t guarantee that it will not mess something up. Better not do it.

#5

Thank you :wink:

There are no guarantees in life except taxes and death! :smiley:

1 Like
#6

I would further point out that the N2 has its EMMC on a removable card (which you have to buy separately anyway).

This gives you the same recovery opportunity with EMMC that other boxes with soldered down EMMC must use an SD card for.

Thus, even if you were to install a disastrous image or update to it, all you have to do is take the EMMC card back to your PC and flash a stable version onto it. (Hint: buy an EMMC reader/writer card from the N2 vendor so you can update any card you have on your PC/Mac)

In an abundance of caution I bought two blank EMMC cards and a reader/writer so that I could have a ‘safe’ copy I could just drop in if the experimental one turned bad. The minimum to be safe is one EMMC card and a SD card or USB adapter to read/write it. The spare EMMC is just for convenience.

Since even the u-boot is on the EMMC card, there is basically nothing you can do to an N2 (short of a hammer) that will make it unrecoverable. I know, when you make something foolproof, someone will come up with a better fool. But if you can flash an SD card, you can flash EMMC (with the adapter) and thus fix almost any mistake.

#7

Good info there … but the point of the question was about installing the N2 image on other devices, rather than the reverse.

Thanks for the info. :wink:

#8

Ah! I failed to appreciate that you really wanted to use the image on a different type of device rather than concern about bricking the device through some error. Sorry for the unnecessary deviation from your real question.

#9

Since the N2 image is for one specific device, is it not possible to add a check that the device is actually an N2 to the image installer? There would be no risk at all then :thinking:

#10

The check would have to be added to the image currently running on the device, which is currently problematic, as 9.0.1 has been out for a while now and it doesn’t have this check.

#11

Do the images of themselves write to the internal when booting and running from SD?

If not then I do not understand how any image on an SD card can brick any device.

I guess that is at the heart of what I was asking … as I have no idea about the behaviour of the image.

#12

Surely that cant be the case for the new install image though, since there would be no existing CE installation. Is there no known info of the N2 that can be probed and confirmed prior to installation?
If you note how many CE users have posted here they experimented with this and that file, because they can’t find the images that work with their unknown box, it seems a little dangerous to not have some kind of check in place before the magic is let loose with the potential to cripple a device (in inexperienced hands).

#13

Trying to boot an sdcard with the N2 image on it with anything but an N2 won’t result in much of anything besides wasting your time. Good dtb files for s905 and s912 devices for the 4.9 kernel are lacking, and there are also a couple of bugs with that kernel that effect support for older devices so even when you have a good working dtb you won’t get very far with an s905 or s912 based device yet. Though I have managed to boot an s905x device with the 4.9 kernel, It’s not a priority to work out the remaining problems currently preventing more widespread use of the 4.9 kernel.

#14

Ahh! Good to know.
So the only potential for damage, is attempting to load the N2 image to internal storage of the wrong device?

#15

I suspect I could probably recover an s905 or s912 device that had it’s internal storage updated with the n2 files. But If somebody was dumb enough to screw up their known unsupported internal storage install by trying to manually update to something that is labeled for a different device then they have after being warned in multiple places that they would end up with a bricked device if they did so… I’m not likely to be in any rush to put that theory to the test.

#16

That is what I thought and wanted clarification on, so thank you.

Am I correct in saying the same applies to all other images also, when used in inappropriate boxes?

I am just checking that none of the images cause interference with the internal card unless installtointernal is invoked.

Thanks.

#17

Yes same goes the other devices and images, pretty much any image can be on the sdcard, and you will just be wasting your time if it wasn’t meant for that devices. The install to internal is where you have to get it right, since installing something to internal memory that wasn’t meant to be there can cause problems.

1 Like
#18

Sounds fair enough, I’m not likely to screw anything up myself, because I don’t meddle until I know what I’m doing. Just wanted a little clarification for the reckless kids often seen around here :rofl: