Minix Bios Key

[Temika]

Itwon't (but see below). The DMA setting in the BIOS affects only the

BIOS :^) and Minix normally uses its own setting; so while you might

enable or disable DMA use with MINIX, it won't be done with BIOS.

Can you give a bit more details about your hardware (particularly around

the southbridge and the "chipset")? And how the drives are connected to

the motherboard.

Anyway, as I said it is possible to disable DMA use in Minix' at_bios

driver: instead to using bios_wini, you should try

ata_no_dma=1

menu(and similarly, doing it on every reboot, and using save to make it

permanent on the disk when you have it installed.)Antoine

I remember there were problems years ago (which is congruent with this

hardware) when ATA and ATAPI commands were mixed on the same channel

while using DMA. Perhaps it is the case which is hurting you.

Unfortunately, I assume there is no way to test otherwise, since

disconnecting the CD will makes your computer unable to install from CD

I do not believe so. DMA (or the opposite, PIO) is just a way to use the

disk driver; each driver does it its own way; you are using two drivers

(first the BIOS, in order to load the boot monitor and then to load the

OS proper; second Minix acting on its own), but there is no real reason

they have to use the same protocol.What might be a problem could be that for whatever hardware reason DMA

does not work (bad chip, bad cable, bad mood between the two devices as

I said above, etc); in this case your only solution is to stick to

no-dma for both BIOS booting _and_ Minix.

If not, check what is within that directory /usr/mdec.

The best way to avoid typing problems is to use filename completion:

after typing /usr/mdec/bo, hit the tabulation key, and the shell should

complete the filename automatically, without possibility for error.

Antoine

Hmmm, if the datas are the same for the whole 512-byte sector, it means

the informations about the partitions are the same... (and also there

are no Windows NT signature which would randomize somewhat the bytes at

offsets 01b8-01bb.)You should also double-check that the first sector of the active

partition (corresponding to /dev/c0d0p0, assuming p0 is active) also is

correct, and then that the content of the first sector of the root

filesystem (corresponding to /dev/c0d0p0s0) has the code from

/usr/mdec/bootblock. Also, you should double check that the s0

subpartition is indeed active.

Assuming both disks are partionned the same way as said above, this

boils down to check that in addition to the MBR sector, the first

sectors of the Minix partitions are also identical on both disks.

Note that the next sector (which is normally the first sector of the

subpartition, ie the first sector of the root file system) could be

different, since it records the position on disk of /boot/boot:

depending on how the filesystem is actually written, the physical

position of a file could be different between two systems which

otherwise look identical.

Antoine

Well, does the faulty machine actually boots that harddisk?I mean, is it enable in the BIOS? (no intervening extension card like

SSCI, intervening disk, incorrect geometry, inexistant floppy etc.)

Also, perhaps you can try the reverse way, ie put the disk of the

known-working station in the suspect one, and give it a try? As long as

you stop at the boot monitor, Minix does not write anything to the disk,

so it is completely safe.

Antoine

I haven't used Macs a lot, so I will go in some detail into things thatmay be obvious to experienced Mac users, but that were not so obviousto me with my experience with Unix and Windows systems.I started by going to the Bochs project home pageat . The Bochs site is confusing -- on thetop level page it was stated that Bochs 2.0.2 for the Mac OS was notyet available, but somehow I found the Bochs x86 PC emulator File Listpage at _id=12580&release_id=135273.There I found bochs-2.0.2.ppc-macos.sit with other Bochs 2.0.2 filesdated 21 Jan 2003. On the same page I also found a disk image forMinix, minix203.tar.gz, dated 2 October 2002. I downloaded both.These files are fairly large, and I still have just a 56K modemconnection at home, so I downloaded them to a PC at work, and broughtthem home on a Zip disk to transfer them to the iMac. The Bochs fileis 2.9 MB and the Minix image is 6.4 MB. First I installed Bochs. I copied the .sit file to the Mac hard disk.The .sit file is opened by Stuffit Expander; it created a bochs-2.0.2directory. Current Bochs releases include a small version of Linux,DLX Linux, and inside the boch-2.0.2 directory I found a dlxlinuxdirectory containing a 10 MB DLX Linux disk image, and a Readme filethat tells how to start Bochs and load DLX Linux. The bochsrc.dlx fileis located in the main boch-2.0.2 directory. I recommend using DLXLinux on Bochs to get familiar with the system before attempting to runMinix under Bochs. On to Minix -- I copied minix203.tar.gz to the Mac hard disk. When Iclicked on it a window opened saying the application that created thefile could not be found, and offering to try Stuffit Expander to openthe file. That worked, and the result was a minix203 directorycontaining 3 files: a 64 MB Minix disk image, a readme.txt, andbochsrc.txt. I moved that directory into the bochs-2.0.2 directory.For reference I kept the original bochsrc.txt unaltered and made a copywhich I renamed bochsrc.minix and moved to the top level bochs-2.0.2directory, so the structure for Minix is parallel to that for DLXLinux, with the disk image file in a subdirectory and the workingbochsrc in the main directory with the MacBochs executable. Iattempted to start Bochs according to the procedure that worked withthe DLX Linux image: run MacBochs, select 2, type in "bochsrc.minix",and select 5. I wasn't terribly surprised when this didn't work. Thenext step was to look more closely at bochsrc.minix.The error message on the first attempt was: ">>PANIC>PANIC

