[U-Boot] [PATCH] samsung: fix DMC1_MEM_CFG for s3c64xx
The MSB of DMC1_MEM_CFG can be set to '1' for separate CKE control for S3C6400. In the configuration of SMDK6400, however, two 16-bit mDDR (SAMSUNG K4X51163) chips are used in parallel to form 32-bit memory bus and there is no need to contorl CKE for each chip separately. AFAIK, CKE1 is not at all connected. Only CKE0 is used. Futhermore, it should be '0' always for S3C6410. When tested with a board which has a S3C6410 and the same memory configuration, a side effect is obsearved that u-boot command "reset" doesn't work leading to system hang. Leaving the bit clear is safe in most cases. Signed-off-by: Seunghyeon Rhee --- include/s3c6400.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/include/s3c6400.h b/include/s3c6400.h index e527c08..7229ea6 100644 --- a/include/s3c6400.h +++ b/include/s3c6400.h @@ -817,7 +817,7 @@ /*--- * Physical Memory Map */ -#define DMC1_MEM_CFG 0x80010012 /* Chip1, Burst4, Row/Column bit */ +#define DMC1_MEM_CFG 0x00010012 /* Chip1, Burst4, Row/Column bit */ #define DMC1_MEM_CFG2 0xB45 #define DMC1_CHIP0_CFG 0x150F8 /* 0x4000_ ~ 0x43ff_ (64MB) */ #define DMC_DDR_32_CFG 0x0 /* 32bit, DDR */ -- 1.6.2.5 -- Seunghyeon Rhee, Ph.D. / Director LPM Technology Inc. T +82-70-8255-6007 F +82-2-6442-6462 M +82-10-2790-0657 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] fix flash_sect_erase() to display correct message
Dear Wolfgang Denk,
Wolfgang Denk wrote:
> Dear =?UTF-8?B?7J207Iq57ZiE?=,
>
> In message you
> wrote:
>
>> flash_sect_erase() displays message "Erased #N sectors" even when
>> there are some protected sectors found and command "erase" fail.
>>
>> Signed-off-by: Seunghyeon Rhee
>> ---
>> common/cmd_flash.c |5 -
>> 1 files changed, 4 insertions(+), 1 deletions(-)
>>
>> diff --git a/common/cmd_flash.c b/common/cmd_flash.c
>> index 3773412..b3d982f 100644
>> --- a/common/cmd_flash.c
>> +++ b/common/cmd_flash.c
>> @@ -451,7 +451,10 @@ int flash_sect_erase (ulong addr_first, ulong addr_last)
>> rcode = flash_erase (info, s_first[bank],
>> s_last[bank]);
>> }
>> }
>> -printf ("Erased %d sectors\n", erased);
>> +if (rcode == ERR_PROTECTED)
>> +printf ("Not erased - protected sector(s) found\n");
>> +else
>> +printf ("Erased %d sectors\n", erased);
>> } else if (rcode == 0) {
>> puts ("Error: start and/or end address"
>> " not on sector boundary\n");
>>
>
> I think this patch is not an improvement. Now it prints "Not erased"
> even when sectors _have_ successfully been earased, which is at least
> as wrong als the old behaviour.
>
>
> Just to see what we are talking about:
>
> Preparation:
>
>
> => fli 2
>
> Bank # 2: CFI conformant FLASH (32 x 16) Size: 4 MB in 35 Sectors
> AMD Standard command set, Manufacturer ID: 0x04, Device ID: 0x2249
> Erase timeout: 16384 ms, write timeout: 1 ms
>
> Sector Start Addresses:
> 4040404080004040C00040414042
>
> 404440464048404A404C
>
> 404E4050405240544056
>
> 4058405A405C405E4060
>
> 4062406440664068406A
>
> 406C406E407040724074
>
> 40764078407A407C407E
>
>
> => protect on 2:2-4
> Protect Flash Sectors 2-4 in Bank # 2
> => fli 2
>
> Bank # 2: CFI conformant FLASH (32 x 16) Size: 4 MB in 35 Sectors
> AMD Standard command set, Manufacturer ID: 0x04, Device ID: 0x2249
> Erase timeout: 16384 ms, write timeout: 1 ms
>
> Sector Start Addresses:
> 4040404080004040C000 RO 4041 RO 4042
> RO
> 404440464048404A404C
>
> 404E4050405240544056
>
> 4058405A405C405E4060
>
> 4062406440664068406A
>
> 406C406E407040724074
>
> 40764078407A407C407E
>
>
> Case 1:
> ===
>
> => erase 4040 4047
> - Warning: 3 protected sectors will not be erased!
> done
> Erased 7 sectors
>
> Case 2:
> ===
>
> => erase 4040 +7
> - Warning: 3 protected sectors will not be erased!
> done
> Erased 7 sectors
>
> Case 3:
> ===
>
> => erase 2:0-6
> Erase Flash Sectors 0-6 in Bank # 2 - Warning: 3 protected sectors will not
> be erased!
> done
>
> Case 4:
> ===
>
> => erase bank 2
> Erase Flash Bank # 2 - Warning: 3 protected sectors will not be erased!
> done
>
>
> As you can see, we _always_ print a warning message.
>
Actually, we usually print the warning message but not _always_.
That depends on the flash implementation (*flash.c) of each board.
At least 20 implementations currently do nothing and return with
ERR_PROTECTED if they found any protected sectors. I was porting U-Boot
to my board and found the artifact. Unfortunately (or fortunately in
some respect), I chose smdk2410's flash.c as a template which belongs
to the _irregular_ case.
> You can argument that it is incorrect to print "Erased 7 sectors" in
> cases 1 and 2, as actually only 7 - 3 = 4 have been erased, but
> printing "Not erased" would definitely be worse.
>
> If you want, and if you can find a clean way to implement it, it
> might make sense to change the output into something like "Erased 4
> (instead of 7 requested) sectors" or the like.
>
I think we need to first make all of them consistent. My suggestion is:
- display a warning message in flash_erase() that there are some
protected sectors and erase unprotected sectors like now.
- remove the number indicating how manny sectors are erased from the
message in flash_sect_erase() or any caller of flash_erase(). A simple
message like "done" would be enough.
>
Re: [U-Boot] [PATCH] samsung: move DRAM parameters
Dear Minkyu Kang, What causes the current ambiguity is, in my opinion, the "parameters" themselves and "the way of setting them." As you know, DRAM controller is integrated in the SoC while the parameters required to set them are dependent on the external components, DRAM chips. In this respect, cpu_init.S - I don't like the name because all it does is set up the memory controller. mem_setup.S is more appropriate - don't need to be moved to board description stuffs. The memory controller (the hardware logic in the SoC) is not changeable according to the board design. Neither does the way of setting it, which is in charge of cpu_init.S. What is changed from board to board is not cpu_init.S but the parameters. If we move it to board directory, we have to add redundant code - actually several copies of the same file - every time we add support for a new board with the same SoC. Thererfore, I think cpu_init.S(or mem_setup.S) would better be placed with SoC stuffs like it is now while DRAM parameters be moved to board description stuffs. We can make the function for setting up the DRAM controller completely independent of board design by introducing more macro definitions if necessary. All we have to do for adding support for new boards then will be reduced to creating the new board's description. No redundant codes, no repeated modification of the SoC description will be required. Best regards, Seunghyeon Seunghyeon Rhee, Ph.D. / Director LPM Technology Inc. T +82-70-8255-6007 F +82-2-6442-6462 M +82-10-2790-0657 Minkyu Kang 쓴 글: > Dear Seunghyeon Rhee, > > 2009/11/4 "Seunghyeon Rhee (이승현)" : > >> Move the definitions of DRAM parameters from SoC description >> (s3c6400.h) to board description (smdk6400.h). DRAM parameters >> are rather board-specific than SoC specific. According to the >> current source, one may have to change the definitions in >> s3c6400.h in addition to creating the new board description >> whenever he wants to add support for a new board based on >> s3c6400. I don't think this meets the U-Boot policy of >> separating SoC description and board description. >> There will be no observable changes in operation. It's just >> to make it easier to add support for new boards. >> >> Signed-off-by: Seunghyeon Rhee >> --- >> include/configs/smdk6400.h | 21 + >> include/s3c6400.h | 21 - >> 2 files changed, 21 insertions(+), 21 deletions(-) >> >> diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h >> index f6e1221..a2b46fd 100644 >> --- a/include/configs/smdk6400.h >> +++ b/include/configs/smdk6400.h >> @@ -309,4 +309,25 @@ >> # error "usb_ohci.c is currently broken with MMU enabled." >> #endif >> >> +/*--- >> + * Physical Memory Map >> + */ >> +#define DMC1_MEM_CFG 0x80010012 /* Chip1, Burst4, Row/Column bit */ >> +#define DMC1_MEM_CFG2 0xB45 >> +#define DMC1_CHIP0_CFG 0x150F8 /* 0x4000_ ~ 0x43ff_ (64MB) >> */ >> +#define DMC_DDR_32_CFG 0x0 /* 32bit, DDR */ >> + >> +/* Memory Parameters */ >> +/* DDR Parameters */ >> +#define DDR_tREFRESH 7800/* ns */ >> +#define DDR_tRAS 45 /* ns (min: 45ns)*/ >> +#define DDR_tRC68 /* ns (min: 67.5ns)*/ >> +#define DDR_tRCD 23 /* ns (min: 22.5ns)*/ >> +#define DDR_tRFC 80 /* ns (min: 80ns)*/ >> +#define DDR_tRP23 /* ns (min: 22.5ns)*/ >> +#define DDR_tRRD 15 /* ns (min: 15ns)*/ >> +#define DDR_tWR15 /* ns (min: 15ns)*/ >> +#define DDR_tXSR 120 /* ns (min: 120ns)*/ >> +#define DDR_CASL 3 /* CAS Latency 3 */ >> + >> #endif /* __CONFIG_H */ >> diff --git a/include/s3c6400.h b/include/s3c6400.h >> index e527c08..34d0d15 100644 >> --- a/include/s3c6400.h >> +++ b/include/s3c6400.h >> @@ -814,27 +814,6 @@ >> #endif >> >> >> -/*--- >> - * Physical Memory Map >> - */ >> -#define DMC1_MEM_CFG 0x80010012 /* Chip1, Burst4, Row/Column bit */ >> -#define DMC1_MEM_CFG2 0xB45 >> -#define DMC1_CHIP0_CFG 0x150F8 /* 0x4000_ ~ 0x43ff_ (64MB) >> */ >> -#define DMC_DDR_32_CFG 0x0 /* 32bit, DDR */ >> - >> -/* Memory Parameters */ >> -/* DDR Parameters */ >> -#define DDR_tREFRESH 7800/* ns */ >> -#define DDR_
[U-Boot] [PATCH] samsung: move DRAM parameters
Move the definitions of DRAM parameters from SoC description (s3c6400.h) to board description (smdk6400.h). DRAM parameters are rather board-specific than SoC specific. According to the current source, one may have to change the definitions in s3c6400.h in addition to creating the new board description whenever he wants to add support for a new board based on s3c6400. I don't think this meets the U-Boot policy of separating SoC description and board description. There will be no observable changes in operation. It's just to make it easier to add support for new boards. Signed-off-by: Seunghyeon Rhee --- include/configs/smdk6400.h | 21 + include/s3c6400.h | 21 - 2 files changed, 21 insertions(+), 21 deletions(-) diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h index f6e1221..a2b46fd 100644 --- a/include/configs/smdk6400.h +++ b/include/configs/smdk6400.h @@ -309,4 +309,25 @@ # error "usb_ohci.c is currently broken with MMU enabled." #endif +/*--- + * Physical Memory Map + */ +#define DMC1_MEM_CFG 0x80010012 /* Chip1, Burst4, Row/Column bit */ +#define DMC1_MEM_CFG2 0xB45 +#define DMC1_CHIP0_CFG 0x150F8 /* 0x4000_ ~ 0x43ff_ (64MB) */ +#define DMC_DDR_32_CFG 0x0 /* 32bit, DDR */ + +/* Memory Parameters */ +/* DDR Parameters */ +#define DDR_tREFRESH 7800/* ns */ +#define DDR_tRAS 45 /* ns (min: 45ns)*/ +#define DDR_tRC68 /* ns (min: 67.5ns)*/ +#define DDR_tRCD 23 /* ns (min: 22.5ns)*/ +#define DDR_tRFC 80 /* ns (min: 80ns)*/ +#define DDR_tRP23 /* ns (min: 22.5ns)*/ +#define DDR_tRRD 15 /* ns (min: 15ns)*/ +#define DDR_tWR15 /* ns (min: 15ns)*/ +#define DDR_tXSR 120 /* ns (min: 120ns)*/ +#define DDR_CASL 3 /* CAS Latency 3 */ + #endif /* __CONFIG_H */ diff --git a/include/s3c6400.h b/include/s3c6400.h index e527c08..34d0d15 100644 --- a/include/s3c6400.h +++ b/include/s3c6400.h @@ -814,27 +814,6 @@ #endif -/*--- - * Physical Memory Map - */ -#define DMC1_MEM_CFG 0x80010012 /* Chip1, Burst4, Row/Column bit */ -#define DMC1_MEM_CFG2 0xB45 -#define DMC1_CHIP0_CFG 0x150F8 /* 0x4000_ ~ 0x43ff_ (64MB) */ -#define DMC_DDR_32_CFG 0x0 /* 32bit, DDR */ - -/* Memory Parameters */ -/* DDR Parameters */ -#define DDR_tREFRESH 7800/* ns */ -#define DDR_tRAS 45 /* ns (min: 45ns)*/ -#define DDR_tRC68 /* ns (min: 67.5ns)*/ -#define DDR_tRCD 23 /* ns (min: 22.5ns)*/ -#define DDR_tRFC 80 /* ns (min: 80ns)*/ -#define DDR_tRP23 /* ns (min: 22.5ns)*/ -#define DDR_tRRD 15 /* ns (min: 15ns)*/ -#define DDR_tWR15 /* ns (min: 15ns)*/ -#define DDR_tXSR 120 /* ns (min: 120ns)*/ -#define DDR_CASL 3 /* CAS Latency 3 */ - /* * mDDR memory configuration */ -- 1.6.2.5 -- Seunghyeon Rhee, Ph.D. / Director LPM Technology Inc. T +82-70-8255-6007 F +82-2-6442-6462 M +82-10-2790-0657 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] NET: Fix MAC addr handling for smc911x
This patch turns off MAC address mismatch warning when
optional eeprom programmed with MAC address is not available.
In that case, smc911x's MAC address register has its default
value ff:ff:ff:ff:ff:ff and it's not a valid address. This
makes eth_initialize() show the warning which has no
meaningful information while environment variable ethaddr
overrides the address read from the register. If there's no
eeprom and the value of MAC address register is not valid
after initialization, dev->enetaddr had better not be updated
and maintain its initial value 00:00:00:00:00:00, which I
think is what eth_initialize() expects. This is not a bug fix.
Even without this patch, the driver works fine. It's just for
enhancing the way of displaying messages.
Signed-off-by: Seunghyeon Rhee
---
drivers/net/smc911x.c | 15 +--
1 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/net/smc911x.c b/drivers/net/smc911x.c
index c50758e..3244850 100644
--- a/drivers/net/smc911x.c
+++ b/drivers/net/smc911x.c
@@ -257,12 +257,15 @@ int smc911x_initialize(u8 dev_num, int base_addr)
addrh = smc911x_get_mac_csr(dev, ADDRH);
addrl = smc911x_get_mac_csr(dev, ADDRL);
- dev->enetaddr[0] = addrl;
- dev->enetaddr[1] = addrl >> 8;
- dev->enetaddr[2] = addrl >> 16;
- dev->enetaddr[3] = addrl >> 24;
- dev->enetaddr[4] = addrh;
- dev->enetaddr[5] = addrh >> 8;
+ if (!(addrl == 0x && addrh == 0x)) {
+ /* address is obtained from optional eeprom */
+ dev->enetaddr[0] = addrl;
+ dev->enetaddr[1] = addrl >> 8;
+ dev->enetaddr[2] = addrl >> 16;
+ dev->enetaddr[3] = addrl >> 24;
+ dev->enetaddr[4] = addrh;
+ dev->enetaddr[5] = addrh >> 8;
+ }
dev->init = smc911x_init;
dev->halt = smc911x_halt;
--
1.6.2.5
--
Seunghyeon Rhee, Ph.D. / Director
LPM Technology Inc.
T +82-70-8255-6007 F +82-2-6442-6462
M +82-10-2790-0657
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] S3C6400/SMDK6400: fix stack_setup in start.S
Dear Minkyu Kang, 2009/11/2 Minkyu Kang : > Dear Seunghyeon Rhee > > 2009/10/31 "Seunghyeon Rhee (이승현)" : >> stack_setup is modified to initialize the stack on the correct address in >> DRAM accroding to the typical memory configuration described in >> README and the related CONFIG_* macro definitions. This makes macro >> CONFIG_MEMORY_UPPER_CODE no longer necessry. This was introduced >> and used only by this board for some unclear reason. The definition of >> this macro is removed because it's not referenced elsewhere. >> >> Signed-off-by: Seunghyeon Rhee >> --- >> cpu/arm1176/start.S|7 +-- >> include/configs/smdk6400.h |2 -- >> 2 files changed, 1 insertions(+), 8 deletions(-) >> >> diff --git a/cpu/arm1176/start.S b/cpu/arm1176/start.S >> index cb891df..1ecb3b9 100644 >> --- a/cpu/arm1176/start.S >> +++ b/cpu/arm1176/start.S >> @@ -241,16 +241,11 @@ mmu_enable: >> skip_hw_init: >> /* Set up the stack*/ >> stack_setup: >> -#ifdef CONFIG_MEMORY_UPPER_CODE >> -ldrsp, =(CONFIG_SYS_UBOOT_BASE + CONFIG_SYS_UBOOT_SIZE - 0xc) >> -#else >> -ldrr0, _TEXT_BASE/* upper 128 KiB: relocated uboot */ >> +ldrr0, =CONFIG_SYS_UBOOT_BASE/* base of copy in DRAM*/ > > this change is unnecessary, TEXT_BASE and CONFIG_SYS_UBOOT_BASE must be same. That's true for the body of U-Boot but not for SPL, where TEXT_BASE is defined to be '0'. Please refer to board/samsung/smdk6400/config.mk. On the other hand, CONFIG_SYS_UBOOT_BASE is always dependent on DRAM's base. In SPL, the base of the code should be '0' (the steppingstone memory) and then the stack is located below '0' - not a valid area. If SPL itself requires no stack, it should be no problem. But start.S calls nand_boot function right after the stack is badly set up in the air. My test results are like the following: with CONFIG_MEMORY_UPPER_CODE defined : OK with CONFIG_MEMORY_UPPER_CODE undefined : - SPL bypassed (U-Boot downloaded to DRAM directly by USB monitor program) : OK - through SPL : Not OK (seems to fail for SPL downloading the code to DRAM) I think CONFIG_MEMORY_UPPER_CODE was tested for the case it's defined but not enough for the case it's not defined. Would you check it again? > btw, is there need CONFIG_SYS_UBOOT_BASE define? > If you are not sure, why did you use CONFIG_SYS_UBOOT_BASE for the case CONFIG_MEMORY_UPPER_CODE is defined while you use TEXT_BASE otherwise? I think the unnecessary macro definition here is not CONFIG_..._BASE but CONFIG_..._CODE. TEXT_BASE and CONFIG_..._BASE have their own meanings and so both are necessary. Best regards, Seunghyeon >> subr0, r0, #CONFIG_SYS_MALLOC_LEN/* malloc >> area */ >> subr0, r0, #CONFIG_SYS_GBL_DATA_SIZE /* >> bdinfo*/ >> subsp, r0, #12/* leave 3 words for abort-stack*/ >> >> -#endif >> - >> clear_bss: >> ldrr0, _bss_start/* find start of bss segment*/ >> ldrr1, _bss_end/* stop here*/ >> diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h >> index f6e1221..f644cd2 100644 >> --- a/include/configs/smdk6400.h >> +++ b/include/configs/smdk6400.h >> @@ -49,8 +49,6 @@ >> #define CONFIG_ENABLE_MMU >> #endif >> >> -#define CONFIG_MEMORY_UPPER_CODE >> - >> #define CONFIG_SETUP_MEMORY_TAGS >> #define CONFIG_CMDLINE_TAG >> #define CONFIG_INITRD_TAG >> -- >> 1.6.2.5 >> >> >> -- >> Seunghyeon Rhee, Ph.D. / Director >> LPM Technology Inc. >> T +82-70-8255-6007 F +82-2-6442-6462 >> M +82-10-2790-0657 >> ___ >> U-Boot mailing list >> U-Boot@lists.denx.de >> http://lists.denx.de/mailman/listinfo/u-boot >> > > Thanks for patch :) > Minkyu Kang > -- > from. prom. > www.promsoft.net > ___ > U-Boot mailing list > U-Boot@lists.denx.de > http://lists.denx.de/mailman/listinfo/u-boot > -- Seunghyeon Rhee, Ph.D. / Director LPM Technology Inc. T +82-70-8255-6007 F +82-2-6442-6462 M +82-10-2790-0657 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] S3C6400/SMDK6400: fix stack_setup in start.S
stack_setup is modified to initialize the stack on the correct address in DRAM accroding to the typical memory configuration described in README and the related CONFIG_* macro definitions. This makes macro CONFIG_MEMORY_UPPER_CODE no longer necessry. This was introduced and used only by this board for some unclear reason. The definition of this macro is removed because it's not referenced elsewhere. Signed-off-by: Seunghyeon Rhee --- cpu/arm1176/start.S|7 +-- include/configs/smdk6400.h |2 -- 2 files changed, 1 insertions(+), 8 deletions(-) diff --git a/cpu/arm1176/start.S b/cpu/arm1176/start.S index cb891df..1ecb3b9 100644 --- a/cpu/arm1176/start.S +++ b/cpu/arm1176/start.S @@ -241,16 +241,11 @@ mmu_enable: skip_hw_init: /* Set up the stack*/ stack_setup: -#ifdef CONFIG_MEMORY_UPPER_CODE -ldrsp, =(CONFIG_SYS_UBOOT_BASE + CONFIG_SYS_UBOOT_SIZE - 0xc) -#else -ldrr0, _TEXT_BASE/* upper 128 KiB: relocated uboot */ +ldrr0, =CONFIG_SYS_UBOOT_BASE/* base of copy in DRAM*/ subr0, r0, #CONFIG_SYS_MALLOC_LEN/* malloc area */ subr0, r0, #CONFIG_SYS_GBL_DATA_SIZE /* bdinfo*/ subsp, r0, #12/* leave 3 words for abort-stack*/ -#endif - clear_bss: ldrr0, _bss_start/* find start of bss segment*/ ldrr1, _bss_end/* stop here*/ diff --git a/include/configs/smdk6400.h b/include/configs/smdk6400.h index f6e1221..f644cd2 100644 --- a/include/configs/smdk6400.h +++ b/include/configs/smdk6400.h @@ -49,8 +49,6 @@ #define CONFIG_ENABLE_MMU #endif -#define CONFIG_MEMORY_UPPER_CODE - #define CONFIG_SETUP_MEMORY_TAGS #define CONFIG_CMDLINE_TAG #define CONFIG_INITRD_TAG -- 1.6.2.5 -- Seunghyeon Rhee, Ph.D. / Director LPM Technology Inc. T +82-70-8255-6007 F +82-2-6442-6462 M +82-10-2790-0657 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please check if the patch for SMSC LAN9220 is missing
There were two patches submitted to add support for SMSC LAN9220 and
LAN9221.
The latter (more recent one) has been applied but the former hasn't yet.
Refer to the
following and check please.
Regards,
Seunghyeon Rhee
Thu Apr 23 07:36:25 CEST 2009
> Daniel Mack wrote:
> > Signed-off-by: Daniel Mack
> > Cc: Sascha Hauer
> > ---
> > drivers/net/smc911x.h |2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
> > index 80d2ce0..2b01cf5 100644
> > --- a/drivers/net/smc911x.h
> > +++ b/drivers/net/smc911x.h
> > @@ -382,6 +382,7 @@ static inline void smc911x_reg_write(u32 addr,
> u32 val)
> > #define CHIP_92160x116a
> > #define CHIP_92170x117a
> > #define CHIP_92180x118a
> > +#define CHIP_92200x9220
> >
> > struct chip_id {
> > u16 id;
> > @@ -398,6 +399,7 @@ static const struct chip_id chip_ids[] = {
> > { CHIP_9216, "LAN9216" },
> > { CHIP_9217, "LAN9217" },
> > { CHIP_9218, "LAN9218" },
> > +{ CHIP_9220, "LAN9220" },
> > { 0, NULL },
> > };
> >
> >
> Applied to net/next branch.
>
> thanks,
> Ben
Fri Jul 10 08:21:31 CEST 2009
> Andreas Pretzsch wrote:
> > Signed-off-by: Andreas Pretzsch
> > ---
> > drivers/net/smc911x.h |2 ++
> > 1 files changed, 2 insertions(+), 0 deletions(-)
> >
> > diff --git a/drivers/net/smc911x.h b/drivers/net/smc911x.h
> > index 80d2ce0..c14003c 100644
> > --- a/drivers/net/smc911x.h
> > +++ b/drivers/net/smc911x.h
> > @@ -382,6 +382,7 @@ static inline void smc911x_reg_write(u32 addr,
> u32 val)
> > #define CHIP_92160x116a
> > #define CHIP_92170x117a
> > #define CHIP_92180x118a
> > +#define CHIP_92210x9221
> >
> > struct chip_id {
> > u16 id;
> > @@ -398,6 +399,7 @@ static const struct chip_id chip_ids[] = {
> > { CHIP_9216, "LAN9216" },
> > { CHIP_9217, "LAN9217" },
> > { CHIP_9218, "LAN9218" },
> > +{ CHIP_9221, "LAN9221" },
> > { 0, NULL },
> > };
> >
> >
> Applied to net repo.
>
> thanks,
> Ben
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
