Re: ODROID XU4 and UEFI - Re: Cautionary tale: how to kill an SDCard with one simple command
On Wednesday 25 July 2018 07:22:46 Mark Morgan Lloyd wrote:
> On 25/07/18 10:15, Gene Heskett wrote:
> > On Wednesday 25 July 2018 00:49:55 Brian Sammon wrote:
> >> On Sat, 21 Jul 2018 15:42:41 -0400
> >>
> >> Gene Heskett <gheskett@shentel.net> wrote:
> >>>> https://odroidinc.com/products/odroid-xu4
> >>>
> >>> I have one, bricked, it has a uefi bios and at the time, the linux
> >>> installer had no clue how to deal with it. The only option I could
> >>> find in the bios was to disable the tcp chip, which bricked it,
> >>> and a jtag programmer and adapter worth more than the odroid is
> >>> required to restore it. This is NOT mentioned ANYPLACE is the
> >>> sales propaganda on their site or in this link. Had they not been
> >>> drinking the windows koolaid, it
> >>
> >> I'm a little confused by this. Are you saying that they put UEFI
> >> on the ODROID XU4 so that it could run Windows? As you said, this
> >> is not mentioned anyplace in the marketing info, but I can't find
> >> it mentioned anywhere else either. I also see no claims that the
> >> XU4 could run Windows.
> >>
> >> Did you ever discuss this with Hardkernel (preferably in a public
> >> forum like https://forum.odroid.com/)? Did they acknowledge or
> >> deny the UEFI situation?
> >
> > They acknowledged it, and told me how to fix it, but the fix cost
> > more than the odroid, a jtag programmer and a special cable that
> > cost well
>
> Did you get them to acknowledge this in /public/, i.e. where
> prospective customers can see it?
It, unless its been erased to protect the guilty, should be in that
forums msg base, but I've long since forgotten the subject line. Nearly
2 years ago now.
>
> > over $125 is required. And someone else recently advised me that
> > UEFI bypassing in the bios was only legal on x86 stuffs. If thats
> > so, I'd
>
> "Only legal" in the USA, and I regret to say that it's /your/
> political system that enabled things like the DMCA.
Touche` It damned sure wasn't something I wanted, and told my congress
critters so at the time, but big checks from the stakeholders can always
buy the votes they need to get anything they want. Democracy has sadly
developed into a highest bidder gets the job over the last 150 years.
Goes along with the winners always getting to write the history books I
guess.
> > push for legislation to outlaw the whole concept as it is unfair
> > competition to me, and microsoft should owe damages to everyone that
> > got burnt as I did. In any event, I've not been back to their site
> > and if they starve I could care less. Get screwed once, shame on
> > them, twice, shame on me.
> >
> > The only possible mention is at
> > <https://forum.odroid.com/viewtopic.php?f=138&t=20593>
> > Smarter folks than I might be able to build a workaround, but they
> > were pretty carefull how that subject was covered. u-boot might be
> > able to deal with it, but I haven't studied up on that enough to
> > say. The rock64 gets around it but I've no clue how that works
> > either.
> >
> > I have successfully built the linux-rt kernels on both the pi and
> > the rock64, but now I cannot find a utility that will actually
> > update the sd cards boot code to install the replacement code, and
> > questions about how to do this seem to be ignored on all the
> > revelant forums. zero answers other than a few links to code from
> > 2011 & 2012 that seems to be unrelated have been supplied. I do know
> > that dpkg knows how to deal with it as I've seen its onscreen log
> > while doing it on the rock64, but it doesn't seem to be covered in
> > the dpkg man pages. Also a stumbling block, make doesn't know how to
> > "make" a vmlinuz, only huge vmlinux, and no initrd's. But I have
> > made those.
>
> In the kernel source directory run make help | less and check the
> section "Architecture specific targets" towards the bottom, then what
> formats your loader etc. supports. As I said a few days ago, initrd is
> made by distro-specific tools, it has to be done that way since apart
> from the format it's really got very little to do with the kernel per
> se.
I'll do that make help|less, thanks. How about make help >filename so I
can load and print it with geany? Done, and printed.
I have not been successfull at "make pdfdocs", it hits something it
doesn't like in the chapter on networking, not finding a file that is
(or was) installed since this is now armbian, and which an apt-file
find pdftex returns 262 versions of it as available. But which is the
correct version? $64k question, that. Lots of stuff missing for make
pdfdocs, not working yet and apt has drug in close to a gigabyte of
stuff. And apt can't find half of what it wants even then. But it may
have succeeded, now installing okteta, and okular another 150 megs of
dependencies that pulls in for each.
There were 3 reported warnings and a 4th I saw go by.
Highlighting of certain text will be skipped. couldn't lex something.
The 3 errors are:
build succeeded, 3 warnings.
make PDFLATEX=xelatex LATEXOPTS="-interaction=batchmode" -C
Documentation/output/./latex || exit;
xelatex -interaction=batchmode 'dev-tools.tex'
This is XeTeX, Version 3.14159265-2.6-0.99996 (TeX Live 2016/Debian)
(preloaded format=xelatex)
restricted \write18 enabled.
entering extended mode
Makefile:66: recipe for target 'dev-tools.pdf' failed
make[2]: *** [dev-tools.pdf] Error 1
Documentation/Makefile:85: recipe for target 'pdfdocs' failed
make[1]: *** [pdfdocs] Error 2
Makefile:1523: recipe for target 'pdfdocs' failed
make: *** [pdfdocs] Error 2
> > It took something just over 1 hour to build that on the rock64. On
> > an 120GB SSD mounted to /media/slash via a sata to usb-3 adapter, so
> > I wasn't beating the sd card to death. What I'd like to do is copy
> > that sd to the eMMC module, plugged in but empty ATM and do the
> > installs to the eMMC memory, so it boots from a known good boot, but
> > will use the eMMC as the bootable medium if the sd card is removed.
> > That way I'd have a fallback rescue path if the install on the eMMC
> > card is broken. Just plug the sd card back in and push the power
> > button.
>
> Usual caveat about not getting anything on the eMMC that subsequently
> prevents you booting from SDCard etc. I for one always feel a bit
> queasy about writing to non-removable Flash devices.
>
I would not claim its not removable, I assume it can be lifted back out
of the socket since I had to insert it into the socket. The trick is
probably in a boot priority setting someplace so it boots from the sd
card if its present, eMMC if its not. Wishfull thinking perhaps but it
would make a lot of sense to do it that way. OTOH, if there was a
lawyer in the building, any and all bets are null and void. :(
I'm like that fellow Shakespear, first we kill all the lawyers.
> We had a removable Odroid eMMC module that died, they subsequently
> admitted (in public) that they'd had manufacturing problems.
Humm, wonder if that applies to these rock64's too as they are at least a
year old now. These 2 are from the 2nd run.
But lastly, because I've made some real progress, I need to make an image
backup of / but without the contents of /media/slash because that is
where I'll put the "backup". How the heck do I do that? And what
command is used to image the sd to the eMMC? Then I'll see if it will
boot from the eMMC, then have make make the debs. Seems like a logical
order anyway...
Thanks Mark.
--
Cheers, Gene Heskett
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>
Reply to: