[martinredolatti]

Cool thanks a lot!

I tried building the kernel using "meson_reff16_defconfig" and everything went fine.

I renamed it to uImage_recovery, placed it on the only fat partition and booted with the reset pressed. LCD screen stayed black.

I forgot to tell you, i'm now working on a geniatech/MyGica ATV1000 now. Also has an AMLOGIC8726M3 but i'm not sure if it's f16ref

Am I using the right configuration for the kernel?
Should I see the kernel boot-up messages on the screen? or are they sent to the UART?

I know i'm not using a root filesystem yet, I want to get the kernel to boot and then start working on a root fs.

Thanks a lot!

Martín.

[j1nx]

The geniatech products are not f16ref, so you should take another config. Kernel boot is sent to uart, so hook up a ttl adapter.

Good luck!

[davilla]

And stay away from flashing uboot or recovery. These are sure fire ways to semi-brick a box

[noggin]

And stay away from flashing uboot or recovery. These are sure fire ways to semi-brick a box

Yep - UART access is very useful - as is Davilla's very sensible suggestion to me of running an NFS server with the rootfs and TFTPing the kernel. A LOT faster than flashing SD cards.

Haven't had much time to start properly looking at the USB power issue on my box. Think it might be a GPIO thing? Is it feasible a GPIO line would control USB power - particularly on Host vs OTG vs Slave?

[martinredolatti]

I thought it was!

I flashed one of the devices with the image you provide on your site thru the recovery menu of the geniatech and XBMC boots and works flawlessly except for wifi.

Do you remember what defconfig you used for that?

Thanks!

[davilla]

Haven't had much time to start properly looking at the USB power issue on my box. Think it might be a GPIO thing? Is it feasible a GPIO line would control USB power - particularly on Host vs OTG vs Slave?

yep

[noggin]

http://openlinux.amlogic.com/wiki/index.php/GPIO Seems to work in both Android (which works properly) and Linux - do you think booting in Android and then Linux and comparing the results might tell me something?

[j1nx]

CONFIG_CMDLINE_EXTEND does a prepend not an append. So what is in CONFIG_CMDLINE comes 1st. What comes 1st is used. If the same parameter is found again, it it ignored. This is by design so you can override a uboot command-line value.

CONFIG_CMDLINE="root=/dev/mtdblock2 rw rootfstype=yaffs2 init=/sbin/init"
CONFIG_CMDLINE_EXTEND=y

[ 0.000000] Kernel command line: root=/dev/mtdblock2 rw rootfstype=yaffs2 init=/sbin/init rw noinitrd root=/dev/nfs nfsroot=192.168.2.202:/opt/aml-rootfs-m3,nfsvers=3 init=/sbin/init ip=192.168.2.215:192.168.2.202:192.168.2.1:255.255.255.0:target:eth0:off console=ttyS0,115200 a9_clk=800M clk81=187500k nohltmem=1024M mac=00:0d:fe:7b:5c:c4 logo=osd1,0x84100000,full,1080p,full androidboot.resolution=720p resolution_size=1280,720

The quote is actually from the GBox thread, but move the discussing to this thread for obvious reasons.

Davilla,

I am reading into the PATCH logics used for the CONFIG_CMDLINE_EXTEND and while indeed the values are concatenated, the main reason about the patch was to allow for variables not been set by uboot. The uboot parameters are appended to the ones from the CMDLINE.

Now while this appears to be fine for the root= (it is not set within uboot, because of the initrd I guess) it looks like rootfstype= is not really playing nice or the way you wanted it to be. I was wondering. Does the Pivos uses YAFFS2 under Android as well?

CONFIG_CMDLINE is meant to be a default in case nothing else managed to set the command line, unless CONFIG_CMDLINE_FORCE is set in which case it overrides whatever was found earlier.

It kind of suprises me Pivos does not have issues.

[martinredolatti]

Kernel is booting.

I soldered a couple of cables and a max3232 and was able to see the output in my laptop.

Is it possible to see such info in the TV instead? Or you can't because of TV not having text-mode like computer screens do? I noticed XBMC doesn't have a command line either unless you ssh from from a pc.

Should I start a new thread since I am no longer working on an f16ref?

Thanks everyone for all the help!

[davilla]

CONFIG_CMDLINE_EXTEND does a prepend not an append. So what is in CONFIG_CMDLINE comes 1st. What comes 1st is used. If the same parameter is found again, it it ignored. This is by design so you can override a uboot command-line value.

