Re: [PATCHv4 1/3] common: Allow for I/O mapped I/O
On Mon, Apr 07, 2014 at 12:01:20PM +0200, mic...@reverze.net wrote: From: Michel Stam m.s...@fugro.nl Rework the current framework so that I/O mapped I/O resources are also possible. Signed-off-by: Michel Stam mic...@reverze.net Applied, thanks 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] Documentation: Update binding doc for i.MX IIM
On Mon, Apr 07, 2014 at 05:58:14PM +0400, Alexander Shiyan wrote:
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
Applied, thanks
Sascha
---
Documentation/devicetree/bindings/misc/fsl,imx-iim.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/misc/fsl,imx-iim.txt
b/Documentation/devicetree/bindings/misc/fsl,imx-iim.txt
index ed3efcc..9759210 100644
--- a/Documentation/devicetree/bindings/misc/fsl,imx-iim.txt
+++ b/Documentation/devicetree/bindings/misc/fsl,imx-iim.txt
@@ -2,7 +2,7 @@ Freescale i.MX IIM (Ic Identification Module)
Required properties:
-- compatible: fsl,imx-iim
+- compatible: fsl,imx27-iim
- reg: physical register base and size
Optional properties:
@@ -14,7 +14,7 @@ Optional properties:
Example:
iim: iim@83f98000 {
- compatible = fsl,imx51-iim, fsl,imx-iim;
+ compatible = fsl,imx51-iim, fsl,imx27-iim;
reg = 0x83f98000 0x4000;
barebox,provide-mac-address = fec 1 9;
};
--
1.8.3.2
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
--
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: RFC: barebox-x86 as a coreboot payload
On Apr 6, 2014, at 3:02 AM, Alexander Shiyan shc_w...@mail.ru wrote: Sat, 5 Apr 2014 23:00:29 +0400 от Antony Pavlov antonynpav...@gmail.com: Hi! I have seen your recent activity on barebox-x86 improvements. IMHO using barebox-x86 as a coreboot payload can be beneficial for barebox promotion. Please see http://www.coreboot.org/Payloads -- Amused: http://www.coreboot.org/File:Coreboot_libpayload_tint.png This is a really missing feature in barebox :) I already did the job with barebox-apps just need to integrate it mainline Best Regards, J. --- ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 0/3] MIPS: loongson-ls1b: switch to device tree probe
On Tue, 8 Apr 2014 08:06:19 +0200 Sascha Hauer s.ha...@pengutronix.de wrote: On Mon, Apr 07, 2014 at 11:38:46AM +0400, Antony Pavlov wrote: New boards should probe from devicetree and not use the platform registration code. This patchseries adds device tree stuff for Longson LS1B SoC and Loongson Tech LS1B Demo Board. Antony Pavlov (3): MIPS: add Longson LS1B SoC dtsi file MIPS: add Loongson Tech LS1B Demo Board dts file MIPS: loongson-ls1b: switch to device tree Applied, thanks. BTW what's the status of mips devicetree support in Linux Mainline? I sometimes have a look at arch/mips/boot/dts there and find it empty. Does the kernel start with the devicetrees you add to barebox? linux-mips world is different from linux-arm world in many ways :) $ find linux.git/arch/mips/ -iname '*dts*' linux.git/arch/mips/mti-sead3/sead3.dts linux.git/arch/mips/boot/dts linux.git/arch/mips/ralink/dts linux.git/arch/mips/ralink/dts/rt2880_eval.dts linux.git/arch/mips/ralink/dts/mt7620a.dtsi linux.git/arch/mips/ralink/dts/rt2880.dtsi linux.git/arch/mips/ralink/dts/rt3883.dtsi linux.git/arch/mips/ralink/dts/rt3883_eval.dts linux.git/arch/mips/ralink/dts/rt3052_eval.dts linux.git/arch/mips/ralink/dts/rt3050.dtsi linux.git/arch/mips/ralink/dts/mt7620a_eval.dts linux.git/arch/mips/lantiq/dts linux.git/arch/mips/lantiq/dts/easy50712.dts linux.git/arch/mips/lantiq/dts/danube.dtsi linux.git/arch/mips/netlogic/dts linux.git/arch/mips/netlogic/dts/xlp_gvp.dts linux.git/arch/mips/netlogic/dts/xlp_evp.dts linux.git/arch/mips/netlogic/dts/xlp_fvp.dts linux.git/arch/mips/netlogic/dts/xlp_svp.dts linux.git/arch/mips/cavium-octeon/octeon_3xxx.dts linux.git/arch/mips/cavium-octeon/octeon_68xx.dts So there is no support in barebox for a mainline linux dts-capable machine. I have revived my qemu-malta linux-boot-capable barebox branch (it also introduces PCI support, but I have to clean it): https://github.com/frantony/barebox/tree/next.mips-malta-elf-linux.20140408 So there is a chance to organize qemu-barebox-linux dts-capable system. Also AR9331-based system has a chances to be converted to dt. There is some notes on AR9331 support: * some of AR933x linux-mainline devices are dt-capable (but mips ath79 mainline kernel code is not dt-capable); may be there is some ar933x kernel branch with dt support? * I have to port AR933x Ethernet driver to barebox so barebox will be capable to load linux kernel quickly and comfortably; * kexec code for booting linux kernel already realized for qemu-malta; there are possible some cache support issues (qemu-mips does no support caches), but draft cache support code is already stolen from u-boot. Loongson developers have no plan to port OpenFirmware in the near future, see this http://www.linux-mips.org/archives/linux-mips/2014-03/msg00164.html -- Best regards, Antony Pavlov ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Confusion about memory layout
Hi, I'm trying to get barebox running via usb-download. Unfortunately, the verify step failed (see log below). This made me think about my memory layout, but I'm a bit helpless here. If I look at arch/arm/mach-imx/Kconfig, I see that several i.MX boards define different CONFIG_ARCH_TEXT_BASE. Why? default 0x4fc0 if MACH_MX6Q_ARM2 default 0x4fc0 if MACH_SABRELITE ... some other also, but look at this: default 0x1780 if MACH_SABRESD And why specify most x4fc0_ ? Doesn't the physical memory map of DDR3 start at x1000_ or 0x8000_, depending on mapping ? Similarly: the loadaddr statement in various *.imxcfg files are also different: loadaddr 0x00907000 loadaddr 0x1000 loadaddr 0x2000 I'd have expected that all will be loaded at 0x1000_, the start of DDR RAM? That made me think about my memory map is the 0400: vs. 1400: prefix in the following compare: barebox/scripts/imx/imx-usb-loader -c -v barebox/barebox.imx found i.MX6q USB device [15a2:0054] main dcd length 308 sub dcd length 304 loading binary file(barebox/barebox.imx) to 1000, skip=0x0, fsize=249800 type=170... binary file successfully loaded verifying file... mismatch 0400: 402000d1 10001000 1400 1400: 40d1 1000 0004 10001000 00ff 0420: 1000 0003d000 400803d2 040403cc 68400c02 6c400c02 1420: 1020 00030400 4008 040003cc 6840d000 ff00 6c4003d2 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH 21/29] video: rework mode_name parameter setting
On Mon, Apr 07, 2014 at 06:45:55PM +0400, Alexander Shiyan wrote:
Fri, 14 Mar 2014 15:32:41 +0100 от Sascha Hauer s.ha...@pengutronix.de:
We have dev_add_param_enum() now, so use it for the mode_name
setting. Also drop the special case for single mode framebuffers,
just add the mode_name parameter for this case aswell.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
...
+static int fb_setup_mode(struct fb_info *info)
+{
+ struct device_d *dev = info-dev;
+ int ret;
...
- ret = info-fbops-fb_activate_var(info);
+ if (info-fbops-fb_activate_var) {
+ ret = info-fbops-fb_activate_var(info);
+ if (ret)
+ return ret;
+ }
So, ret is unitialized without fb_activate_var().
It is wrong since this variable is used in code below.
Damn. I remember times when compilers used to warn on unitialized
variables :(
The following should fix this.
Thanks for reporting.
Sascha
8
From 7b8779541f86bbc6f6b461f1ea1c2f4310bb8335 Mon Sep 17 00:00:00 2001
From: Sascha Hauer s.ha...@pengutronix.de
Date: Tue, 8 Apr 2014 08:37:09 +0200
Subject: [PATCH] fb: Fix use of unitialized variable
'ret' is only initialized when info-fbops-fb_activate_var exists, so
only use it in this case.
Reported-by: Alexander Shiyan shc_w...@mail.ru
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/video/fb.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/drivers/video/fb.c b/drivers/video/fb.c
index 2c8b8eb..ecf6142 100644
--- a/drivers/video/fb.c
+++ b/drivers/video/fb.c
@@ -85,8 +85,10 @@ static int fb_setup_mode(struct fb_info *info)
if (info-fbops-fb_activate_var) {
ret = info-fbops-fb_activate_var(info);
- if (ret)
+ if (ret) {
+ info-cdev.size = 0;
return ret;
+ }
}
if (!info-line_length)
@@ -94,14 +96,11 @@ static int fb_setup_mode(struct fb_info *info)
if (!info-screen_size)
info-screen_size = info-line_length * info-yres;
- if (!ret) {
- dev-resource[0].start = (resource_size_t)info-screen_base;
- info-cdev.size = info-line_length * info-yres;
- dev-resource[0].end = dev-resource[0].start + info-cdev.size
- 1;
- } else
- info-cdev.size = 0;
+ dev-resource[0].start = (resource_size_t)info-screen_base;
+ info-cdev.size = info-line_length * info-yres;
+ dev-resource[0].end = dev-resource[0].start + info-cdev.size - 1;
- return ret;
+ return 0;
}
static int fb_set_modename(struct param_d *param, void *priv)
--
1.9.1
--
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] ARM: dts: edmqmx6: add SPI SCLK pinmux
On Mon, Apr 07, 2014 at 12:32:09PM +0200, Lucas Stach wrote: Otherwise reading or writing to the SPI flash doesn't work. Signed-off-by: Lucas Stach l.st...@pengutronix.de Applied, thanks Sascha --- Sascha, this is a fairly simple fix, but a severe restriction in functionality, as barebox isn't able to write itself to the flash. Please apply to master. --- arch/arm/dts/imx6q-dmo-edmqmx6.dts | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/dts/imx6q-dmo-edmqmx6.dts b/arch/arm/dts/imx6q-dmo-edmqmx6.dts index 4cd1c55ff82e..f4f0bd6c14ba 100644 --- a/arch/arm/dts/imx6q-dmo-edmqmx6.dts +++ b/arch/arm/dts/imx6q-dmo-edmqmx6.dts @@ -329,6 +329,7 @@ fsl,pins = MX6QDL_PAD_SD1_DAT0__ECSPI5_MISO 0x8000 MX6QDL_PAD_SD1_CMD__ECSPI5_MOSI 0x8000 + MX6QDL_PAD_SD1_CLK__ECSPI5_SCLK 0x8000 MX6QDL_PAD_SD2_DAT3__GPIO1_IO12 0x8000 /* cs0: m25p80 */ ; }; -- 1.9.1 ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox -- 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 0/3] MIPS: loongson-ls1b: switch to device tree probe
On Mon, Apr 07, 2014 at 11:38:46AM +0400, Antony Pavlov wrote: New boards should probe from devicetree and not use the platform registration code. This patchseries adds device tree stuff for Longson LS1B SoC and Loongson Tech LS1B Demo Board. Antony Pavlov (3): MIPS: add Longson LS1B SoC dtsi file MIPS: add Loongson Tech LS1B Demo Board dts file MIPS: loongson-ls1b: switch to device tree Applied, thanks. BTW what's the status of mips devicetree support in Linux Mainline? I sometimes have a look at arch/mips/boot/dts there and find it empty. Does the kernel start with the devicetrees you add to 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
Re: Secure Boot support on Barebox
Thanks Sascha, Do you know if there are intentions from Freescale side to support Barebox as they do with u-boot 2009? BR, Igor Bezukh On Sat, Apr 5, 2014 at 7:23 PM, Sascha Hauer s.ha...@pengutronix.de wrote: On Fri, Apr 04, 2014 at 02:07:42PM +0300, Igor Bezukh wrote: Hi, I would like to know whether Barebox supports one of the following: 1. Freecale i.MX6 High Assurance Boot. 2. Verified boot as in U-Boot. No, barebox doesn't support this yet. 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: RFC: barebox-x86 as a coreboot payload
On Apr 6, 2014, at 10:32 PM, Michel Stam mic...@reverze.net wrote: Hello Antony, Interesting idea- I wonder if its difficult given that U-boot is already supported? Personally I have no experience with coreboot, the systems I test on are industrial x86 SBCs with their own BIOS. I suppose it is oossible, maybe we can borrow code from u-boot. Should be fairly easy Another thing along the sane lines that crossed my mind is EFI support for barebox, I wonder if theres interest in that? EFI yes as ARM will use UEFI too Next on my list is keyboard/VGA, maybe VESA support if I have the time. I would like to see a console, possibly a framebuffer driver. No idea how difficult that will be. good idea Cheers, Michel Stam On 5 apr. 2014, at 21:00, Antony Pavlov antonynpav...@gmail.com wrote: Hi! I have seen your recent activity on barebox-x86 improvements. IMHO using barebox-x86 as a coreboot payload can be beneficial for barebox promotion. Please see http://www.coreboot.org/Payloads -- Best regards, Antony Pavlov ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox signature.asc Description: Message signed with OpenPGP using GPGMail ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
Re: [PATCH] spi: i.MX: Fix direction for CS GPIOs
On Mon, Apr 07, 2014 at 04:22:15PM +0400, Alexander Shiyan wrote:
Direction for CS GPIOs (for some targets) is undefined.
This patch fixes this issue.
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
Applied, thanks
Sascha
---
drivers/spi/imx_spi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/spi/imx_spi.c b/drivers/spi/imx_spi.c
index 6675729..45461bd 100644
--- a/drivers/spi/imx_spi.c
+++ b/drivers/spi/imx_spi.c
@@ -167,7 +167,7 @@ static void cspi_0_0_chipselect(struct spi_device *spi,
int is_active)
if (!is_active) {
if (gpio = 0)
- gpio_set_value(gpio, !cs);
+ gpio_direction_output(gpio, !cs);
return;
}
@@ -253,7 +253,7 @@ static void cspi_0_7_chipselect(struct spi_device *spi,
int is_active)
if (!is_active) {
if (gpio = 0)
- gpio_set_value(gpio, !cs);
+ gpio_direction_output(gpio, !cs);
return;
}
--
1.8.3.2
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
--
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] GPIO: i.MX: Implement get_direction()
On Mon, Apr 07, 2014 at 06:17:39PM +0400, Alexander Shiyan wrote:
Signed-off-by: Alexander Shiyan shc_w...@mail.ru
Applied, thanks
Sascha
---
drivers/gpio/gpio-imx.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpio/gpio-imx.c b/drivers/gpio/gpio-imx.c
index a71492a..d32638c 100644
--- a/drivers/gpio/gpio-imx.c
+++ b/drivers/gpio/gpio-imx.c
@@ -113,11 +113,21 @@ static int imx_gpio_get_value(struct gpio_chip *chip,
unsigned gpio)
return val (1 gpio) ? 1 : 0;
}
+static int imx_get_direction(struct gpio_chip *chip, unsigned offset)
+{
+ struct imx_gpio_chip *imxgpio = container_of(chip, struct
imx_gpio_chip, chip);
+ void __iomem *base = imxgpio-base;
+ u32 val = readl(base + imxgpio-regs-gdir);
+
+ return (val (1 offset)) ? GPIOF_DIR_OUT : GPIOF_DIR_IN;
+}
+
static struct gpio_ops imx_gpio_ops = {
.direction_input = imx_gpio_direction_input,
.direction_output = imx_gpio_direction_output,
.get = imx_gpio_get_value,
.set = imx_gpio_set_value,
+ .get_direction = imx_get_direction,
};
static int imx_gpio_probe(struct device_d *dev)
--
1.8.3.2
___
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
--
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: Secure Boot support on Barebox
On Tue, Apr 08, 2014 at 10:26:34AM +0300, Igor Bezukh wrote: Thanks Sascha, Do you know if there are intentions from Freescale side to support Barebox as they do with u-boot 2009? No, I don't think this will happen. 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: Confusion about memory layout
Hi Holger, On Tue, Apr 08, 2014 at 08:51:45AM +0200, Holger Schurig wrote: Hi, I'm trying to get barebox running via usb-download. Unfortunately, the verify step failed (see log below). This made me think about my memory layout, but I'm a bit helpless here. If I look at arch/arm/mach-imx/Kconfig, I see that several i.MX boards define different CONFIG_ARCH_TEXT_BASE. Why? default 0x4fc0 if MACH_MX6Q_ARM2 default 0x4fc0 if MACH_SABRELITE ... some other also, but look at this: default 0x1780 if MACH_SABRESD And why specify most x4fc0_ ? Doesn't the physical memory map of DDR3 start at x1000_ or 0x8000_, depending on mapping ? On i.MX6 SDRAM starts at 0x1000. The above memory locations are near the end of SDRAM of the corresponding board. (Note CONFIG_ARCH_TEXT_BASE is only used if CONFIG_RELOCATABLE is not set. With CONFIG_RELOCATABLE barebox will relocate itself near the end of SDRAM automatically.) Similarly: the loadaddr statement in various *.imxcfg files are also different: loadaddr 0x00907000 loadaddr 0x1000 loadaddr 0x2000 The loadaddr is where the ROM loads the binary. barebox will copy itself to a suitable address during runtime, so the loadaddr doesn't really matter. the suitable address is either CONFIG_ARCH_TEXT_BASE or near the end of SDRAM, depending on CONFIG_RELOCATABLE. Most boards load somewhere to SDRAM. The DMO board loads to SRAM because it does SDRAM setup in code instead of the DCD header. I'd have expected that all will be loaded at 0x1000_, the start of DDR RAM? 0400: 402000d1 10001000 1400 1400: 40d1 1000 0004 10001000 00ff 0420: 1000 0003d000 400803d2 040403cc 68400c02 6c400c02 1420: 1020 00030400 4008 040003cc 6840d000 ff00 6c4003d2 Does your SDRAM setup work? This looks like bitflips. Try using SRAM (0x00907000) as loadaddr, do you get verify errors aswell? You might have to disable options until the image fits into SRAM (256k - 0x7000). 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
[PATCH] 2048: port to barebox
Signed-off-by: Marc Kleine-Budde m...@pengutronix.de
---
common/2048/2048.c| 357 ++
common/2048/LICENSE | 21 +++
common/2048/Makefile | 1 +
common/2048/README.md | 32 +
common/Makefile | 1 +
5 files changed, 412 insertions(+)
create mode 100644 common/2048/2048.c
create mode 100644 common/2048/LICENSE
create mode 100644 common/2048/Makefile
create mode 100644 common/2048/README.md
diff --git a/common/2048/2048.c b/common/2048/2048.c
new file mode 100644
index 000..fe9970e
--- /dev/null
+++ b/common/2048/2048.c
@@ -0,0 +1,357 @@
+/*
+
+ Name: 2048.c
+ Author : Maurits van der Schee
+ Description : Console version of the game 2048 for GNU/Linux
+
+ */
+
+#include common.h
+#include readkey.h
+#include command.h
+#include stdlib.h
+
+#define SIZE 4
+static uint32_t score;
+
+static void getColor(uint16_t value, char *color, size_t length) {
+#if 0
+ uint8_t blackwhite[] =
{232,255,234,255,236,255,238,255,240,255,242,255,244,255,246,0,248,0,249,0,250,0,251,0,252,0,253,0,254,0,255,0};
+ uint8_t bluered[] =
{235,255,63,255,57,255,93,255,129,255,165,255,201,255,200,255,199,255,198,255,197,255,196,255,196,255,196,255,196,255,196,255};
+#endif
+ uint8_t original[] =
{8,255,1,255,2,255,3,255,4,255,5,255,6,255,7,255,9,0,10,0,11,0,12,0,13,0,14,0,255,0,255,0};
+ uint8_t *scheme = original;
+ uint8_t *background = scheme+0;
+ uint8_t *foreground = scheme+1;
+ if (value 0) while (value = 1) {
+ if (background+2scheme+sizeof(original)) {
+ background+=2;
+ foreground+=2;
+ }
+ }
+ snprintf(color,length,\033[38;5;%d;48;5;%dm,*foreground,*background);
+}
+
+static void drawBoard(uint16_t board[SIZE][SIZE]) {
+ int8_t x,y;
+ char color[40], reset[] = \033[m;
+ printf(\033[H);
+
+ printf(2048.c %17d pts\n\n,score);
+
+ for (y=0;ySIZE;y++) {
+ for (x=0;xSIZE;x++) {
+ getColor(board[x][y],color,40);
+ printf(%s,color);
+ printf( );
+ printf(%s,reset);
+ }
+ printf(\n);
+ for (x=0;xSIZE;x++) {
+ getColor(board[x][y],color,40);
+ printf(%s,color);
+ if (board[x][y]!=0) {
+ char s[8];
+ int8_t t;
+ snprintf(s,8,%u,board[x][y]);
+ t = 7-strlen(s);
+ printf(%*s%s%*s,t-t/2,,s,t/2,);
+ } else {
+ printf( · );
+ }
+ printf(%s,reset);
+ }
+ printf(\n);
+ for (x=0;xSIZE;x++) {
+ getColor(board[x][y],color,40);
+ printf(%s,color);
+ printf( );
+ printf(%s,reset);
+ }
+ printf(\n);
+ }
+ printf(\n);
+ printf(←,↑,→,↓ or q\n);
+ printf(\033[A);
+}
+
+static int8_t findTarget(uint16_t array[SIZE],int8_t x,int8_t stop) {
+ int8_t t;
+ // if the position is already on the first, don't evaluate
+ if (x==0) {
+ return x;
+ }
+ for(t=x-1;t=0;t--) {
+ if (array[t]!=0) {
+ if (array[t]!=array[x]) {
+ // merge is not possible, take next position
+ return t+1;
+ }
+ return t;
+ } else {
+ // we should not slide further, return this one
+ if (t==stop) {
+ return t;
+ }
+ }
+ }
+ // we did not find a
+ return x;
+}
+
+static bool slideArray(uint16_t array[SIZE]) {
+ bool success = false;
+ int8_t x,t,stop=0;
+
+ for (x=0;xSIZE;x++) {
+ if (array[x]!=0) {
+ t = findTarget(array,x,stop);
+ // if target is not original position, then move or
merge
+ if (t!=x) {
+ // if target is not zero, set stop to avoid
double merge
+ if (array[t]!=0) {
+ score+=array[t]+array[x];
+ stop = t+1;
+ }
+ array[t]+=array[x];
+ array[x]=0;
+
Re: RFC: barebox-x86 as a coreboot payload
On 04/05/2014 09:02 PM, Alexander Shiyan wrote: Sat, 5 Apr 2014 23:00:29 +0400 от Antony Pavlov antonynpav...@gmail.com: Hi! I have seen your recent activity on barebox-x86 improvements. IMHO using barebox-x86 as a coreboot payload can be beneficial for barebox promotion. Please see http://www.coreboot.org/Payloads -- Amused: http://www.coreboot.org/File:Coreboot_libpayload_tint.png This is a really missing feature in barebox :) What about 2048? 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] 2048: port to barebox
Hi Marc, On Tue, Apr 08, 2014 at 11:50:42PM +0200, Marc Kleine-Budde wrote: ... diff --git a/common/Makefile b/common/Makefile index 204241c..b40a078 100644 --- a/common/Makefile +++ b/common/Makefile @@ -44,6 +44,7 @@ obj-$(CONFIG_SHELL_HUSH)+= hush.o obj-$(CONFIG_SHELL_SIMPLE) += parser.o obj-$(CONFIG_UIMAGE) += image.o uimage.o obj-$(CONFIG_MENUTREE) += menutree.o +obj-y+= 2048/ srsly? But otherwise it makes no sense, because everybody would disable games in his/her barebox config. - Alex ___ barebox mailing list barebox@lists.infradead.org http://lists.infradead.org/mailman/listinfo/barebox
