S905x p212 - balbes150 20.10 - ignores extlinux.conf

[Bokies]

Hi,

newb on this board, am so stuck with this box I had no choice but to register.

I can run "LibreELEC-LePotato.arm-9.0.2.img" from usb without problem.
I can also run "Armbian_5.44_S9xxx_Debian_stretch_3.14.29_xfce_20180601.img" without further meaningful problems.

trying to get this MXQPro 4k (S905XQ p212 8gb) running with Balbes150's last 20.10 Armbian but without any meaningful progress.
As per Instructions/FAQ I copied u-boot-s905x-s912 to u-boot.ext
also edited extlinux.conf

label Armbian_S905X-p212
linux /zImage
initrd /uInitrd
fdt /dtb/meson-gxl-s905x-p212.dtb
append root=label=rootfs rootflags=data=writeback rw console=ttyAML0,115200n8 console=tty0 no_console_suspend consoleblank=0 fsck.fix=yes fsck.repair=yes net.ifnames=0

toothpicking reboots it to u-boot, giving following result:

 

U-Boot 2020.07-dirty (Jul 26 2020 - 13:24:26 +0200) hexdump-gx1
Model: hexdump usbkbd/hdmi u-boot gxl
SoC:    
Amlogic Meson GXL (5905X) Revision 21:a (82:2)
Met: eth0: ethernet8c9410000
starting USB...
Bus dwc3@c9000000: Register 2000140 MbrPorts 2  
Starting the controller
USE XHCI 1.00
scanning bus dwc38c9000000 for devices... 6 USE Device(s) found
scanning usb for storage devices... 1 Storage Deuice(s) found  
Card did not respond to voltage select!
Card did not respond to voltage select!  
Card did not respond to voltage select!  
Card did not respond to voltage select!  
Hit any key to stop autoboot: 0
Card did not respond to voltage select!  
Card did not respond to voltage select!  
MMC Device 2 not found
no mmc device at slot 2
Device 0: Vendor: USB    
Reu: 1100 Prod: Flash Disk
Type: Remouable Hard Disk
Capacity: 15200.0 MB = 14.8 GB (3112%00 x 512)  
... is now current device
Scanning usb 0:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1562 bytes read in 5 ms (304.7 XiB/s)  
1:    
Armbian
Retrieuing file: /uInitrd
for failure retrieving initrd
SCRIPT FAILED: continuing...
28939 bytes read in 10 ms (2.8 MiB/s)  
Speed: 100, full duplex
BOOTP broadcast 1
DHCP client bound to address 192.168.1.16
 Using ethernet0c9410000 deuice    
(1003 ms)
TFTP from server 192.168.1.1; our IP address Is 192.168.1.16  
Filename l/extlinux/extlinux.confl.
Load address: 0x1000000  
Loading:TTTTTTT

this is were the weirdness starts
it finds the extlinux.conf, tries to load the files but fails
if i remove the line for uInitrd it fails the same way on zImage
it also seems to totally ignore the dtb line since it always just loads meson-gxl-s905x-libretech-cc.dtb, if i rename this file, it loads nothing, if i rename other files to meson-gxl-s905x-libretech-cc.dtb it loads that one
i can delete/rename the whole extlinux.conf file and it still just buts the same way (without the FAILURE part ofcourse)

tried al the 6 images, all same result
tried moving and renaming (and editing extlinxu.conf)  .. to no avail

Edited September 28, 2021 by Bokies

[SteeMan]

The multiboot mechanism (what gets installed/setup when you use the toothpick method), sets certain u-boot variables on the emmc storage of your device.  So the boot process is that you are using the original android firmware u-boot, which then chainloads the u-boot.ext file on your sdcard/usb drive.  The nature of what settings get installed in the emmc storage have changed over time.  I suspect that what is happening is that you have previously installed a set of u-boot variables on your emmc that is incompatible with what is trying to be installed/used in the later build you are now attempting to install.

