balbes150 Posted November 15, 2018 Share Posted November 15, 2018 4 hours ago, jock said: Again: to let the tvbox boot from the sdcard, eMMC must be erased. I'm not a masochist to put on such experiments. I have everything I need to restore almost any AML TV box, but I'm not going to do such stupid experiments. All the more I strongly not recommend other to do such experiments without serious training and real need. 3 hours ago, zogu said: # store init 3 (u-boot command) This command completely erases the entire eMMC (including the u-boot loader), turning the TV box into a brick. To start system, you need a guaranteed working version of u-boot for your TV box model or set (firmware+cable+software) to restore from the PC. The instruction referenced by the user is intended solely for developers who need to be able to test their work. In particular, check the operation of its version of u-boot. Are you a system developer? 1 Link to comment Share on other sites More sharing options...
jock Posted November 15, 2018 Share Posted November 15, 2018 24 minutes ago, balbes150 said: I'm not a masochist to put on such experiments. I have everything I need to restore almost any AML TV box, but I'm not going to do such stupid experiments. All the more I strongly not recommend other to do such experiments without serious training and real need. Your choice. Doing "experiments" is for people who has the proper skills to do that. As long as you asked, I answered. Never said you or anyone else must do it for any reason. just to be clear, because it looks like I'm bringing people into mysterious and self-destroying practices: perhaps you intend "you have to" as instructions or obligation to follow a suggestion; NOPE. It is intended as "in the case you want to do this, the fullfil your goal the operation to do is ...". So, again, I'm not suggesting anyone to erase their's eMMC, just explaining how the boot thing works (it still looks like the thread title is "s905w boot process?", isn't it?) Link to comment Share on other sites More sharing options...
zogu Posted November 15, 2018 Share Posted November 15, 2018 It does not look so dangerous , didn't know what it does. I don't want to brick my box and never tried soething what i don't know what it does, , but also i have some skills and a lot of hardware (uart, jtag, eeprom and flash programmers), but usually i'm using it when someone else brick his device. Thank you for explanation and all your help for all our devices. I'm using older version on my tv boxes, but i like to learn and test everything else I'm not developer, i work as linux sysadmin, i just quote what jock posted not knowing what this command does. 1 hour ago, balbes150 said: This command completely erases the entire eMMC (including the u-boot loader), turning the TV box into a brick. To start system, you need a guaranteed working version of u-boot for your TV box model or set (firmware+cable+software) to restore from the PC. The instruction referenced by the user is intended solely for developers who need to be able to test their work. In particular, check the operation of its version of u-boot. Are you a system developer? Sent from my Redmi Note 4 using Tapatalk Link to comment Share on other sites More sharing options...
PiotrO Posted November 16, 2018 Author Share Posted November 16, 2018 Guys, I think we need to distiguish booting from sd and _unattended_ booting from sd. In case of my hw (tx3-mini) I think unattended boot from sd is NOT possible without erasing[modifying] eMMC bootloader. I think so as IPL by default is passing control to eMMC. So if we want unattended boot from SD - we MUST: 1\ change eMMC content 2\ modify IPL As IPL is in ROM (I think) - only option 1\ is choice. Reasonably written IPL should have fall-back to SD[USB] if SPL from eMMC fails (i.e. for case when flash ageing leading to data rot). In such case IPL should offer recovery by booting from SD and refresh eMMC SPL. So I agree with initial @jock answer as IMHO his intention was to describe what needs t be done to have tv-box _unattended_ boot from sd 1 Link to comment Share on other sites More sharing options...
Tido Posted November 16, 2018 Share Posted November 16, 2018 On 11/9/2018 at 4:03 PM, PiotrO said: Rest of things packed in 2835 SoC: BCM2835-ARM-Peripherals.pdf If You are interested for more details - here You go: 2835 details or here why it is what it is, but not ARM https://www.youtube.com/watch?v=eZd0IYJ7J40 Link to comment Share on other sites More sharing options...
balbes150 Posted November 16, 2018 Share Posted November 16, 2018 6 hours ago, PiotrO said: Guys, I think we need to distiguish booting from sd and _unattended_ booting from sd. In case of my hw (tx3-mini) I think unattended boot from sd is NOT possible without erasing[modifying] eMMC bootloader. I think so as IPL by default is passing control to eMMC. So if we want unattended boot from SD - we MUST: 1\ change eMMC content 2\ modify IPL As IPL is in ROM (I think) - only option 1\ is choice. Reasonably written IPL should have fall-back to SD[USB] if SPL from eMMC fails (i.e. for case when flash ageing leading to data rot). In such case IPL should offer recovery by booting from SD and refresh eMMC SPL. So I agree with initial @jock answer as IMHO his intention was to describe what needs t be done to have tv-box _unattended_ boot from sd For TV boxes (and not only) everything you need to run different systems from external media has long been developed, tested and used on thousands of devices. And it's called " universal multi-boot." It is used in all versions of Armbian, Libreelec, Archlinux, Volumio etc for TV boxes on Amlogic s905 s912 s805 S812 etc. If you like to "reinvent the wheel" - that's your right. By the way, you can run an external system without any modification of u-boot (for example, if the user does not want to make the minimum changes to the existing system on his TV box), but it is not convenient, because it will require each time to run a regular Android and perform several steps in it. Link to comment Share on other sites More sharing options...
jock Posted November 16, 2018 Share Posted November 16, 2018 7 hours ago, PiotrO said: Guys, I think we need to distiguish booting from sd and _unattended_ booting from sd. In case of my hw (tx3-mini) I think unattended boot from sd is NOT possible without erasing[modifying] eMMC bootloader. I think so as IPL by default is passing control to eMMC. So if we want unattended boot from SD - we MUST: 1\ change eMMC content 2\ modify IPL As IPL is in ROM (I think) - only option 1\ is choice. Reasonably written IPL should have fall-back to SD[USB] if SPL from eMMC fails (i.e. for case when flash ageing leading to data rot). In such case IPL should offer recovery by booting from SD and refresh eMMC SPL. So I agree with initial @jock answer as IMHO his intention was to describe what needs t be done to have tv-box _unattended_ boot from sd You exactly got the point! Link to comment Share on other sites More sharing options...
PiotrO Posted November 16, 2018 Author Share Posted November 16, 2018 Guys, Finally I have working (and quite understand) booting on my s905w with my full control on software used/configured. My system is working enough to start exploring GLES (via ARM mail blobs) and hw video decode (v4l2 m2m). Huge thx for Your really helpful support! Just quick Q: Has anybody have this in kernel log (in every 120sec)? [ 242.654622] INFO: task kworker/2:1:35 blocked for more than 120 seconds. [ 242.655686] Not tainted 4.19.0 #1 [ 242.659570] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [ 242.667272] kworker/2:1 D 0 35 2 0x00000028 [ 242.672714] Workqueue: events_freezable mmc_rescan [ 242.677434] Call trace: [ 242.679908] __switch_to+0x94/0xd8 [ 242.683224] __schedule+0x1e4/0x620 [ 242.686677] schedule+0x38/0xa0 [ 242.689761] schedule_timeout+0x1f4/0x378 [ 242.693761] wait_for_common+0xb8/0x170 [ 242.697537] wait_for_completion+0x14/0x20 [ 242.701635] mmc_wait_for_req_done+0x28/0x170 [ 242.705950] mmc_wait_for_req+0x80/0xf0 [ 242.709705] mmc_send_tuning+0x120/0x1d8 [ 242.713580] meson_mmc_execute_tuning+0x68/0x228 [ 242.718194] mmc_execute_tuning+0x60/0xa0 [ 242.722120] mmc_init_card+0x8c4/0x19d0 [ 242.725922] mmc_attach_mmc+0xc0/0x180 [ 242.729658] mmc_rescan+0x300/0x3d8 [ 242.733075] process_one_work+0x1e8/0x340 [ 242.737035] worker_thread+0x40/0x460 [ 242.740700] kthread+0x128/0x130 [ 242.743854] ret_from_fork+0x10/0x1c I don't have this with balbes150 kernel - so there must be something balbes150 add to his kernel and I'm missing.... 1 Link to comment Share on other sites More sharing options...
jock Posted November 20, 2018 Share Posted November 20, 2018 On 11/17/2018 at 12:04 AM, PiotrO said: Just quick Q: Has anybody have this in kernel log (in every 120sec)? I don't have this with balbes150 kernel - so there must be something balbes150 add to his kernel and I'm missing.... It seems that the eMMC driver has some issues dealing with it. Are you compiling your own kernel or using an already compiled one? AFAIK the eMMC driver is work in progress and in my latest tests (long ago) on 4.18 it was not working at all (or not present, didn't dig through) Link to comment Share on other sites More sharing options...
PiotrO Posted November 20, 2018 Author Share Posted November 20, 2018 33 minutes ago, jock said: Are you compiling your own kernel or using an already compiled one? I'm building my own kernel by patching mainline 4.19.0 Probably diff on my kernel vs. balbes150 will give hint - but maybe balbes150 has quick idea here? Link to comment Share on other sites More sharing options...
PiotrO Posted November 21, 2018 Author Share Posted November 21, 2018 By accident I discover that issue events_freezable mmc_rescan is 4.19 GA regression compared to 4.19-rc4 as I don't have this in 4.19-rc4. Need to look at kernel sources. Any pointers to narrow such sources inspection? Link to comment Share on other sites More sharing options...
Recommended Posts