CONFIG_CMDLINE="root=/dev/mtdblock2 rw rootfstype=yaffs2 init=/sbin/init"
CONFIG_CMDLINE_EXTEND=y

[ 0.000000] Kernel command line: root=/dev/mtdblock2 rw rootfstype=yaffs2 init=/sbin/init rw noinitrd root=/dev/nfs nfsroot=192.168.2.202:/opt/aml-rootfs-m3,nfsvers=3 init=/sbin/init ip=192.168.2.215:192.168.2.202:192.168.2.1:255.255.255.0:target:eth0:off console=ttyS0,115200 a9_clk=800M clk81=187500k nohltmem=1024M mac=00:0d:fe:7b:5c:c4 logo=osd1,0x84100000,full,1080p,full androidboot.resolution=720p resolution_size=1280,720

The quote is actually from the GBox thread, but move the discussing to this thread for obvious reasons.

Davilla,

I am reading into the PATCH logics used for the CONFIG_CMDLINE_EXTEND and while indeed the values are concatenated, the main reason about the patch was to allow for variables not been set by uboot. The uboot parameters are appended to the ones from the CMDLINE.

Now while this appears to be fine for the root= (it is not set within uboot, because of the initrd I guess) it looks like rootfstype= is not really playing nice or the way you wanted it to be. I was wondering. Does the Pivos uses YAFFS2 under Android as well?

CONFIG_CMDLINE is meant to be a default in case nothing else managed to set the command line, unless CONFIG_CMDLINE_FORCE is set in which case it overrides whatever was found earlier.

It kind of suprises me Pivos does not have issues.

Seems to work fine for us, in fact, I'm the one that added the patch for cmdline extend.

[j1nx]

Strange because the patch is designed such that parameters are prepended and be override by the appended uboot passed parameters. But if the Pivos android firmware also has the /system partition formatted as yafs2 it makes sence it works for you. root= is not set in uboot, so it is nicely prepending that variable, ignoring the rootfs=

EDIT: Or Pivos firmware has moved both the root= and rootfstype= away from the uboot env's

[davilla]

Below is the normal cmdline for m1/android

Code:

root@android:/ # cat /proc/cmdline                                            
console=ttyS0,115200n8 logo=osd1,0x84100000,full,720p,full androidboot.resolution=720p resolution_size=1200,690 mem=512M a9_clk=800M clk81=200000000 mac=00:0d:fe:74:25:42

<5>[    0.000000] Kernel command line: console=ttyS0,115200n8 logo=osd1,0x84100000,full,720p,full androidboot.resolution=720p resolution_size=1200,690 mem=512M a9_clk=800M clk81=200000000 mac=00:0d:fe:74:25:42

geniatech runs a kernel embedded initramfs, inside that is the init.rc which contains 'mount yaffs2 mtd@system /system'. So that's how system gets mounted. For plain linux kernels, we don't run a kernel embedded initramfs so the cmdline is extended to handle where root is located and the type of filesystem.

I highly recommend that rather than modifying CONFIG_CMDLINE_EXTEND, a replacement is created like CONFIG_CMDLINE_SOMETHING and in this you can do both the extend and the override. While CONFIG_CMDLINE_EXTEND is not present in m1/m3 kernel code from amlogic, It is a real kernel patch that was added after 2.6.34 and you don't want your modifications to collide when dealing with AML MX dual-core which uses 3.0.8+.

[jaybob413]

I took that approach to add a CMDLINE_APPEND configuration option that populates default_command_line with the inverse of what CMDLINE_EXTEND does. It copies the bootloader args first (tag->u.cmdline.cmdline), then concatenates the kernel command string (CMDLINE). This keeps the options from the bootloader, but allows them to be overridden by the kernel config. This is working for G-Box and fixes the MAC address issue by using the ethadd value from the bootloader.

https://github.com/wjb/buildroot-linux-k...7b7667cac9

[j1nx]

Great, just saw your PR. This was exactly what i was searching for or had planned (although i called it config_cmdline_override, but it appears that is the old force) Still don't believe we are the only ones that want to override only some of the uboot parameters.

Will revert the dirty boolean hack and use this instead.

@davilla,

That is exactly the way how it is done with android indeed. It is completely beyond me why all those f16ref boxes have rootfstype defined in the uboot parameters, while it is not used?

[davilla]

@jaybob413, please pull request that commit back pivos if you can, it is something that might be handy with future aml CPUs.