Tinycore's boot sequence.

I was thinking it may boot faster: for the one I use the on/off switch to control which TextToSpeech *.wav to play next -- since I don't know how to signal/interrupt/poll via a max of 2-wires [other than the power-leads].

The README 'reads':---- Installation ============ piCore is distributed in .zip archives containing raw SD card image which can be installed with dd command on Linux or Win32 Disk Imager on Windows. After successfully copying image to SD card it is ready to boot in Raspberry Pi.....

SD card partitioning ==================== First partition (mmcblk0p1) is VFAT type; it contains the basic piCore system and the Raspberry Pi boot loader, firmware and other support files. Partition is unmounted during operation, system is not using it after boot and never writes....

This difficult-language seems completely inconsistent with my hardware, which:

  • apparently boots via the GPM [in some hidden way] and needs partition-1 of the SD the be a FAT-FS and mountable.

  • dd if=piCore-5.2.2.img of= makes no longer a mountable FAT-partition

  • But most strangely: piCore-5.2.2.img starts out as:
00000000 FA B8 00 10 8E D0 BC 00 B0 B8 00 00 8E D8 8E C0 .... 000001A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000001B0 00 00 00 00 00 00 00 00 CB 81 09 00 00 00 00 00 000001C0 01 20 06 03 90 BF 00 08 00 00 00 A8 00 00 00 00 000001D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000001E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 000001F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA which [without decodeing in detail] is a MasterBootRecord ?!

What the hell is going on?

Reply to
Unknown
Loading thread data ...

VFAT is FAT.

You need to dd it to the raw device, not to partition 1.

and needs to be in block 0 of the raw device, not in block 0 of the first partition.

--
roger ivie 
rivie@ridgenet.net
Reply to
Roger Ivie

OK, so that's eg. ...of=/dev/sda

Of course I'm going to try your advice. But I just recently AGAIN read that rPi boots from the GPM's to be able to read-FAT from the SD. So the first code that accesses SD expects to find a mountable FAT partition 1. Perhaps the code is

Reply to
Unknown

Reply to
Roger Ivie

.....snip ..

OK, Thanks! It boots fast. But you can't . Mounted USBs and the SD:1st-partition are read-only; so you can't get data out to .

I could `chroot mc`, so it seems strange that write

-permission was denied?

But the doco show quirky stuff like:-- ]Login, passwords ]================ ] ]Default user is tc. There are no user passwords, tc user is auto logged ]in on the terminal. In case of piCore-5.x-SSH password for tc user is ] ]piCore ] ]It is not possible to log in as root.

and the forum had got an absurd registration procedure.

Reply to
Unknown

OMG, the standard /boot partition of rPi starts with a dos MBR from the previous millenium, including "insert a bootable floppy". You can't escape M$!

But tc is useless if everything is locked-down to be read-only. I tried to uncomment a line in /etc/inittab to get an extra console; perhaps by `init` after the edit. I can't write to any files.

Why would inittab have all but the 1st tty disabled? It's starting to look like a scam.

Reply to
Unknown

The does not start with an MBR.

The starts with an MBR which contains a standard MS-DOS style , like the majority of disks and similar storage media.

The "insert bootable floppy" and stuff is possibly because the original was built on a card that had been partitioned on a windows system which put the legacy code there.

The few bytes that identify it as an MS-DOS MBR and the partition table itself are the only parts of that 512 bytes that are used on the Pi.

To cut down on the number of processes running and therefore save memory? I often disable 2 or 3 of the ttys on my older, slower PCs (yes, slower than a Pi by a long way and with much less memory).

Reply to
Dom

Yes ! It's very important to not forget that the partition starts after the MBR & stuff. But there's still some confusion:- ==this is a USBstik Device Boot Start End Blocks Id System /dev/sdc1 * 32 4339843 2169906 c W95 FAT32 (LBA) /dev/sdc2 4339844 15384303 5522230 83 Linux == and this is hda Device Boot Start End Blocks Id System /dev/hda1 * 1 128 1028128+ b W95 FAT32 /dev/hda2 129 256 1028160 b W95 FAT32 /dev/hda3 257 384 1028160 83 Linux ... and `dd` shows the MBR. So then is NOT the beginning.

Sure, I guessed that, but expected them to 'clean it'.

This was the report/question that I REALLY wanted an answer to.

Yes OK; that's obvious ONCE you mention it.

But even if you COULD write to inittab, you can't update it for the next boot, because the 'original' inittab is buried and reborn for each boot. For debugging and tracebility, it may be usefull to leave to leave the original, but now bypassed info?

==Thanks.

Reply to
Unknown

Start=1 is the beginning of the partition.

The MBR is always in sector 0.

Soemtimes there is other stuff in the "unallocated" space between the MBR and the first partition.

The other thing is that partition editors tend to align partition start/end to a certain number of KB for efficiency/speed.

Why bother? It doesn't do any harm.

This one I don't know the answer to, as I've never looked at tinycore Linux. I suspect it uses something like a loop-mounted squashfs file system, which would be a pain to update, so is only available in ro mode.

It might be possible to extract the compressed filesystem on another Linux box, mount it r/w, edit files, unmount and compress the file again. I'm sure a quick search will give results.

Reply to
Dom

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.