Posts by chewitt

    1. /storage represents one of several probable partitions on the internal emmc

    2. depends on the kernel, but /dev/mmcblk0 or /dev/mmcblk1 - check with blkid

    3. if booting from emmc it's on emmc .. and if using sdcard it's on sdcard

    4. it looks exactly the same, because it's exactly the same OS, only installed to different storage media

    5. uboot splash isn't easily changed, oemsplash.png in /flash will change the LE splash, kodi splash is separate again

    If the whole point of all those questions was changing the splash, all you need to do is boot the box after install and remount /flash rw and copy oemsplash.png to /flash. No need to edit the read-only installtointernal file unless you deliberately want to make everything complicated.

    For once the undocumented closed-source GPU drivers won't be the issue (or probably won't be) as this time around Amlogic licensed the right blobs from ARM and we already have them. The bigger issue is that S905X2/D2 hardware requires the Amlogic 4.9 BSP kernel, which in an evolution of all the low-quality Amlogic proprietary media code from the 3.14 kernel with additional new capabilities (none of which follow emerging kernel standards) and everything a bit more Android oriented than before. We can expect all the old bugs .. plus new ones. So the challenge is all about persuading good developers to take an interest in a(nother) bad codebase. You fix something, you break something else. You fix that thing, you break two things more. You fix those two things, something else doesn't work. So it's a shitty thankless slog, and with Kodi dropping amcodec support after K18 ships the large effort has a potentially short lifespan (far less than the run 3.14 has had). I'm not aware of anyone poking their nose into the Amlogic 4.9 kernel at the moment, so right now these boxes are Android only.

    In the long-term there will be mainline support, but at the current near-glacial rate that Amlogic is submitting G12 platform code (which all requires nip/tuck rework, which incurs extra time) it's going to be "some time" before G12 hardware is mainline usable. There is also a conspicuous absence of media code being submitted, so we could be looking at a rerun of the current GX platform situation where Amlogic upstreams core platform support only and media support is left entirely to the goodwill of the community and a couple of vendor benefactors. It won't be quite such a drama as there's a moderate level of code inheritance from GX, but until core platform support gets further along we can't really start. I doubt we'll have mainline support for G12 boards within the next 12 months. Current GX boards will have moved to mainline long before then as the codebase is ~85% complete and so much easier to work with (and nearly all the major code components are written by LE team members). Once you've moved forwards and seen the light it's really (really) hard to resume an interest in the older kernels again.

    NB: Apart from USB 3.0 support the main addition to S905X2/D2 boxes is hardware support for more codecs, e.g. HDR10, but support in hardware needs matching support in software and Linux doesn't support any of that stuff yet (and nobody has media to watch) so once you put the spec. sheet down and re-enter the real world there's no major compelling reason/advantage for S905X2/D2 over current S905X/D.

    Install the drivers to Windows and then connect the Slice to Windows via the micro-USB port. Windows should see something is attached. Now add power to the Slice box and it should power up in 'disk' mode allowing the eMMC to be written. The drivers aren't brilliant and it can take a reboot of Windows and some patience before the CM3 cards shows up as a disk target, but it's the only method.

    Code
    <3>[   13.496949] squashfs: SQUASHFS error: unable to read id index table
    <6>[   13.497211] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0xc71e53f1)
    <3>[   13.497214] F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
    <6>[   13.497254] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x41e10784)
    <3>[   13.497256] F2FS-fs (loop0): Can't find valid F2FS filesystem in 2th superblock
    <6>[   13.497265] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0xc71e53f1)
    <3>[   13.497268] F2FS-fs (loop0): Can't find valid F2FS filesystem in 1th superblock
    <6>[   13.497270] F2FS-fs (loop0): Magic Mismatch, valid(0xf2f52010) - read(0x41e10784)
    <3>[   13.497273] F2FS-fs (loop0): Can't find valid F2FS filesystem in 2th superblock
    <3>[   14.533541] squashfs: SQUASHFS error: unable to read id index table

    The good thing about packaging the entire OS into two files is you only have two files (not thousands). The bad thing is you have one byte of corruption in the image and the entire OS doesn't boot. The lines above indicate something is bad with the SYSTEM file - which matches the error message you're seeing.

    I'd guess it's time for a new USB stick?

    Code
    cp /etc/connman/main.conf /storage/.config/connman_main.conf
    nano /storage/.config/connman_main.conf

    ^ edit the order of PreferredTechnologies so wifi is before ethernet and then save and reboot to effect the change. When wireless is connected it will become the internet routed connection.

    Download and run the USB/SD Creator tool. Select Generic etc. and create a USB. Boot from the USB and clean install the OS. This will nuke whatever is currently installed, but you end up with a clean system and a 512MB boot partition.

    You may have tons of space on /storage but the update requires 235MB ish space in the separate boot partition and yours is probably an older OE sized boot partition that's 230MB. Hence the error message.

    If there is truly nothing on the box .. just clean install and start over. If there's something you want to save, make a backup in the LE settings addon and move it off-box and then clean install and restore the backup. This is considerably faster than trying to shrink/expand the existing filesystem.

    It's not a driver problem. Bootloaders need to have an elementary understanding of physical hardware to see and present stuff for boot. When you boot from USB (which the bootloader understands) you end up in the kernel initramfs which has drivers/support for the eMMC/SD card so you can see it as an install target. Once you reboot and attempt to boot directly from that the eMMC/SD hardware (which the bootloader doesn't support or understand) .. you don't boot.

    Hence the suggestion of using another bootloader. If you can boot an Ubuntu LiveUSB image on your device; whatever version of GRUB that the LiveUSB is using works on your hardware and you can use that to boot LE. The only thing you'll need to figure out is the GRUB boot config, but that's never too hard and there's probably some posts in this forum on the topic (i'm being lazy and not Googling it for you).