Vero 4K+ board bring-up and testing

    Quote from chewitt

    Did you bisect to a breaking commit? .. just that's how far back you've looked? - MPEG2 was the first codec upstreamed (H264 and VP9 were added later) so while it's had less focus it should also work. If 'we' can find the breaking commit it would be a good lead for investigating why the codec is currently broken.

    I probably phrased it poorly, it was broken in 5.10 and that's as far as I went back. I know it was introduced in 5.6, so I can give that a shot and see, but I think there were some changes with the DT bindings related to sound that I didn't have time to figure out. I was going to look when the DT binding change was introduced and build that version.

    The general idea was to bisect and see if I could find it. Best I can tell is they set up a few registers with the codec chip (similar to 4.9) and then start pushing buffers and the interrupt just never fires, which suggests the hardware is probably not setup properly -- because I am assuming the interrupt fires when the buffers are processed by the codec chip. I didn't look too closely at how the buffers are transferred, assuming it is DMA, with 2 ring buffers. I guess it is possible that it's DT related, so maybe I should just test with the p230 DTS and see (I was backporting the DT changes made for my device).

    BTW, I went back to 5.6, which there was a few issues to sort out, and MPEG2 doesn't appear to work on that build either. 5.6 is pretty rocky, as you would expect :). So my guess is something is missing, could be there is a patch not pushed, or a DT component missing, or perhaps it's very specific hardware.

    SW decoding MPEG2 for now is fine for me, so can wait for upstream.

    Any thoughts on how to approach mainline U-Boot? I did test the libretech-s905-pc config (which is a close match) with mainline U-Boot via chainloading:

    fatload mmc 0 1000000 u-boot.bin

    go 1000000

    Console went from the SDIO debug board (using a Adafruit SD card breakout board with a 4.7k pull-down resistor between D3 & ground, then with my USB UART its RX is on D3 and its TX is on D2) to the TV, but U-Boot does appear to work and a bit more functional than the Amlogic U-Boot in the sense that tftp is working. It did seem to recognize the eMMC, but assuming there are some tweaks to get it to use the UART. I also assume that mainline U-Boot knows nothing about the Android MPT partition table (much like mainline Linux is oblivious to it), so eventually a format of the eMMC would be in order.

    Main goal was to verify I could chainload, to verify the status of U-Boot. Does anyone else do it this way, or do you just go for broke and write U-Boot to the eMMC? :)

    As long as you backup the eMMC using "dd" first it shouldn't be too hard to restore it again if things go wrong. GXL devices boot the same from eMMC and SD card so once you've erased eMMC it's simple to test u-boot(s) from SD and when you've proven it works, you can write the boot stuff to eMMC. In the event you do screw up and need to erase eMMC the worst-case scenario is shorting pins on the eMMC chip to stop it being checked during boot, and then the SOC finds u-boot on SD or USB again.

    IIRC there are some capabilities that OSMC runs from the secure world (BL32) to prevent them being copied (Dolby Vision?) so any mainline u-boot will lose those (not that upstream supports DV anyway). I can ask Sam for the boot FIPs (minus the BL32 bits I'd expect) and then it's a straightforward process to create a complete image. It's not something I'd have interest in adding to LE as the "box" approach with vendor u-boot works fine, but the ability to TFTP boot can be useful for testing.

    Quote from chewitt

    As long as you backup the eMMC using "dd" first it shouldn't be too hard to restore it again if things go wrong. GXL devices boot the same from eMMC and SD card so once you've erased eMMC it's simple to test u-boot(s) from SD and when you've proven it works, you can write the boot stuff to eMMC. In the event you do screw up and need to erase eMMC the worst-case scenario is shorting pins on the eMMC chip to stop it being checked during boot, and then the SOC finds u-boot on SD or USB again.

    Ah yes, I recall reading that Amlogic will fallback to booting from an SD card when the eMMC wiped. And I do have dd copies of the eMMC already, just recently had a problem where the instaboot partition was wiped and OSMC uses that partition as a part of the VG for the root disk. I am guessing there is some "Android" specific scenario that causes this, this is the 2nd time I have ran into.

    I guess I'll need 2 SD cards, one with the original Amlogic U-Boot and some sort of basic Linux OS to run DD on (sounds like LE will do), and another one with the testing U-Boot.

    Quote from chewitt

    IIRC there are some capabilities that OSMC runs from the secure world (BL32) to prevent them being copied (Dolby Vision?) so any mainline u-boot will lose those (not that upstream supports DV anyway). I can ask Sam for the boot FIPs (minus the BL32 bits I'd expect) and then it's a straightforward process to create a complete image.

    For now I used gxlimg to pull those pieces out, and they should be usable directly in aml_encrypt_gxl I would think (at least it doesn't complain). Probably the next step is to give this a shot from an SD card.