ARM SoCs do not work like that, they don't have a standardized BIOS with a standardized boot sequence. The user-provided bootloader most likely resides in a dedicated flash IC on the board, simply because it makes things less likely to get bricked when playing around with the system partition - we're not talking about "oops I lost my master boot record" here, it is more comparable to deleting your BIOS. I wouldn't be surprised if the ability to boot off an SD card is being implemented into U-boot instead of using the on-chip mask-ROM boot code provided by TI, as there is a lot of really dirty initialization work needed that will already be done once U-boot was executed, like the DDR RAM controller - the MBR master boot sector might be compatible with the RAW SD card boot mode implemented in the mask-ROM, but I seriously doubt that it is large enough to even reach the next boot stage without the help of U-boot.
No, as I understand it we don't use MBR or GPT; those are x86 BIOS inventions, and we're not running one of those. The exact byte format of the paritition header on ARM devices is not something I've ever investigated though, so I'm not sure which it's more similar to if either, but it's not mounted using the same code so that's probably irrelevant.
But in practice, if the uboot code is on a visible disc interface, then yes we can dd to it. It might be risky to do that to a partition when you've already mounted it though, which is why on Pandora we had special images we could burn to SD cards to boot off which would do that update for it without mounting and booting from the flash chip.
Edit: I'm not contradicting the above poster; this was also in reply to docbroke, and I didn't see there was an extra page when I wrote it.
Yes, the two battery reports are a software thing - Toastbucket has already fixed them in his driver setup (which also improves charging) but it's not yet on your device. A full reflash with the current intallation image would fix that.
Unzip it.
Flash it with dd, etcher or a similar tool onto an SD card.
Put the SD Card into the left slot.
Switch on the Pyra.
Wait until the flasher tool appears on the screen. Type y + Enter (you can't see that you're typing, just do it blindly).
If you don't see that anything happens, press ENTER again.
Wait until it's finished. Press a key to power off. Remove the SD Card and boot.
I've already checked with aTc: Flashing the bootloader directly from a booted up system works, so no need to reinstall. This means that we should also be able to create a debian bootloader package, so installing and updating (or even offer different bootloaders for the user to choose from) is possible via apt.
The SoC only cares about the partition tables as far as they are relevant for its own boot sequence, everything else is only relevant to the OS and the user-provided bootloader. The Linux kernel supports whatever you're throwing at it and I bet U-boot has at least some kind of MBR support compiled in. As we now have a proper block-based drive for the OS (instead of a bare metal NAND like on the Pandora) it actually makes sense to use a partition table on the eMMC.
Not exactly. The OMAPs have their own bootloader code (called MLO).
When you start the processor, the OMAP checks all devices in a given order for the MLO signature starting on sector 0 (USB, MMC, etc.) and once it finds it, it loads the next few sectors and runs that code.
The MLO sets up the basic information about the system and the OMAP runs the code.
These days, you often combine the MLO with U-Boot, but basically all the OMAP does is look for the MLO signature and runs that.
It does not know about partitions, etc. You just dd it to the first sectors of the used medium
thanks @funkyarif and @Grench for these first impressions! looks and reads awesome!!
verry happy that you have your well deserved pyras now.
have fun!!!!!
thanks @funkyarif and @Grench for these first impressions! looks and reads awesome!!
verry happy that you have your well deserved pyras now.
have fun!!!!!
The point is that none of that is able to boot a system on its own, Cortex-A and -R chips are designed to use a multi-stage boot loader design. Some of the early stages are directly carved into the silicon and therefore not modifiable (mask-ROM), some are provided by the user (flashed onto external flash memory or provided on removable media). Some chips actually allow a configuration that entirely skips the mask-ROM and directly starts executing off an external flash IC, though.
The MLO is just another user-provided bootloader stage that makes it easier to get U-boot to work, it does not work on its own. U-boot itself is using a two stage design, the MLO is basically replacing the first U-boot stage - you could modify U-boot's first stage to do the job as well, if you want to (some manufacturers enforce using their own shims by using mandatory signatures, though).
The OMAP3 was already able to boot off of bootloaders stored in a file on a FAT partition with or without an underlying MBR partition table, I doubt they removed this ability from the OMAP5. You just name it "MLO" and place it in the root directory of the first primary FAT-based partition. The available boot options of these Cortex chips are a lot more varied than that, which can be pretty confusing.
The OMAP3 was already able to boot off of bootloaders stored in a file on a FAT partition with or without an underlying MBR partition table, I doubt they removed this ability from the OMAP5. You just name it "MLO" and place it in the root directory of the first primary FAT-based partition. The available boot options of these Cortex chips are a lot more varied than that, which can be pretty confusing.
No, simply copying the MLO onto the card does not work - it needs to be the very first file that's on the SD Card, otherwise, the OMAP3 won't boot.
We had to do that on the Pandora.
So i don't that the Mask ROM can actually read a filesystem - it just expects the file to be at the beginning.
On the Pyra, we used EXT4 cards with the MLO simply dd'ed to the first sectors to make it boot.
No, simply copying the MLO onto the card does not work - it needs to be the very first file that's on the SD Card, otherwise, the OMAP3 won't boot.
We had to do that on the Pandora.
The OMAP35x TRM is very clear about that it is supposed to actively search the root directory for the file, it describes how it is parsing the FAT directory entries in great detail. It also describes that FAT32 handles the root directory differently (FAT12/16 have a fixed location for it), maybe there's a corner case that is causing issues with the FAT32 code.
Wait until the flasher tool appears on the screen. Type y + Enter (you can't see that you're typing, just do it blindly).
If you don't see that anything happens, press ENTER again.
The newer flasher doesn't ask anything anymore, it'll just start erasing the emmc once it starts.
So be careful
(There were some problems where all the screen output would stop sometimes until you pressed enter for a second time, probably because it would see some extra keypresses)
The OMAP35x TRM is very clear about that it is supposed to actively search the root directory for the file, it describes how it is parsing the FAT directory entries in great detail. It also describes that FAT32 handles the root directory differently (FAT12/16 have a fixed location for it), maybe there's a corner case that is causing issues with the FAT32 code.
Unzip it.
Flash it with dd, etcher or a similar tool onto an SD card.
Put the SD Card into the left slot.
Switch on the Pyra.
Wait until the flasher tool appears on the screen. Type y + Enter (you can't see that you're typing, just do it blindly).
If you don't see that anything happens, press ENTER again.
Wait until it's finished. Press a key to power off. Remove the SD Card and boot.
I've already checked with aTc: Flashing the bootloader directly from a booted up system works, so no need to reinstall. This means that we should also be able to create a debian bootloader package, so installing and updating (or even offer different bootloaders for the user to choose from) is possible via apt.
When I switch on the Pyra with the OS card in the left slot, the power button turns red - and that's it. Just sits there. Red power light. Nothing. Reset it without the card in the left slot, boots to the old OS as normal, so the unit itself is working.
I'm pretty sure I made the card right - unless the bs=4M isn't right for this?
/Desktop/Pyra/PyraOS/20191227# dd if=./install-nobat.img of=/dev/sdj bs=4M; sync
425+0 records in
425+0 records out
1782579200 bytes (1.8 GB, 1.7 GiB) copied, 0.770585 s, 2.3 GB/s
I just noted the insane transfer rate reported above - can't be right. Doing it again resulted in:
/Desktop/Pyra/PyraOS/20191227# dd if=./install-nobat.img of=/dev/sdj bs=1M; sync
1700+0 records in
1700+0 records out
1782579200 bytes (1.8 GB, 1.7 GiB) copied, 175.128 s, 10.2 MB/s
Trying that card now.
Card booted! It took me straight to "Installing rootfs" without prompt.
Syncing
Done
----------------------------------------------
Done. Press any key to poweroff_
Well, it did not prompt for Y+Enter, but it did make it to the poweroff prompt, so I'm assuming it is 'done'.
I'm through that part. I have the latest OS image loaded. I used Synaptic to install VLC, Audacious and Gkrellm. While configuring Gkrellm I asked it to report on the battery - at which point the system locked up / froze.
Rebooted and now there seems to be something weird going on with the OS.
In the original image that was on my Pyra, the brightness button worked as intended for the screen and keyboard with Shift and Fn modifiers. On this new image, it does not work at all.
Battery icon no longer appears in the panel. Right click + add to panel = momentary stopwatch on screen then no more launch menu or panel or time. Mouse still moves, home folder in the corner, dp logo background still there. Right click on the background, dp logo background vanishes, gradient green to blue background appears on screen, short options menu. Selecting open in terminal = nothing. None of the options on it seem to work. Unit isn't dead, but there isn't much it is letting me do.
As far as I know, Gkrellm is a passive monitor - doesn't change any system settings just monitors them. It seems, though, that something isn't right now. I'll reflash again and see if that fixes any of the above.
reflashing it won't actually help with the two batteries thing, you need to install the other kernel package that has the battery fixes in it.
apt update
apt install linux-image-4.19.60-letux-lpae-pyra
or
apt install linux-image-4.19.60-letux-lpae-pyra-nobat ( modified kernel that can boot the pyra without a battery inserted (does need the charger connected though ) )
You can select the kernel from the boot menu you get on the serial connection on the charger usb port
It defaults to always using the kernel with the highest version number, but you can change that in /boot/extlinux/extlinux.conf.
If you only have one other kernel installed, changing "default l0" to "default l1" will make it boot the other one.
Look in /boot/extlinux/linux.cfg to see the other kernel labels.
Installing a new kernel will rewrite the /boot/extlinux/ config files again, using defaults from /etc/default/pyra-extlinux . it also changes the kernel labels based on how the kernel version sort.
The actual rewriting of the config files is done by /usr/sbin/pyra-extlinux-update , in case you want to mess about with it manually.
It's not very user friendly, but people expecting userfriendlyness probably aren't going to have multiple kernels installed anyway.
The reason the other kernel is used is because that has the sgx support in it, while the battery fixed ones currently don't.
I'm on my third round through the welcome configuration steps. The second thing it does is ask if I want to Calibrate touchscreen. Answering yes seems to confuse it a bit as it skips the calibration and jumps to a prompt for the user name - and fills it out to about 64 characters with ++++++++++++++. Answering No does the same thing. Cancel, Please try again, now I have a blank box to put my username in. Shoulder button shift does not seem to work during this setup stage.
Now it is stuck in a loop.
A start job is running for Hold until boot process finishes up (5min 56 58s / no limit)
381.787415 systemd-journald[1339): Failed to rotate /var/log/journal/loonnngghexcode/system.journal: Input/output error
Press and hold power button exited that loop.
Powering on again - this should be interesting as the OS setup may not have completed.
Back to the welcome to setup screen.
New loop.
"Please ensure that your username consists of only letters and numbers and is not already in use on the system."
Putting in my 'grench' username results in the above quote. I can't use the same username I started with then. OK. grench2 it is. Apparently it had set up the user the first time when it failed to complete. Configured time zone city and keyboard region - and Done! [OK]
Unit powered down at end of configuration this time.
Battery icon back and desktop back. Now to try for aTc's kernel package.
Got an error. Going to try something.
I figured out the error. Idiot me had not connected back to wireless after that reinstall.
This is a special post though. It is beimg made by my two thumbs on my Pyra using F.
**********************
At that point Firefox crashed hard and the above snippet was in my editor window when I refreshed the site on my main workstation. Instabilities are part of the Prototype stage and I'm good at breaking things.
Back to adding aTc's suggested kernel. Old error was unable to locate package - because I wasn't connected to the internet.
New error:
root@Marble:/home/grench2/Desktop# apt install linux-image-4.19.60-letux-lpae-pyra-nobat
bash: /usr/bin/apt: Input/output error
That is it for me tonight - not out of frustration, just getting late. It's 10:15 PM here, time to give it a break and charge a bit.
Shutting down I got a long pile of Failed to rotate /var/log/journal/GIANTHEXNUMBER/user-1001.journal: Input/output error
Here I thought I was going to give it a break and charge it.
Apparently there is a disadvantage to the -nobat install. It auto-starts whenever plugged in via the microUSB 3.0 port to a power source. I can't seem to get it to simply sit in the off+charging state on this version of the OS.
I'm not sure if it is this version of the OS or if my lower left shoulder button broke - but I cannot seem to get it to work.
So - using the image I downloaded tonight of install-nobat.img I am having some issues:
Shoulder Shift not working. (Note, shoulder Fn IS working.)
Brightness button not working.
Cannot charge battery without the OS booting when plugged in.
Some seemingly random instabilities dealing with battery monitoring and WiFi usage.
For tonight I'm going to pull the battery and put it away.
thanks for pioneering the new and adventurous pyra-land!
take your time. reading your report of these first steps was verry interesting, have a nice evening.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