The reason I believe this is your problem is that you seem to have a strange mixture of environment variables that are causing the boot process to load things one would not expect it to be loading.

What I would recommend is that you reinstall a clean environment (i.e. reload an android firmware) which will reset everything to a known state and then try installing multiboot through the toothpick method using the 20.10 build.

[Bokies]

regardless of whatever might have been overwritten on the emmc boot-partition (or where-ever it is written)
i can still run the original android-recovery 6.0.1, can still run from there the original MBOX Android 6.0.1, they're still on there just fine ... and no matter what .. the 20.10 version refuses to budge ..
since i can not (like most users of these mass-garbage-products) find a good or perfect "original" firmware (up to now) i'll have to make do with what i got.
I'm somehow not so sure the error is on the emmc part

I can paste the "env print" or whatever i can get to from u-boot (or maybe from the 5.44 armbian) if that can tell us anything useful ..

Isn't there any way of reading that boot-partition or memory/sector/whatever of the emmc ? (i'm looking but haven't found anything yet .. no (hidden) partitions (or drives) in partition-manager etc.) .. (but at least i got a new lead now )
if u-boot (and others) can write to it and the booting process can read from it ..there must be a way for us to read from it too ..i'm guessing ?!
(or even just wipe that part altogether ..since booting via usb and sd will write their own stuff there on each instance)
a full reset in android-recovery does not wipe the log data funny enough ..so i can somehow see there might be other stuff staying behind as well

-edit
hardware is nand Sandisk sdtnq-gama008g and memory samsung 416 k4b4g1646q-hyko (2 of 4 places filled .. guessing 8gb?), network realtek 8188etv

[SteeMan]

7 hours ago, Bokies said:

I can paste the "env print" or whatever i can get to from u-boot (or maybe from the 5.44 armbian) if that can tell us anything useful ..

Yes this would be useful.  So you have a serial cable soldered to the board so you can interact with the u-boot process from a terminal?  The issue (as I suspect) is all about the u-boot environment variables that are stored on the emmc.  These are what get changed by the 'multiboot' processes that the other firmwares setup.  If you look at any distribution you have for amlogic boxes where will be a file aml_autoscript that gets run when you use the toothpick method or android update method.  All that script does is set u-boot environment variables that get stored on emmc.  Different distros do their multiboot differently and it has changed over time and there are incompatibilities in how different groups have done things.

 

7 hours ago, Bokies said:

or even just wipe that part altogether ..since booting via usb and sd will write their own stuff there on each instance

This will brick your box.  The thing about amlogic based boxes that makes them difficult to work with, is that the boot process basically only looks for u-boot on emmc.  So you are always running the u-boot shipped with android.  The 'multiboot' hacks are about tricking u-boot to use other media, but the tricks all involve starting with running the original u-boot from android.  Thus if you mess with the emmc partitions that contain the android u-boot and its required files, you brick your box.  So the boot process is essentially run the native android u-boot and hope that it is capable of launching a different more modern kernel that exists on sdcard/usb.

[Bokies]

I know where the header is for uart .. not soldered in yet (maybe i can do that this evening..got some skillz in that departement )
what i did until now is take photos from the screen and run it through OCR
 

[SteeMan]

What gets printed to the screen comes from the secondary u-boot.  All of the initial u-boot activity is only going to the serial console.

[Bokies]

Uart created, Putty installed .. and then one gets garbage ..sigh

 

[¬®X±ûûûû••µýëÍšjjºÔô+õúZVëmcsa‹¿¿¿¿¿¿}33m#‹¿g55'¿Ÿ§¿e_mw¿ŸŸ§¿Y=5¿acåëmcsa‹¿¿¿¿¿¿}33m#‹¿g55'¿Ÿ§¿e_mw¿Ÿ§¿Y=5¿assåëmcsa‹¿¿¿¿¿¿}33m#‹¿g55'¿Ÿ§¿e_mw¿Ÿ›§¿Y=5¿assåëmcsa‹¿¿¿¿¿¿}33m#‹¿g55'¿Ÿ§¿e_mw¿Ÿ™§¿Y=5¿assåë;'™¿5;!!¿5=!#‹¿Ÿ7åë;'™¿5;!!¿5=!#‹¿ŸŸåë
5%¿9%7¿¿£ååë

