from:"Josua Mayer"

Re: [OpenWrt-Devel] [PATCH v4 1/4] mvebu: add squashfs image type to MMCProfile

2016-06-21 Thread Josua Mayer

Hi Andrej,

Many thanks to your last reply which I seem to have totally missed,
sorry about that.

Am 11.05.2016 um 21:31 schrieb Andrej Vlasic:
> Hi Josua,
> 
> On 06.05.2016 02:15, Josua Mayer wrote:
>> Hi Andrej,
>>
>> First let me thank you for taking the time to review my proposals!
>>
>> Am 06.05.2016 um 02:04 schrieb Andrej Vlasic:
>>> Hi Josua,
>>>
>>> On 04.05.2016 21:24, josua.maye...@gmail.com wrote:
>>>> From: Josua Mayer <josua.maye...@gmail.com>
>>>>
>>>> Added gen_mvebu_sdcard_img.sh to create bootable sdcard images. It
>>>> takes
>>>> the bootloader and partition images to create a bootable sdcard image.
>>>>
>>>> Partition Layout:
>>>> p1: fat32: for kernel, dtb and boot config files if any
>>>> p2: squashfs: for openwrt
>>>>
>>>> This change is developed for the Clearfog, but should work on all A38x
>>>> SoCs that can boot from mmc.
>>>>
>>>> Signed-off-by: Josua Mayer <josua.maye...@gmail.com>
>>>> ---
>>>>  target/linux/mvebu/image/Makefile|  16 
>>>>  target/linux/mvebu/image/gen_mvebu_sdcard_img.sh | 100
>>>> +++
>>>>  tools/Makefile   |   1 +
>>>>  3 files changed, 117 insertions(+)
>>>>  create mode 100755 target/linux/mvebu/image/gen_mvebu_sdcard_img.sh
>>>>
>>>> diff --git a/target/linux/mvebu/image/Makefile
>>>> b/target/linux/mvebu/image/Makefile
>>>> index cb73c3b..fc5fded 100644
>>>> --- a/target/linux/mvebu/image/Makefile
>>>> +++ b/target/linux/mvebu/image/Makefile
>>>> @@ -107,6 +107,9 @@ define MMCProfile
>>>>  ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
>>>>  $(call Image/Build/Profile,$(1)/Initramfs)
>>>>  endif
>>>> +ifneq ($(CONFIG_TARGET_ROOTFS_SQUASHFS),)
>>>> +$(call Image/Build/squashfs)
>>>> +endif
>>>>endef
>>>>
>>>>define Image/Build/Profile/$(1)/Initramfs
>>>> @@ -114,6 +117,19 @@ define MMCProfile
>>>>  cp $(KDIR)/uImage-initramfs-$(2)
>>>> $(BIN_DIR)/$(IMG_PREFIX)-$(2)-initramfs
>>>>endef
>>>>
>>>> +  define Image/Build/Profile/$(1)/squashfs
>>>> +$(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
>>>> +cp $(KDIR)/root.squashfs
>>>> $(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs
>>>> +rm -f $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32
>>>> +mkfs.fat -C $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(shell echo
>>>> $$((4*1024)) # 4MB)
>>>> +mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32
>>>> $(KDIR)/zImage ::
>>>> +mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32
>>>> $(DTS_DIR)/$(2).dtb ::
>>>> +./gen_mvebu_sdcard_img.sh
>>>> "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-squashfs-sdcard.img" \
>>>> +
>>>> "$(BIN_DIR)/uboot-mvebu-clearfog/openwrt-mvebu-clearfog-u-boot-spl.kwb"
>>>> \
>>>> +c "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32" \
>>>> +83 "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs"
>>>> +  endef
>>>> +
>>>
>>> Image generation script here requires u-boot binary to exist, but what
>>> if one doesn't select u-boot to be generated? It would be better to
>> That would certainly be a problem.
>>> exclude it from generated sdcard image, it can be flashed anyway with dd
>>> to beginning of the sd card.
>> While I agree that this would work, it does not give the one-click
>> solution I would like to build. Why burden people with using dd to flash
>> u-boot to some magic offset on sdcard?
>>
>> Maybe we can add u-boot as a dependency so it is always built when
>> clearfog is selected?
>>>
> You could modify script to check if u-boot is selected and than include
> it, otherwise user just needs to flash it with dd to the beginning of sd
> card.
You are right. For simplicity I could just check if the u-boot binary
exists.
Another solution is to introduce a special value, say '-' and call it
with that from the Makefile if u-boot was not selected.
> 
>>> Also one ext4 partition for boot and second one for rootfs would be
>>> better than fat32 + squashfs on sdcard, both Marvell u-boot and
>>> uboot-mvebu have support for loading kernel from ext4.
&g

Re: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that prevented matching names

2016-06-19 Thread Josua Mayer

Hi Ram,

sorry for taking so long to reply.
So you are right that with a gpt-partition table this feature should be
straight forward. However GPT does not seem to be an option for many arm
boards. And sadly with the old MBR table I know of no way to set partname.

br
Josua Mayer


Am 09.05.2016 um 13:15 schrieb Ram Chandra Jangir:
> Hi Josua Mayer,
>
> Partname is nothing but respective partition name of emmc card. It reads 
> partition name from GPT partition table.
> I think fdisk may not be able to write partition name in GPT table, but you 
> should be able to create the partition name with GPT fdisk (consisting of the 
> gdisk, cgdisk, sgdisk, and fixparts programs).
>
> Thanks,
> Ram 
>
> -Original Message-
> From: Josua Mayer [mailto:josua.maye...@gmail.com] 
> Sent: Wednesday, May 04, 2016 6:13 PM
> To: Ram Chandra Jangir <rja...@codeaurora.org>; 
> openwrt-devel@lists.openwrt.org
> Subject: Re: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that 
> prevented matching names
>
> Hi Ram,
>
> Thanks for your comments. Now it appears I misunderstood what the code is 
> supposed to match.
> So if there is a PARTNAME= line, it can be matched.
>
> However on my system I dont have PARTNAME.
> Here a real-life sample:
> root@OpenWrt:/# cat /sys/block/mmcblk0/mmcblk0p3/uevent
> MAJOR=179
> MINOR=3
> DEVNAME=mmcblk0p3
> DEVTYPE=partition
> 
> What is partname and how can I set it? fdisk? filesystem label?
>
> br
> Josua Mayer
>
> Am 29.04.2016 um 14:35 schrieb Ram Chandra Jangir:
>> Thanks  Josua Mayer.
>>
>> Devname and partname both are different. Devname is holding the device 
>> node(ex.  mmcblkXpY) and given name(or partname) is the partition name(ex. 
>> rootfs or rootfs_data).
>> For below uevent  sysfs entries, it tries to populate the device 
>> node(mmcblkXpY) in devname variable and tries to match the given name with 
>> the PARTNAME(buf will have this value("PARTNAME=rootfs_data") at  n'th 
>> iteration).
>> If it is found then the loop will break, and we will get the given name's 
>> device node(/dev/mmcblkXpY) which will be mounted later.
>>
>> Example:
>> root@OpenWrt:/# cat /sys/block/mmcblk0/mmcblk0p3/uevent
>> MAJOR=179
>> MINOR=3
>> DEVNAME=mmcblk0p3  <--  device node: /dev/mmcblk0p3
>> DEVTYPE=partition
>> PARTN=3
>> PARTNAME=rootfs_data
>>
>> This is required, because the emmc card may have multiple partitions too. So 
>> our aim is to get the device node from the given name's uevent file.
>>
>> Thanks,
>> Ram
>>
>> -Original Message-
>> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] 
>> On Behalf Of josua.maye...@gmail.com
>> Sent: Thursday, April 28, 2016 11:50 PM
>> To: openwrt-devel@lists.openwrt.org
>> Cc: Josua Mayer <privacy@not.given>
>> Subject: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that 
>> prevented matching names
>>
>> From: Josua Mayer <privacy@not.given>
>>
>> Actually use the populated devname variable to compare against given name, 
>> instead of the buf variable, which incidentally contains either:
>> MAJOR=xyz, MINOR=x, or DEVTYPE=partition, none of which ever match a name.
>>
>> Signed-off-by: Josua Mayer <josua.maye...@gmail.com>
>> ---
>>  libfstools/ext4.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libfstools/ext4.c b/libfstools/ext4.c index 
>> f648aa8..b9401c3 100644
>> --- a/libfstools/ext4.c
>> +++ b/libfstools/ext4.c
>> @@ -78,7 +78,7 @@ ext4_part_match(char *dev, char *name, char *filename)
>>  continue;
>>  }
>>  /* Match partition name */
>> -if (strstr(buf, name))  {
>> +if (strstr(devname, name))  {
>>  ret = 0;
>>  break;
>>  }
>> --
>> 2.6.6
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
>>
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v4 1/4] mvebu: add squashfs image type to MMCProfile

2016-05-05 Thread Josua Mayer

Hi Andrej,

First let me thank you for taking the time to review my proposals!

Am 06.05.2016 um 02:04 schrieb Andrej Vlasic:
> Hi Josua,
> 
> On 04.05.2016 21:24, josua.maye...@gmail.com wrote:
>> From: Josua Mayer <josua.maye...@gmail.com>
>>
>> Added gen_mvebu_sdcard_img.sh to create bootable sdcard images. It takes
>> the bootloader and partition images to create a bootable sdcard image.
>>
>> Partition Layout:
>> p1: fat32: for kernel, dtb and boot config files if any
>> p2: squashfs: for openwrt
>>
>> This change is developed for the Clearfog, but should work on all A38x
>> SoCs that can boot from mmc.
>>
>> Signed-off-by: Josua Mayer <josua.maye...@gmail.com>
>> ---
>>  target/linux/mvebu/image/Makefile|  16 
>>  target/linux/mvebu/image/gen_mvebu_sdcard_img.sh | 100
>> +++
>>  tools/Makefile   |   1 +
>>  3 files changed, 117 insertions(+)
>>  create mode 100755 target/linux/mvebu/image/gen_mvebu_sdcard_img.sh
>>
>> diff --git a/target/linux/mvebu/image/Makefile
>> b/target/linux/mvebu/image/Makefile
>> index cb73c3b..fc5fded 100644
>> --- a/target/linux/mvebu/image/Makefile
>> +++ b/target/linux/mvebu/image/Makefile
>> @@ -107,6 +107,9 @@ define MMCProfile
>>  ifneq ($(CONFIG_TARGET_ROOTFS_INITRAMFS),)
>>  $(call Image/Build/Profile,$(1)/Initramfs)
>>  endif
>> +ifneq ($(CONFIG_TARGET_ROOTFS_SQUASHFS),)
>> +$(call Image/Build/squashfs)
>> +endif
>>endef
>>
>>define Image/Build/Profile/$(1)/Initramfs
>> @@ -114,6 +117,19 @@ define MMCProfile
>>  cp $(KDIR)/uImage-initramfs-$(2)
>> $(BIN_DIR)/$(IMG_PREFIX)-$(2)-initramfs
>>endef
>>
>> +  define Image/Build/Profile/$(1)/squashfs
>> +$(call prepare_generic_squashfs,$(KDIR)/root.squashfs)
>> +cp $(KDIR)/root.squashfs $(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs
>> +rm -f $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32
>> +mkfs.fat -C $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(shell echo
>> $$((4*1024)) # 4MB)
>> +mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32 $(KDIR)/zImage ::
>> +mcopy -i $(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32
>> $(DTS_DIR)/$(2).dtb ::
>> +./gen_mvebu_sdcard_img.sh
>> "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-squashfs-sdcard.img" \
>> +   
>> "$(BIN_DIR)/uboot-mvebu-clearfog/openwrt-mvebu-clearfog-u-boot-spl.kwb" \
>> +c "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-boot.fat32" \
>> +83 "$(BIN_DIR)/$(IMG_PREFIX)-$(2)-root.squashfs"
>> +  endef
>> +
> 
> Image generation script here requires u-boot binary to exist, but what
> if one doesn't select u-boot to be generated? It would be better to
That would certainly be a problem.
> exclude it from generated sdcard image, it can be flashed anyway with dd
> to beginning of the sd card.
While I agree that this would work, it does not give the one-click
solution I would like to build. Why burden people with using dd to flash
u-boot to some magic offset on sdcard?

Maybe we can add u-boot as a dependency so it is always built when
clearfog is selected?
> 
> Also one ext4 partition for boot and second one for rootfs would be
> better than fat32 + squashfs on sdcard, both Marvell u-boot and
> uboot-mvebu have support for loading kernel from ext4.
Very interesting you would argue on this part!
So I will just outline the reasons why I made this choice:
1) fat32
make it easier to edit boot files for Windows users too.
I think this will be very useful when somebody wants to supply bootargs
or try a different kernel, but is not familiar with using unix.
2) squashfs
I like the read-only nature of squashfs. What I am working towards is a
system that feels like just any router out there. Factory wiping
involves just clearing the read-write part of storage, while firmware
updates replace the read-only parts.
If anyone messes up, they can just mkfs.ext4, or rm -rf * on the data
partition.

Please let me know if you agree or disagree here.
> 
>>PROFILES_LIST += $(1)
>>  endef
>>
>> diff --git a/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh
>> b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh
>> new file mode 100755
>> index 000..88d017a
>> --- /dev/null
>> +++ b/target/linux/mvebu/image/gen_mvebu_sdcard_img.sh
>> @@ -0,0 +1,100 @@
>> +#!/bin/bash -x
>> +#
>> +# Copyright (C) 2016 Josua Mayer
>> +#
>> +# This program is free software; you can redistribute it and/or
>> +# modify it under the terms of the GNU General Public License
&g

Re: [OpenWrt-Devel] [PATCH v3 1/2] mvebu: config-4.1: make mmc drivers builtin

2016-05-04 Thread Josua Mayer

Hi Andrej,

Am 28.04.2016 um 23:59 schrieb Andrej Vlasic:
> Hi Josua,
> 
> On 28.04.2016 17:03, josua.maye...@gmail.com wrote:
>> From: Josua Mayer <privacy@not.given>
>>
>> This is especially useful on the Clearfog board which boots from mmc by
>> default.
>>
>> Signed-off-by: Josua Mayer <josua.maye...@gmail.com>
>> ---
>>  target/linux/mvebu/config-4.1 | 24 
>>  1 file changed, 24 insertions(+)
>>
>> diff --git a/target/linux/mvebu/config-4.1
>> b/target/linux/mvebu/config-4.1
>> index ee5c983..73319dd 100644
>> --- a/target/linux/mvebu/config-4.1
>> +++ b/target/linux/mvebu/config-4.1
>> @@ -362,3 +362,27 @@ CONFIG_ZBOOT_ROM_TEXT=0x0
>>  CONFIG_ZLIB_DEFLATE=y
>>  CONFIG_ZLIB_INFLATE=y
>>  CONFIG_ZONE_DMA_FLAG=0
>> +CONFIG_MMC=y
>> +CONFIG_MMC_BLOCK=y
>> +CONFIG_MMC_BLOCK_BOUNCE=y
>> +CONFIG_MMC_BLOCK_MINORS=8
>> +CONFIG_MMC_CB710=n
>> +CONFIG_MMC_CLKGATE=n
>> +CONFIG_MMC_DEBUG=n
>> +CONFIG_MMC_DW=n
>> +CONFIG_MMC_MVSDIO=y
>> +CONFIG_MMC_SDHCI=n
>> +CONFIG_MMC_TEST=n
>> +CONFIG_MMC_TIFM_SD=n
>> +CONFIG_MMC_TOSHIBA_PCI=n
>> +CONFIG_MMC_USDHI6ROL0=n
>> +CONFIG_MMC_USHC=n
>> +CONFIG_MMC_VIA_SDMMC=n
>> +CONFIG_MMC_VUB300=n
>> +CONFIG_MMC_SDHCI=y
>> +CONFIG_MMC_SDHCI_F_SDH30=n
>> +CONFIG_MMC_SDHCI_OF_ARASAN=n
>> +CONFIG_MMC_SDHCI_PCI=n
>> +CONFIG_MMC_SDHCI_PLTFM=y
>> +CONFIG_MMC_SDHCI_PXAV3=y
>> +CONFIG_SDIO_UART=n
>>
> 
> Instead of adding those config options to default kernel config, it
> would be better to create new mvebu subtarget, maybe called "harddisk"
> that has support for external boot devices.

Thanks for your pointer at this. I now created such a target using
ixp4xx as a template.
Please let me know if the new approach is any better.

br
Josua Mayer
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 1/2] mount_root: implement overlay= boot option

2016-05-04 Thread Josua Mayer

Hi everyone,

please note that this patch is not final in that the code does not look
for device-node-names, but for a partition name.
But don't hesitate to comment anyway!

Am 04.05.2016 um 14:45 schrieb josua.maye...@gmail.com:
> From: Josua Mayer <privacy@not.given>
> 
> This change adds code to handle a new option on cmdline: overlay=
> This is used to find the rootfs_data partition / disk when it has a
> non-standard name or location.
> 
> It takes either the device node name, or the full path to the device node:
> i.e. /dev/mmcblk0p3 or mmcblk0p3
> 
> This option has precedence over the default name "rootfs_data", and extroot.
> 
> Signed-off-by: Josua Mayer <josua.maye...@gmail.com>.
> ---
>  mount_root.c | 29 +
>  1 file changed, 29 insertions(+)
> 
> diff --git a/mount_root.c b/mount_root.c
> index 47a3409..446e3cc 100644
> --- a/mount_root.c
> +++ b/mount_root.c
> @@ -33,6 +33,35 @@ start(int argc, char *argv[1])
>   if (!getenv("PREINIT"))
>   return -1;
>  
> + /*
> +  * Check cmdline for a hint about overlay device
> +  */
> + if (!data) {
> + FILE *fp;
> + char buffer[100] = {0};
> +
> + fp = fopen("/proc/cmdline", "r");
> + while (!feof(fp)) {
> + if(fscanf(fp, "overlay=%s", buffer))
> + break;
> +
> + fseek(fp, 1, SEEK_CUR);
> + }
> + fclose(fp);
> +
> + // overlay= argument was found
> + if (buffer[0]) {
> + // strip /dev/ prefix if any
> + int offset = 0;
> + if (strstr(buffer, "/dev/"))
> + offset = 5;
> +
> + // try to find the volume
> + ULOG_NOTE("Looking for overlay device given on 
> commandline\n");
> + data = volume_find(buffer + offset);
> + }
> + }
> +
>   if (!data) {
>   root = volume_find("rootfs");
>   volume_init(root);
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that prevented matching names

2016-05-04 Thread Josua Mayer

Hi Ram,

Thanks for your comments. Now it appears I misunderstood what the code
is supposed to match.
So if there is a PARTNAME= line, it can be matched.

However on my system I dont have PARTNAME.
Here a real-life sample:
root@OpenWrt:/# cat /sys/block/mmcblk0/mmcblk0p3/uevent
MAJOR=179
MINOR=3
DEVNAME=mmcblk0p3
DEVTYPE=partition

What is partname and how can I set it? fdisk? filesystem label?

br
Josua Mayer

Am 29.04.2016 um 14:35 schrieb Ram Chandra Jangir:
> Thanks  Josua Mayer.
> 
> Devname and partname both are different. Devname is holding the device 
> node(ex.  mmcblkXpY) and given name(or partname) is the partition name(ex. 
> rootfs or rootfs_data).
> For below uevent  sysfs entries, it tries to populate the device 
> node(mmcblkXpY) in devname variable and tries to match the given name with 
> the PARTNAME(buf will have this value("PARTNAME=rootfs_data") at  n'th 
> iteration).
> If it is found then the loop will break, and we will get the given name's 
> device node(/dev/mmcblkXpY) which will be mounted later.
> 
> Example:
> root@OpenWrt:/# cat /sys/block/mmcblk0/mmcblk0p3/uevent
> MAJOR=179
> MINOR=3
> DEVNAME=mmcblk0p3  <--  device node: /dev/mmcblk0p3
> DEVTYPE=partition
> PARTN=3
> PARTNAME=rootfs_data
> 
> This is required, because the emmc card may have multiple partitions too. So 
> our aim is to get the device node from the given name's uevent file.
> 
> Thanks,
> Ram
> 
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On 
> Behalf Of josua.maye...@gmail.com
> Sent: Thursday, April 28, 2016 11:50 PM
> To: openwrt-devel@lists.openwrt.org
> Cc: Josua Mayer <privacy@not.given>
> Subject: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that 
> prevented matching names
> 
> From: Josua Mayer <privacy@not.given>
> 
> Actually use the populated devname variable to compare against given name, 
> instead of the buf variable, which incidentally contains either:
> MAJOR=xyz, MINOR=x, or DEVTYPE=partition, none of which ever match a name.
> 
> Signed-off-by: Josua Mayer <josua.maye...@gmail.com>
> ---
>  libfstools/ext4.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libfstools/ext4.c b/libfstools/ext4.c index f648aa8..b9401c3 
> 100644
> --- a/libfstools/ext4.c
> +++ b/libfstools/ext4.c
> @@ -78,7 +78,7 @@ ext4_part_match(char *dev, char *name, char *filename)
>   continue;
>   }
>   /* Match partition name */
> - if (strstr(buf, name))  {
> + if (strstr(devname, name))  {
>   ret = 0;
>   break;
>   }
> --
> 2.6.6
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3 1/2] mvebu: config-4.1: make mmc drivers builtin

2016-05-01 Thread Josua Mayer


Hi Andrej,

Am 28.04.2016 um 23:59 schrieb Andrej Vlasic:


Hi Josua,

On 28.04.2016 17:03, josua.maye...@gmail.com wrote:

From: Josua Mayer <privacy@not.given>

This is especially useful on the Clearfog board which boots from mmc by
default.

Signed-off-by: Josua Mayer <josua.maye...@gmail.com>
---
 target/linux/mvebu/config-4.1 | 24 
 1 file changed, 24 insertions(+)

diff --git a/target/linux/mvebu/config-4.1 
b/target/linux/mvebu/config-4.1

index ee5c983..73319dd 100644
--- a/target/linux/mvebu/config-4.1
+++ b/target/linux/mvebu/config-4.1
@@ -362,3 +362,27 @@ CONFIG_ZBOOT_ROM_TEXT=0x0
 CONFIG_ZLIB_DEFLATE=y
 CONFIG_ZLIB_INFLATE=y
 CONFIG_ZONE_DMA_FLAG=0
+CONFIG_MMC=y
+CONFIG_MMC_BLOCK=y
+CONFIG_MMC_BLOCK_BOUNCE=y
+CONFIG_MMC_BLOCK_MINORS=8
+CONFIG_MMC_CB710=n
+CONFIG_MMC_CLKGATE=n
+CONFIG_MMC_DEBUG=n
+CONFIG_MMC_DW=n
+CONFIG_MMC_MVSDIO=y
+CONFIG_MMC_SDHCI=n
+CONFIG_MMC_TEST=n
+CONFIG_MMC_TIFM_SD=n
+CONFIG_MMC_TOSHIBA_PCI=n
+CONFIG_MMC_USDHI6ROL0=n
+CONFIG_MMC_USHC=n
+CONFIG_MMC_VIA_SDMMC=n
+CONFIG_MMC_VUB300=n
+CONFIG_MMC_SDHCI=y
+CONFIG_MMC_SDHCI_F_SDH30=n
+CONFIG_MMC_SDHCI_OF_ARASAN=n
+CONFIG_MMC_SDHCI_PCI=n
+CONFIG_MMC_SDHCI_PLTFM=y
+CONFIG_MMC_SDHCI_PXAV3=y
+CONFIG_SDIO_UART=n



Instead of adding those config options to default kernel config, it 
would be better to create new mvebu subtarget, maybe called "harddisk" 
that has support for external boot devices.
Personally I would prefer not to create a new target, just for different 
boot storage. There can be spi flash, sdcard, emmc, sata, who-knows-what 
other flavours. But I suppose there are mvebu devices out there with 
very limited flash memory?


So what do you think about making a new target mvebu_fat, which includes 
all the storage drivers that the supported SoCs have?
I came up with the name because my target device, the clearfog has 
plenty of storage so it does not mind if the OpenWRT image grows fat.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 1/3] mount_root: implement overlay= boot option

2016-04-29 Thread Josua Mayer



Am 29.04.2016 um 07:47 schrieb Rafał Miłecki:
> On 28 April 2016 at 20:20,   wrote:
>> @@ -33,6 +33,35 @@ start(int argc, char *argv[1]) if
>> (!getenv("PREINIT")) return -1;
>> 
>> +   /* +* Check cmdline for a hint about overlay
>> device +*/ +   if(!data) { +   FILE *fp; 
>> +   char buffer[100] = {0}; + +   fp =
>> fopen("/proc/cmdline", "r"); +   while(!feof(fp)) { +
>> if(fscanf(fp, "overlay=%s", buffer)) +
>> break;
> 
> Please keep coding style consistent across the project. You can see
> there is: if (!getenv("PREINIT")) with space after "if". Please
> update your code to use the same style, e.g.: if (!data) while
> (!feof(fp)) {
> 
Will do, thanks for the pointer (I really didn't notice)!
Meanwhile any comments on the content itself?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v4 1/4] mvebu: add squashfs image type to MMCProfile

Re: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that prevented matching names

Re: [OpenWrt-Devel] [PATCH v4 1/4] mvebu: add squashfs image type to MMCProfile

Re: [OpenWrt-Devel] [PATCH v3 1/2] mvebu: config-4.1: make mmc drivers builtin

Re: [OpenWrt-Devel] [PATCH v3 1/2] mount_root: implement overlay= boot option

Re: [OpenWrt-Devel] [PATCH v2 2/3] ext4_part_match: fix bug that prevented matching names

Re: [OpenWrt-Devel] [PATCH v3 1/2] mvebu: config-4.1: make mmc drivers builtin

Re: [OpenWrt-Devel] [PATCH v2 1/3] mount_root: implement overlay= boot option

8 matches

Site Navigation

Mail list logo

Footer information