So, all Intel CPUs since 2008 contain a chip inside CPU that runs a full-fledged MINIX OS with unrestrained access to RAM, devices and TCP/IP stack. It's outside of operating systems that we boot, undetectable mostly, but we have an interface exposed for it. Can one write assembly code to interface with the file server on MINIX of the Management Engine chip? Or the only way to modify it is via disassembly of bios and removing modules from bios?

The fundamental basis of trust is "if they do something dodgy it will hurt them". For example; if a large company does something deliberately dodgy and get caught it effects their reputation and their profits (and they may be sued); and this is why other large companies and governments trust Intel products.

For random people (e.g. anonymous people on the Internet, a person working at an OEM assembly line, the person that drives a truck from manufacturer to retail store, the person selling computers cheap on eBay, ...); there is either no consequence or the consequence is small ("if they do something dodgy it will hurt them" doesn't apply) so there's no reason to trust them. Unfortunately lots of these untrusted people have access to the computer before the final consumer/user gets it; so to ensure something can be trusted these untrusted people have to be unable to modify it.

After downloading the Debian 8 amd64 iso image ( -8.6.0-amd64-cd-1.iso/), create a bootable USB pendrive with Debian 8 (there are plenty of tutorials and softwares to do it). Than from the bios, boot the system from the bootable USB. Attach a second USB stick (32gb are more than enough) and start installation process: you will need a basic Debian installation, avoid environmental desktops and all the other options, except SSH.

A number of years ago, I purchased a Minix Neo U9-H (when I constructed my home theater, 2017 believe). I immediately installed LibreELEC on it (wiped out Android and installed directly on the device) and, until recently, used it as my primary media player for movies stored on my local NAS. I believe I updated the box maybe once a few years ago. It is currently running LibreELEC 8.2.2.3 and Kodi 17.6. Recently I replaced it in my theater setup with a Zidoo Z9X running OSMC but may use the old Minix in another room. A while back I checked the LibreELEC forums and it appeared that there would be no future LibreELEC support for my Amlogic based box. I just visited the forums here after quite a while and was shocked to see that the recently released LibreELEC 11.0 apparently returned support for the Amlogic S912 of my Minix U9-H. I'm excited about the prospect of bringing my old box up to date but have a few questions.

2) After extracting and writing the image to a USB drive with LibreELEC.USB-SD.Creator.Win32, I assume I still need to go into the dtb folder, copy and paste the meson-gxm-minix-neo-u9h.dtb file to the root of the drive, and then rename it dtb.img...correct?

3) At this point, I believe I have a bootable USB that should boot my device and run the newest version of LibreELEC. Given that my older version of LibreELEC is resident on my device in the eMMC storage, I should unplug power to my Minix, insert the bootable USB, hold down power button, reattach power cable, wait 5 or 6 seconds and take finger off power button. At this point, the box should boot into the new version on the USB...correct?

4) I understand about not trying to install this new version of LibreELEC internally on the device, so I just leave the USB drive inserted and it will default to the USB boot of the new version unless I remove the USB and then it will boot into older version on eMMC...correct?

4. Once booted from AMLGX the u-boot environment is modifed to find AMLGX boot files, meaning it will no longer find legacy image boot files. However if you remove the USB and repeat the 'toothpick' forced-recovery boot it should then search for and find the legacy image boot scripts and work with content on eMMC again.

3a8082e126