it's actually more ..but it somehow won't let me paste it all .. it's garbage whatsoever

the garbage comes up when cold-booting or resetting
in 2 parts ..so it is the data ..just not right
--need to check the connections, cables, ic's, batteries, sparkplugs, fuel-filter and what not .. get back to it once it gives decent output

[Bokies]

Fuel-filter was clogged, sparkplugs were corroded, heavy carbon deposit and bent, also signal degradation was present .. fixed now

initial start as normal (all images give identical output)

U-Boot 2015.01 (Nov 16 2016 - 16:20:01)

compared the different images that run fine .. i'll feel free to omit the start (for now) that is the same for all ..
this is were 20.10 takes over:
 

Hit Enter or space or Ctrl+C key to stop autoboot -- :  1  0 
(Re)start USB...
USB0:   USB3.0 XHCI init start
Register 2000140 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 6 USB Device(s) found
       scanning usb for storage devices... 1 Storage Device(s) found
reading s905_autoscript
537 bytes read in 22 ms (23.4 KiB/s)
## Executing script at 01020000
start amlogic old u-boot
## Error: "bootfromsd" not defined
card out
emmc/sd response timeout, cmd8, status=0x1ff2800
emmc/sd response timeout, cmd55, status=0x1ff2800
emmc/sd response timeout, cmd1, status=0x1ff2800
** Bad device mmc 0 **
reading boot_android
** Unable to read file boot_android **
emmc/sd response timeout, cmd8, status=0x1ff2800
emmc/sd response timeout, cmd55, status=0x1ff2800
emmc/sd response timeout, cmd1, status=0x1ff2800
** Bad device mmc 0 **
reading u-boot.ext
650183 bytes read in 366 ms (1.7 MiB/s)
## Starting application at 0x01000000 ...
[BL31]: tee size: 0
[BL31]: tee size: 0

from here s905x takes over

after that "normal" operation takes over (no more putty .. rest on tv)

what caught my eye immediately is the:

 

## Error: "bootfromsd" not defined
card out

which is odd ..since i boot from usb (but tried sd in the past .. with no difference - had no putty then but ok)

the "bootfromsd" comes from the aml_autoscript (and emmc_autoscript and s905x_autoscript)... cannot simply "edit" the file .. so ..now what ? (if that even is the or one problem)
 

[Bokies]

tried editing aml_autoscript (and the others) with a hexedit .. but ..of course

 

       scanning usb for storage devices... 1 Storage Device(s) found
reading aml_autoscript
710 bytes read in 22 ms (31.3 KiB/s)
## Executing script at 01080000
Bad data crc
reading recovery.img
** Unable to read file recovery.img **
ee_gate_off ...
## Booting Android Image at 0x01080000 ...

 

[Bokies]

if i use the older s905_autoscript from the working 5.44 version box "seems" to hang but through uart i can see it tries to actually start
it loads zImage and uInitrd than tries to load kernel ..

so yeah ..  i think i confirmed my own theories again .. my box isn't really the problem (nothing  "wrong" was written to it)
the fact that the newer autoscripts are hung-up on sd is ..

I get there are very few goofing around with these cheap boxes .. but .. how am i (apparently) the only (noob) trying to use usb instead of sd-card ?!
what are the odds (well there is another oddity to add to my long list )

if anyone happens to have some altered/alternative/different versions of the autoscripts for balbes150's 20.10 version of Armbian ...   (not that i don't mind trying to make them myself ..)