Se vuoi posso provarlo solo dovresti essere sicuro che non mi si in*cula il cellulare se c'è qualcosa che non va:)
Visualizzazione stampabile
non sono certo che il comando fastboot possa funzionare, comunque continuando a leggere in giro ho scoperto che la board del nostro telefono usa proprio la k3v2oem1 come il d quad... stavo preparando uno zip per il kernel originale da flashare con la recovery e mi sono imbattuto in un paio di problemi... ti riporto quello che avevo in mente:
La nostra recovery però non supporta il comando mount che gli do (dice che vuole solo 3 parametri)codice:mount("ext4", "EMMC", "/dev/block/mmcblk0p15", "/system");
mount("ext4", "EMMC", "/dev/block/mmcblk0p18", "/data");
mount("ext4", "EMMC", "/dev/block/mmcblk0p16", "/cache");
# ---- Flash the kernel ----
ui_print("");
ui_print("Installing Kernel, please wait a moment...");
ui_print("-----------------------------------------");
show_progress(0.100000, 60);
package_extract_dir("kernel_update", "/tmp");
package_extract_file("boot/flash_image", "/tmp/flash_image");
set_perm(0, 0, 0777, "/tmp/flash_image");
assert(package_extract_file("boot/zImage", "/tmp/zImage"),
run_program("/tmp/flash_image", "/dev/block/mmcblk0p11", "/tmp/zImage"),
delete("/tmp/zImage"));
delete("/tmp/flash_image");
ui_print("Kernel successfully installed");
show_progress(0.100000, 0);
# ---- Clean ----
ui_print("");
ui_print("Cleaning...");
ui_print("This may take a while...");
ui_print("-----------------------------------------");
show_progress(0.100000, 60);
delete_recursive("/sys/devices/system/cpu/cpu0/cpufreq");
delete_recursive("/sys/devices/system/cpu/cpu/cpufreq");
delete("/sys/devices/system/cpu/cpu/sched_mc_power_savings");
delete_recursive("/cache");
ui_print("");
show_progress(1.000000, 0);
ui_print("Cleaning complete!");
unmount("/system");
unmount("/data");
la mia idea era di usare flash_image (incluso nel pacchetto zip) per flashare il kernel (per intenderci) però a questo punto mi sa che è meglio rivisitare l'intero script.
anche questo tentativo non ha funzionato per la cronaca:
fatto un tentativo con il semplicecodice:ui_print(" FLASHING ");
show_progress(0.100000, 0);
ui_print("Doing necessary wipes.. ");
delete_recursive("/cache");
run_program("/sbin/busybox", "sync");
package_extract_file("boot.img", "/tmp/boot.img");
run_program("/sbin/busybox", "dd", "if=/dev/zero", "of=/dev/block/mmcblk0p11");
run_program("/sbin/busybox", "sync");
run_program("/sbin/busybox", "dd", "if=/tmp/boot.img", "of=/dev/block/mmcblk0p11");
delete("/tmp/boot.img");
run_program("/sbin/busybox", "sync");
delete_recursive("/cache");
show_progress(0.100000, 0);
ui_print(" DONE. ");
e si è bloccato sul logo Huawei ma niente brick..codice:package_extract_file("boot.img", "/dev/block/platform/hi_mci.1/by-name/boot");
però non sono ancora sicuro che abbia fatto veramente il suo dovere quel comando... riproverò con il kernel stock
quindi a breve ci sarà un nuovo kernel fatto da voi?
ok c'è qualcosa che non va nella mia procedura di pack zImage e Ramdisk...
qualcuno mi può spiegare come si fa?
Quote:
Originariamente inviato da mangusta86
Tu non sai quanto io sia felice di averti condotto verso questo forum....
A parte tutto grazie davvero per quello che state facendo..siete fantastici!
Inviato dal mio HUAWEI U9508 usando Androidiani App
Mmm..., allora la tua giustamente è una procedura per installazione da recovery, ma realisticamente parlando ci conviene? Io molto + semplicemente flasho il kernel con fastboot e poi eseguo un backup con cwm della rom e la si distribuisce!! Poi dopo si pensa a procedure come la tua, cioè concentriamoci sul nocciolo della questione prima.
Cmq se il kernel andasse bene non escludo un porting da cyanogen , anche se la la cosa si fa complicata a causa del bootloader .
Fastboot non credo lo potremo usare comunque flash_image ha funzionato bene (ovviamente devi dargli il block esatto che se gli dici solo boot, non fa niente), credo che il suo lavoro lo abbia fatto...
forse però ho capito cosa non fa avviare il nostro kernel...
Io gli ho sempre passato questa stringa che non credo sia corretta:
e credo che debba somigliare di più a quella con cui ricompatto il kernelcodice:CONFIG_CMDLINE="console=ttyAMA4,115200 k3v2_pmem=1 root=/dev/mmcblk0p2 rootfstype=ext2 rw init=/init"
qualche idea?codice:console=ttyS0 vmalloc=384M k3v2_pmem=1 mmcparts=mmcblk0:p1(xloader),p3(nvme),p4(misc),p5(splash),p6(oeminfo),p7(reserved1),p8(reserved2),p9(recovery2),p10(recovery),p11(boot),p12(modemimage),p13(modemnvm1),p14(modemnvm2),p15(system),p16(cache),p17(cust),p18(userdata);mmcblk1:p1(ext_sdcard)
Hai ancora il bootloop? Io ora flasho... pregate per me..... :)
Aggiornamento,
fastboot non si richiama il fatidico comando boot ( avevi ragione mangusta86 ) ... :'( credo sia bloccato , a questo punto non resta che flasharlo sul serio e studiare la soluzione di mangusta86!!
A questo punto non converrebbe usare il config_cmdline della seconda stringa ma nella sua versione completa (prendendo come spunto il nostro)?
Gli si indica anche il tipo di bootloader in questo modo, o no...?
ps: tra l'altro, non mi convice quel rootfstype=ext2...
Il mount del nostro dispositivo mi restituisce:
Quote:
rootfs / rootfs ro,relatime 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
none /acct cgroup rw,relatime,cpuacct 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
none /dev/cpuctl cgroup rw,relatime,cpu 0 0
/dev/block/mmcblk0p15 /system ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p16 /cache ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p18 /data ext4 rw,nosuid,nodev,noatime,user_xattr,acl,commit=20,b arrier=0,data=writeback,noauto_da_alloc,discard 0 0
/dev/block/platform/hi_mci.1/by-name/cust /cust ext4 ro,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p12 /modem/modem_image ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p13 /modem/nvm1 ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/block/mmcblk0p14 /modem/nvm2 ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
/dev/block/platform/hi_mci.1/by-name/reserved2 /reserved2 ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0
/sys/kernel/debug /sys/kernel/debug debugfs rw,relatime 0 0
tmpfs /data/peers tmpfs rw,relatime,mode=700,gid=1000 0 0
/dev/block/vold/179:97 /mnt/sdcard2 vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,g id=1015,fmask=0002,dmask=0002,allow_utime=0020,cod epage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
/dev/block/vold/179:97 /mnt/secure/asec vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,g id=1015,fmask=0002,dmask=0002,allow_utime=0020,cod epage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
tmpfs /mnt/sdcard2/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0
/dev/fuse /mnt/sdcard fuse rw,nosuid,nodev,relatime,user_id=1023,group_id=102 3,default_permissions,allow_other 0 0.... ecc.
Il rootfstype ext2 a me sembra ok, in Linux tutte le partizioni di boot sono sempre ext2. Non capisco cosa sia il 115200 e soprattutto cosa cambia cambiando il nome del device della console...
Qualcuno mi illumini.
Comunque non avevo boot loop, si impianta proprio al simbolo Huawei e basta
Inviato dal mio HUAWEI U9508 con Tapatalk 2
In allegato il kernel modificato .mangusta86 hai detto che flash_image ha fatto il suo dovere, ma in che senso? Ha flashato il kernel ma hai comunque un blocco ma non un brick?
https://mega.co.nz/#!eA83BSQL!AFr0y3...sEaZ9m7jhv1Awo
Si in effetti mi riferivo in parte a quel comando, il problema è che comunque devi configurare il kernel a mano se non vuoi usare un file .config esistente e dovrai comunque passargli qualcosa come argomento a cmdline
Inviato dal mio HUAWEI U9508 con Tapatalk 2
Ecco il mistero svelato per il valore 115200 , Very recent Linux kernels can also o...ts per second.
Questo è un buon punto di partenza, ora bisognerebbe capire qual è la partizione di root corretta, guardate se potete su github il kernel del gs2 di dorimanx e il suo initramfs, io mi ispiro a lui e mi ha confermato che possiamo usare il suo codice a nostro piacimento...
Se si riesce a capire come è strutturato il filesystem prima di dare il comando init sarebbe un ottima cosa
Inviato dal mio HUAWEI U9508 con Tapatalk 2
Se riesci a dirmi anche da dove prende il file di configurazione_defconfig nel repo del mio kernel mi fai un piacere così quando sono a casa riprovo a compilare
Inviato dal mio HUAWEI U9508 con Tapatalk 2
allora, o lo prendiamo dal dispositivo con questi comandi
adb pull /proc/config.gz ~/kernel_source/kernel
cd ~/kernel_source/kernel
gunzip config.gz
e poi prendiamo il config e lo compiliamo con
make menuconfig
e poi
make
io questa cosa l'ho già fatta modificando anche il pqmos con l'allegato che ti ho inviato
In ogni caso questo è il path /u9508/arch/arm/configs/hisi_k3v2oem1_defconfig
Io non me la sento di flasharlo in maniera definitiva , vorrei aspettare conferme dall' ingegnere huawei!!
bhe mettiamola cosi, se non hai il coraggio tu, figurati gli altri...
Comunque nel frattempo ho scompattato anche la recovery cinese e ho la sua ramdisk...
date un occhio a recovery.fstab se non ci credete:
codice:# mount point fstype device
# DTS2012030702504 l00186011 2012/03/07 reserve the data of inner_sdcard when resetuser
/sdcard datamedia /dev/null
/system ext4 /dev/block/platform/hi_mci.1/by-name/system
/cache ext4 /dev/block/platform/hi_mci.1/by-name/cache
/data ext4 /dev/block/platform/hi_mci.1/by-name/userdata length=-16384
/misc emmc /dev/block/platform/hi_mci.1/by-name/misc
/boot emmc /dev/block/platform/hi_mci.1/by-name/boot
/recovery emmc /dev/block/platform/hi_mci.1/by-name/recovery
/cust ext4 /dev/block/platform/hi_mci.1/by-name/cust
#/uboot emmc /dev/block/platform/hi_mci.1/by-name/uboot
#/reserved2 ext4 /dev/block/platform/hi_mci.1/by-name/reserved2
/external_sd vfat /dev/block/mmcblk1p1
...................
Un ringraziamento speciale a mangusta86, per avere reso disponibili allo studio, i sorgenti del kernel dell' Ascend D quad :)
Quote:
Originariamente inviato da Rockguy40
Quotissimo....
Inviato dal mio HUAWEI U9508 usando Androidiani App
Sono andato sul profilo facebook della huawei, a quanto pare brullica di domande ed ogni tanto c'è qualche risposta......
Ecco la mia,
Hi, i'm a devolper and i would ask you if the U9510 and the U9508 has the same IDENTICAL hardware. huawei has'nt still publisced the source code for u9508, but has publisced the sources of u9510.
I've compiled the kernel of the u9510 and wanna flash it over U9508.
Thanx in advance.
https://www.facebook.com/huaweidevic...63561?filter=2
per quanto riguarda il fastboot che volevo provare, il bootloader deve essere sbloccato con un codice da 16 cifre che per ora huawei tiene nascosto nonostante ci sia una petizione
a questo link https://www.change.org/es/peticiones...for-all-models
pare che servano solo 100 firme :o
Per mangusta86: forse converrebbe recuperare la ramdisk dalla recovery ufficiale, ho appena messo tutto stock causa vari esperimenti , e facendo caso alla procedura di update ho notato la dicitura flashing kernel, insomma forse possiamo capirci qualcosa di più da li...
detto fatto...
https://github.com/mangusta86/ramdisk1
https://github.com/mangusta86/ramdisk2
comunque il kernel lo ho flashato più e più volte... non ha fatto niente... il problema è che non fa niente appunto... però sono sicuro di averlo flashato zippandolo... nel prossimo post metto lo script che ho usato... poi se volete vi passo il resto del materiale che serve e faccio un piccolo tutorial se lo vorrete usare....
codice:# Script Pack Kernel + Ramdisk
# By Mangusta86 credit to Adi_Pat
tput setaf 6
setterm -bold
echo "**** KERNEL PACKER SCRIPT ****"
echo "**** By Mangusta86 ****"
echo "**** Credit to Adi_Pat ****"
tput sgr0
setterm -bold
echo "Checking zImage in kernel/zImage"
if test -e kernel/zImage
then echo "zImage found"
else echo "Kernel not found!"
tput sgr0
exit
fi
echo "Checking Ramdisk"
if test -d ramdisk
then echo "Ramdisk found"
else echo "Ramdisk not found!"
tput sgr0
exit
fi
echo "zImage + ramdisk found, preparing ramdisk"
sleep 2
find ramdisk/. | cpio -o -H newc | gzip > ramdisk.cpio.gz
#./tools/mkbootfs ramdisk | gzip > ramdisk.gz
sleep 2
echo "Packing final Kernel (boot.img) "
mkdir -p out
cp kernel/zImage zImage
./tools/mkbootimg --kernel zImage --ramdisk ramdisk.cpio.gz --base 0x0 --cmdline 'console=ttyS0 vmalloc=384M k3v2_pmem=1 mmcparts=mmcblk0:p1(xloader),p3(nvme),p4(misc),p5(splash),p6(oeminfo),p7(reserved1),p8(reserved2),p9(recovery2),p10(recovery),p11(boot),p12(modemimage),p13(modemnvm1),p14(modemnvm2),p15(system),p16(cache),p17(cust),p18(userdata);mmcblk1:p1(ext_sdcard)' -o out/boot.img
sleep 2
setterm -bold
rm ramdisk.cpio.gz
rm zImage
echo "boot.img ready!"
echo "Making CWM Flashable zip file"
cd out
# Copy some essential files
cp -r ../tools/META-INF META-INF
cp ../tools/signapk.jar signapk.jar
cp ../tools/testkey.x509.pem testkey.x509.pem
cp ../tools/testkey.pk8 testkey.pk8
cp ../tools/reserved.img reserved.img
###################################
zip -r Kernel-Mangusta86-CWM.zip META-INF boot.img reserved.img
echo "ZIP Ready, signing it"
java -jar signapk.jar testkey.x509.pem testkey.pk8 Kernel-Mangusta86-CWM.zip SIGNED_Mangusta86_CWM.zip
# Remove everything ###############
rm Kernel-Mangusta86-CWM.zip
rm *.jar
rm *.pk8
rm *.pem
rm -r META-INF
rm reserved.img
cd ..
##################################
s1=`ls -lh boot.img | sed -e 's/.* [ ]*\([0-9]*\.[0-9]*[MK]\) .*/\1/g'`
cd out
s2=`ls -lh boot.img | sed -e 's/.* [ ]*\([0-9]*\.[0-9]*[MK]\) .*/\1/g'`
rm boot.img
tput setaf 3
echo "Size of old boot.img: $s1"
echo "Size of new boot.img: $s2"
tput setaf 1
echo "Flashable zip is out/SIGNED_Mangusta86_CWM.zip"
tput sgr0
setterm -bold
echo "All Done, press enter to exit"
tput sgr0
read ANS
Questo è un dmsg della recovery dall'avvio: di particolare importanza abbiamo finalmente la kernel command line (aka CMDLINE) e qualche info in più per lo sviluppo del kernel
codice:<6>[0.0, swapper] [ 0.000000] Initializing cgroup subsys cpuset
<6>[0.0, swapper] [ 0.000000] Initializing cgroup subsys cpu
<5>[0.0, swapper] [ 0.000000] Linux version 3.0.8-02064-gc66cb43 (android@localhost) (gcc version 4.6.x-google 20120106 (prerelease) (GCC) ) #2 SMP PREEMPT Wed Dec 12 16:53:44 GMT 2012
<4>[0.0, swapper] [ 0.000000] CPU: ARMv7 Processor [413fc090] revision 0 (ARMv7), cr=10c5387f
<4>[0.0, swapper] [ 0.000000] CPU: VIPT nonaliasing data cache, VIPT aliasing instruction cache
<4>[0.0, swapper] [ 0.000000] Machine: huawei
<6>[0.0, swapper] [ 0.000000] k3v2_mem_setup
<6>[0.0, swapper] [ 0.000000] k3v2_mem = 524256K@0x20000000
<6>[0.0, swapper] [ 0.000000] early_k3v2_mem start 0x20000000 size 0x0
<6>[0.0, swapper] [ 0.000000] [bdid]boardid = 0x47.
<4>[0.0, swapper] [ 0.000000] power down charge p:0, pd_charge_flag :0
<4>[0.0, swapper] [ 0.000000] enter recovery p:1, enter_recovery_flag :1
<4>[0.0, swapper] [ 0.000000] runmode is normal, runmode_factory = 0
<6>[0.0, swapper] [ 0.000000] hpm_value = 67.
<4>[0.0, swapper] [ 0.000000] logctl p:1, logctl :1
<6>[0.0, swapper] [ 0.000000] cpu_maxfreq = 0.
<4>[0.0, swapper] [ 0.000000] Memory policy: ECC disabled, Data cache writeback
<4>[0.0, swapper] [ 0.000000] k3v2oem2 map io
<7>[0.0, swapper] [ 0.000000] On node 0 totalpages: 203264
<7>[0.0, swapper] [ 0.000000] free_area_init_node: node 0, pgdat c087b060, node_mem_map c125f000
<7>[0.0, swapper] [ 0.000000] Normal zone: 1216 pages used for memmap
<7>[0.0, swapper] [ 0.000000] Normal zone: 0 pages reserved
<7>[0.0, swapper] [ 0.000000] Normal zone: 154432 pages, LIFO batch:31
<7>[0.0, swapper] [ 0.000000] HighMem zone: 372 pages used for memmap
<7>[0.0, swapper] [ 0.000000] HighMem zone: 47244 pages, LIFO batch:15
<6>[0.0, swapper] [ 0.000000] PERCPU: Embedded 7 pages/cpu @c189f000 s5216 r8192 d15264 u32768
<7>[0.0, swapper] [ 0.000000] pcpu-alloc: s5216 r8192 d15264 u32768 alloc=8*4096
<7>[0.0, swapper] [ 0.000000] pcpu-alloc: [0] 0 [0] 1 [0] 2 [0] 3
<4>[0.0, swapper] [ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 201676
<5>[0.0, swapper] [ 0.000000] Kernel command line: k3v2_mem=524256K@0x20000000 console=ttyS0 vmalloc=384M k3v2_pmem=1 mmcparts=mmcblk0:p1(xloader),p3(nvme),p4(misc),p5(splash),p6(oeminfo),p7(reserved1),p8(reserved2),p9(recovery2),p10(recovery),p11(boot),p12(modemimage),p13(modemnvm1),p14(modemnvm2),p15(system),p16(cache),p17(cust),p18(userdata);mmcblk1:p1(ext_sdcard) boardid=0x36200110,0x00000024,0x00000047 pd_charge=0 enter_recovery=1 androidboot.swtype=normal fastboot_version=U9508V100R001C00B107_FASTBOOT androidboot.serialno=022AMY2131016587 androidboot.powerupreason=NORMAL sb=sl hpm_value=67 setup_logctl=1 cpu_maxfreq=
<4>[0.0, swapper] [ 0.000000] pmem allocating 81854464 bytes at (31b00000 physical) for gpu pmem area
Cavolo, lo avevo proprio dimenticato quel comando! :D
Tra l'altro, ci sono moltissime altre voci interessanti (praticamente si mette a nudo tutto il terminale, dal. boot, al reg, al prob, ecc. )
Una in particolare potrebbe fare la gioia di noi tutti;
Oltre ad avere anche la conferma del driver usb-otg che viene registrato.Quote:
<4>[183.0, HDMIDaemon] [ 5.834900]
<4>[183.0, HDMIDaemon] [ 5.834978] hdmi[W]:hdmi_control_hpd_store:1954: this device support mhl, and don't need to enable hpd.
<4>[183.0, HDMIDaemon] [ 5.835172]
ps: Marco, mentre si aspetta (speriamo) i sorgenti del nostro kernel, si potrebbe già dare un occhiatina di confronto sul prob dei driver del tuo sorgente :)
pps: curiosità, il kernel registra tutte e 3 gli scheduler (noop, deadline e il cfq che usa di default) e il device ha il più Alto partizionamento della storia LOL!!! (18, leggasi diciotto!)
Mi sono letto tutte le partizioni in esadecimale... sto male:eek: domani vi dirò quello che ho scoperto. Qualche novità c é...
Sent from my HUAWEI U9508 using Tapatalk 2
con tutto lo smazzo che vi state facendo...... avete dato un'occhiata a questa pagina ????ROM????? io l'ho tradotta con chrome e l'ho trovata piuttosto interessante
Non solo è il telefono più partizionato, ma è anche quello più chiuso, se non fosse per il fastboot bloccato su alcuni comandi avremmo già fatto!! imvece ci tocca fare il reverse....