Booting Linux bzImage on x86_64
Hi, I recently discovered barebox and I am trying to boot a Linux bzImage on an x86_64 embedded platform. Some background: My project involves an x86_64 embedded device for which I am building a bzImage and a root filesystem with buildroot. The idea is to have multiple combinations of these in order to serve different use cases, but also for fallback situations. I went down both possible ways on x86, but cannot really find a way to boot a bzImage. Both configurations are tested under QEMU with barebox 2015.10.0. 1. EFI - I have a working barebox.efi living inside an EF00 partition. The issue I am having is that I cannot really find any pointers as to how to boot a bzImage from these. I have found some earlier posts on the list indicating that it is not possible to boot a bzImage from EFI, but also a G+ post saying that it is possible. 2. Non-EFI - I have compiled barebox with the attached config file, but it seems to triple fault according to qemu. AFAICT (zero asm knowledge here), it seems to be in pmjump.S. Triple fault CPU Reset (CPU 0) EAX= EBX=0001 ECX=0018 EDX=0011 ESI=7c9f EDI=0030 EBP= ESP=79fa EIP=00024b42 EFL=0006 [-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES = 9300 DPL=0 DS16 [-WA] CS =0010 00cf9b00 DPL=0 CS32 [-RA] SS = 9300 DPL=0 DS16 [-WA] DS = 9300 DPL=0 DS16 [-WA] FS = 9300 DPL=0 DS16 [-WA] GS = 0000 9300 DPL=0 DS16 [-WA] LDT= 8200 DPL=0 LDT TR = 8b00 DPL=0 TSS32-busy GDT= 81e0 0037 IDT= 03ff CR0=0011 CR2= CR3= CR4= DR0= DR1= DR2= DR3= DR6=0ff0 DR7=0400 CCS=002c CCD=0011 CCO=LOGICB EFER= FCW=037f FSW= [ST=0] FTW=00 MXCSR=1f80 FPR0= FPR1= FPR2= FPR3= FPR4= FPR5= FPR6= FPR7= XMM00= XMM01= XMM02= XMM03= XMM04= XMM05= XMM06= XMM07= Any advice / pointer would be welcome as to booting a bzImage on x86. Thanks. -- Abraar config-bb Description: Binary data ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
[PATCH v2 1/2] arm/cpu/start.c: Distil some common code in __start().
Both barebox_boarddata and barebox_boot_dtb perform essentially the
same function -- hold a pointer to a chunk of private data. Since only
one variable is ever used at any given time we may as well merge those
two variable into one. This also allows us to share more code between
two boot paths (board data vs. device tree)
Signed-off-by: Andrey Smirnov
---
Changes since v1:
- Unified barebox_boarddata and barebox_boot_dtb into
barebox_private_data which allowed to simplify distilled code
and avoid using double star pointers
arch/arm/cpu/start.c | 58 +---
1 file changed, 37 insertions(+), 21 deletions(-)
diff --git a/arch/arm/cpu/start.c b/arch/arm/cpu/start.c
index 8e5097b..066dad8 100644
--- a/arch/arm/cpu/start.c
+++ b/arch/arm/cpu/start.c
@@ -32,25 +32,35 @@
#include "mmu-early.h"
unsigned long arm_stack_top;
-static void *barebox_boarddata;
+static void *barebox_private_data;
u32 barebox_arm_machine(void)
{
struct barebox_arm_boarddata *bd;
- if (!barebox_boarddata)
+ if (!barebox_private_data)
return 0;
- bd = barebox_boarddata;
+ bd = barebox_private_data;
return bd->machine;
}
-static void *barebox_boot_dtb;
-
void *barebox_arm_boot_dtb(void)
{
- return barebox_boot_dtb;
+ return barebox_private_data;
+}
+
+static uint32_t get_any_boarddata_magic(const void *boarddata)
+{
+ if (get_unaligned_be32(boarddata) == FDT_MAGIC)
+ return FDT_MAGIC;
+
+ if (((struct barebox_arm_boarddata *)boarddata)->magic ==
+ BAREBOX_ARM_BOARDDATA_MAGIC)
+ return BAREBOX_ARM_BOARDDATA_MAGIC;
+
+ return 0;
}
static noinline __noreturn void __start(unsigned long membase,
@@ -70,7 +80,6 @@ static noinline __noreturn void __start(unsigned long membase,
pr_debug("memory at 0x%08lx, size 0x%08lx\n", membase, memsize);
- barebox_boarddata = boarddata;
arm_stack_top = endmem;
endmem -= STACK_SIZE; /* Stack */
@@ -89,21 +98,28 @@ static noinline __noreturn void __start(unsigned long
membase,
}
if (boarddata) {
- if (get_unaligned_be32(boarddata) == FDT_MAGIC) {
- uint32_t totalsize = get_unaligned_be32(boarddata + 4);
+ uint32_t totalsize = 0;
+ const char *name;
+
+ switch (get_any_boarddata_magic(boarddata)) {
+ case FDT_MAGIC:
+ totalsize = get_unaligned_be32(boarddata + 4);
+ name = "DTB";
+ break;
+ case BAREBOX_ARM_BOARDDATA_MAGIC:
+ totalsize = sizeof(struct barebox_arm_boarddata);
+ name = "machine type";
+ break;
+ default:
+ break;
+ }
+
+ if (totalsize) {
endmem -= ALIGN(totalsize, 64);
- barebox_boot_dtb = (void *)endmem;
- pr_debug("found DTB in boarddata, copying to 0x%p\n",
- barebox_boot_dtb);
- memcpy(barebox_boot_dtb, boarddata, totalsize);
- } else if (((struct barebox_arm_boarddata *)boarddata)->magic ==
- BAREBOX_ARM_BOARDDATA_MAGIC) {
- endmem -= ALIGN(sizeof(struct barebox_arm_boarddata),
64);
- barebox_boarddata = (void *)endmem;
- pr_debug("found machine type in boarddata, copying to
0x%p\n",
- barebox_boarddata);
- memcpy(barebox_boarddata, boarddata,
- sizeof(struct barebox_arm_boarddata));
+ pr_debug("found %s in boarddata, copying to 0x%lu\n",
+name, endmem);
+ barebox_private_data = memcpy((void *)endmem,
+ boarddata, totalsize);
}
}
--
2.1.4
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
[PATCH v2 2/2] arm/cpu: Avoid multiple definitions of barebox_arm_entry
All versions of barebox_arm_entry (in uncompress.c, start.c and
start-pbl.c) appear to be doing exacty the same thing. So move the
definition into a separate file and use IS_ENABLED macro to avoid
re-definition.
Signed-off-by: Andrey Smirnov
---
Changes since v1:
- Hopefully more meningfull names for former internal symbols
arch/arm/cpu/Makefile | 4 ++--
arch/arm/cpu/entry.c | 38 +
arch/arm/cpu/entry.h | 48 +++
arch/arm/cpu/start-pbl.c | 29 +---
arch/arm/cpu/start.c | 29 ++--
arch/arm/cpu/uncompress.c | 16 +---
6 files changed, 92 insertions(+), 72 deletions(-)
create mode 100644 arch/arm/cpu/entry.c
create mode 100644 arch/arm/cpu/entry.h
diff --git a/arch/arm/cpu/Makefile b/arch/arm/cpu/Makefile
index fb3929c..418bcab 100644
--- a/arch/arm/cpu/Makefile
+++ b/arch/arm/cpu/Makefile
@@ -1,7 +1,7 @@
obj-y += cpu.o
obj-$(CONFIG_ARM_EXCEPTIONS) += exceptions.o
obj-$(CONFIG_ARM_EXCEPTIONS) += interrupts.o
-obj-y += start.o setupc.o
+obj-y += start.o setupc.o entry.o
#
# Any variants can be called as start-armxyz.S
@@ -23,7 +23,7 @@ AFLAGS_pbl-cache-armv7.o :=-Wa,-march=armv7-a
pbl-$(CONFIG_CPU_32v7) += cache-armv7.o
obj-$(CONFIG_CACHE_L2X0) += cache-l2x0.o
-pbl-y += setupc.o
+pbl-y += setupc.o entry.o
pbl-$(CONFIG_PBL_SINGLE_IMAGE) += start-pbl.o
pbl-$(CONFIG_PBL_MULTI_IMAGES) += uncompress.o
diff --git a/arch/arm/cpu/entry.c b/arch/arm/cpu/entry.c
new file mode 100644
index 000..3b74c6a
--- /dev/null
+++ b/arch/arm/cpu/entry.c
@@ -0,0 +1,38 @@
+#include
+
+#include
+
+#include "entry.h"
+
+/*
+ * Main ARM entry point. Call this with the memory region you can
+ * spare for barebox. This doesn't necessarily have to be the full
+ * SDRAM. The currently running binary can be inside or outside of
+ * this region. TEXT_BASE can be inside or outside of this
+ * region. boarddata will be preserved and can be accessed later with
+ * barebox_arm_boarddata().
+ *
+ * -> membase + memsize
+ * STACK_SIZE - stack
+ * 16KiB, aligned to 16KiB - First level page table if early MMU support
+ * is enabled
+ * 128KiB - early memory space
+ * -> maximum end of barebox binary
+ *
+ * Usually a TEXT_BASE of 1MiB below your lowest possible end of memory should
+ * be fine.
+ */
+
+void __naked __noreturn barebox_arm_entry(unsigned long membase,
+ unsigned long memsize, void
*boarddata)
+{
+ arm_setup_stack(membase + memsize - 16);
+ arm_early_mmu_cache_invalidate();
+
+ if (IS_ENABLED(CONFIG_PBL_MULTI_IMAGES))
+ barebox_multi_pbl_start(membase, memsize, boarddata);
+ else if (IS_ENABLED(CONFIG_PBL_SINGLE_IMAGE))
+ barebox_single_pbl_start(membase, memsize, boarddata);
+ else
+ barebox_non_pbl_start(membase, memsize, boarddata);
+}
diff --git a/arch/arm/cpu/entry.h b/arch/arm/cpu/entry.h
new file mode 100644
index 000..80fee57
--- /dev/null
+++ b/arch/arm/cpu/entry.h
@@ -0,0 +1,48 @@
+#ifndef __ENTRY_H__
+#define __ENTRY_H__
+
+#include
+
+#if !defined (__PBL__)
+void __noreturn barebox_non_pbl_start(unsigned long membase,
+ unsigned long memsize,
+ void *boarddata);
+#else
+static inline
+void __noreturn barebox_non_pbl_start(unsigned long membase,
+ unsigned long memsize,
+ void *boarddata)
+{
+ hang();
+};
+#endif
+
+#if defined (__PBL__) && defined(CONFIG_PBL_MULTI_IMAGES)
+void __noreturn barebox_multi_pbl_start(unsigned long membase,
+ unsigned long memsize,
+ void *boarddata);
+#else
+static inline
+void __noreturn barebox_multi_pbl_start(unsigned long membase,
+ unsigned long memsize,
+ void *boarddata)
+{
+ hang();
+}
+#endif
+
+#if defined (__PBL__) && defined(CONFIG_PBL_SINGLE_IMAGE)
+void __noreturn barebox_single_pbl_start(unsigned long membase,
+unsigned long memsize,
+void *boarddata);
+#else
+static inline
+void __noreturn barebox_single_pbl_start(unsigned long membase,
+unsigned long memsize,
+void *boarddata)
+{
+ hang();
+}
+#endif
+
+#endif
diff --git a/arch/arm/cpu/start-pbl.c b/arch/arm/cpu/start-pbl.c
index f2490fd..2075ffe 100644
--- a/arch/arm/cpu/start-pbl.c
+++ b/arch/arm/cpu/start-pbl.c
@@ -45,7 +45,7 @@ void __naked __section(.text_head_entry) pbl_start(void)
extern void *input_data;
extern void *input_data_end;
-static noinline __noreturn void __barebox_a
[PATCH v2] ARM: Add support for semihosting
Add semihosting API implementation and implement a filesystem driver to access debugging host filesystem using it. Tested on Freescale SabreSD board (i.MX6Q) using OpenOCD Signed-off-by: Andrey Smirnov --- New in version 2: - Added documntation for host side setup needed (including no MMU limitation for OpenOCD) - Fixed a small bug, where errno values were not negated - Fixed compilation errors of the previous patch Documentation/filesystems/smhfs.rst | 57 + arch/arm/Kconfig| 9 ++ arch/arm/include/asm/semihosting.h | 19 +++ arch/arm/lib/Makefile | 1 + arch/arm/lib/semihosting-trap.S | 28 + arch/arm/lib/semihosting.c | 227 fs/Kconfig | 9 ++ fs/Makefile | 1 + fs/smhfs.c | 178 9 files changed, 529 insertions(+) create mode 100644 Documentation/filesystems/smhfs.rst create mode 100644 arch/arm/include/asm/semihosting.h create mode 100644 arch/arm/lib/semihosting-trap.S create mode 100644 arch/arm/lib/semihosting.c create mode 100644 fs/smhfs.c diff --git a/Documentation/filesystems/smhfs.rst b/Documentation/filesystems/smhfs.rst new file mode 100644 index 000..28de146 --- /dev/null +++ b/Documentation/filesystems/smhfs.rst @@ -0,0 +1,57 @@ +.. index:: smhfs (filesystem) + +.. _filesystems_smhfs: + +File I/O over ARM semihosting support += + +Target Side Setup +- + +barebox can communicate with debug programms attached via SWD/JTAG by +means of ARM semihosting protocol. + +Not all of the I/O primitives neccessary to implement a full +filesystem are exposed in ARM semihosting API and because of that some +aspects of filesystem funcionality are missing. Implementation does +not have support for listing directories. This means a +:ref:`command_ls` to a SMHFS-mounted path will show an empty +directory. Nevertheless, the files are there. + +Example:: + + mount -t smhfs /dev/null /mnt/smhfs + + +Host Side Setup +--- + +FIXME: Currently OpenOCD does not work correctly if Barebox is built +with MMU enabled, so before using this featrue, please make sure that +MMU is disabled in your particular configuration + +To make semihosting work host machine connected to the target via +JTAG/SWD must have semihosting capable debug software running. One +such tool would be OpenOCD. For ARM9 and ARM11 CPUs most recent +release of OpenOCD should suffice, however for ARMv7A based devices +patched version from here http://openocd.zylin.com/#/c/2908/ has to be +used. + +The following steps are required to set up a operational semihosting +channel: + + 1. In a terminal start OpenOCD and specify your particular board + and debug adapter used. + + 2. In a separate terminal connect to OpenOCD via telnet + + telnet localhost + + 3. In resulting telnet session execute the following commands: + + halt + arm semihosting on + resume + +After that is done all of the semihosting related functions should be +ready to use. diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 304b6e6..1bccca3 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -326,6 +326,15 @@ config ARM_UNWIND the performance is not affected. Currently, this feature only works with EABI compilers. If unsure say Y. +config ARM_SEMIHOSTING + bool "enable ARM semihosting support" + help + This option enables ARM semihosting support in barebox. ARM + semihosting is a communication discipline that allows code + running on target ARM cpu perform system calls and access + the data on the host computer connected to the target via + debugging channel (JTAG, SWD). If unsure say N + endmenu source common/Kconfig diff --git a/arch/arm/include/asm/semihosting.h b/arch/arm/include/asm/semihosting.h new file mode 100644 index 000..b478dad --- /dev/null +++ b/arch/arm/include/asm/semihosting.h @@ -0,0 +1,19 @@ +#ifndef __ASM_ARM_SEMIHOSTING_H +#define __ASM_ARM_SEMIHOSTING_H + +int semihosting_open(const char *fname, int flags); +int semihosting_close(int fd); +int semihosting_writec(char c); +int semihosting_write0(const char *str); +ssize_t semihosting_write(int fd, const void *buf, size_t count); +ssize_t semihosting_read(int fd, void *buf, size_t count); +int semihosting_readc(void); +int semihosting_isatty(int fd); +int semihosting_seek(int fd, loff_t pos); +int semihosting_flen(int fd); +int semihosting_remove(const char *fname); +int semihosting_rename(const char *fname1, const char *fname2); +int semihosting_errno(void); +int semihosting_system(const char *command); + +#endif diff --git a/arch/arm/lib/Makefile b/arch/arm/lib/Makefile index a328795..e1c6f5b 100644 --- a/arch/arm/lib/Makefile +++ b/arch/arm/lib/Makefile @@ -20,6 +20,7 @@ p
Re: memtest updates
Hi, On Wed, Oct 28, 2015 at 07:17:55AM +0100, Sascha Hauer wrote: > On Tue, Oct 27, 2015 at 05:55:04PM +0100, Alexander Aring wrote: > > On Tue, Oct 27, 2015 at 09:29:53AM +0100, Sascha Hauer wrote: > > > This series has some updates for the memory test. The output and the > > > code are made more compact and some additional options are added. Also > > > the remap_range function is reworked. > > > > > > > I currently try to build next with memtest, I got the following issue: > > > > commands/memtest.c: In function 'do_test_one_area': > > commands/memtest.c:50:2: error: implicit declaration of function > > 'mem_test_moving_inversions_pattern' [-Werror=implicit-function-declaration] > > ret = mem_test_moving_inversions_pattern(r->r->start, r->r->end, > > 0xdeadbeef); > > > > after running grep I realized and there is no > > "mem_test_moving_inversions_pattern" function. :-( > > > > Then: > > > > after cutting some words from this function and running grep again, then > > I found a "mem_test_moving_inversions" function. :-) > > > > It seems it's a different function and you passed a "0xdeadbeef" there, > > otherwise the function fits. > > > > What means 0xdeadbeef here? > > For a customer I need a moving inversions test with a fixed pattern > instead of the own address written to the address. That's a leftover > here. > > I already fixed that one up. > ok, thanks. I also have some idea to creating a small barebox which do a full memtest on banks, if the architecture supports it. E.g. omap which boots from sd card. We have some MLO image. We could have some switch inside the barebox to build a MLO image which automatically starts the memtest after setup memory. I don't know how possible that is and if MLO have the necessary things inside like "memory bank registration", etc. to make a memory test possible. Also if everything fits then in the MLO with the memtest command. Over Kconfig there exists then some switch to enable this behaviour and also setup the arguments for memtest which should automatically started inside the MLO. A MLO for memory-testing, something like that. Just an idea for somebody which wants a "full" memory test. - Alex ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] lib:font:fbconsole: add custom font support for review
On Wed, Oct 28, 2015 at 04:20:26PM +0800, Kevin Du Huanpeng wrote: > 2015-10-28 14:59 GMT+08:00 Sascha Hauer : > > Hi, > > > > On Tue, Oct 27, 2015 at 04:40:56AM +0800, Kevin Du Huanpeng wrote: > >> On Mon, Oct 26, 2015 at 08:18:36AM +0100, Sascha Hauer wrote: > >> > > >> > This patch has several hunks without changes which makes it hard to look > >> > at. > >> > > >> > Somehow this looks like beginning unicode support. Wouldn't it be better > >> > to pick the relevant parts we need from unicode and support them? > >> > >> > >> How about store the font data externally, for reasons > >> 1. the font data maybe hurge, it take time to burn it to flash make > >> barebox fat. > >> 2. the part of font data namally don't change durning the devolopment. > >> 3. 'custom' means usless for other application. > >> 4. the fontdata maybe stored in a external spi flash and share with OS. > >> just pass the base address of index and fontdata or tell barebox how to > >> get the > >> font data. > > > > Do you know the pf2 font format? That may be the right candidate for a > > font format. See: http://grub.gibibit.com/New_font_format > > If we could read this font format we could throw arbitrary unicode fonts > > into barebox. > > > > Nice font! it designed for bootloader! > but it needs more learning, if being a bootloader user, for supportting > several > dozens of chars. the barebox user have to get font data from some .ttf or > other format font, or hardware font(hardware font chip). and convert it > to pf2 format. need more work. My system already has a full unicode font under /boot/grub/unicode.pf2, it probably came with a grub standard installation. > but maybe some people use barebox as a bare-metal application, not a > bootloader, > it will be useful. I guess. I don't think that people are doing that. > How about simply support the 'bitmap' font, simple and friendly to barebox > user. > next step, support pf2. I don't know what you are planning. Your current approach looks fine to me if you are fine with keeping the unicode characters you need out of tree. It doesn't scale very well if everybody starts to merge his favourite characters to the tree. If you want to be able to load external font files then these files should describe themselves. We shouldn't use a file format which needs additional informations like the widths of a font passed on the commandline when loading a file. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH v3 2/9] of_path: add of_find_path_by_node()
On 10/28/2015 07:20 AM, Sascha Hauer wrote:
> On Sun, Oct 25, 2015 at 10:03:29PM +0100, Marc Kleine-Budde wrote:
>> This patch adds the function of_find_path_by_node(), which is similar to
>> of_find_path(), but it translates a device tree node into a barebox device
>> path
>> directly.
>>
>> Signed-off-by: Marc Kleine-Budde
>> ---
>> drivers/of/of_path.c | 17 -
>> include/of.h | 1 +
>> 2 files changed, 17 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/of/of_path.c b/drivers/of/of_path.c
>> index ad64bee08af9..690390525919 100644
>> --- a/drivers/of/of_path.c
>> +++ b/drivers/of/of_path.c
>> @@ -126,7 +126,7 @@ static int __of_find_path(struct device_node *node,
>> const char *propname, char *
>>
>> i = 1;
>>
>> -while (1) {
>> +while (propname) {
>> ret = of_property_read_string_index(node, propname, i++, &str);
>> if (ret)
>> break;
>
> Is this hunk intentional? Is this a fix for something?
Yes, it's called with propname == NULL by int of_find_path_by_node():
> +int of_find_path_by_node(struct device_node *node, char **outpath, unsigned
> flags)
> +{
> + return __of_find_path(node, NULL, outpath, flags);
> +}
> +
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions| Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917- |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
signature.asc
Description: OpenPGP digital signature
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] lib:font:fbconsole: add custom font support for review
2015-10-28 14:59 GMT+08:00 Sascha Hauer : > Hi, > > On Tue, Oct 27, 2015 at 04:40:56AM +0800, Kevin Du Huanpeng wrote: >> On Mon, Oct 26, 2015 at 08:18:36AM +0100, Sascha Hauer wrote: >> > >> > This patch has several hunks without changes which makes it hard to look >> > at. >> > >> > Somehow this looks like beginning unicode support. Wouldn't it be better >> > to pick the relevant parts we need from unicode and support them? >> >> >> How about store the font data externally, for reasons >> 1. the font data maybe hurge, it take time to burn it to flash make >> barebox fat. >> 2. the part of font data namally don't change durning the devolopment. >> 3. 'custom' means usless for other application. >> 4. the fontdata maybe stored in a external spi flash and share with OS. >> just pass the base address of index and fontdata or tell barebox how to get >> the >> font data. > > Do you know the pf2 font format? That may be the right candidate for a > font format. See: http://grub.gibibit.com/New_font_format > If we could read this font format we could throw arbitrary unicode fonts > into barebox. > Nice font! it designed for bootloader! but it needs more learning, if being a bootloader user, for supportting several dozens of chars. the barebox user have to get font data from some .ttf or other format font, or hardware font(hardware font chip). and convert it to pf2 format. need more work. but maybe some people use barebox as a bare-metal application, not a bootloader, it will be useful. I guess. How about simply support the 'bitmap' font, simple and friendly to barebox user. next step, support pf2. Du Huanpeng +86.13719074147 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] lib:font:fbconsole: add custom font support for review
Hi, On Tue, Oct 27, 2015 at 04:40:56AM +0800, Kevin Du Huanpeng wrote: > On Mon, Oct 26, 2015 at 08:18:36AM +0100, Sascha Hauer wrote: > > > > This patch has several hunks without changes which makes it hard to look > > at. > > > > Somehow this looks like beginning unicode support. Wouldn't it be better > > to pick the relevant parts we need from unicode and support them? > > > How about store the font data externally, for reasons > 1. the font data maybe hurge, it take time to burn it to flash make barebox > fat. > 2. the part of font data namally don't change durning the devolopment. > 3. 'custom' means usless for other application. > 4. the fontdata maybe stored in a external spi flash and share with OS. > just pass the base address of index and fontdata or tell barebox how to get > the > font data. Do you know the pf2 font format? That may be the right candidate for a font format. See: http://grub.gibibit.com/New_font_format If we could read this font format we could throw arbitrary unicode fonts into barebox. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
