thx arci, currently implementing old vs. new kernel...
only question: new kernels have ULK in name - old ones not - is this enough to differentiate them?
thx arci, currently implementing old vs. new kernel...
only question: new kernels have ULK in name - old ones not - is this enough to differentiate them?
"Every Setback is a Set Up for a Comeback"
In simple terms ...
The ULK definition is one of the rules imposed by @The_Ripper and @Telesat to easily recognize the kernel version inside file patch.e2 container and being able to manage it from their AZUp Tool !!!
For a more professional control ... for example ... you could discriminate (FNIB) magic header that on unlicensed kernel version (vmlinux_xload.zbf) start always from offset address x00000090h ... while ... on the licensed version (xrpc_xload_vmlinux_ES4_prod.bin) at this offset address begins data area for Hash customer key definitions (Sigma SDK) for SoC's XRPC control & decrypt kernel on VRAM.
Another thing to be recommended for the MAT tool ... before nor-flash writing process ... you always have to check that PLL divider clock is set to normal (SoC not overclocked) otherwise you risk corrupting the data on the nor-flash ... in this case the receiver can be recovered only with Jtag procedure or replacing nor-flash with other one already programmed !
On XENV data environment (setxenv):
XENV Block "Overclocked" PLL clock divider settings
XENV Block "Normal" PLL clock divider settingsCode:(0x00) 4 x.pll3 0x01020065
XENV Block "Normal" PLL clock divider variable set:Code:(0x00) 4 x.pll3 0x01020057
Obviously, in the case, the new setting will be effective only after a reboot of the receiver !!!Code:setxenv -b x.pll3 0x01020057
Ciao ...
Geändert von arci (24.03.2015 um 23:51 Uhr)
implemented - thx (with next version)
"Every Setback is a Set Up for a Comeback"
My problem is, if I create a fullbackup I don't have the ULK info available anymore...The ULK definition is one of the rules imposed by @The_Ripper and @Telesat to easily recognize the kernel version inside file patch.e2 container and being able to manage it from their AZUp Tool !!!
For a more professional control ... for example ... you could discriminate (FNIB) magic header that on unlicensed kernel version (vmlinux_xload.zbf) start always from offset address x00000090h ... while ... on the licensed version (xrpc_xload_vmlinux_ES4_prod.bin) at this offset address begins data area for Hash customer key definitions (Sigma SDK) for SoC's XRPC control & decrypt kernel on VRAM
so I need a way to find it out just having the kernel.img or of the running system
Can you give me some more details to the more professional control?
"Every Setback is a Set Up for a Comeback"
There aren't many kernel versions for azbox ...
Official Opensat fw - kernel Opensat licensed
2.6.15-sigma - (Opensat key licenced)
First E2 - kernel version licensed
2.6.22.19-19-the_ripper- Sigma Licensed (? key)
2.6.22.19-25-the-ripper - Sigma Licensed (? key)
2.6.29-the-ripper - Sigma Licensed (? key)
Last E2 - kernel version not licensed
3.3.1-opensat - ULK
3.4.4-opensat - ULK
3.9.2-opensat - ULK
Example ... simple verification method for reconstruction e2 image info:
plus check with ... setxenv -f /dev/mtdblock/0 ... if you want verify "y.start" start point set ... for confirmation !!!Code:root@azboxhd:~# uname -a Linux azboxhd 3.3.1-opensat #1 PREEMPT Thu Mar 5 02:59:52 CET 2015 mips GNU/Linux root@azboxhd:~# cat /etc/motd HDMU 13881 Git 1956 root@azboxhd:~# cat /etc/version 201503241537 root@azboxhd:~# cat /etc/.box azboxhd root@azboxhd:~# cat /proc/model ultra
Ciao ...Code:root@azboxhd:~# setxenv -f /dev/mtdblock/0 (0x00) 4 a.avclk_mux 00.00.00.00. 0x00000000 (0x00) 8 a.board_id 22.38.35.32.2d.45.32.22. "852-E2" (0x00) 4 a.cd2_freq 00.d8.b8.05. 0x05b8d800 (0x00) 4 a.cd4_freq 55.a0.fc.01. 0x01fca055 (0x00) 4 a.cd5_freq 40.78.7d.01. 0x017d7840 (0x00) 4 a.cd6_freq 00.2d.31.01. 0x01312d00 (0x00) 4 a.cd7_freq 00.2d.31.01. 0x01312d00 (0x00) 4 a.chip_rev 86.00.34.86. 0x86340086 (0x00) 4 a.enable_devices ce.1a.02.00. 0x00021ace (0x00) 4 a.gpio_data 00.00.00.76. 0x76000000 (0x00) 4 a.gpio_dir 38.00.00.76. 0x76000038 (0x00) 4 a.gpio_irq_map 20.08.09.20. 0x20090820 (0x00) 4 a.hostclk_mux 00.01.00.00. 0x00000100 (0x00) 4 a.irq_fall_edge_hi 00.00.00.00. 0x00000000 (0x00) 4 a.irq_fall_edge_lo 00.c0.00.00. 0x0000c000 (0x00) 4 a.irq_rise_edge_hi 9f.00.00.00. 0x0000009f (0x00) 4 a.irq_rise_edge_lo 00.ca.28.ff. 0xff28ca00 (0x00) 4 a.pb_cs_config 40.00.0e.00. 0x000e0040 (0x00) 4 a.pb_def_timing 10.10.10.10. 0x10101010 (0x00) 4 a.pb_timing0 10.10.10.10. 0x10101010 (0x00) 4 a.pb_timing1 01.01.11.00. 0x00110101 (0x00) 4 a.pb_timing2 10.10.5f.10. 0x105f1010 (0x00) 4 a.pb_use_timing0 f4.03.00.00. 0x000003f4 (0x00) 4 a.pb_use_timing1 f3.03.00.00. 0x000003f3 (0x00) 4 a.pb_use_timing2 f8.03.00.00. 0x000003f8 (0x00) 4 a.pcidev1_irq_route 01.01.01.01. 0x01010101 (0x00) 4 a.pcidev2_irq_route 01.01.01.01. 0x01010101 (0x00) 4 a.pcidev3_irq_route 02.02.02.02. 0x02020202 (0x00) 4 a.pcidev4_irq_route 02.02.02.02. 0x02020202 (0x00) 4 a.scard_5v_pin 01.00.00.00. 0x00000001 (0x00) 4 a.scard_cmd_pin 02.00.00.00. 0x00000002 (0x00) 4 a.scard_off_pin 00.00.00.00. 0x00000000 (0x00) 4 a.uart0_baudrate 00.c2.01.00. 0x0001c200 (0x00) 4 a.uart0_gpio_data 00.00.00.00. 0x00000000 (0x00) 4 a.uart0_gpio_dir 00.00.00.00. 0x00000000 (0x00) 4 a.uart0_gpio_mode 6e.7f.00.00. 0x00007f6e (0x00) 4 a.uart1_baudrate 80.25.00.00. 0x00002580 (0x00) 4 a.uart1_gpio_data 00.00.00.00. 0x00000000 (0x00) 4 a.uart1_gpio_dir 00.00.00.00. 0x00000000 (0x00) 4 a.uart1_gpio_mode 6e.7f.00.00. 0x00007f6e (0x00) 4 a.uart_console_port 00.00.00.00. 0x00000000 (0x00) 4 a.uart_used_ports 02.00.00.00. 0x00000002 (0x00) 4 l.cs0_size 00.00.00.00. 0x00000000 (0x00) 4 l.cs1_size 00.00.00.00. 0x00000000 (0x00) 4 l.cs2_part1_offset 00.00.00.00. 0x00000000 (0x00) 4 l.cs2_part1_size 00.00.02.00. 0x00020000 (0x00) 4 l.cs2_part2_offset 00.00.02.00. 0x00020000 (0x00) 4 l.cs2_part2_size 00.00.02.00. 0x00020000 (0x00) 4 l.cs2_part3_offset 00.00.04.00. 0x00040000 (0x00) 4 l.cs2_part3_size 00.00.04.00. 0x00040000 (0x00) 4 l.cs2_part4_offset 00.00.08.00. 0x00080000 (0x00) 4 l.cs2_part4_size 00.00.68.00. 0x00680000 (0x00) 4 l.cs2_part5_offset 00.00.70.00. 0x00700000 (0x00) 4 l.cs2_part5_size 00.00.10.00. 0x00100000 (0x00) 4 l.cs2_parts 05.00.00.00. 0x00000005 (0x00) 4 l.cs2_size 00.00.80.00. 0x00800000 (0x00) 4 l.cs3_size 00.00.00.00. 0x00000000 (0x00) 4 x.boot 00.00.02.00. 0x00020000 (0x00) 4 x.csf 02.00.00.00. 0x00000002 (0x00) 4 x.d0.cfg ba.11.41.f3. 0xf34111ba (0x00) 4 x.d0.dl0 44.44.0a.00. 0x000a4444 (0x00) 4 x.d1.cfg ba.11.41.f3. 0xf34111ba (0x00) 4 x.d1.dl0 44.44.0a.00. 0x000a4444 (0x00) 4 x.ds 80.00.02.00. 0x00020080 (0x00) 4 x.dt 01.00.00.00. 0x00000001 (0x00) 4 x.mux 01.07.00.00. 0x00000701 (0x00) 10 y.gateway 22.31.30.2e.30.2e.31.2e.31.22. "10.0.1.1" (0x00) 12 y.ipaddr 22.31.30.2e.30.2e.31.2e.31.39.39.22. "10.0.1.199" (0x00) 3 y.startdelay 22.31.22. "1" (0x00) 13 y.subnetmask 22.32.35.35.2e.32.35.35.2e.30.2e.30.22. "255.255.0.0" (0x00) 4 z.boot0 00.00.04.00. 0x00040000 (0x00) 4 z.boot1 00.00.08.00. 0x00080000 (0x00) 4 z.boot2 00.00.04.00. 0x00040000 (0x00) 4 z.boot3 00.00.08.00. 0x00080000 (0x00) 16 a.build_date 22.54.44.32.31.30.3a.32.30.30.39.30.31.32.33.22. "TD210:20090123" (0x00) 19 a.eth_mac 22.30.30.2e.30.32.2e.31.34.2e.31.39.2e.41.35.2e.43.39.22. "00.02.14.19.A5.C9" (0x00) 31 a.linux_cmd 22.6d.65.6d.3d.31.30.37.6d.20.63.6f.6e.73.6f.6c.65.3d.74.74.79.53.30.2c.31.31.35.32.30.30.22. "mem=107m console=ttyS0,115200" (0x00) 4 x.pll3 57.00.02.01. 0x01020057 (0x00) 45 y.start 64.75.6d.70.20.72.6f.6d.66.73.20.30.78.61.63.30.38.30.30.30.30.3b.6c.6f.61.64.20.7a.62.66.20.30.78.61.63.30.38.30.30.39.30.3b.20.67.6f. dump romfs 0xac080000;load zbf 0xac080090; go 79 records, 1707 bytes root@azboxhd:~#
thx arci - i thought there would be a way to analyze the kernel.img...
OK - then I mark the kernel version of the fullbackup using the kernel description (ULK for new, anything else for old kernels)...
only thing left: testing my fullbackup with azup
my new procedere:
- box in rescue mode? if no reboot to rm
- box overclocked? if yes switch it to normal mode and reboot
- enough ram available?
- started tool from /tmp? otherwise big warning for flashing
- check kernel CRC on PC
- check for same kernel CRC after uploading
- check for same kernel CRC after flashing (if it fails - install old kernel again)
- setting up environment for either old or new kernel
- flash image
- done
"Every Setback is a Set Up for a Comeback"
OK ... but three things yet:thx arci - i thought there would be a way to analyze the kernel.img...
OK - then I mark the kernel version of the fullbackup using the kernel description (ULK for new, anything else for old kernels)...
only thing left: testing my fullbackup with azup
my new procedere:
- box in rescue mode? if no reboot to rm
- box overclocked? if yes switch it to normal mode and reboot
- enough ram available?
- started tool from /tmp? otherwise big warning for flashing
- check kernel CRC on PC
- check for same kernel CRC after uploading
- check for same kernel CRC after flashing (if it fails - install old kernel again)
- setting up environment for either old or new kernel
- flash image
- done
1) box in rescue mode? if no reboot to rm
Yesterday, I have made an Italian guide for flashing AZBoxHD with the MAT and in a test phase ... at reboot the receiver did not go into rescue mode ... but it start previous stored DOM image ... and the tool is remained on waiting stalled !
Since we were still in the safety area (no flashing procedure started) I turned off the receiver and closed the tool ... then I started with the receiver already in rescue mode (STB On - Vol +) ... and of course everything went correctly !
Only, so you know ...
2) started tool from /tmp? otherwise big warning for flashing
OK ... I have not checked if already is possible ... but wanting ... it would not be appropriate to allow the cache and transfer procedure using also an USB storage device ? ... if the user prefers this ... obviously with choice conditioned by the tool !
3) check for same kernel CRC after flashing (if it fails - install old kernel again)
After you have flashed the new kernel on nor-flash and the CRC control not passes, how do you restore previous kernel version? Do you do a security backup before flashing process? I think so ...
Have a nice day and thanks for the great support ... Ciao
@1) did he use the new Toolsfolder? Otherwise reboot to RM fails
@2) not yet - from the next version; but I already flashed from movie partition without problems
@3) of course
greets
"Every Setback is a Set Up for a Comeback"